AnsweredAssumed Answered

LPC11U68 ADC linearity problems

Question asked by marcschuman on Feb 1, 2017
Latest reply on Mar 3, 2017 by Kerry Zhou

Like • Show 0 Likes0
Comment • 27

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.

No one else has this question

Outcomes

26 Replies

Kerry Zhou Feb 6, 2017 1:00 AM
Mark Correct
Correct Answer
Hi marcschuman,
What the ramp input wave frequency you are using?
And what the ADC convert rate you are configuring?
In the application, the ADC convert rate need at least 5 times or 10 times than the input wave frequency.
You also can provide the ramp input wave picture, and your lpc11u68 adc test code.

Waiting for your reply!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Like • Show 0 Likes0
Actions
marcschuman Feb 6, 2017 1:43 AM
Mark Correct
Correct Answer
Here is an image of the collected data. I am converting at 10 ksps. I have a precision analog ramp feeding the input that is stepping at about 1/3 lsb per ADC conversion. You can see that the jumps occur always at 8 counts below a 64 count boundary. That is independent of input offset, sample rate, etc. The ADC seems to have missing codes for the 8 counts prior to each 64 count boundary. Notice also that there is a slope error on each segment. We have seen this exact behavior on multiple samples of the LPC11 MPU. Do you think that the chip should be performing better than this? Is there any kind of software setup problem that could cause this? Or is it possible that we have a bad batch of chips?
Like • Show 0 Likes0
Actions
- marcschuman @ marcschuman on Feb 9, 2017 1:41 PM
  Mark Correct
  Correct Answer
  Could someone from NXP confirm or dispute this performance data on the LPC11U68? I have a product that depends on this ADC, and it is a huge problem. I will have to redesign the product if this is the actual performance that we will get in production.
  Like • Show 0 Likes0
  Actions
