I'm seeing an intermittent problem when reading the ADC on an LPC1768.
I'm reading ADC channel 1 in software-start mode and 99% of the time
I'm seeing results within range. For this test, I'm reading a voltage
divider that divides the 3.3v reference by 2, so I'm expecting to see
something in the 2048 range, which I do 99% of the time. Occasionally, I see
4095 returned when I read channel 1.
I have the ADC clkdiv set to 2, which divides the 25 Mhz pclk by 3 down to 8.3
Mhz, which is less than the 13 MHz max stated in the user's guide. I have
ADC channel 1 set to the ADC function in the Pinsel register and have neither
pull-up or pull-down enabled.
I have BURST=0 in AD0CR and start a conversion by writing 001 to the start bits
in AD0CR.
When the conversion is complete and I get the expected value, the DONE bit, but
not OVERRUN, is set in the ADC data register. When a conversion is complete and
I get the bogus 0xfff result, OVERRUN is always set in the data register.
The manual says this about the OVERRUN bit: "This bit is 1 in burst mode if the
results of one or more conversions was (were) lost
and overwritten before the conversion that produced the result in the RESULT
bits."
I'm not using BURST mode, so what does having the OVERRUN bit set in the
data register mean in this case? I'm not initiating another conversion
until the previous one completes (by waiting for DONE to be set in the data
register).
ADC Issue
Started by ●January 29, 2012
Reply by ●January 29, 20122012-01-29
I just finished some ADC code on the similar LPC1766, it works perfect. I am
using an IRQ service routine. Overrun and Done flags are always the same.
Chris.
Chris.
Reply by ●February 10, 20122012-02-10
--- In l..., "Chris" wrote:
>
> I just finished some ADC code on the similar LPC1766, it works perfect. I am using an IRQ service routine. Overrun and Done flags are always the same.
I implemented an interrupt-driven version of my LPC1768 ADC driver and I'm seeing the same issue I saw with the polling version.
I put come code in the driver to count the number of conversions for each of the 4096 possible steps and connected channel 0 to a resistor voltage divider dividing the Vcc (3.3v) to the processor by 2. As expected, I'm seeing a roughly Gaussian distribution of counts centered around 2048 counts.
I'm sampling the voltage on channel 0 four times a second. Every hour I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few buckets right below the 4095 bucket.
I connected a scope to the input of the ADC and trigger on an output port connected to another scope channel that goes high when the code detects an ADC count outside the expected range. When one of these triggers occurs, I don't see anything on the input to the ADC that would cause a conversion up in the 4095 range. The scope trace shows the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope with 4GS/sec sampling rate).
I tried ADC channel 1 and see the same results.
Any ideas? This is driving me crazy and I'm just about to say to hell with it and use an external ADC.
>
> I just finished some ADC code on the similar LPC1766, it works perfect. I am using an IRQ service routine. Overrun and Done flags are always the same.
I implemented an interrupt-driven version of my LPC1768 ADC driver and I'm seeing the same issue I saw with the polling version.
I put come code in the driver to count the number of conversions for each of the 4096 possible steps and connected channel 0 to a resistor voltage divider dividing the Vcc (3.3v) to the processor by 2. As expected, I'm seeing a roughly Gaussian distribution of counts centered around 2048 counts.
I'm sampling the voltage on channel 0 four times a second. Every hour I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few buckets right below the 4095 bucket.
I connected a scope to the input of the ADC and trigger on an output port connected to another scope channel that goes high when the code detects an ADC count outside the expected range. When one of these triggers occurs, I don't see anything on the input to the ADC that would cause a conversion up in the 4095 range. The scope trace shows the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope with 4GS/sec sampling rate).
I tried ADC channel 1 and see the same results.
Any ideas? This is driving me crazy and I'm just about to say to hell with it and use an external ADC.
Reply by ●February 10, 20122012-02-10
To isolate the problem, can you lower the ADC clock
down to 4~6Mhz range and see what happens?
It's strange to see overrun bit set in non-burst mode.
Tom
--- In l..., "Jerry" wrote:
>
> --- In l..., "Chris" wrote:
> >
> > I just finished some ADC code on the similar LPC1766, it works perfect. I am using an IRQ service routine. Overrun and Done flags are always the same.
> I implemented an interrupt-driven version of my LPC1768 ADC driver and I'm seeing the same issue I saw with the polling version.
>
> I put come code in the driver to count the number of conversions for each of the 4096 possible steps and connected channel 0 to a resistor voltage divider dividing the Vcc (3.3v) to the processor by 2. As expected, I'm seeing a roughly Gaussian distribution of counts centered around 2048 counts.
>
> I'm sampling the voltage on channel 0 four times a second. Every hour I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few buckets right below the 4095 bucket.
>
> I connected a scope to the input of the ADC and trigger on an output port connected to another scope channel that goes high when the code detects an ADC count outside the expected range. When one of these triggers occurs, I don't see anything on the input to the ADC that would cause a conversion up in the 4095 range. The scope trace shows the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope with 4GS/sec sampling rate).
>
> I tried ADC channel 1 and see the same results.
>
> Any ideas? This is driving me crazy and I'm just about to say to hell with it and use an external ADC.
>
down to 4~6Mhz range and see what happens?
It's strange to see overrun bit set in non-burst mode.
Tom
--- In l..., "Jerry" wrote:
>
> --- In l..., "Chris" wrote:
> >
> > I just finished some ADC code on the similar LPC1766, it works perfect. I am using an IRQ service routine. Overrun and Done flags are always the same.
> I implemented an interrupt-driven version of my LPC1768 ADC driver and I'm seeing the same issue I saw with the polling version.
>
> I put come code in the driver to count the number of conversions for each of the 4096 possible steps and connected channel 0 to a resistor voltage divider dividing the Vcc (3.3v) to the processor by 2. As expected, I'm seeing a roughly Gaussian distribution of counts centered around 2048 counts.
>
> I'm sampling the voltage on channel 0 four times a second. Every hour I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few buckets right below the 4095 bucket.
>
> I connected a scope to the input of the ADC and trigger on an output port connected to another scope channel that goes high when the code detects an ADC count outside the expected range. When one of these triggers occurs, I don't see anything on the input to the ADC that would cause a conversion up in the 4095 range. The scope trace shows the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope with 4GS/sec sampling rate).
>
> I tried ADC channel 1 and see the same results.
>
> Any ideas? This is driving me crazy and I'm just about to say to hell with it and use an external ADC.
>
Reply by ●February 10, 20122012-02-10
Hello Jerry,
Saturday, February 11, 2012, 1:01:23 AM, you wrote:
J> Any ideas? This is driving me crazy and I'm just about to say to
J> hell with it and use an external ADC.
ADC issues with LPC1768 have been often discussed on mbed forums.
Various theories, workarounds and solutions have been suggested. Check
these links:
http://mbed.org/users/chris/notebook/Getting-best-ADC-performance/
http://www.nxp.com/documents/application_note/AN10974.pdf
http://mbed.org/forum/bugs-suggestions/topic/1514/
http://mbed.org/forum/mbed/topic/1866/
http://mbed.org/forum/mbed/topic/2919/
--
WBR,
Igor mailto:s...@mail.ru
Saturday, February 11, 2012, 1:01:23 AM, you wrote:
J> Any ideas? This is driving me crazy and I'm just about to say to
J> hell with it and use an external ADC.
ADC issues with LPC1768 have been often discussed on mbed forums.
Various theories, workarounds and solutions have been suggested. Check
these links:
http://mbed.org/users/chris/notebook/Getting-best-ADC-performance/
http://www.nxp.com/documents/application_note/AN10974.pdf
http://mbed.org/forum/bugs-suggestions/topic/1514/
http://mbed.org/forum/mbed/topic/1866/
http://mbed.org/forum/mbed/topic/2919/
--
WBR,
Igor mailto:s...@mail.ru
Reply by ●February 11, 20122012-02-11
Il 11/02/2012 01:01, Jerry ha scritto:
First of all disable jtag and then repeat the test.
If there are still values on 0xffff if not program adc to convert only
one channel, better no 0 and 7 channels, try with channel 4 for instance
and repeat the tests. Polling or irq method are the same for these tests.
If you can answer with the result I would try to help you.
>
>
> --- In l... ,
> "Chris" wrote:
> >
> > I just finished some ADC code on the similar LPC1766, it works
> perfect. I am using an IRQ service routine. Overrun and Done flags are
> always the same.
>
> I implemented an interrupt-driven version of my LPC1768 ADC driver and
> I'm seeing the same issue I saw with the polling version.
>
> I put come code in the driver to count the number of conversions for
> each of the 4096 possible steps and connected channel 0 to a resistor
> voltage divider dividing the Vcc (3.3v) to the processor by 2. As
> expected, I'm seeing a roughly Gaussian distribution of counts
> centered around 2048 counts.
>
> I'm sampling the voltage on channel 0 four times a second. Every hour
> I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few
> buckets right below the 4095 bucket.
>
> I connected a scope to the input of the ADC and trigger on an output
> port connected to another scope channel that goes high when the code
> detects an ADC count outside the expected range. When one of these
> triggers occurs, I don't see anything on the input to the ADC that
> would cause a conversion up in the 4095 range. The scope trace shows
> the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope
> with 4GS/sec sampling rate).
>
> I tried ADC channel 1 and see the same results.
>
> Any ideas? This is driving me crazy and I'm just about to say to hell
> with it and use an external ADC.
First of all disable jtag and then repeat the test.
If there are still values on 0xffff if not program adc to convert only
one channel, better no 0 and 7 channels, try with channel 4 for instance
and repeat the tests. Polling or irq method are the same for these tests.
If you can answer with the result I would try to help you.
>
>
> --- In l... ,
> "Chris" wrote:
> >
> > I just finished some ADC code on the similar LPC1766, it works
> perfect. I am using an IRQ service routine. Overrun and Done flags are
> always the same.
>
> I implemented an interrupt-driven version of my LPC1768 ADC driver and
> I'm seeing the same issue I saw with the polling version.
>
> I put come code in the driver to count the number of conversions for
> each of the 4096 possible steps and connected channel 0 to a resistor
> voltage divider dividing the Vcc (3.3v) to the processor by 2. As
> expected, I'm seeing a roughly Gaussian distribution of counts
> centered around 2048 counts.
>
> I'm sampling the voltage on channel 0 four times a second. Every hour
> I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few
> buckets right below the 4095 bucket.
>
> I connected a scope to the input of the ADC and trigger on an output
> port connected to another scope channel that goes high when the code
> detects an ADC count outside the expected range. When one of these
> triggers occurs, I don't see anything on the input to the ADC that
> would cause a conversion up in the 4095 range. The scope trace shows
> the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope
> with 4GS/sec sampling rate).
>
> I tried ADC channel 1 and see the same results.
>
> Any ideas? This is driving me crazy and I'm just about to say to hell
> with it and use an external ADC.
Reply by ●February 11, 20122012-02-11
I have a stupid question... Are you sure that VREFP is connected to a valid
supply voltage?
Olivier Gautherot
o...@gautherot.net
On Sat, Feb 11, 2012 at 10:07 AM, M. Manca wrote:
> **
> Il 11/02/2012 01:01, Jerry ha scritto:
> First of all disable jtag and then repeat the test.
> If there are still values on 0xffff if not program adc to convert only
> one channel, better no 0 and 7 channels, try with channel 4 for instance
> and repeat the tests. Polling or irq method are the same for these tests.
> If you can answer with the result I would try to help you.
> >
> >
> >
> >
> > --- In l... ,
> > "Chris" wrote:
> > >
> > > I just finished some ADC code on the similar LPC1766, it works
> > perfect. I am using an IRQ service routine. Overrun and Done flags are
> > always the same.
> >
> > I implemented an interrupt-driven version of my LPC1768 ADC driver and
> > I'm seeing the same issue I saw with the polling version.
> >
> > I put come code in the driver to count the number of conversions for
> > each of the 4096 possible steps and connected channel 0 to a resistor
> > voltage divider dividing the Vcc (3.3v) to the processor by 2. As
> > expected, I'm seeing a roughly Gaussian distribution of counts
> > centered around 2048 counts.
> >
> > I'm sampling the voltage on channel 0 four times a second. Every hour
> > I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few
> > buckets right below the 4095 bucket.
> >
> > I connected a scope to the input of the ADC and trigger on an output
> > port connected to another scope channel that goes high when the code
> > detects an ADC count outside the expected range. When one of these
> > triggers occurs, I don't see anything on the input to the ADC that
> > would cause a conversion up in the 4095 range. The scope trace shows
> > the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope
> > with 4GS/sec sampling rate).
> >
> > I tried ADC channel 1 and see the same results.
> >
> > Any ideas? This is driving me crazy and I'm just about to say to hell
> > with it and use an external ADC.
> >
> >
>
>
>
supply voltage?
Olivier Gautherot
o...@gautherot.net
On Sat, Feb 11, 2012 at 10:07 AM, M. Manca wrote:
> **
> Il 11/02/2012 01:01, Jerry ha scritto:
> First of all disable jtag and then repeat the test.
> If there are still values on 0xffff if not program adc to convert only
> one channel, better no 0 and 7 channels, try with channel 4 for instance
> and repeat the tests. Polling or irq method are the same for these tests.
> If you can answer with the result I would try to help you.
> >
> >
> >
> >
> > --- In l... ,
> > "Chris" wrote:
> > >
> > > I just finished some ADC code on the similar LPC1766, it works
> > perfect. I am using an IRQ service routine. Overrun and Done flags are
> > always the same.
> >
> > I implemented an interrupt-driven version of my LPC1768 ADC driver and
> > I'm seeing the same issue I saw with the polling version.
> >
> > I put come code in the driver to count the number of conversions for
> > each of the 4096 possible steps and connected channel 0 to a resistor
> > voltage divider dividing the Vcc (3.3v) to the processor by 2. As
> > expected, I'm seeing a roughly Gaussian distribution of counts
> > centered around 2048 counts.
> >
> > I'm sampling the voltage on channel 0 four times a second. Every hour
> > I'm seeing around 17 counts in the 4095 bucket and 2-3 counts in a few
> > buckets right below the 4095 bucket.
> >
> > I connected a scope to the input of the ADC and trigger on an output
> > port connected to another scope channel that goes high when the code
> > detects an ADC count outside the expected range. When one of these
> > triggers occurs, I don't see anything on the input to the ADC that
> > would cause a conversion up in the 4095 range. The scope trace shows
> > the voltage solid at 1.65v with no glitches (I'm using a 500 MHz scope
> > with 4GS/sec sampling rate).
> >
> > I tried ADC channel 1 and see the same results.
> >
> > Any ideas? This is driving me crazy and I'm just about to say to hell
> > with it and use an external ADC.
> >
> >
>
>
>
Reply by ●February 11, 20122012-02-11
--- In l..., Igor Skochinsky wrote:
> ADC issues with LPC1768 have been often discussed on mbed forums.
> Various theories, workarounds and solutions have been suggested. Check
> these links:
Igor,
Those links were very helpful. Thanks.
I've tried several things, but nothing has really helped so far. Here's what I've tried:
1. Reducing the ADC clock to 6 MHz.
2. Grounding all unused ADC inputs.
3. Setting unused ADC inputs to GPIO outputs and driving them low.
4. Adding more bypass caps to various places on the board.
5. Adding a 2nd order low pass filter between the output of the resistor divider and the input of the ADC.
Not much improvement, if any, from the original configuration. I increased the sample rate to collect data more rapidly, and it shows a shotgun scattering of conversions from 0-4095 with the heaviest concentration of bad conversions at the high end near 4095.
The board I have is a NGX Technologies BlueBoard.
I'll try a MCP3204 I have sitting around tomorrow and see if I see the same pattern of noise and glitches.
> ADC issues with LPC1768 have been often discussed on mbed forums.
> Various theories, workarounds and solutions have been suggested. Check
> these links:
Igor,
Those links were very helpful. Thanks.
I've tried several things, but nothing has really helped so far. Here's what I've tried:
1. Reducing the ADC clock to 6 MHz.
2. Grounding all unused ADC inputs.
3. Setting unused ADC inputs to GPIO outputs and driving them low.
4. Adding more bypass caps to various places on the board.
5. Adding a 2nd order low pass filter between the output of the resistor divider and the input of the ADC.
Not much improvement, if any, from the original configuration. I increased the sample rate to collect data more rapidly, and it shows a shotgun scattering of conversions from 0-4095 with the heaviest concentration of bad conversions at the high end near 4095.
The board I have is a NGX Technologies BlueBoard.
I'll try a MCP3204 I have sitting around tomorrow and see if I see the same pattern of noise and glitches.
Reply by ●February 12, 20122012-02-12
Il 12/02/2012 04:44, Jerry ha scritto:
Try to disable jtag.
>
>
> --- In l... ,
> Igor Skochinsky wrote:
>
> > ADC issues with LPC1768 have been often discussed on mbed forums.
> > Various theories, workarounds and solutions have been suggested. Check
> > these links:
>
> Igor,
>
> Those links were very helpful. Thanks.
>
> I've tried several things, but nothing has really helped so far.
> Here's what I've tried:
>
> 1. Reducing the ADC clock to 6 MHz.
> 2. Grounding all unused ADC inputs.
> 3. Setting unused ADC inputs to GPIO outputs and driving them low.
> 4. Adding more bypass caps to various places on the board.
> 5. Adding a 2nd order low pass filter between the output of the
> resistor divider and the input of the ADC.
>
> Not much improvement, if any, from the original configuration. I
> increased the sample rate to collect data more rapidly, and it shows a
> shotgun scattering of conversions from 0-4095 with the heaviest
> concentration of bad conversions at the high end near 4095.
>
> The board I have is a NGX Technologies BlueBoard.
>
> I'll try a MCP3204 I have sitting around tomorrow and see if I see the
> same pattern of noise and glitches.
Try to disable jtag.
>
>
> --- In l... ,
> Igor Skochinsky wrote:
>
> > ADC issues with LPC1768 have been often discussed on mbed forums.
> > Various theories, workarounds and solutions have been suggested. Check
> > these links:
>
> Igor,
>
> Those links were very helpful. Thanks.
>
> I've tried several things, but nothing has really helped so far.
> Here's what I've tried:
>
> 1. Reducing the ADC clock to 6 MHz.
> 2. Grounding all unused ADC inputs.
> 3. Setting unused ADC inputs to GPIO outputs and driving them low.
> 4. Adding more bypass caps to various places on the board.
> 5. Adding a 2nd order low pass filter between the output of the
> resistor divider and the input of the ADC.
>
> Not much improvement, if any, from the original configuration. I
> increased the sample rate to collect data more rapidly, and it shows a
> shotgun scattering of conversions from 0-4095 with the heaviest
> concentration of bad conversions at the high end near 4095.
>
> The board I have is a NGX Technologies BlueBoard.
>
> I'll try a MCP3204 I have sitting around tomorrow and see if I see the
> same pattern of noise and glitches.
Reply by ●February 12, 20122012-02-12
--- In l..., "Jerry" wrote:
> --- In l..., Igor Skochinsky wrote:
>
> > ADC issues with LPC1768 have been often discussed on mbed forums.
> > Various theories, workarounds and solutions have been suggested. Check
> > these links:
>
> Igor,
>
> Those links were very helpful. Thanks.
>
> I've tried several things, but nothing has really helped so far. Here's what I've tried:
>
> 1. Reducing the ADC clock to 6 MHz.
> 2. Grounding all unused ADC inputs.
> 3. Setting unused ADC inputs to GPIO outputs and driving them low.
> 4. Adding more bypass caps to various places on the board.
> 5. Adding a 2nd order low pass filter between the output of the resistor divider and the input of the ADC.
>
> Not much improvement, if any, from the original configuration. I increased the sample rate to collect data more rapidly, and it shows a shotgun scattering of conversions from 0-4095 with the heaviest concentration of bad conversions at the high end near 4095.
>
> The board I have is a NGX Technologies BlueBoard.
>
> I'll try a MCP3204 I have sitting around tomorrow and see if I see the same pattern of noise and glitches.
I ran my data collection code overnight and collected a bunch of data that shows that the LPC1768 ADC will generate many thousands of bad conversions throughout the 4096 wide space, with the majority of the bad conversions closer to the 4095 end of the range.
I tried an MCP3208 (12-bit 8-channel SPI ADC) this morning. I plonked it on a solderless breadboard without bothering to ground any of the unused analog inputs, nor did I bother with a bypass cap on the IC. I then took the output of the resistor voltage divider via a 10cm jumper wire and connected it directly to channel 0 on the MCP3208.
I ran my test code on the LPC1768, and after 11.2 million conversions on the MCP3208 I see ZERO glitches or misconversions. All conversions fall between 2023-2066 and centered on 2048 in the classical Gaussian distribution.
So the question remains: why such poor performance with the LPC1768's built-in ADC? In its current state, it's nearly unusable without extensive filtering and averaging to reject the bogus conversions it's constantly spewing out.
> --- In l..., Igor Skochinsky wrote:
>
> > ADC issues with LPC1768 have been often discussed on mbed forums.
> > Various theories, workarounds and solutions have been suggested. Check
> > these links:
>
> Igor,
>
> Those links were very helpful. Thanks.
>
> I've tried several things, but nothing has really helped so far. Here's what I've tried:
>
> 1. Reducing the ADC clock to 6 MHz.
> 2. Grounding all unused ADC inputs.
> 3. Setting unused ADC inputs to GPIO outputs and driving them low.
> 4. Adding more bypass caps to various places on the board.
> 5. Adding a 2nd order low pass filter between the output of the resistor divider and the input of the ADC.
>
> Not much improvement, if any, from the original configuration. I increased the sample rate to collect data more rapidly, and it shows a shotgun scattering of conversions from 0-4095 with the heaviest concentration of bad conversions at the high end near 4095.
>
> The board I have is a NGX Technologies BlueBoard.
>
> I'll try a MCP3204 I have sitting around tomorrow and see if I see the same pattern of noise and glitches.
I ran my data collection code overnight and collected a bunch of data that shows that the LPC1768 ADC will generate many thousands of bad conversions throughout the 4096 wide space, with the majority of the bad conversions closer to the 4095 end of the range.
I tried an MCP3208 (12-bit 8-channel SPI ADC) this morning. I plonked it on a solderless breadboard without bothering to ground any of the unused analog inputs, nor did I bother with a bypass cap on the IC. I then took the output of the resistor voltage divider via a 10cm jumper wire and connected it directly to channel 0 on the MCP3208.
I ran my test code on the LPC1768, and after 11.2 million conversions on the MCP3208 I see ZERO glitches or misconversions. All conversions fall between 2023-2066 and centered on 2048 in the classical Gaussian distribution.
So the question remains: why such poor performance with the LPC1768's built-in ADC? In its current state, it's nearly unusable without extensive filtering and averaging to reject the bogus conversions it's constantly spewing out.
