I'm using the LPC11U68, and am seeing rather bad ADC performance. If I run a precision ramp into the input to collect the transfer function, I see that it plateaus at 8 counts before every 64 count boundary, and then jumps up to the boundary. So for example, the ramp will be clean and one to one from 0 to 56, and then the ADC continues to return 56 for 8 steps, and then jumps to 64. Same thing happens at 120 through 128, 184 through 192, etc.
This has been the case with multiple samples of the chip.
Has anyone encountered this? Any ideas? I am running the chip at 3.3V, Ref at 2.5V, and doing the ADC calibration operation per the user manual.
Hi Marcschuman,
Please give me your ramp testing wave from the oscilloscope ASAP.
Kerry
We will do that when we can. But the person with access to the
equipment at this time is busy working with our customers that are
affected. And I am busy redesigning the product to eliminate the NXP ADC!
I also do not feel that a scope capture is necessary; as I've explained
carefully, the alignment of the jumps with specific 2^n boundaries of
the ADC output codes points overwhelmingly to the problem being inside
the ADC, not with the test ramp. We only created the test ramp to
investigate the cause of the problem that was already affecting our product.
We will however, send you the scope capture when we have time. We will
also try the test with the NXP eval board, to see if it is also present
with a different batch of the chips.
Thanks,
Marc
Hi Marcschuman,
Thank you for your reply!
Now, we also need to check these points.
1. You said you have test the specific voltage before.
Did you use the on board voltage, or the external voltage, which is not the same source of your MCU board?
Please try to test the external specific voltage(another power supply), if it is still in +/-1LSB, it will exclude the VDDA and VREF problem.
2. You also can check your VDDA, VREFH, whether it have the waveform when do the ADC conversion. You can use the precise power supply for the ADC circuit.
3. We have a application about the PCB layout and ADC circuit recommendations for LPC1100 and LPC1300, you can refer to it, whether your hardware meet the application's demand.
I have attached the application note, you can refer to it.
4. Input source wave is necessary to us, we must guarantee the input wave is really clean, and have no bounce.
Thanks a lot for your effort.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Kerry Zhou,
I have done more work on this and I believe that I now understand what is going on.
First, we set up our firmware and our ramp generator on your Xpresso eval board. With this configuration we found that the 8 count jumps *did not* occur. The data looked fine. This lead me to consider what the differences were between your eval board and our board. At first I thought that maybe it was the source impedance of our VREF supply. But in fact, that is not the problem. I am pretty sure now that the ADC performance issue is caused by the VREF being 2.5V. If I supply our board with a 3.3V VREF, through 100 ohms with a 10uF filter, the ADC performance is fine. If I change the VREF to 2.5V, with the same circuit configuration, the 8 count jumps are present.
We consider this performance to be very bad. It is true that the User Guide mentions that for best performance VREF should be the same as VDDA. But 8 missing counts is very poor performance indeed. And if a user wants an accurate voltage reference, it *has* to be lower than the available power supply voltage that is used to generate the reference! The datasheet gives no performance data at all for this common configuration. If we had been able to find out that with a 2.5V reference the ADC becomes effectively a 9 bit converter, we would have known that it would not work for our application....
Please try your test setup with a 2.5V reference and see what results you get. You will need, however, a quieter signal than what you showed in your previous postings. I would suggest that you divide the output of your signal generator by e.g. a factor of 10, and add a filter capacitor right at the ADC input. That way you should be able to get a quiet enough signal. You should see the jumps at every n*64 count boundary, so you only need to sweep say 100mV of the input range to see one.
Hi Marcschuman,
Really good news from your side.
What 2.5V you are using? Did you test your 2.5V, is it stable? Please use oscilloscope to check your VREFP and VREFHL, the source must stable, no interference.
From user manual:
When you use the 2.5V, did you meet this remark? Please also tell me how you get your VREFP, VREFN.
I can't test the DNL on my side now, my function waveform generator is just 8 bit, the source have the stage to jump up.
Besides, your problem is make sure not caused by the DNL, still need to check the VREFP, VREFL, and the input source.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I will send you the Excel file. How can I do that?
Hi Marcschuman,
Choose advanced editor, then zip your excel and attach it.
Hi Kerry,
One more thing that I would like to point out. If you look closely at the plot that I posted, you will see that where the vertical gap is, in fact the two segments overlap in the X dimension. If you look at the numerical data that I sent, you will see that what is happening is that the ADC output is jittering between e.g. 56 and 64 for several steps. This is exactly what one would expect if the ADC has as huge DNL error (many missing steps). The input and conversion noise is causing the output to jump between the two adjacent available codes--which are 8 counts apart.
I hope this will really convince you that it is not a case of dropped data points. The two discontinuous segments clearly overlap in time. And the codes 57 through 63 are *never* present.
The question is whether this is inherent in the chip hardware, or if there is some software mediated setup that is responsible.
Hi Marcschuman,
Please give me the orginal data in excel which plot the chart from step1 to step 550, thank you!
Best Regards,
Kerry
Hi Kerry,
I will see if I can have someone get a picture of the test ramp for you.
Our code is fairly complicated; the ADC is using the sequencer, which is triggered from one of the counter/timers. The data is read from the ADC buffers in an interrupt routine. I am very confident that that is all working correctly, and that we are not dropping any data. If I just sent you some parts of the project, you would not be able to verify that it is working correctly, because there are a lot of interactions between different modules. However, we are working on creating a simplified standalone program specifically to demonstrate this problem. It will take a while, as we are very busy right now.
Can you tell me, have there been multiple revisions of the chip? The parts we have are labeled:
LPC11U68JBD100
S4A551.1 05
ZSD15501A
Is it possible that this a bad version of the chip, or a bad datecode?
Hi Marcschuman,
I am totally understand you about the project complexity, that's why I give you my test project before, it is really a simple project.
If you have time, you also can try my project on your precise ADC input, that's will help both of our analysis(but you reject me before). You can test it when you are free, I am not in hurry. After you test it, just give me the printf points and the original wave.
I find you create a new case again, I will take it, and go on to follow this question.
About the multiple revision question, I will help you to check it with our according department when they are online, then will give you reply later.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Kerry,
Thank you for all the work that you have been doing to investigate this problem. Unfortunately I don't think that the test ramp you are using has enough resolution to see the problem that we are seeing. The discontinuity that is a problem for our application is 8 lsb's, with a reference voltage of 2.5V. So that is only about 5 mV. The step size of your ramp is already larger than that. Also the noise floor is rather high.
The test signal that we are using is generated with a PWM output. It is running at 4 kHz with a master clock of 48 MHz, so the resolution is 1/12000. That is scaled over the input range of the ADC, so we get about 1/3 LSB per step. The PWM output is filtered with a 4th order Low Pass Filter at 100 Hz, so the result is a very clean test signal that is inherently linear.
The reason that I feel sure that the problem is in the ADC is that the jump occurs at every multiple of 64, precisely over the 8 counts preceding the boundary. If the problem were in the test signal, it would not line up with the ADC codes so precisely. Voltage and timing offsets would cause it to appear at different places over the course of the test. Similarly, if there were some problem saving or reading out the results from the ADC, it would not align perfectly with the actual numeric code values like that. It doesn't matter how fast we run the ramp or where in the ramp we start. The jumps always occur at ADC codes of (n * 64) - 8. This really *has* to be something happening in the ADC. The only thing I'm wondering is if there is some setup process for the ADC that we are not doing correctly.
I can't send you our entire test code because it is integrated into the complete application, which has more than 100 files, some of which are proprietary. But I did copy the important ADC parts out in an earlier post. At thsi point I don't have time to set up your application on our hardware. I was hoping that you would be able to confirm the performance of the ADC, and that you might be able to see something about our ADC setup that would explain the problem.
Let me ask you: does NXP guarantee the performance of the ADC specified in the datasheet: +/- 2.5 lsb DNL? And do you have some sample test data that shows that?
Is it possible for you to show this discussion to the chip designer, and ask if this might be a known issue?
Thank you.
Hi marcschuman,
1. You said your test signal is very precise, please share your test signal wave in the oscilloscope. Post the picture.
2. I don't need your whole project, just as I said, copy a project, delete all the other important code, just leave ADC code which can reflect the problem, it should contains the code segment how to save the several 64 datas, how to printf it. Especially in the loop code about the adc.
The code you have shared can't see how you save the adc result, how to printf out, this is important to check the data continuous problem.
From your post picture, it seems you missed one or two adc points, and the slope never changed. if it caused by the error(DNL), it won't be so regular. That's why I think it caused by the software.
3. All the data in our datasheet has been test, after contact with the according department, the datasheet data is reliable.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi marcschuman,
After analyzing your post adc picture again, we think it may caused by your code about the adc result saving, not the adc performance, DNL shouldn't like that.
Because you don't want to give me your adc test code, now, to work in accordance, please use my test project and test on your side with your precision ramp wave.
My code is modified based on the lpcopen_2_12_lpcxpresso_nxp_lpcxpresso_11u68, and test on the LPCXpresso LPC11U68 board, convert ADC channel 0, PIO1_9.
The code will trigger the adc convert in 20us, and save the convert result to the buffer, after the result reach 1000 points, then stop adc converting and printf the data out.
If you want to change the trigger time to 1ms, you can modify adc.c file, line 204 configuration to:
SysTick_Config(48000);//1ms trigger
Please use my attached project, and test it on your side.
After testing, just like me sharing my test result.
Give me your precision ramp wave oscilloscope wave, zoom up to check whether it have the stage up.
And give me your test 1000 points data, and the according excel wave or the excel with test result directly.
You can find the 1000 points data from the uart0, PIO0_19(tx). PIO0_18(rx).
Waiting for your test result.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Marcschuman,
Please also use the oscilloscope to test your ramp wave, whether it have the jump after zoom up. Whether it is really 1/3 LSB step as you said.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I do not have a setup right now to collect that data. However, we have done so in the past, and I can tell you that the result is as expected. Most samples are +/- 1 count from the nominal value, occasionally 2 counts, and very occasionally more. Here is an example of real data collected (ADC output values):
2136 2136 2136 2136 2137 2137 2138 2137 2136 2136 2136 2136 2138 2136 2137 2137 2136 2136 2136 2136 2136 2137 2137 2136 2136 2138 2135 2136 2135 2136 2137 2136
The jumps that are the problem are clearly not related to timing, sample rate, specific voltage, or anything besides the ADC output code value. They are clearly happening at the (n *64) - 8 transition. It seems very much like a differential nonlineariy problem, perhaps caused by incorrect capacitor values internal to the chip.
Can you send me a proper DNL test result for this chip? That is a very standard measure of ADC performance.
Thanks!
Hi Marcschuman,
Sorry for my later reply.
I test it on my side, now share you my test result in the LPCXpress LPC11U68 board.
In put wave:
My function waveform generator may not as precise as yours(it is just 8 bit), from the wave, it has the small jump in the rising wave.
The ADC convert data, this is just part of the sawtooth wave.
I saved 1000 points, printf data:
Zoom up the wave in the red frame.
From the overall wave, the data is rising. The jump in the wave should caused by the original wave in my side.
My ADC trigger is using the systick, 20us do one ADC trigger, and save the convert result, then save it to the buffer, after the counter reach 1000, it will stop the adc convert, and printf the 1000 adc results. From the above result, every stage is about 50 points, one pints is 20us, so 50*20us is 1000us=1ms=1Khz, just like the original wave.
Send you partical test data:
869 |
866 |
871 |
867 |
869 |
870 |
869 |
870 |
867 |
867 |
865 |
867 |
867 |
868 |
868 |
870 |
868 |
867 |
869 |
866 |
869 |
868 |
870 |
869 |
868 |
871 |
869 |
867 |
868 |
869 |
865 |
868 |
870 |
871 |
871 |
869 |
872 |
891 |
888 |
884 |
885 |
885 |
883 |
885 |
887 |
881 |
886 |
885 |
887 |
883 |
885 |
886 |
882 |
882 |
880 |
885 |
883 |
882 |
883 |
885 |
884 |
883 |
883 |
885 |
883 |
887 |
882 |
884 |
884 |
884 |
883 |
889 |
883 |
891 |
883 |
885 |
888 |
883 |
881 |
884 |
886 |
882 |
883 |
884 |
886 |
886 |
898 |
902 |
896 |
899 |
894 |
903 |
901 |
901 |
897 |
903 |
897 |
901 |
903 |
896 |
The above is just my test result.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
The Y axis is giving actual raw ADC values. The X axis is the step number of the staircase waveform being input to the ADC, where each step is about 1/3 lsb. The spot where you ask on the graph "How many lsb in this area" is 8 lsb. The jumps in the recorded data are always 8 lsb, and they happen at every multiple of 64 in the ADC results. That is, there is always a jump from ADC output (n * 64) - 8 to (n * 64). The maximum DNL specified by the datasheet is 2.5 lsb. But the actual DNL I am seeing is 8 lsb, and that happens regularly. This means that the "12 bit" ADC in the chip is actually only usable as a 9 bit ADC.
I can send you an Excel spreadhseet with all of this data if you have a way for me to do that. But here is a sample, which covers the area of the jump in the graph above. Step is the input step number, and counts is the raw ADC value:
step: | 71 | counts | 308 |
step: | 72 | counts | 308 |
step: | 73 | counts | 309 |
step: | 74 | counts | 308 |
step: | 75 | counts | 308 |
step: | 76 | counts | 309 |
step: | 77 | counts | 309 |
step: | 78 | counts | 310 |
step: | 79 | counts | 309 |
step: | 80 | counts | 309 |
step: | 81 | counts | 310 |
step: | 82 | counts | 310 |
step: | 83 | counts | 310 |
step: | 84 | counts | 310 |
step: | 85 | counts | 310 |
step: | 86 | counts | 311 |
step: | 87 | counts | 312 |
step: | 88 | counts | 312 |
step: | 89 | counts | 313 |
step: | 90 | counts | 312 |
step: | 91 | counts | 312 |
step: | 92 | counts | 320 |
step: | 93 | counts | 313 |
step: | 94 | counts | 313 |
step: | 95 | counts | 314 |
step: | 96 | counts | 321 |
step: | 97 | counts | 320 |
step: | 98 | counts | 321 |
step: | 99 | counts | 321 |
step: | 100 | counts | 321 |
step: | 101 | counts | 321 |
step: | 102 | counts | 321 |
step: | 103 | counts | 322 |
step: | 104 | counts | 323 |
step: | 105 | counts | 323 |
step: | 106 | counts | 322 |
step: | 107 | counts | 323 |
step: | 108 | counts | 324 |
step: | 109 | counts | 323 |
step: | 110 | counts | 324 |
step: | 111 | counts | 324 |
step: | 112 | counts | 324 |