[SILICON BUG ?] Why does OPAMP fail to calibrate with internal output routing? (STM32G474)

Albi G. · ‎2019-10-07

Hi,

I am using the relatively new STM32G4(74).

I am currently implementing the OPAMP-abstraction and i am having issues with calibration.

The calibration works in general, if the output routing goes to the pin (OPAINTOEN = 0). (n&p is around 15/16)

The calibration does not work (OUTCAL always 0, no matter which trimming values) if the opamp output is routed to the internal connection (OPAINTOEN=1) for e.g. measuring it with the ADC.

Therefore i need to make sure that during calibration OPAINTOEN=0. this->behavior = !documented;

Further i noticed another issue:

When i calibrate (with OPAINTOEN=0), then switch to OPAINTOEN=1 to connect to the ADC, the ADC-Values arent even close to what I expect.

For example, with VREF=3.3V, the OPAMP in FollowerMode, external Voltage=2.413V, i expect a reading of 2995. What I really read is 3060 while the OPAMP is in highspeed-mode and 3420 while the OPAMP is in normal mode. (Sampling time is at maximum, but shorter sampling time does not worsen the behavior)

It seems like the internal connection is straining the OPAMP far beyond its output current capabilities. This would also explain why the reading changes, if high-speed mode is enabled.

And this output strain would also explain why the calibration fails.

I however dont understand why calibration is setting-depended, since the documentation states, that all switches should be opened.

I have tested all OPAMPs 1..6. They are all the same concerning the calibration miss-behavior.

The ADC-value desaster is tested with:

OPAMP2 connected to ADC2/Ch16 as Follower.
OPAMP6 connected to ADC4/Ch17 as Follower.

The ADC value seems independend of highspeed mode with

OPAMP4 connected to ADC5/Ch5 as Follower
OPAMP3 connected to ADC2/Ch18 as Gain x32

Does anyone know what is wrong here?

It really seems strange, since the OPAMP->ADC connection is a highly advertised/mentioned feature in those chips. Yet, it really sounds like a silicon bug. Specially the calibration dependence on output routing....

Albi G. · ‎2019-10-26

I think the spirit of Vincents answer is to use the MSB of the ADC-reading as the CALOUT equivalent.

I wonder if one could actually extrapolate some ADC-Readings and predict the final reading and get a much faster calibration that way.

If the derivation over time of the ADC reading is not large enough (or has the wrong sign) to flip the MSB within 2ms, that would be interesting

Albi G. · ‎2019-10-28

Hi Vincent,

i have tried the PB12 experiment. I have attached all relevant code concerning the test procedure:

maximum sampling time
averaging of 64 samples
2ms wait time between sampling:
External voltage @ PB12 = 1.329V
VREF = 3.300V
VDD = around 3.3V
Expected ADC-Reading = 1.329/3.3*2^12 = 1650.

Well...

Eval.Direct = 1688,
Eval.OPAMP_normal = 1721,
Eval.OPAMP_hs = 1609

No where near... :loudly_crying_face:

Reducing the ADC-Frequency from somewhere near 60MHz to 6MHz:

Eval.Direct = 1720,
Eval.OPAMP_normal = 1704,
Eval.OPAMP_hs = 1736

Reduced effect, but still unacceptable. The change in the apparent absolute value is also a little strange..

There is some run-to-run variation of the ADC-readings. There might be some noise on PB12 in my circuit. However, no matter the values, the relative differences between measurement methods stay somewhat constant. Please consider the values above "representative". Especially have a close look at the influence of the OPAMP speed.

As you can see i am using my own C++ framework. It is entirely possible that i am missing an important bit/setting somewhere.. if so, it is practically undocumented or very well hidden.

Edit: i have done some signal analysis via FFT and stuff (using 2048 samples @ 10ksps).

My RMS signal noise is 2.3LSBs when i sample directly from the pin
2.1LSB with OPAMP in high speed mode
6.5LSB with OPAMP in normal mode...

Albi G. · ‎2019-11-05

