PG0 EXTI0 interrupt HW bug in STM32H743ZI MCU

[Torsten Jaekel]

I use on STM32H743ZI-Nucleo PG0 as GPIO interrupt with Falling Edge. It works, I get INT triggered, but:

an INT is also triggered - sometimes (once every 1000 falling edges) - on a raising edge. After several tests I am sure, this PG0 EXTI0 is randomly and sporadicly also triggered by a rising edge and dependent on when you clear the INT GPIO flag (e.g. much later) also on a low-level.

It is very disappointing because I get false, spurious interrupts: Sometimes, when I clear the INT reason on my external chip (e.g. via SPI register write), the signal is de-asserted (goes high for a low-active interrupt) - this raising edge triggers again my EXTI0 ISR handler,

in a random, sporadic way.

I am sure, GP0 as EXTI0 with falling edge trigger does NOT work properly.

And it looks like a HW bug inside the STM32H7 MCU itself:

if I route the same signal from PG0 to PF3 and use EXTI3 ISR handler instead, with the same way to configure, handle INT, similar ISR etc. - all is fine, no spurious INTs.

So, it cannot be my board, it cannot be the NUCLEO board - the PG0 EXTI0 falling edge triggered INT does not work properly.

It seems to be triggered by some other events, by internal glitches or cross-talks.

The signal on PG0 looks fine on logic analyzer, scope and as mentioned: just bring PG0 to PF3 and all works fine (must be inside the MCU, PG0 is clear of glitches).

What to do?

Assuming the HAL drivers, macros etc. are correct (because they work on PF3), it looks to me like a (serious) HW bug inside the INT Controller of the MCU.

I have not found a way as a work around, e.g. via disable EXTI0 INT in ISR, CLEAR INT before and nable EXTI0 again at the final end: it looks like, it is still triggered again, even when disabled and I get EXTI0 triggered randomly again on the raising edge of the signal just by

enabling the EXTI0 again.

--> PG0 EXTI0 sees glitches inside MCU or the falling edge trigger is flaky and triggers

also on raising edge or even level

Please,

STM Team:

Is this a HW bug? (it looks to me)

Is there a work-around (but still using PG0 because my board design is done)?

Thank you.

Torsten Jaekel

[Torsten Jaekel · Accepted solution]

I am SOOOO sorry,

my mistake: it works!

Issue:

The signal inbound to the MCU was configured as an Open Drain. There was not a pull-up provided on my extension board so that this signal was "floating" during the inactive, high level period.

This signal goes through an external Schmitt-trigger IC before it reaches the MCU.

So, depending on the PCB trace length (trace capacity, cross-talk charge) it could generate a glitch on the signal. On a rising edge the Open Drain signal can go again low which triggered my EXTI0 interrupt.

All FINE after changing this signal to a Push-Poll signal.

The only impression (conclusion): EXTI0 (with PG0) is more sensitive for glitches.

But datasheet says clearly: make sure such a signal is glitch free.

So, if you realize similar issues: check if signal is an Open Drain output going to MCU and if there is a pull-up resistor.

All fine, no issues with the MCU.

[S.Ma]

Great! Usually for any programmable chip device functionality (from what is told in Ref Man and Datasheet) is being tested at EWS (Electrical Wafer Sort) wafer level and at package level (Final Test). Good test coverage (a percentage) limits design level bug finding at application level.