Showing results for 
Search instead for 
Did you mean: 

STM32G431 Comparator BUG


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 detectionFalse falling edge detectionDouble rising edge detectionDouble rising edge detectionHysteresis provedHysteresis provedSmall noiseSmall noise

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


Accepted Solutions
Simon V.
ST Employee

Hello Michal,

What you are observing may be relative to the Miller effect inside the comparator circuitry.

Would it be possible for you to set bit#1 (not documented) in COMP_CxCSR, it enables a compare feature which hold the comparator output during the duration of the Miller effect.

On my side, using your setup and a nucleo board, I was able to hold the comparator output during the falling phase and obtain the expected behavior. 



To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post


It seems that a comparator with 70mV hysteresis which is flipped by less than 10mV noise is not an interesting topic. To be sure that i am not wrong, i've measured comparator HW output by 1GHz active probe (included screenshots).

I will summarize the observation:
1. EXTI often catch rising edge on comparator output even input signal is falling
2. Input signal noise (<10mV) is much less then comparator hysteresis (nominal ~70mV)
3. That happen even if any fast or sensitive signal is outputed from MCU (comparator HW output disabled, DAC output only internal)
4. Regardles of MCU clock frequency (16MHz or 170MHz)
5. Nasty spikes can be seen on comparator HW output if enabled (and pin speed set to maximum) - I susspect these spikes are inside MCU and are source of problem (EXTI is fast enought to detect them).

Anybody who will want to detect "reasonable low" noise slow rising or falling edge by comparator on STM32G431 will have to find some workaround.


> It seems that a comparator with 70mV hysteresis which is flipped by less than 10mV noise is not an interesting topic

It is an interesting, but at the same time also hard, topic.

As you've demonstrated, the hysteresis as such works, so that's not the primary issue here (and, as you've noted, the digital clocks are not that relevant here, as EXTI is asynchronous and apparently perfectly capable of capturing the spikes you're observing).

I'd say, this is entirely unrelated to the input signal's noise either. If anything, the input signal's impedance may be questioned, but then, the blue traces in initial post are measured directly at the comparator input pin, aren't they? 

So, I'd say the output capacitively coupling into the other (reference, DAC-driven) input, or a more complicated effect within the comparator itself e.g. through common ground impedances or through VREF+->DAC.

So, I'd start with looking closely at the DAC output and at VREF+ (and perhaps even at VDDA?). I'd try to bring out DAC to external pin and decouple, and/or try some stable external voltage used for negative comparator input instead of the DAC.

In the past, @Igor Cesko was providing here excellent help with the 'G4 ADC; maybe he can offer some insight into other analog features of 'G4 such as DAC and COMP, too?


PS. You don't use the S&H mode of DAC, right?

I am not using S&H mode and blue traces are measured at input pin. Thanks to pointing on VREF+. STM32G431 have VREF+ hardconnected to VDDA. I checked the VDDA supply voltage and it is clean (SB5 jumper on G431KB nucleo removed). I also tried bring DAC output to GPIO and add filter (22nF to GND) and with no effect. DAC output voltage is clean too. I've didnt tested ground bounce, but i suppose that ground impedance on Nucleo32 kit is low enought. And moreover i've measured the same behaviour on two different PCBs with exactly the same "glitch shape".

To summarize:
6. Enabling, disabling compartor output neither its slew rate have no effect - no fast signals outside MCU
7. AVDD looks clean (scope trigger synchronized by comparator slew limited output), DAC output (if used) looks clean the same way (trace included).
8. Changing comparator negative input from DAC driven to "internal Vref" driven have no effect. Exactly the same output glitch shapes.
9. Lowering input waveform slew rate to stay at threshold voltage for a longer period of time have no effect. Duration, rate and shape of spikes are the same.

Used comparator 4 have no external connection for negative input. To test fully externaly controlled comparator i have to change test setup. That may or may not bring another information about cause of problem. But probably does not change anything on original problem with comparator with internal DAC/Vref threshold.

It looks like that threshold change (hysteresis) is slower then comparator and therefore there is short "window" where comparator works effectively without hysteresis.

by the way, what is purpose of SB5 ?


Sorry, I have nothing relevant to add.

> by the way, what is purpose of SB5 ?



No idea...



I dont think it is close. But it looks like that you are confusing VREF and Vrefint in your original question (i will reply in original thread).

And could this be related - i.e. do you have any other analog peripheral active?


As far as i know it is not related. He was performing ADC measurments on the same channel where was comparator input connected and ADC sampling simply changed input voltage, probably due high signal impedance.

I believe it is silicon bug, arising from super fast comparators, probably fastest i've ever seen on MCU. I've casually tested them and they can handle much shorter pulses then 17ns (propagation delay) and i will test them properly soon, when my student begin to work on pulse detector.

Sorry I haven't noticed that the ADC works on the same pin.

However, my point was, couldn't other analog functionality impact output of DMA or the comparator itself, via common supply/reference/ground paths or otherwise. There are several non-digital ADC errata (End of 10/8/6-bit ADC conversion disturbing other ADCs, ADC input channel switching disturbs ongoing conversions, An ADC instance may impact the accuracy of another ADC instance at specific conditions), and also the 'G4-specific ADC appnote, indicating, that while 'G4 is aimed at replacing 'F3 as the mixed-signal solution, there may be shortcomings in the analog paths.

Also, IIRC, ST mentioned reduced number of GND/VCC pins on the 'G4 (and 'G0) citing some innovative power arrangement; I am lazy to look this up at the moment, but that also might rise doubts.

That's why I was asking, whether you are running some other analog functionality alongside the COMP test.




>I believe it is silicon bug

Maybe. However, I am somewhat reluctant to accept the idea ST would not perform basic COMP testing on what again is supposed to be a mixed-signal family. I can imagine a scenario where they tested it in separation, see above. I also can imagine that certain packages perform worse than others and the chip was tested in some particular package or as a bare chip. I can also imagine

Nonetheless, at this point, given your findings, pending further explanation from ST, I personally would not consider the 'G4 COMP as usable. I would perhaps consider external comparator instead, or would perhaps also consider the "more conservative" 'F3 (although, differences in COMP details between the 'F303xB/xC and 'F303xD/xE may rise questions too).