TMS320F280039: ADC pin measurement daviation

Hello Marc,

Please kindly provide some more information to clarify:

- Describe the circuit connected to the AIO pins (a schematic if possible);

- How much offset are you seeing compared to the baseline? 

Thanks,
Ibukun

Hello Ibukun,

I'm the hardware guy in this same project.

The schematic looks as followed:

The reference voltage (VREFHI) is 3V, the analog voltage (VDDA) is 3.3V.

The following measurements show the error (voltage increase) on TP1927 (AOI248) as well as a ADC-Error on VOLT_DCL_POS_1 at 200V.

As you can see, the voltage is higher at TP1927 as the voltage dividor would allow.

I then also repeated the measurement up to 300V with the microcontroller in reset (Pin nXRS connected to GND) and the voltage rise on AOI229 got smaller.

I then disconnected the Signal "VOLT_DCL_POS_2" from the AOI229 Pin (Pin 18) and repeated the measurement again up to 300V. (Pin nXRS still connected to GND) The error on TP1927 is now gone.

During the same time we applied the same voltage UHV to the following 3 circuits. And the behaved as expected:

The ADC Channels chosen are the following (correct me Marc if I'm wrong)

Hello Cedric and Marc,

This may be a long shot, but have you tried explicitly disabling all pull-ups on the AIO pins? Basically, write 0xFFFFFFFF to the GPHPUD register. It does sound like an internal pull-up is affecting it, although it really ought to have been disabled by default.

The offset does also seem to be fairly constant - in the range of 50-60 LSBs or so. One mitigation option here might be to use the ADC PPB offset calibration feature, which can automatically add an offset value from -512 to 511 to the ADC conversion result.

Ibukun

Hello Ibukun,

I can't find GPHPUD register on the code. I searched on the C2000ware with no success.  Also, Technical Reference Manual is only mentioning GPHPUD on the last revision of the document which is from 06/2023, so the one I was using until now is also not mapping this register. Do you think mismatch could be related to the issue?

Moreover, we also tested by writing 0xFFFFFFFF to the register address where GPHPUD register should be, but the result was the same. 

Thanks in advance,
Marc

We did some more testing and I think we found the root cause for the problem.

On one Channel, AIO226 we measure the DCL voltage in the range of 0-75 to have a better accuracy. Since the DCL voltage can go up to 1000V we added a clamping diode, but it seems, that the clamping is not strong enougth.

When the voltage on TP1935 exceeds the 3V reference we start to see an influence on some ADC-channels but not on all.

Could you give us an overview over the internal clamping?

Cedric,

That's good news to hear you were able to track this down. The clamping mechanism you have in the diagram above is actually the same mechanism used in the device at the input pin cell. These diodes are primarily intended for ESD protection but have the effect of sinking or sourcing current whenever the input voltage exceeds the operating range. The exact forward bias voltage for the diodes is not specified, however.

In my testing, I have found that the clamping diode will sink current on the order of a few mA when it is turned on.

Best regards,
Ibukun

One point of clarification: the top diode is connected to the VDDA supply rail, which is nominally 3.3V (this is different from VREF which in your case is 3.0V).

Best regards,
Ibukun

Yes, we expected the clamping mechanism to be a diode to VDDA on every analog pin.

Since we knew, that the voltage on TP1935 will exceed 3V and potentially go up to 40V we added the external claping diode and a 10k series resistor to limit the current into the pin to approx. 30uA.

If (as expected) every ADC Pin has a seperate clamping diode towards VDDA we should protect the ADC Pin VOLT_DCL_POS_3 / AIO226 / Pin 15 effectively.

What I now don't understand, is that we see an effect on other ADC Pins from this current.

On VOLT_DCL_POS_3 / AIO226 / Pin 15 we measure 3.72V with UHV = 100V. This is below the max. Input voltage of 4.6V in the datasheet and as established above, the current is also limited to approx. 30uA.

Are the ADC-Pins also grouped somehow besides the clamping diode on every Pin? They somehow need to be, in order to see the dsescribed effect of a voltage rise on other ADC-Pins but not all.

Ok, I am one step closer to the solution:

I adjusted the clamping and measurement circuit of VOLT_DCL_POS_3 / AIO242 to limit the voltage below 3.3V

 Ra = 300e, Rb = 1k, R1957 = 121k

Nevertheless I see a small deviation to the expected ADC result in the lower voltages.

What I can say for sure is, that all voltages on all ADC Pins are below VDDA.

But we use several AIO as digital inputs, that are usually always high and do not switch, except in the event of a mayor fault. (This is why I placed those digital input signals on the spare AOI pins.)

Is it possible, that the nFLT and RDY signals that are all constantly 3.3V somehow influence the high impedance measurement of VOLT_DCL_POS_1 and VOLT_DCL_POS_2?

If yes, what can be done about it?

My guess comes from the fact, that both VOLT_DCL_POS_1 (Pin29) and VOLT_DCL_POS_2 (Pin18) have nFLT and RDY signals close by. The also high impedance measurements of VOLT_PHASE_U/V/W that are basically the same circuit show no inaccuracies and have no nFLT and RDY signals close by.

Ok, I now tried to test if there is a influence of the digital signals on the AOI pins to the ADC values, and there is not.

I reduced the voltage on the RDY and nFLT signals to 3V. -> no Change on the AD-RAW values.

I also applied 70V to U_HV  and then changed to voltage individually to 0V on the other AOI inputs. This also did not change the AD-RAW values measured.

Could you help us understand the ADC error we see on the Channels VOLT_DCL_POS_1 / AIO248 and VOLT_DCL_POS_2 / AIO229?

Best regards,

Cedric Gasser

Hello Cedric,

I think the clamping issue has been resolved. What I see in your data now is a basic gain error problem, which would primarily be a characteristic of your voltage reference. The gain error is about 0.72%. In the chart below, the blue is the test point voltage and the orange is the ADC conversion, which is linear but has a slightly different slope (gain).

Can you describe your voltage reference circuit? What components are you using?

We might also want to confirm that you are using the ADC_setVref() function correctly to enable the external reference and load the trims correctly. If ADC_setVref() is not used, it is possible that the device will be incorrectly trimmed during ADC operation.

Best regards,
Ibukun

Hello Ibukun,

I also think that the clamping issue is resolved. (At the very least I hope so :-) )

