HAL_EXTI_SetConfigLine() generates the continuous interrupt.

[suikan4github]

Describe the set-up

• Nucleo F746
• CubeIDE 1.3.0
• FW F7 v1.16.0

Describe the bug Calling HAL_EXTI_GetConfigLine() and HAL_EXTI_SetConfigLine().

How To Reproduce

1. The demo application gets the EXTI line configuration and saves it by HAL_EXTI_GetConfigLine(). And then, restore it by calling HAL_EXTI_SetConfigLine().
2. Perhaps, HAL_EXTI_SetConfigLine() implementation is wrong. Other series like STM32G4 works fine.
3. To reproduce at your lab, clone the stm32-defects repository.
4. Import the d002-nucleo-f746-exti into the CubeIDE workspace.
5. Build and run it on Nucleo F746.

If the program runs correctly, only the LED2( Blue ) turns on. But we can see both LED2 and 3 ( Blue and Red) turn on. In the EXTI callback, the program just toggles LED2 and LED3. If you see both LED turn on, that means, interrupt is accepted continuously.

Additional context The d002-nucleo-g431rb-control can demonstrate the expected behavior. This is the same logic, but it toggles LED for each time pushes B1 ( EXTI ). the HAL_EXTI_SetConfigLine() is working correctly. This project runs on the Nucleo-G431RB.

This is a duplicated issue with a bug-report to the community.

The detail of the report and program can be here : https://github.com/suikan4github/stm32-defects#d002-stm32f7-hal_exti_setconfigline-runtime-bug

[ALABSTM]

Hi Suikan,

Thank you for this other one report. It will be forwarded to our development teams for analysis. We will be back to you as soon as they provide us with feedback.

With regards,

[ALABSTM]

Hi @suikan4github,

I hope you are doing well. Any news from you side regarding what you reported here? Are you still facing the same issue?

I checked what members from the ST Community replied to your post and I could not read comments confirming the issue.

I also downloaded the zipped projects you shared on the ST Community page. I noticed no particular difference between the F7 and the G4 projects. Would it be an issue at the hardware level (faulty user button)?

Have you tried to set a break point at the call to the HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_13) in the EXTI15_10_IRQHandler() within the stm32f7xx_it.c file? Execution shall freeze at this break point level only when you push the user button.

Thank you in advance for your answers and clarifications. Take care and stay safe.

With regards,

[suikan4github]

Hi @ALABSTM

Thank you for your reply.

First of all, setting the breakpoint shows the same result of LED. In other words, interrupt breakpoints hits continuously while I don't push the button.

The problem still exists on my side. And I don't believe this is the problem of the switch. If I comment out from line 109 to the 123 of the main.c of the d002-nucleo-f746-exti project, it works well ( means LED toggles only when I push the blue button ). Thus, something is wrong in the following sources code.

    // Get the handle of the EXTI 13 ( B1 switch )
    HAL_EXTI_GetHandle(&hexti_b1, EXTI_LINE_13);

    // Save the configuration of the EXTI 13. This is set as  edge interrupt, by  initializer.
    HAL_EXTI_GetConfigLine(
                           &hexti_b1,
                           &hexti_b1_config
                           );

    // Clear the EXTI 13. Interrupt is disabled.
    HAL_EXTI_ClearConfigLine(&hexti_b1);

    // Restore the EXTI13 configuration. Now, it should be  edge trigger.
    HAL_EXTI_SetConfigLine(&hexti_b1, &hexti_b1_config);

Regards,

[suikan4github]

Hi I forgot to add the link to the detailed report. https://github.com/suikan4github/stm32-defects#d002-stm32f7-hal_exti_setconfigline-runtime-bug

I also added same link to the top of this thread too.

[Minloud]

The same bug with STM32G030. Do you have any updates to solve the issue?

[ALABSTM]

Hi @suikan4github and @Minloud,

I hope you are both fine. We could finally catch the bug behind the behaviour you observed and reported. Actually the problem comes from this line below in the HAL_EXTI_GetConfigLine() function:

https://github.com/STMicroelectronics/STM32CubeF7/blob/f8cefdf02e8ad7fd06bd38a2dd85a55ecdbe92a9/Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_exti.c#L304

To fix the issue, the line shall be updated as follows:

-      pExtiConfig->GPIOSel = ((regval << (SYSCFG_EXTICR1_EXTI1_Pos * (3uL - (linepos & 0x03u)))) >> 24);
+      pExtiConfig->GPIOSel = ((regval >> (SYSCFG_EXTICR1_EXTI1_Pos * ((linepos & 0x03u)))));

The defect will be logged into our internal database and a fix will be made available in a future release.

Please excuse the time it took to reply. Thank you for your comprehension and thank you again for having reported.

With regards,

[ALABSTM]

ST Internal Reference: 120908

[carlo-dev-git]

I thiink that the same bug is present in STMCubeH7.

[ALABSTM]

Hi @carlo-dev-git and @Minloud,

Thank you for having reported the issue on the other series. If confirmed, the fix will be propagated.

With regards,

[iabdalkader]

Hi, this will only work if 1 EXTI is set:

+      pExtiConfig->GPIOSel = ((regval >> (SYSCFG_EXTICR1_EXTI1_Pos * ((linepos & 0x03u)))));

regval needs to be masked with 0x0F after right shift, because it includes higher bits from EXTICRx. For example:

In [11]: SYSCFG_EXTICR1 = 0x00003210 # PD[x] PC[x] PB[x] PA[x]

In [12]: linepos = 1

In [13]: hex(((SYSCFG_EXTICR1 >> (4 * ((1 & 0x03))))))
Out[13]: '0x321'

In [14]: hex(((SYSCFG_EXTICR1 >> (4 * ((1 & 0x03))))) & 0xf)
Out[14]: '0x1

Also, why SYSCFG_EXTICR1_EXTI1_Pos is used ? It should be a literal 4 (there are 4 bits per EXTI line config), EXTI1_Pos just happens to be 4 that's why it works.

[ALABSTM]

Hi @iabdalkader,

Thank you for this remark. You are absolutely right! Indeed, the proposed fix does not cover the case which more than one EXTI line is set in. We already spotted this and are testing another fix.

Regarding the use of macro SYSCFG_EXTICR1_EXTI1_Pos, it allows a more generic solution as the EXTIx fields' width varies from one product to another, being 4-bit wide for some and 8 for others.

With regards,

[iabdalkader]

the EXTIx fields' width varies from one product to another, being 4-bit wide for some and 8 for others.

I see, that makes sense, thanks for the clarification! Well in that case it might make more sense to mask regval with SYSCFG_EXTICR1_EXTI0_Msk in my previous example.