- Kerry Zhou @ marcschuman on Feb 14, 2017 12:11 AM
  Mark Correct
  Correct Answer
  Hi marcschuman,
  Please share your ADC sample code(just the ADC code which can reproduce the problem, you don't need to send the whole code), then we can help you to check whether it is the software setup problem.
  Please also give me the analog ramp feeding scope waveform, then I will find a similar wave , test it on my side, and try to reproduce your problem.
  
  Waiting for your reply!
  
  Have a great day,
  Kerry
  
  -----------------------------------------------------------------------------------------------------------------------
  Note: If this post answers your question, please click the Correct Answer button. Thank you!
  -----------------------------------------------------------------------------------------------------------------------
  Like • Show 0 Likes0
  Actions
marcschuman Feb 14, 2017 1:52 AM
Mark Correct
Correct Answer
I cannot send you the sample code because it is part of a very large and complicated code base. But here are the key setup lines:

    Chip_ADC_Init(LPC_ADC, 99);
    Chip_ADC_StartCalibration(LPC_ADC);
    while (!(Chip_ADC_IsCalibrationDone(LPC_ADC))) {}
    Chip_ADC_SetDivider(LPC_ADC,15);
    Chip_ADC_SetupSequencer(LPC_ADC, ADC_SEQA_IDX,
         ADC_SEQ_CTRL_CHANSEL(1) |
         ADC_SEQ_CTRL_CHANSEL(2) |
         ADC_SEQ_CTRL_CHANSEL(4) |
         ADC_SEQ_CTRL_CHANSEL(5) |
         ADC_SEQ_CTRL_MODE_EOS |
         ADC_SEQ_CTRL_HWTRIG_CT32B0_MAT0 |
         ADC_SEQ_CTRL_HWTRIG_SYNCBYPASS |
         ADC_SEQ_CTRL_HWTRIG_POLPOS |
         ADC_SEQ_CTRL_SEQ_ENA);
    Chip_ADC_ClearFlags(LPC_ADC, Chip_ADC_GetFlags(LPC_ADC));
    Chip_ADC_EnableInt(LPC_ADC, (ADC_INTEN_SEQA_ENABLE));

The counter timer triggers the sequencer at 1 kHz.

The analog input is created by dividing down and filtering a precision waveform created by custom equipment. I cannot get you a scope capture of that waveform at this time. But I can explain that it is a perfect staircase pattern, with the height of each step approximately 200 uV. That is about 1/3 of an lsb for the ADC, which has a Vref of 2.5V. The steps are occurring at 1 kHz and the sampling is at 1 kHz. So there is an uncertainty about where the step edge occurs relative to the sample point, but the step edge is only 200 uV.

I think that if you set up such a test, you will see the same results. This is a standard test of ADC linearity! You can do the same thing with a precision programmable voltage source.

The problem is that this ADC seems to have terrible DNL. I need to know if it is due to a software setup problem, a problem with a batch of chips that we bought, or a problem with all LPC11U68 chips.

Can you provide some actual captured data showing the linearity performance of your ADC?

Thanks!
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 15, 2017 3:08 AM
  Mark Correct
  Correct Answer
  HI Marcschuman,
      Please tell me how you get your picture:
  what is the horizontal axis unit, and vertical axis?
  Actually, the slope of the wire is still not change, but it seems the x axis(horizontal axis) time is change, it caused your wire move upword.
  So, please tell me how you get these data? save the adc data in the ADC interrupt or the timer interrupt? or any other else?
  I do the testing on my LPC11U68 board with a fixed voltage:1.318V, test with multimeter.
  Then use a flag in the timer interrupt to indicate the hardware timer happens. And save 100 datas in the while(1) like this:
  The converted ADC data also have fluctuation. Tomorrow, I will find a ramp source to test it.
       Except the your picture's horizontal axis unit and test method, please also tell me how many LSB on your side in this picutre:
       From the datasheet, the LPC11U68 really have the LSB errors:
  Please give me more details, I also need to check it with our AE department.
  
  Have a great day,
  Kerry
  
  -----------------------------------------------------------------------------------------------------------------------
  Note: If this post answers your question, please click the Correct Answer button. Thank you!
  -----------------------------------------------------------------------------------------------------------------------
  Like • Show 0 Likes0
  Actions

marcschuman Feb 15, 2017 7:43 AM

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

Actions

Kerry Zhou @ marcschuman on Feb 16, 2017 2:52 AM
Mark Correct
Correct Answer
Hi marcschuman,
Are you convenient to use the ADC to test the fixed voltage, for example 1V on your side? Still use the 64 counts to test it, then send me your excel data.
It also useful to my analysis.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Like • Show 0 Likes0
Actions

marcschuman Feb 16, 2017 10:37 PM

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!

Actions

Kerry Zhou

@ marcschuman on Feb 20, 2017 9:34 PM

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!
-----------------------------------------------------------------------------------------------------------------------

Actions

Kerry Zhou Feb 20, 2017 3:50 AM
Mark Correct
Correct Answer
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!
-----------------------------------------------------------------------------------------------------------------------
Like • Show 0 Likes0
Actions
Kerry Zhou Feb 20, 2017 10:02 PM
Mark Correct
Correct Answer
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!
-----------------------------------------------------------------------------------------------------------------------
Attachments
- lpcopen_2_12_lpcxpresso_nxp_lpcxpresso_11u68_adc.rar1.3 MB
Like • Show 0 Likes0
Actions
marcschuman Feb 21, 2017 2:47 AM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 23, 2017 7:24 PM
  Mark Correct
  Correct Answer
  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!
  -----------------------------------------------------------------------------------------------------------------------
  Like • Show 0 Likes0
  Actions
marcschuman Feb 26, 2017 11:41 PM
Mark Correct
Correct Answer
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?
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 27, 2017 12:00 AM
  Mark Correct
  Correct Answer
  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!
  -----------------------------------------------------------------------------------------------------------------------
  Like • Show 0 Likes0
  Actions
marcschuman Feb 26, 2017 11:54 PM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 27, 2017 12:16 AM
  Mark Correct
  Correct Answer
  Hi Marcschuman,
  Please give me the orginal data in excel which plot the chart from step1 to step 550, thank you!
  
  Best Regards,
  Kerry
  Like • Show 0 Likes0
  Actions
marcschuman Feb 27, 2017 12:24 AM
Mark Correct
Correct Answer
I will send you the Excel file. How can I do that?
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 27, 2017 12:30 AM
  Mark Correct
  Correct Answer
  Hi Marcschuman,
  Choose advanced editor, then zip your excel and attach it.
  Like • Show 0 Likes0
  Actions
marcschuman Feb 27, 2017 12:35 AM
Mark Correct
Correct Answer
Here is the Excel file with the test data.
Attachments
- LPC11U68 ADC DNL test.zip736.5 KB
Like • Show 0 Likes0
Actions
- Kerry Zhou @ marcschuman on Feb 27, 2017 8:29 PM
  Mark Correct
  Correct Answer
  Hi Marcschuman,
  Please give me your ramp testing wave from the oscilloscope ASAP.
  
  Kerry
  Like • Show 0 Likes0
  Actions
  - marcschuman @ Kerry Zhou on Feb 27, 2017 10:50 PM
    Mark Correct
    Correct Answer
    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
    Like • Show 0 Likes0
    Actions
    - Kerry Zhou @ marcschuman on Feb 27, 2017 11:24 PM
      Mark Correct
      Correct Answer
      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!
      -----------------------------------------------------------------------------------------------------------------------
      Attachments
      AN11031v1.zip973.7 KB
      Like • Show 0 Likes0
      Actions
      - marcschuman @ Kerry Zhou on Feb 27, 2017 11:46 PM
        Mark Correct
        Correct Answer
        Here is the circuitry for the reference supply. Please let me know if
        you think this is appropriate.
        
        As I said, we are busy for the next few days, but we will get you more
        data when we can.
        
        Thanks for your help.
        
        Marc
        Attachments
        lpc11u68 reference circuit.png81.9 KB
        Like • Show 0 Likes0
        Actions
        marcschuman @ marcschuman on Mar 2, 2017 3:28 AM
        Mark Correct
        Correct Answer
        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.
        
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ marcschuman on Mar 3, 2017 12:39 AM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        Like • Show 0 Likes0
        Actions

LPC11U68 ADC linearity problems

Outcomes

Attachments

Attachments

Attachments

Attachments

Related Content

Recommended Content

NEWS