We use the component "REF3430-Q1" as reference voltage in the following circuit:

As for how we are using the reference function in the uC I have to refer to Marc.

Best regards,
Cedric

Hello Ibukun,

I can confirm we are using ADC_setVref during initialization of the three ADC modules (as ADC_REFERENCE_EXTERNAL and ADC_REFERENCE_3_3V).Before that, we are also calling SysCtl_deviceCal. 

Regards,

Marc Ferrer

Hello Cedric,

The 200nF cap on the Vref pin is too much. REF3430 is only rated for 10uF on the output, and this 12-bit ADC should be fine with 2.2-4.7uF for VREFHI cap.

Ibukun

Hello Ibukun,

I'm sorry, but I'm not sure if I understand your advice

The only capacitance we have on VREFHI at the moment, are the 2x 100nF. One cap close to the reference and one cap close to the microcontroller. If I understand you correctly, this is not enougth. (and not too much)
I assume I should replace the 100nF cap close to the microcontroller with a 2.2-4.7uF cap?

Regards, Cedric

Hello Cedric,

I'm saying 100nF is too much for the REF3430 to support. 2x100nF is even worse

The total load cap cannot exceed 10uF per the REF3430 data sheet.

Best regards,
Ibukun

But 100nF or 200nF are way less than 10uF

100 nano farad < 10 micro farad

Apologies! My brain's a little scrambled this morning.

Yes, 100nF is too little. Minimum should be 2.2uF. You can put one 2.2uF near the reference and another 2.2uF near the pin and that works.

Hello Ibukun,

Unfortunately, the corrected capacitance of 2x 2,2uF did not solve our issue:

The measurement from 0 to 300V still looks the same.

Any other suggestions?

