Strange ADC issue in STM32G491

[macbum]

Hi,

I have a very strange ADC issue which I am unable to find the root cause to. The symptom is as follows;

While performing ADC readings to ADC1 IN1 and ADC2 IN1 consecutively, the readings sometimes differ by more than 32 ADC counts. I perform this check as part of BIST. This only happens when at the same time a UART signal is coming in to USART3_RX (115kbps). To prove that the USART3_RX is causing the problem, I sever the connection or stop transmission (both produce the same result). The issue goes away and everything works fine.

What could be the issue? Is there something else I could do to mitigate this issue besides stopping the UART signal?

I have not been able to mitigate the issue so far. All my efforts so far to uncover the issue have not yielded any results.

I am aware that these 2 channels are essentially routed to the same pin and shared by the 2 ADCs so the readings should be identical if not very close.

[KnarfB]

How are the pins externally connected?

What are the details for measurement like sampling time? Code?

[waclawek.jan]

Are those two readings taken simultaneously or in close succession? 

Is the input signal rock stable? 

What happens if Rx signal is present but you disable Rx in software?

What happens if you introduce deliberate delays in software?

JW

[macbum]

To answer your questions;

1. The 2 readings are taken in close succession.

2. Input signal is rock solid, essentially at mid-rail ie. reads 2048 counts

3. USART3_RX pin is not configured as USART3 yet at that point. It is in reset.

4. Did not try injecting delays. Do you mean delays between the 2 readings?

-m

[macbum]

The pin is connected to the output of an op-amp. The signal measured should be at mid-rail (ie. 2048 ADC counts).

Sampling time is set to 2.5ADC clocks.

[waclawek.jan]

> The 2 readings are taken in close succession

Read errata and the 'G4-specific ADC appnote.

I don't know how exactly is it related to UART, if there's no code - maybe through common ground, maybe through injection through the overvoltage protection diodes.

JW

[Igor Cesko]

Dear macbum,

 There can be some reasons for ADC error:

1. You wrote that ADC is connected to OPAMP output. What type of OPAMP are you using? Because you use sampling time only 2.5cycles (I don't know the ADC frequency) - I expect that such short sampling time is too short to have stable output from OPAMP at end of sampling time. The OPAMP speed must be very high to provide stable output. Principle: At sampling point we connect (discharged) sampling capacitor to OPAMP output. At first moment the output from OPAMP is zero due to discharged sampling capacitor connected to OPAMP output. The OPAMP has feedback which "registers" this discrepancy and started to drive output (charging the sampling capacitor) to have correct voltage on OPAMP output. Problem is the OPAMP speed (OPAMP + feedback). For example if the OPAMP speed (bandwidth) is 1MHz then we expect that OPAMP output became stable after more than 1us (usually 3..5 times more due to necessity to wait for precise stabilization to 1LSB - attenuated oscillations). In STM32G5 datasheet we have OPAMP with ~13MHz bandwidth and while ADC is sensing output from this OPAMP then (according to datasheet data) the sampling time must be more than 200ns (for example: if ADC clock is 40MHz we must use sampling time more than 8 cycles => practically 12.5 cycles).
2. Another reason can be crosstalk from UART pins toggling to OPAMP. If you are using external OPAMP please check on PCB if UART signals are not so close to OPAMP inputs. OPAMP inputs are very sensitive - high impedance inputs with extra high OPAMP amplification.
3. Errata: If you are using internal OPAMP - please check the errata "OPAMP disturbed by fast-edge toggle on GPIO pin corresponding to VINM0". There depends on which pins we mapped UART signals. Please check this pins and errata.
4. VREF+ decoupling: if the VREF+ pin is not perfectly decoupled then VREF+ is not stable and there can be error. This error has maximum at ~2048 level (and some another multiples). Try to change the signal level - to check the error on another levels. If error disappears then problem is in this VREF+ pin decoupling. Solution is better decoupling - important is to put capacitor immediately to VREF+/VSSA pins (each millimeter is important). Or we can decrease ADC clock - if possible.
5. Influence of VREFBUF by toggling of some pins: If you are using for VREF+ internal VREFBUF signal then this VREFBUF can be influenced by toggling of some pins. This is errata for STM32G474 - not valid for STM32G491 - we never observed such problem on STM32G491. Are you using internal VREFBUF to generate VREF+ voltage or you used external source? 

Please read this AN5346 for tips and source of problems:

https://www.st.com/resource/en/application_note/an5346-stm32g4-adc-use-tips-and-recommendations-stmicroelectronics.pdf

Regards

                            Igor