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.

[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