Dropouts in ADC capture on STM32H743

[ANovi.7]

If I connect a constant rising signal at the ADC input, I observe significant fluctuations at certain ADC values. These fluctuations always appear at the same ADC values. The affected values have the following format XX500, e.g. 18500, 19500, 20500 etc.

I was also able to reproduce this behavior with the NUCLEO-H743ZI and the example projects (ADC_DMA_Transfer and ADC_RegularConversion_Polling) from the current cube firmware V1.5.0. The graphic in the appendix shows a recorded ADC values, which shows the problem.

Can someone help me to solve the problem?

[fbar]

Are you using a RevX or RevV chip? RevX seems to have ADc problems that have been fixed in RevV

[ANovi.7]

I use RevY, which is even more recent than RevV

[fbar]

Actually RevY us the one with problems. RevX doesn't exist, my bad for mistakenly using RevX when I should have used RevY. not sure what short circuited in my brain when I typed RevX

Please have a look at AN5312 (https://www.st.com/content/ccc/resource/technical/document/application_note/group1/95/22/7c/0c/57/de/4b/f9/DM00609692/files/DM00609692.pdf/jcr:content/translations/en.DM00609692.pdf) and the ADc sections for RevY and RevV in the STM32H7 reference

The ADC section has been extensively reworked in RevV, to the point where the ADC code is not compatible anymore between revisions. Max conversion rates have changed, too, slightly

[ANovi.7]

Thanks for the hint, but that seems to have been taken into account in the HAL library, as seen here on the example of ADC boost:

 if(HAL_GetREVID() <= REV_ID_Y) /* STM32H7 silicon Rev.Y */

 {

   if(freq > 20000000UL)

   {

     SET_BIT(hadc->Instance->CR, ADC_CR_BOOST_0);

   }

   else

   {

     CLEAR_BIT(hadc->Instance->CR, ADC_CR_BOOST_0);

   }

 }

 else /* STM32H7 silicon Rev.V */

 {

   freq /= 2U; /* divider by 2 for Rev.V */

...

 }

You write, that RevY is the one with problems, but that's the last / current revision or is that wrong?

[Hh.1607]

ADC clock how many M do you configure?

[ANovi.7]

I am out of the office until 25.11.2019.
Note: This is an automated response to your message "User15744079967188602917 answered you: Fluctuations in ADC capture on STM32H743" sent on 22.11.2019 8:37:06.
This is the only notification you will receive while this person is away.

[Hh.1607]

I also encountered this situation, the higher the configuration, the greater the signal impact

[ANovi.7]

I am out of the office until 25.11.2019.
Note: This is an automated response to your message "User15744079967188602917 answered you: Fluctuations in ADC capture on STM32H743" sent on 22.11.2019 8:39:12.
This is the only notification you will receive while this person is away.

[Hh.1607]

Can you think that the ADC stability of H7 is not as good as that of F4?

[Hh.1607]

F4's ADC is still very stable

[ANovi.7]

I switched from F4 to H7 because F4 ADC had a lot of noise. With the same RC element and 12 bit value, I measured 3x higher noise with F4 than with H7.

Did you try to disconnect the Ethernet PHY?

https://community.st.com/s/question/0D70X000007PAk8/fluctuations-in-adc-value-of-stm32h743-mcu?s1oid=00Db0000000YtG6&t=1572098945317&s1nid=0DB0X000000DYbd&emkind=chatterCommentNotification&s1uid=0050X000007vuOa&emtm=1571808056457&fromEmail=1&s1ext=0

[ANovi.7]

This issue concerns more the noise or the behavior in the static state. I got that with the hardware and software filter in the handle. In my case, the dropouts with a constantly rising signal are the problem. These dropouts still occur at the same ADC values. That's why it can not be due to the Ethernet PHY.

[PWalt.2]

I am using an H750RevV with HalV1.9. I am seeing these issues on both ADC1 and ADC3. It is definitely related to a calibration issue, but that is not the only factor. Depending on which microcontroller we are testing, we will see anywhere from 0 gapping to ~150 ADC count gaps (this is 16 bit ADC). We were able to replicate this on evaluation kits as well. There are regions in the digital output that are just jumped over (ie offset).

We switched from ADC_CALIB_OFFSET to ADC_CALIB_OFFSET_LINEARITY which solved the problem on most devices but not all.

We are still seeing this issue, is there anyone who has absolutely eradicated this?