Skip to main content
CHead
CHead
Associate III
November 2, 2018
Question

What is the impact of overlapping ADC conversion on STM32H743?

  • November 2, 2018
  • 1 reply
  • 1176 views

In the STM32H743 errata sheet (ES0392 revision 4), section 2.3.1 “Conversion overlap may impact the ADC accuracy�? leaves me with three questions:

  1. If I am reading correctly, this means that running conversions on two different ADCs, from two different channels, at the same time, may result in inaccurate results. Is this a correct interpretation?
  2. The erratum talks about “conversion�? specifically. Does this mean that only the conversions, and not the sampling periods, are affected, so that one ADC can sample while another is converting at the same time without impact?
  3. The erratum says only that this “may impact the ADC accuracy�?. What impact does it have? I would like to simultaneously sample two channels (i.e. dual-ADC Regular Simultaneous Mode). If I do this, given the erratum, what accuracy can I expect? What if I have the third ADC operating at the same time, as well?
This topic has been closed for replies.

1 reply

Dan4
Dan4
Associate II
November 3, 2018

Great questions, hope to get some comments from ST.

I have experimented with overlapped (or better say purposely synchronized measurements) and do not see any deterioration. I have used 2x ADCs triggered by a timer simultaneously + third ADC running asynchronously - but still is expected to coincide sometimes + DAC -which is too supposed to cause issues.

But... the noise in my system is 8mV p-p at 3.3V supply. I do not see the ADC measuring worse noise than this. This noise level would mean ~ 150 LSBs at 16 bits that I use - so I guess my application is not very demanding.

One thing I found out, which was totally unexpected - PLL clock configurations may affect ADC results. No matter if one or more ADC is converting. I was getting random offsets on the channels, which kept changing with every reset around 8-16 mV up/down. It is channel dependent problem - some channels did not show any issues, while others showed random offsets. Resolved it by configuring PLL1 and PLL3 to be divisible on one another - took me weeks to find out... So the MCU definitely has issues. Hope they resolved it in rev X.

CHead
CHeadAuthor
Associate III
November 3, 2018

Interesting! Do you mean just the VCO frequencies, or did you have to modify the divider outputs as well? And I assume that you were using PLL3R as the ADC source in this case, since you say that it was PLL3 that affected you?

Dan4
Dan4
Associate II
November 3, 2018

Yes, I am using PLL3R as ADC source. What worked for me was - setting VCOs identical for PLL1 and 3, then the final dividers P/Q/R are different, but I take care all 6 of them to have a common denominator - i.e. setting one to 32 and the other to 16 is OK, but 32 and 5 is not.

Not saying that this is the only way to make it work, but it resolved the random offset issues for me.

Terms & ConditionsAccessibility statement