Comparator Bug Report on STM32G0

[Carl_G]

I have configured the comparator 2 PB6 on the STM32G071RB Nucleo board. It is configured for rising edge interrupt.  As soon as HAL_COMP_Start is called on the COMP you can see the EXTI rising edge interrupt flag immediately go high. (well not immediately, it happens when HAL_COMP_Start is in its startup wait loop so presumably as soon as the COMP peripheral physically starts up.) This happens even if I change it to falling edge but I guess that should be expected. but certainly not reliably both!

It seems that this is how the MCU works as I can't find any obvious mistakes in the LL or HAL driver startup function. I have seen several posts to this effect over the last 4-5 years with 1 to 2 replies but no solution.  I think the reference manual needs to mention that this will happen as it seems to be an MCU behavior. Is it only the G0?

The COMP output also triggers. But the input does not move. My guess is that when COMP is activated the initial value of the negative input is initializing and low to COMP and causes a trigger. But I don't know as I can't tell any internal MCU values. This happens even if I use DAC as the negative input. I guess its kind of expected and maybe the interrupt should not be on before the COMP? But that's how the IDE does it.

Note: this is not a real trigger based on real circuit voltage. Please test this for yourself. I have changed from my custom board to the demo board to avoid the questions about the hardware.

 

Below you can see the INP in green. Negative is 3/4 refint voltage. You can see a slight bump in INP that I assume is due to GND shift from the COMP drawing a bit more power? Anyway, not enough to properly trigger. Yellow is the COMP output.

This happens only at start but no false triggers afterward.

 

 

[waclawek.jan]

> I have seen several posts to this effect over the last 4-5 years with 1 to 2 replies but no solution.

Can you gave links to these, please?

On the waveform you've posted, at which point does the false EXTI happen? Isn't rising edge interrupt the expected one there?

While this is annoying indeed, is it something hard to mitigate, once you know about it?

JW

[Carl_G]

Other examples

> Can you gave links to these, please?

https://community.st.com/t5/stm32-mcus-products/comp2-and-exti-does-not-seem-to-work-using-hal-stm32l452/td-p/68790

https://community.st.com/t5/stm32-mcus-embedded-software/avoid-interrupt-after-hal-comp-start-hcomp1/td-p/108438

 

>On the waveform you've posted, at which point does the false EXTI happen? Isn't rising edge interrupt the expected one there?

The rising yellow trace is the output of the comparator.  The green line is the input. At no point does the INP go high so there should never be any COMP detection.  This happens right at enable.

>While this is annoying indeed, is it something hard to mitigate, once you know about it?

Agreed. That's why I haven't asked for a fix but instead a statement in the reference manual or the errata. That way others won't have to spend as much time as I did proving out every element of their hardware and software trying to figure out why the comparator is behaving that way. 

[Sarra.S]

Hello @Carl_G, 

We've reproduced the COMP behavior internally using an STM32G071, the root cause is that the interrupt (NVIC IRQ channel) from COMP is enabled before enabling the COMP peripheral.

As the COMP is an analog peripheral, it takes some time to startup, during this time, the digital output from COMP is not stable (potentially causing glitches), which can generate interrupt on any edge.

The sequence in the RM should be corrected and propagated to all impacted products (Internal ticket number: 201172)

For the moment, you can follow this sequence: 

1. Enable COMPx and wait the associated startup times.
2. Configure and enable the EXTI lines corresponding to the COMPx output event in interrupt mode and select the rising, falling or both edges sensitivity.

3. Clear any possible pending flag for given EXTI lines.
4. Configure and enable the NVIC IRQ channel mapped to the corresponding EXTI lines.

Please note that step3 is not mandatory, but to eliminate any parasitic edge when line is enabled with rising edge sensitivity while the COMP output is already high.

Hope this is clearer for you!

Thank you! 

[Carl_G]

Thank you for your response @Sarra.S 

I will follow your advice.

[Carl_G]

