This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS1227: ADC1 and ADC2 simultaneous sampling result difference

Part Number: TMS570LS1227

There is a larger difference than expected in conversion result between the same input signal converted by ADC1 or ADC2. The followings relate the detailed configuration we have:

The ADC channel assignments:

ADC1 (Group2): ch5, ch6, ch7, ch13, ch22

ADC2 (Group2): ch5, ch6, ch7, ch8, ch9, ch12, ch14

As indicated in bold, the channels ADC1[22] and ADC2[6] are multiplexed on the same pin with an accurate 4.096 V shunt reference connected. The conversions are triggered simultaneously by a hardware trigger. 

All ADC timing is identical with tACQ= 6 * tADCLK effectively resulting in simultaneous sampling of ADC1 and ADC2 each time according the sequence given above.

The following configuration settings are used:

VCLK1CLK=90MHz

ADCLK = 22.5MHz

12 bit conversion resolution

The theoretical conversion result of ADC1[22] and ADC2[6] would yield: ((4.0973 * 4096) / 5.0214)-0.5 = 3342

And the conversion results with the configuration described above are:

ADC1[22] = 3341 or 3342

ADC2[6]   = 3334 or 3335 (too low value)

There is a larger difference than expected  in conversion result between the same input signal converted by ADC1 or ADC2. In this case the difference is about 7 counts. However, when the timing is changed by changing the G2_ACQ value in the G2SAMP register (for ADC1 one clock period longer, for ADC2 one period shorter), the difference between the samples disappears (1 or 0 count) as expected, and given as followed:

ADC1[22] = 3341 or 3342

ADC2[6]   = 3341 or 3342

On the other hand, without changing timing, we have tested one board at higher temperatures where the difference disappears at about 85 degrees Celsius.

A similar issue listed in the Silicon Errata (TMS570LS12x/11x Microcontroller Silicon Revision B) in page-9 with the name of ADC#1. There are two workarounds suggested in the errata. The first one is about the changing the timing similar to what we have tried.

Thus, we have the following questions:

1- Is the issue and the suggested work-around listed in the errata same as the issue we are having and described above?

2- Would you also suggest the workaround in the errata or another solution? 

3- How can you explain not having the issue anymore when the temperature gets over 85 degrees Celcius?

Thanks in advance for your support!

Kind regards,

Ugur Keskin

  • Hello Uger,

    I need to discuss this further with one of our ADC experts, but this is not the same as what is described in Advisory ADC#1. For starters, the sampling is ocurring on the same pin simultaneously and second the sampled voltage is much less than VCCAD - 0.3V which are both requirements for the conditions of ADC#1.

  • Hello Uger,

    I spoke to one of our ADC experts on this and his belief was that this was the same as Advisory ADC#1. The reason/explanation is that even though you are simultaneously triggering the conversion, there are differences in the timing paths between the trigger of ADC1 vs ADC2 and this, ever so slight, difference can cause the very small difference you are seeing as described in ADC#1 advisory. The fix is as you have mentioned where you shortened ADC1 by 1 and lengthened ADC2 by 1 (overall 2 ADC Clock delta) so that the conversions are not near simultaneous. One consideration is to lessen the delay to 1 in order to minimize the chance of some random event causing a glitch or difference due to the different timing.

    In regard to the problem going away when the temperature increases, this is most likely a result of the improved/faster timing path removing the small gap in timing between ADC1 and ADC2 and eliminating the issue from ADC#1. Higher temps tend to make transistor switching faster.
  • Hello Chuck,

    Thanks for your reply. This answers our questions.

    We just wonder if you have any plans to fix this issue in the further controller revisions?

    Kind regards,

    Ugur Keskin

  • Hello Ugar,

    Currently there are no plans to make any changes to the silicon. Given the complexity associated with Functional Safety certifications, it is sometimes better to leave the silicon unchanged and make system level accommodations dependent on the severity of the issue. In this case, there are methods to work around the issues so there are no plans to make any change.
  • Hi Chuck,

    Thanks for the reply.


    Kind regards,
    Ugur Keskin