Hi,
I have some trouble with the ADC on the LPC55S16.
Our usecase:
For easy integrating in our current codebase, we want to:
When I implemented this, the ADC values were jumping all over the place, like they ended up in the wrong (random) ADC variables.
E.g.: when I did 3 channels (ADC0, ADC1, ADC2), the results were like:
valueADC0 | valueADC1 | valueADC2 |
ADC1 | ADC0 | ADC2 |
ADC0 | ADC2 | ADC1 |
ADC2 | ADC1 | ADC0 |
ADC1 | ADC0 | ADC2 |
ADC0 | ADC2 | ADC1 |
So I tried to reproduce this on me LPCXpresso55S16 development board.
I used the lpadc_temperature_measurement example as basis, with the following changes:
After those changes the example still worked correctly (although temperature measurement needs some additional work, as there is a lot of digital noise due to low resolution of the vbe ADC values, but that's another topic):
Now I added ADC channel ADC0_0 (PIO0_23):
This is what I get:
As you can see the first temperature result looks OK, but after that it's way off.
(I didn't check the ADC0_0 result, but that also looks off, as nothing is connected to the pin yet)
I attached my MCUXpresso project, can you please have a look what I'm doing wrong?
I can't find any example using multiple channels or ADC commands.
I can't figure it out...
It looks like there's something going wrong in the FIFO, but I can only see the top value...
Thanks in advance.
Best regards
Solved! Go to Solution.
Hi Alice,
thanks for your reply.
In my example I have different commands and triggers for each channel, and I also do call seperate triggers.
Anyway, I found the issue:
in the past we found that a trigger was missed somehow occasionally.
This resulted in an infinite wait for the conversion result (with ultimately a watchdog reset).
We fixed this by adding a timeout for the while loop which gets the conversion result.
We set the timeout max at 255 cycles, which is good enough for normal ADC measurements.
However, I found that the internal temperature measurement can take about 4500 cycles (CPU running at 96MHz and ADC clock of 4MHz).
I suppose this is probably because of the hardware averaging used by the internal temperature measurement (we do not do HW averaging on the normal ADC measurements).
So the conversion while loop for the internal temp measurement was aborted due to the timeout, but the FIFO was later on still filled with the temperature values (vbe1/vbe8).
And those values ended up later on when the normal ADC channel measurement is triggered.
I now fixed it by increasing the timeout max to 10000.
Thanks for your effort.
Hello,
There is Multiple ADC demo you can compare to have a look :
BR
Alice
Hi,
thanks, I found that one indeed.
But:
BR, Jan Pieter
Hello,
You said want individual triggers for each measurement, from your result , I think in your project, one triggered three channels.
BR
Alice
Hi Alice,
thanks for your reply.
In my example I have different commands and triggers for each channel, and I also do call seperate triggers.
Anyway, I found the issue:
in the past we found that a trigger was missed somehow occasionally.
This resulted in an infinite wait for the conversion result (with ultimately a watchdog reset).
We fixed this by adding a timeout for the while loop which gets the conversion result.
We set the timeout max at 255 cycles, which is good enough for normal ADC measurements.
However, I found that the internal temperature measurement can take about 4500 cycles (CPU running at 96MHz and ADC clock of 4MHz).
I suppose this is probably because of the hardware averaging used by the internal temperature measurement (we do not do HW averaging on the normal ADC measurements).
So the conversion while loop for the internal temp measurement was aborted due to the timeout, but the FIFO was later on still filled with the temperature values (vbe1/vbe8).
And those values ended up later on when the normal ADC channel measurement is triggered.
I now fixed it by increasing the timeout max to 10000.
Thanks for your effort.