I actually just got around to trying this as a real solution. It doesn't work. Its not just at startup that this happens. It seems somewhere in the MCU the flags are kept hidden. Once I enable the IT I get the rising edge flag. It can't be easily cleared. It also does not show right away. Sometimes up to 500uS later before this flag shows up. But its not from anything that just happened. I presume its from long ago when there was some rising edge and this flag got stored but hidden. Trying to clear it does not work. Essentially, I have to spin in a while loop and keep calling clear. After some time it will clear. But again, you need to spin in a while loop waiting for it to appear before you spin in a while loop clearing it.

I even followed through the HAL with the debugger to see how it handled this. When I start the COMP the HAL will handle the spurious IRQ. However, the first time the HAL tries to clear the flag it doesn't actually clear. So the IRQ gets called back right away. On the second call the HAL is actually able to clear the flag.

Something is seriously wrong.

The only solution seems to be that you have to keep the COMP always on and the IT always on as well. But even then as I say, the HAL took two passes to clear the IRQ. Maybe I need to grow my knowledge about how the NVIC and EXTI work because so far this doesn't make sense.

[truhy]

I also got this problem on a custom board with STM32G071KBT.  My workaround which does work, is an added check for the comparator source (comparator1 in my case) within the callback, e.g.

void HAL_COMP_TriggerCallback(COMP_HandleTypeDef *hcomp){
	if(hcomp->Instance == hcomp1){
		// Comparator is triggered
	}
}

 The initial trigger doesn't have the comparator instance set.

[Carl_G]

Dropping in to give a heads-up while I continue to resolve this issue. It is partially my fault. I haven't figured out which parts are caused by me and which are STM32.  Nevertheless, this is partially caused by having the ADC on and active on the same GPIO as the COMP.

[waclawek.jan]

> Nevertheless, this is partially caused by having the ADC on and active on the same GPIO as the COMP.

Do you mean the same *pin*?

JW

[Carl_G]

Yes. Pin 12. PA1. Both ADC IN1 and COMP1_INP

It sounds like you’re encountering a known behavior with the STM32G0 comparators. What you’re seeing—the EXTI rising edge interrupt flag going high as soon as HAL_COMP_Start is called—is indeed tied to how the COMP peripheral initializes internally. When the comparator powers up, the initial state of the input pins (especially the negative input) can temporarily trigger the output, which in turn sets the EXTI flag. This is why even with DAC as the negative input, you may still see a brief interrupt.

A few points to keep in mind:

1. Startup Behavior is Expected: Many STM32 MCUs, including the G0 series, can exhibit this behavior. The reference manual may not explicitly highlight it, but it’s a hardware characteristic rather than a driver bug.

2. Interrupt Timing: If you need to avoid false triggers, it’s often recommended to enable interrupts only after the comparator has fully stabilized. You can implement a short delay or check the output state before enabling EXTI interrupts.

3. Use of DAC Input: Using a DAC for the negative input can help stabilize the input voltage, but initial transient effects from powering the COMP are usually unavoidable.

4. MCU Variants: This seems more common in the G0 series due to how the comparator startup sequence is implemented; other STM32 families may behave slightly differently.

In short, what you’re observing is mostly a normal startup artifact, and handling it usually involves software checks or delaying EXTI interrupt activation until after startup stabilization.

For a practical guide on handling STM32G0 comparator startup and avoiding false triggers,

<a href="url">Click here</a> to visit my site.

[waclawek.jan]

This explains it.

ADC sampling means, that a sampling capacitor charged to some unspecified voltage is connected to the signal input.

Depending on the signal source's impedance, this generates a voltage spike, and the comparator "sees" it.

Transients during COMP startup may make this worse.

JW

[Carl_G]

I agree. However, the previously sampled channel is an exact replica circuit. So in theory it should have been charged to the same voltage. But i guess there's more to it than that.

[waclawek.jan]

> So in theory it should have been charged to the same voltage.

ST does not specify this nor does ST publish the exact architecture from which this could be inferred.

I've experimented and found that for example on a 'F4, if you take repeated conversions on a single floating pin, even if you ground it briefly i.e. you start from 0V, the conversion leaves the sampling capacitor at a nonzero voltage and the pin will eventually drift to cca 0.7V (while VREF+ is around 3V).

JW

[Carl_G]

I also made provisions to sample a grounded pin prior to this sample. But I thought what could be better than sampling the same voltage. Sometimes things just work until they don't.