HELP :( Anyone there? Shall i try new processors? Can someone from ST please confirm or deny that there was a bad batch or maybe that certain circuit behavior (like an accidentally bad power on sequence?) could damage the chip this way?

Vincent Onde · ‎2019-11-05

Hi Albrecht,

Sorry, I was out for a while...

It's difficult to guess if there are issues with ADC configuration using the code attached. If possible, a register dump would be better.

Considering the code is fine, there may be 2 explanations for what you're seeing now:

the interval between 2 conversions is too large (there must be no more than 1ms idle time
the routing around ADC is not optimum. Eventually some ringing on the analog input(?), a Vref+ and/or Vdda decoupling not sufficient? The capacitor on Vref+ in particular is critical, it must bez located as close as possible from the MCU).

Are you facing the same issues with a Nucleo board?

Best regards,

Vincent

Albi G. · ‎2019-11-05

Thank you. I read that sample interval information actually, but didnt respect it. My fault. I will re-run the test and report.

This kind of explains why my measurements became better (still not good!) when i used DMA+continous mode to sample my inputs, however i can still say for sure that there is a definitive difference between OPAMP in highspeed vs normal mode. As you see my FFT-Test was at 10ksps (= in spec), but the rms noise was extremely different.

I will change to FFT-based analysis completely, this will show DC at bin 0, rms noise in all other bins and even periodic noise on the board.

Unfortuantely i have no access to a Nucleo board, so i cant test. I can ask a friend for a NUCLEO-G474RE when the next mouser order is due however.

------

Btw, meanwhile i can confirm that the MSB of the ADC is a valid way to calibrate the OPAMPS. But it is a resource management nightmare to be honest. It cost me some quite expensive GaN Mosfets to even find out that the OPAMP-calibration (wit external output routing) really changes the Output-Pin level. The suprise was that it happens despite the pin being configured in digital output mode instead of analog mode. This is a really strange pin-driver design structure imho (but at least documented on closer inspection).

waclawek.jan · ‎2019-11-05

> The suprise was that it happens despite the pin being configured in digital output mode instead of analog mode.

In some - if not most - if not all - STM32, the TTa pins (which may be marked as TC in some families DS, e.g. the L0) are directly connected to the analog modules (ADC, DAC, Comparator), even if only some families DS (e.g. F0, F3) acknowledge it. And then it often contradicts the diagrams in the GPIO chapter, where the analog switch (which in reality may not be there at all) appears to be disconnected for these pins in digital "modes".

Sorry, Vincent, but yes, the ST documentation is sloppy. This would be the first of the GPIO's dozen of appnotes (yes I know AN4899 and it does not deal with this particular issue well).

JW

Albi G. · ‎2019-11-05

>In some - if not most - if not all

I dont find this a valid form a critique to be honest. Make a concrete list where this is true and I think ST would listen. But generalized criticism is hard to act up on. For STM32G4 for sure, the documentation of the pin structure is correct. My feedback was more along the lines of "I dont find this behavior consistent with the spirit of the multiplexed peripheral connections and the selection of operating modes".

Concerning the weird OPAMP behavior: the new code for FFT analysis looks like

So i sample definitively quick enough (10µs artificial waiting time between adc invocations, Line 139)

The voltage at PB12 is 1.623V this should give an ADC reading of 2014.

The sampled data in reality is:

PinDirect.DC = {2107.349, 2107.374, 2107.426}
PinDirect.RMSNoise = {2.345, 2.297, 2.339}
 
OPA_Normal.DC  = {2548.031, 2547.769, 2547.841}
OPA_Normal.RMSNoise = {3.308, 3.276, 3.203}
 
OPA_HighSpeed.DC = {1996.755, 1996.913, 1996.964}
OPA_HighSpeed.RMSNoise = {2.310,  2.32, 2.360}

The measured pin is driven by an TLV9064 in my circuit. The sample time at maximum.

I dont think any DC value is acceptable close enough to 2014 +/-noise. The OPA in normal mode is totally kaputt, the Highspeed mode performs the best, however this might be purely by accident. However the the measurement seems repeatable and consistently wrong.

Now it becomes more interesting. I agree that due to my own software framework a register dump would be helpful. I challenge you to tell me which peripherals need to be dumped in order to get a full overview over the important settings. Maybe you name things that i have missed which would already solve the problem.

I have ordered a Nucleo board. I can spare the 15€... but it will take time to arrive. However I use the QFN48-package on my board; can you tell me if the die of the nucleo board is comparable (same die, different bonding)? If it is a different die and the results are different, then the result would be kind of meaningless but interesting nevertheless (to confirm software correctness).

FunFact: the 1.623V is generated via the DAC=2048. The DAC output is used to set the DC-Bias of the TLV9064 output. Basically, DAC + uncalibrated PinBuffer-Offset + TLV9064-Offset = 1.623V. which should be 1.65V. The offsets summing up to 27mV is a bit much. It seems like all the analog things are just weird :( VREF is generated by REF3433. VDDA is derived from VDD at a 10uF MLCC through a 600R@100MHz bead, decoupled by 1uF+100nF close to the chip but both capacitors sit on the other side of the board. The VREF-Pin is connected through a via not more than 1mm away from the pad to the capacitors with the via ring touching the capacitor pads.

waclawek.jan · ‎2019-11-05

> For STM32G4 for sure, the documentation of the pin structure is correct.

Wasn't it you who was surprised to see analog components being connected to pin set to digital input? And you still think the documentation is adequate enough to indicate this fact?

I too came across this issue, I discussed it here (among other things).

> Make a concrete list where this is true and I think ST would listen.

See e.g. https://community.st.com/s/question/0D70X000006SufTSAS/stm32l072-meaning-of-tta-as-iostructure-for-pa0 - see TTa in the first table there - it's taken from a 'F0 datasheet. As I've already said, 'F3 datasheets say this, too. Why couldn't other STM32 families DS say the same, then, and especially DS for the *new* STM32 models, once this information already found its way into older models' DS?

I don't think I am obliged to do ST's work and go through all DS. Those are not my customers who might need this information, or any other pointed out by the users at this forum.

JW

Albi G. · ‎2019-11-07

@Vincent Onde !!!!! I return in shame to tell you that i ****** up baldy.

Basically, because of the ADC register access is highly conditional (some registers may only be written under certain conditions), i gave up on keeping track of all the ifs and buts and flat out disabled the ADC to set up every single conversion in my SingleConversion(...)-function only to reenable the ADC and then trigger the conversion. AFAIK this is a behavior already covered in an errata or ADC related document and it should be avoided.

And indeed, keeping the ADC alive during all sampling makes all the difference. At least the OPAMP in normal mode is not crazy out of wack anymore. Still, i have some much higher than expected offsets, but there is an improvement.

I will add results later today.

As for Mr waclawek, i dont blame this on documentation like him, but it is clearly a limitation of my brain to handle the complexity of the peripherial.

>Wasn't it you who was surprised to see analog components being connected to pin set to digital ~~input~~? output?

Yes, yes indeed. But my unsatisfied expectation is a problem of me personally, not the documentation. There is a point to be made about broken consistency but in the end, it is an engineering decision to not put in an additional analog switch for cost or design reasons. I am stongly opposed to the mindset that the human sense for aesthetics should drive designs, although it is a nice-to-have.

Singh.Harjit · ‎2019-12-13

Hi. Can you please add the results you mentioned above? Thanks.