|
|
View previous topic :: View next topic |
Author |
Message |
russk2txb
Joined: 30 Mar 2008 Posts: 109 Location: New Jersey
|
AD interrupt stops |
Posted: Tue Apr 01, 2008 8:51 pm |
|
|
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
|
|
Posted: Tue Apr 01, 2008 11:06 pm |
|
|
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
|
|
Posted: Wed Apr 02, 2008 2:13 am |
|
|
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
|
|
Posted: Wed Apr 02, 2008 10:49 am |
|
|
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
|
|
Posted: Wed Apr 02, 2008 10:52 am |
|
|
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
|
|
|
|
|
|
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
|