Unexpected EXTI Interrupt Behavior on STM32F407VETx

[MarcoTedoldi]

Hello everyone,

I’m working on a control unit board based on the STM32F407VETx (LQFP100) microcontroller. During development I noticed that some pins configured as external interrupts (rising edge) were being triggered more often than expected.

To better analyze the issue and exclude possible mistakes in my code, I prepared a minimal test project with the following configured pins in IOC:

• Pin 9 – PC15: GPIO_EXTI15 - INPUT_1

• Pin 97 – PE0: GPIO_EXTI0 - INPUT_2

• External crystal/ceramic resonator (HSE)

• Serial Wire Debug with SysTick as timebase source

The only user code added is in gpio.c:

/* USER CODE BEGIN 0 */
volatile uint8_t counter_1 = 0;
volatile uint8_t counter_2 = 0;
/* USER CODE END 0 */

.
.
.

/* USER CODE BEGIN 2 */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
 
 if(GPIO_Pin == INPUT_1_Pin) {
 counter_1 = (counter_1 + 1) % 255;
 }

 if (GPIO_Pin == INPUT_2_Pin) {
 counter_2 = (counter_2 + 1) % 255;
 }

}
/* USER CODE END 2 */

 

On my board both PIN9 and PIN97 have the following input circuit:

 

Additionally, although not used in this test project, the board also supports CAN communication thanks to the following circuit:

For testing, another ECU cyclically sends 8 CAN messages (DLC 8, extended ID):

• 7 messages at 10 ms repetition rate

• 1 message at 100 ms repetition rate

On the input pin I generate a 0–12 V square signal (verified with an oscilloscope), and I monitor counter_1 and counter_2 using STM32CubeMonitor.

OBSERVATIONS:

• counter_1 (PIN 9 - PC15): Increases more than expected only when ST-Link is connected and CubeMonitor is running. Disconnecting ST-Link restores the expected behavior. CAN traffic has no influence.

• counter_2 (PIN97 - PE0): Increases more than expected only when CAN messages are being sent. Stopping CAN traffic restores the expected behavior. ST-Link connection has no influence.

I’ve attached the code and screenshots from both the oscilloscope and CubeMonitor showing all test combinations.

 

Has anyone experienced similar behavior? Could you help me understand why these unexpected triggers occur?

Thanks in advance!

 

[waclawek.jan]

Sounds like coupling between CAN/pin97 resulting in pulses/spikes at pin 97, something similar with pin 9 too.

Sometimes the coupling is capacitive, but often these problems are related to board layout, particularly, also too often, to ground arrangement and currents flowing through ground (sometimes also supplies). Note, that EXTI is asynchronous, i.e. it reacts to very short (nanoseconds) pulses regardless of the system clock.

There's no point in measuring the 12V input. With very good oscilloscope probe and fast oscilloscope you can attempt to measure *directly* at the pin in question, with ground connected through a very short pigtail to the nearest VSS pin of the mcu; however, I repeat, we are talking single-digit nanoseconds here.

Generally, EXTI is better to be avoided. Use either timer inputs, which are synchronous and have an optional digital filter; or, as your input signals appear to be changing in the timeframe of seconds, simply sample the inputs in a periodical interrupt (e.g. 10-100ms, whatever is suitable).

JW

 

[MarcoTedoldi]

Thanks for your reply.

 

I had the same assumption, but in case of signal coupling between CAN/PIN97 and ST-Link/PIN9 I would expect that, with a fixed input level (always 12 V or always 0 V), the variables counter_1 or counter_2 would also increase.

However, this does not happen: the unexpected increments occur only when the input signal is oscillating.

 

To further investigate, I modified the IOC configuration of INPUT_1 and INPUT_2  to trigger on both rising and falling edges, and I updated the callback as follows:

/* USER CODE BEGIN 2 */
GPIO_PinState INPUT_1_status = GPIO_PIN_RESET;
GPIO_PinState INPUT_2_status = GPIO_PIN_RESET;

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
 
 if(GPIO_Pin == INPUT_1_Pin) {
 if(HAL_GPIO_ReadPin(INPUT_1_GPIO_Port, INPUT_1_Pin) == GPIO_PIN_SET && INPUT_1_status == GPIO_PIN_RESET)
 {
 counter_1 = (counter_1 + 1) % 255;
 }
 INPUT_1_status = HAL_GPIO_ReadPin(INPUT_1_GPIO_Port, INPUT_1_Pin);
 }

 if (GPIO_Pin == INPUT_2_Pin) {
 if(HAL_GPIO_ReadPin(INPUT_2_GPIO_Port, INPUT_2_Pin) == GPIO_PIN_SET && INPUT_2_status == GPIO_PIN_RESET)
 {
 counter_2 = (counter_2 + 1) % 255;
 }
 INPUT_2_status = HAL_GPIO_ReadPin(INPUT_2_GPIO_Port, INPUT_2_Pin);
 }

}
/* USER CODE END 2 */

With this change, the issue on counter_1 (so PIN9 - PC15) disappeared. The anomaly on counter_2 , however, is still present.

 

For this reason, I believe that coupling between ST-Link and PIN9 is unlikely. Some doubts remain about possible coupling between CAN and PIN97, although I cannot explain why the effect appears only with an oscillating input signal.

Finally, I also measured the signals directly on the MCU pins with the oscilloscope. The waveforms looked clean, but I acknowledge that my oscilloscope bandwidth might not be sufficient to reveal very fast disturbances.

 

Do you have any other suggestions or hypotheses that could help explain this behavior? Any additional insights would be greatly appreciated.

[waclawek.jan]

> the unexpected increments occur only when the input signal is oscillating.

My guess is, that the input signal has a long rise/fall time, and the interference from STLink has a relatively small amplitude (so in itself it won't cross the input threshold), but is superimposed at that input signal, and when that reaches the vicinity of the input threshold, that superimposed "noise" results in a bunch of rapid EXTI interrupts.

The change you've made in the code effectively filters out shorter pulses; however, "shorter" here depends on the interrupt latency (including the Cube/HAL code, which may be significantly long).

I maintain what I wrote above.

JW

[gbm]

I suspect something weird related to ground connections/potentials between the PC used for debugging, CAN stuff and your MCU power.