STM32G431 Comparator BUG

[Michal Dudka]

Hi,

Few days ago i've encountered a strange behavior of the comparator at STM32G4. I investigated the problem under controlled conditions (used Nuclo kit instead application PCB) and the result is startling.

Comparator 4 configured to get positive input from pin PB0, negative from DAC1 Channel 1 (set to 500mV).
Hysteresis set to maximum (70mV)
DAC output is not connected to external pin (only internal connection)
Input signal is 50Hz sinewave with 400mV amplitude and 600mV offset (to reliably cross 500mV thresholds +- hysteresis)
Enabled Comparator 4 rising edge interrupt.
Interrupt routine simply generates fixed length pulse.

On blue scope trace you can see clean input signal (scope input AC coupled), it certainly does not contain noise that would be close to hysteresis value (more detail at last screen).
On Red trace is application output. You can see that many times interrupt fires also on falling edge, or fires multiple times on tha same rising edge. It looks like that comparator works withou hysteresis. But if you take a look on next screenshot, you will se comparator HW output (yellow) witch marked thresholds. They are separated by about 40mV which corresponds to "typical" value of "70mV" hysteresis. And of course, comparator registers are correctly set to hysteresis level "7".
On yellow trace is comparator HW output (PB6)
Last screenshot shows that there is not excesive noise to "false" trigger comparator.

False falling edge detectionDouble rising edge detectionHysteresis provedSmall noise

I am using STM32G431K Nucleo board, MCU clocked 170MHz from internal oscillator, powered from USB.
Source code included.

[Michal Dudka]

I am runing only DAC to set comparator threshold. Any other analog peripherals is not enabled. Chip run at minimal configuration to demonstrate problem, just DAC,Comp,GPIO,EXTI.

I agree that it is necessary to be conservative when declaring it as silicon bug - lets call that "a disturbing observation". It is up to ST whether they will somehow verify these findings. I probably won't do any more tests. I spent some time on it just because I found it interesting and it can probably save some debug time to somebody else. It does not complicate my work in any way (I do not deploy STM32 in large series) and workaround was simple in my case.

[AScha.3]

>it is necessary to be conservative when declaring it as silicon bug

Right. I see nothing "wrong" here , just look (with your "false trigger problem") at a scope, DSO or analog,

set trigger close to zero/center , on rising , and input just mains (50 or 60Hz) (simply by touching the 10:1 probe tip, getting the stray-in-hum :( 

most scopes will show a mix of "right" and "wrong" traces,  most triggered at rising zero cross, some at falling.

Why ?

Well , when signal rising and trigger set to rising - its doing what we expect.

But at falling signal, when at zero crossing, any tiny EMI/spike giving a small falling+rising signal, maybe only for some nanoseconds , but for a hi-speed circuit enough, to say: ok, rising signal at zero cross -> trigger now.

And we have cell phone, WiFi nets etc always around, so some mV spikes you will see on every unshielded wire , longer than 20mm . 

So if want test something like this, to prove, its a chip bug : first go in a 100% RF tight environment and build also the test setup in a magnetic shielded box - then you might see, is there a EMI/spike source , coming from the chip - or not.

And using the hysteresis improving the "false" trigger, shows: this is the problem.

So with 10mV noise and whising a 100% correct trigger, i guess you need minimum 500mV hysteresis, to be on the "save side" .

And just to think about: we see here a "problem" , that might come from some mV spikes on the input - but where is this sensible circuit sitting ? Some micrometers away from busy switching thousands of gates at 1..3 V levels with swichting times < 1 ns . So -for me- more surprising, it can work at all with such "neighborhood".

[waclawek.jan]

> I am runing only DAC to set comparator threshold. Any other analog peripherals is not enabled.

So this question is settled, then. Thanks.

JW

[Michal Dudka]

It is not an input noise problem. Following simple observation prove that:

I can set positive going threshold to 1.100V, negative threshold 1.05V (hysteresis 50mV) and then i can move DC signal very slowly from 1.000V upwards. When i reach few mV close to 1.100V then comparator single (!) flips. Sometimes with "artefact" sometimes without. And then its output doesn't change anymore. When i slowly decrease input voltage, output is still unchanged. Only when input voltage reach very close (few mV) to 1.05V then comparator single (!) flips back (again with or without "artefact"). If there is any excessive noise able to flip comparator output back and forth, then it must be observed most of the time when the signal is in range between positive and negative going thresholds. And i do not observe anything like that (can be also readed out at third screenshot in my original post). 

I'm not an "arduino newbie" who tries to blame it on a chip bug whenever something fails. Problem is that the comparator single (!) flip is sometimes defected. Its overall behaviour is absolutely normal, hysteresis works and reliably suppress all "macroscopic" false flips caused by ordinary noise (<10mV). But in time of single flipping, there is high probable very specific "artefact", which have  unpleasantly consequences with asynchrounous EXTI. 

[AScha.3]

Ok, 

>It is not an input noise problem.

So sure about ? Did you have a cer.cap (100n or so) direct on the header --> to gnd, and a resistor (1k or so), to have a input filter against any spikes , when doing the tests ?

(I cannot try this with a G4 , because i dont have any...)

But I would be curious to see if the same error occurs , with hysteresis set, of course. (HYST 6 or 7 )

btw

The comp speed 17ns (from ds) is really astonishing fast. 

[Michal Dudka]

Input is filtered by 100nF capacitor direct soldered on header, signal source is arbitrary waveform generator with 50Ohm series impedance. Input signal monitored by oscilloscope. Exactly same "artefact" observed on two different PCBs (both STMG32G431K) and one of them is Nucleo32 . But crucial fact speaking against input noise problem is described observation. If there is any noise capable to overcome 50-70mV hysteresis, why comparator does not floping if i feed it by DC in the middle of negative and positive going thresholds ? Moreover why comparator does not flip even if signal is 10mV close to trip point ?... Because there is no such noise (Comparator itself is "noise detector", it will reliably detect >50mV noise by toggling its output). "17ns" is realy fast and i like it but that does not look astonishing in comparison with 500ps of ADCM553 or  MAX9600. Both of them i am using and they are able to handle signals staying 50mV close to trippoint without any false triggers. And onboard comparator on G431 can do the same (to stay calm even few mV close to trip point)... because its problem is not noise, but single (and only single !) glitch/oscillation/artefact (whatever we call it) during flip. My hypothesis is slow internal threshold change (hysteresis feature just changing input threshold when comparator flips)... but i have no knowledge how it is realised inside MCU ... i have only "alarming observations".

[AScha.3]

Ok, now i understand you more :)

(>single (and only single !) glitch/oscillation/artefact (whatever we call it) during flip )

So it seems a problem of the comparator "block" onchip .

Maybe someone who knows more about this , could help : @STOne-32  , would you take a look ?

[KHarb.1]

Is this only with COMP4?  I just started using an STM32G473 and after some confusion, I see COMP7 and COMP6 working normally...but COMP4 with DAC3 as reference does crazy things.

[Michal Dudka]

I have not tried it on other comparators or on another chip. In some project i've used all 7 comparators on STM32G474 each driven by separated internal DAC channel and they works perfectly (on signals with fast edges, about slow i can't say anything).

[STOne-32]

Dear @AScha.3 @Michal Dudka @KHarb.1  @waclawek.jan ,

Thank you for reaching us on this behavior of the comparator and Hysteresis of STM32G4, we will check to reproduce and back to you in next days.   Much appreciated !

Ciao

STOne-32.