[bug report] EXTI IRQ erroneously enabled when initializing in separate .h/.c files

[Sune Jensen]

STM32CubeMX version: 6.10.0

Firmware version: STM32Cube FW_G4 V1.5.1

 

I have configured a GPIO pin as EXTI and configured that the interrupt should not be enabled when initializing the GPIO, (i.e. removed the check mark from "Generate Enable in Init").

If the initialization code is generated in main.c, the interrupt is not enabled (as expected).

// In main.c

static void MX_GPIO_Init(void)
{
 /* ... */

 /* EXTI interrupt init*/
 HAL_NVIC_SetPriority(EXTI0_IRQn, 5, 0);

 /* ... */
}

 

However, if the initialization code is generated in separate .h/.c files, the interrupt is erroneously generated.

// In gpio.c

void MX_GPIO_Init(void)
{
 /* ... */

 /* EXTI interrupt init*/
 HAL_NVIC_SetPriority(EXTI0_IRQn, 5, 0);
 HAL_NVIC_EnableIRQ(EXTI0_IRQn);

 /* ... */
}

[Mahmoud Ben Romdhane]

Hello @Sune Jensen ,

First let me thank you for posting.

I suggest that you provide your ioc.file for more investigation.

Thanks.

Mahmoud.

[Sune Jensen]

Hey Mahmoud

I attached a minimum working example. It did yield some additional clues.

The problem only exists if more than a single pin is configured as EXTI.
If "Generate Enable in Init" is unchecked for all EXTI lines, the code is generated correctly. However, if at least a one line has the option checked, the IRQ is enabled for all lines.

My bug report seems to be a duplicate of https://community.st.com/t5/stm32cubemx-mcus/stm32cubemx-6-6-1-quot-generate-enable-in-init-quot-does-not/m-p/84845

I can however add the info that the bug only occurs if initialization code is generated in separate .h/.c files. When initialization is generated in main.c, only the desired IRQs are enabled.

[Mahmoud Ben Romdhane]

Hello,

I escalated the problem to CubeMx team in an internal ticket (ID: 168700 ) to take a closer look at this issue.

(PS: ID 168700 is an internal tracking number and is not accessible or usable by customers).

Thanks.

Mahmoud.