TMS320F2812: ADC counts obtained are less than estimated counts

Hemanth,
There is a temperature co-efficient of 50ppm/degC associated with the internal reference of the ADC. Since this will influence the gain error of the device, the absolute count would be depdenent on the input voltage. Firstly, do you think it possible there is some noticable temperature difference in the environment you are in versus last week when you calibrated?

If you are doing constant/boot time calibration then I would ask the same question, but of the references you are supplying to the ADC; i.e. could they be different from last week?

Best,
Matthew

Dear Matthew,

I am also working with Hemanth on this issue. Thanks for the reply!

As per your first suggestion, there is no significant difference in the temperature as we are running the controller in open air i.e room temperature.

Secondly, we are not sure what is constant/boot time calibration. As per the procedure given in spr989a, we wrote the equations in adc interrupt and calibrating the counts read by adc in every interrupt cycle.

However, the problem is that when we were checking the counts in debug mode, the counts read by ADC itself are 100 counts less compared to last week readings. We measured the references last week and this week as well. There is no difference in their values. Not sure what's the issue.

Thanks!
Kashyap

Kashyap,
Thanks for the feedback; is this a custom board or a TI evaluation module? Only asking so I can know more precisely the components, etc.

I would check the goodness/stability of ADCLO pin as well as any delta between the VSSA/ADCLO/ground connection of your reference(s).

Let's also check the ADCRESEXT and REFP/REFM passives for connection/correctness.

I assume this is true, but can you confirm that the device settings are the same run/run? Specifically system clock rate and ACQ_PS for the converted channels?

Best,
Matthew

Dear Matthew

Thanks for the reply. The board which we are using is a custom board.

Here are our observations as per your suggestions:

1. ADCLO pin with respect to ground was stiff at 0.00V

2. VSSA1 and VSSA2 are also grounded properly. Delta of 2mV between ADCLO/VSSA1/VSSA2 was observed.

3. Resistance between RESEXT and ADCLO is 24.86k ohms

4. Capacitances between ADCREFP to ADCLO and  ADCREFM to ADCLO were around 5.2uF

5. Voltage of ADCREFP pin was around 2.00V and ADCREFM was 1.001V

6. The software device settings are the same in both cases. System clock rate and ACQ_PS were the same. No code change was done.

Please let us know if any other causes can be explored.

Thanks

Varun

Varun,
Thanks for checking all of these, the RESEXT looks good as do the REFP/REFM voltages.

The datasheet for the F281x recommends 10uF on both ADCREFP and ADCREFM for transient stability. While 5.2uF is certainly considerable, there are some fast transients during the conversion process that needs enough bulk capacitance to keep those voltages steady state during the conversion process.

I would also look at the type of cap, these should be ceramic X7R or better type caps. Electrolytic caps will cause issues as well as their ESR is not as good as the above.

The other things to consider is the power up time in the C code of the ADC. With this size cap the recommendations is 5us after power up before the 1st conversion. I would check this value as well.

Certainly, conversion to conversion we will expect to see some variation on the order of 5-7 codes in a guass distribution from noise artifacts; but the 100 counts you mention is too large for that, plus looks like a shift in the, rather than a code spread.

Let's see what the above yields in terms of results.

Best,
Matthew

Dear Matthew

Apologies for the delay in reply.

As per your suggestion, I have checked the capacitances. These capacitors are X7R, SMD ceramic capacitors.

Also, through the software the following delays are provided. The delays are as per recommendations in the datasheet.

    AdcRegs.ADCTRL3.bit.EXTREF = 1; 

    AdcRegs.ADCTRL3.bit.ADCBGRFDN = 0x3; 

    DELAY_US(ADC_usDELAY);                  // 10ms delay before powering up rest of ADC as per datasheet 

    AdcRegs.ADCTRL3.bit.ADCPWDN = 1;  // Power up rest of ADC

    DELAY_US(ADC_usDELAY2);                 // 20us delay after powering up ADC as per datasheet 

  AdcRegs.ADCTRL3.bit.SMODE_SEL = 1;   // Simultaneous sampling mode

Please comment.

Thanks

Varun

Hemanth,
Thanks for the update. Everything looks correct in your code posted. I do want to focus on the simultaneous sampling mode, given your issue.

Just to better understand if this matters, would it be possible to switch to sequential mode(SMODE_SEL = 0) and note if the issue remains?

When you see the 100 counts of error, is it present on one of the simultaneous pairs or just one of them(A or B).

Assuming there is more than one pair being sampled, does changing the order of sampling have any effect?

Best,
Matthew

Hemanth,

Wanted to check in to see if you had a chance to follow up on my last post. 

Best,

Matthew

Dear Matthew

I have tried changing  the sampling from simultaneous to sequential. However the issue of lesser no of counts still persists,

There was another change that we tried which is the ACQ_PS setting.  (ACQ_PS 0 - 3)

All the while it was set to 0000. We tried the different available settings and the observations are as under,

TP voltages (DMM)	ACQ_PS	counts _A3
0.448	0	500-540
0.448	1	500-520
0.448	2	500-520
0.448	3	530-550
0.448	4	570-590
0.448	5	600-620
0.448	6	630-650
0.448	7	640-660
0.448	8	620-640
0.448	9	600-615
0.448	A	570-590
0.448	B	550-570
0.448	C	530-550
0.448	D	530-550
0.448	E	540-560

The setting of ACQ_PS of 5 gives the counts close to the expected no of counts of 0.448/3 * 4095 = 611. The same is true with the other pairs of signals sampled.

Regarding the error in counts during simultaneous sampling, we observed it on both the pins that are being sampled simultaneously (A2 and B2 in our case) were measuring lesser no of counts 

As to the change in the order of  sampling, I shall test it and let you know.

Thanks and regards

Varun

Varun,
This is interesting, if there was an issue charging the internal sample and hold capacitor I would expect to see the ADC result becoming ideal with increasing ACQPS, and then stay stable with any larger value since at that point we are just giving longer to charge the cap.

However, this is not what we observe in your data, where we see the value to continue to change as we increase the ACQPS. While I understand the DMM is showing steady state I suspect there could be a system component, perhaps on the introducing noise on ADCREFLO and/or VSSA during sampling that we are picking up.

Given that our devices are typically used in control topologies in power electronics; this can be quite common. Could you comment if there is a switching action co-incident with the ADC sample? If so would there be a way to de-energize that circuit to see if the ADC Result stabilizes?

Best,
Matthew

Varun,
Wanted to check back in to see if you an opportunity to investigate further.

Best,
Matthew

Hi Matthew

The observations were done by giving a fixed DC voltage to the ADC pin and by changing the ACQPS value. This DC voltage was given from a separate DC supply. There was no switching circuit which was active during this test.

Thanks

Varun

Hemanth,
I want to try and see if we can get the sampling cap to settle in a different way than changing the ACQ_PS.

Let's use the ACQ_PS = 0, and the sample the sample channel for all the sequencer slots and then report that list of 16 conversion results back to the thread. You'll want to place the seq 1 in cascaded mode, amd make MAX_CONV = 0xF. On the ADC trigger it should capture the channel continuously 16 times, and results will be in RESULT0-15.

Will see if this settles over time or not.

Can you also confirm if there is voltage on any other ADC channels during the testing we've done so far? If so, what is the value of that voltage? There is potential for an ADC channel to influence another channel if the voltage is above VDDA(which is out of spec, but I want to verify this).

Best,
Matthew