The only other relevant thing I can think of now is the ACQPS setting. I believe your team has already worked through this previously, but maybe it should be revisited. Insufficient acquisition time in this case could manifest as a gain error problem (you can see the conversion-to-expected delta decrease as the input voltage increases/required S+H cap charge time is increasing).

That, coupled with an offset error on VOLT_DCL_POS_1 (manifested as 18 LSBs at 0V) could explain the characteristic graph I posted above. If the offset cannot be eliminated on board, the ADC has a feature to automatically correct systematic offset errors using PPB offset calibration (PPBxOFFCAL register).

Ibukun

Hello Ibukun,

We tried increasing significantly the acquisition time and the results were the same.

We did a second test by swapping SOC2 signals with SOC3 signals (VOLT_DCL_POS_1 and VOLT_DCL_POS_2 were converted from SOC3). Once we perform the swap, we see a difference in the results as follows:

Original Code:

Swap SOC2 signals with SOC3 signals:

Do you think this could be an indication of memory cross-talk issues? Otherwise, would you have any other suggestion?

Thanks in advance,

Marc

Hello Marc,

I will attempt to follow up on this topic on Monday. Crosstalk is a possibility.

Ibukun

Hello Ibukun,

In order to provide more information, under the assumption that we might be facing memory crosstalk, we've also tested by swapping SOC0  with SOC3 signals. (VOLT_DCL_POS_1 and VOLT_DCL_POS_2).

We see that once we move VOLT_DCL_POS_1 and VOLT_DCL_POS_2 to SOC0, its value is lower (We think this result is compatible with memory crosstalk). We also see higher values on signals sampled on SOC3 (previous on SOC0), but the offset is not as high as the other signals, so we wonder if there are other variables to take into account.

Hope this might help to have a better overview.

Thanks in advance,

Marc Ferrer

Marc,

The most direct solution to memory crosstalk is to sample VREFLO in between conversions, obviously at the expense of potentially reduced overall throughput depending on your control loop frequency/budget.

Beyond that, we have an application note that deals with this particular topic in depth: Methods for Mitigating ADC Memory Cross-Talk

Ultimately this is an inherent issue with high impedance signal sources; it becomes a cost vs performance tradeoff.

However, you can always auto-compensate for systematic offset IF you know that it is relatively static/not variable, by using the ADC PPB (offset calibration). A dynamic offset is much harder to deal with.

Best regards,
Ibukun

Dear Ibukun,

We have tested the proposed strategy on " Methods for Mitigating ADC Memory Cross-Talk" (sampling vreflo).  The offset we are seeing is linearly increasing as the measured signal voltage increases (the assumption is that this is aligned with memory crosstalk issue), so my understanding is that we can't use ADC PPB in that case, am I right?

Is there any other ADC config, like adjusting Acq window, that could mitigate that?

Also, is there any way to double check what we are experiencing is in fact, memory crosstalk? 

Thanks in advance,

Marc Ferrer

Marc,

This is what I indicated previously - linearly increasing error over the input voltage range is gain error. Normally this should be directly attributable to the voltage reference accuracy (you can verify this by scoping VREFHI during the conversion phase to see both the rest voltage and load regulation behavior is - does it dip a little during conversion?).

Based on the data you supplied earlier, I had calculated a gain error of 0.72% which is much greater than the spec accuracy of the REF3430 (0.05%). Perhaps there are other (dynamic?) factors at play here. The ideal configuration for the voltage reference on a SAR ADC is to combine the series reference part (REF3430, REF5030) with a high-bandwidth op amp buffer such as OPA320.The inherent gain error of the ADC itself is less than 0.002% FSR, so any observed gain error is attributable to factors external to the device.

The PPB only helps with base offset error, not gain error (note that you could have both). Any adjustment for gain error must be done in software.

On the crosstalk question, a simple test would be to disable all other SOC/channel triggers and simply sample the signal being tested repeatedly. You should have a stable, repeatable conversion value. If the first one or two conversions are lower and the rest are higher, that suggests the ACQPS is not long enough (assuming you started from a zero sampling cap state). Now if the accuracy of the signal changes when other SOCs/channels are enabled and converting, then memory crosstalk is confirmed.

Best regards,
Ibukun