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

[AScha.3]

Hi,

so to find/exclude a hardware problem (stray in signal):

- did you check the adc signal at the pin with a DSO ? (to see, whether there is any spike)

- put a resistor 1kohm in the line, at the rx pin, to avoid any hi speed transient here. Then check again.

[macbum]

Dear Igor,

1. The op-amp we are using have 10MHz bandwidth. Settling time is 500ns. ADC is configured into synchronous mode. Clock is SYSCLK at 168MHz, with prescaler at 256. Therefore the sampling frequency is already quite low and should be sufficient at 2.5 ADC clock cycles.

2. We also checked PCB traces and didn't find any abnormality. The analog and digital signals have their own layers. There is no crossing of the signals so we also rule this out.

3. We are not using internal op-amp.

4. This is a suspect but after probing this, we did not detect any anomalies.

5. We are not using internal VREFBUF.

The problem with this issue is that it is not easy to reproduce under controlled conditions. So far we have only detected this in our product rig and only happens under very specific conditions. We have confirmed that keeping the UART signal quiet eliminated the problem so this is the cause but we would like to determine the root cause.

-m

[macbum]

Hi @AScha.3 ,

We have not tried probing the signal yet. This will take time. Currently we try to sample in code to collect data. We already have a resistor in series at the RX and TX pins.

Now, the pins that are used for the UART, USART3 is not yet configured as a UART at the time that this issue occurs. The pins are still configured as analog. This should not have any bearing on this issue. Correct?

-m