CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

AD interrupt stops

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

AD interrupt stops
PostPosted: Tue Apr 01, 2008 8:51 pm     Reply with quote

I'm using a PIC18F8720 dev kit. The breadboard has the DS1631 temperature chip and also has a MCP4822 dual 12 bit dac. I'm reading back the dac values and the value of the on board pot via several ADC channels.

For each channel the program does an ADC_START_ONLY and then the #int_ad picks up the result and adds it to an accumulator. The main loop then checks to see if enough accumulations have been done. If not, another one is started (for the same channel). After a number of accumulations the value is averaged by the main loop and saved. Then the next active adc channel is initialized and the process repeats.

Meanwhile a PC is communicating with the PIC via the UART, and periodically requesting the values of DAC, Pot, and Temperature. The rda interupt is used to receive commands from the PC and received commands are used by the main loop to set DAC values, and request results. Results are sent back in ASCII by use of fprintf (stream, ...).

This scheme worked great on an older project with a different PIC, but now something very strange is happening. After a few seconds of operation the AD interrupt suddenly stops working - for several seconds, and then starts up again. This happens continuously for perhaps two or three minutes and then the AD interrupt stops for good (until reset anyway). However the RDA int still works and communications are not impaired. I cannot figure out what is causing this. I have checked and rechecked the program looking for such things as overrun buffers, bad RS-232 data, bad formatting of the printf statements, etc, with no success.

And this loss of AD int only occurs while the PC is requesting data periodically (once per second). If I turn off the PC connection, the ADC interrupt continues to work forever. And the same thing happens if I try to use a timer interrupt.


I originally posted this on the MicroChip forum and did not receive an answer there, so trying here. However since then I discovered that if I make the AD interrupt HIGH, then it will not stop. But this should not be necessary??!!??

Does anyone have any ideas why this is happening. The errata sheet on the 18F8720 indicates several problems that may or may not be responsible.

Thanks, Russ
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 01, 2008 11:06 pm     Reply with quote

1. Post a short program that shows the problem. Strip it down as much
as possible. It must be compilable without errors. Post all #include,
#fuses, and #use statements. Try to make it really short. For
example, if you can demonstrate the problem by leaving out the
code for the MCP4822 and DS1631, then do so. The shorter the better.

2. Post your compiler version.
Ttelmah
Guest







PostPosted: Wed Apr 02, 2008 2:13 am     Reply with quote

First, I'd really suggest not using the INT_AD.
The thing is that the time taken to enter and leave an interrupt, is _longer_, than the time needed for the ADC to acquire. So INT_AD, just wastes processor time...
The only real reasons to use INT_AD, are:
1) If you trigger the ADC, via a CCP. Then the interrupt occurs when the conversion finishes, allowing timed operation of the ADC, independant of the main code. You might want to consider this.
2) If you use the 'sleep' ability to perform the ADC conversion, where the interrupt allows you to wake after the conversion completes.
Otherwise 'INT_AD', is a waste of space, and time....

Now, having said that, instead to look at your actual problem.
What silicon revision have you got?. The A3 revision of the 8720, has a really nasty bug, which can cause instructions to behave incorrectly, almost at random, in some code. It is so nasty, that if you have got this revision chip, get rid of it... There are some other erratas on this chip, but this one is the real 'nasty'...

Best Wishes
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

PostPosted: Wed Apr 02, 2008 10:49 am     Reply with quote

How can I find out the silicon revision? The actual chip on this CCS development kit has a white label glued to the top.

Thanks, Russ
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Apr 02, 2008 10:52 am     Reply with quote

If you have MPLAB and an ICD2, the silicon revision is reported when
you give MPLAB the "connect" command in the Programmer menu.
Example for a 16F877:
Quote:

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to target
Target Device PIC16F877 found, revision = b8
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group