[STM32G0B0] External interrupt

[YDann.7]

Dear,

I'm using a STM32G0B0RET6 as MCU and I encouter a bug on GPIO external interrupt specifically on PC14.

Configuring as external IT on rising edge, it works correctly and the interrupt is generated only on rising edge.

Configuring as external IT on falling edge, an interrupt is generated 2 times, 1 on falling edge and 1 on rising but both call the HAL_GPIO_EXTI_Falling_Callback callback.

Configuring as external IT on falling and rising edge, an interrupt is generated 3 times (consistent with previous configurations).

Configuring this pin (PC14) as external interrupt on falling edge generates a falling interrupt on rising edge.

(I precise I checked EXTI registers and they are correctly configured)

If I do same tests on PC13, all work correctly. ITs are generated in accordance with the configuration.

A workaround is to the check the state of this pin in the interrupt callback but it seems to be a bug.

(and I saw nothing in the errata sheet)

[TDK]

It's pretty unlikely there's a critical silicon flaw here. More likely to be a test setup issue.

Can you replicate using the pin itself as the signal source? Set up PC13 as output + interrupt and trigger the interrupt that way. Post code if you can.

What board hardware are you using?

[waclawek.jan]

Your input signal is not clean enough. Noise - and it often originates in improper grounding/return arrangement but there may be other sources, too - superimposed on the edge results in 3 threshold crossings upon your rising edge - rising, falling, rising - but they are in a rapid succession, so at the moment when the software starts to process them both rising edges have already passed so the software sees only one of them. Note, that EXTI is asynchronous and capable to capture spikes faster than is the system clock.

You may be better off using some of the timers' inputs, they are synchronous and have optional digital filter, too.

JW

[Karl Yamashita]

Is this a custom board? Schematic?

[YDann.7]

It's on a custom board.

The MCU is connected to a sensor which periodically pull down this pin to enable an "I2C communication window" and pull up at the end of communication.

I did the test that mentionned @TDK and it works fine that expected so it's not a MCU problem.

But it's ok now. I removed the logic analyzer connected to the pin, which allowed me to capture and see what was happening, and I don't have any problem. So I called that a "pebkac".