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 · Accepted solution]

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.