2017-09-14 09:02 AM
Using CubeMX 4.21.0
I have GPIO that is attached to an EXTI interrupt. (Pin Configuration page)
On the NVIC Configuration page, the EXTI interrupts are Enabled
The EXTI interrupts are checked to generate IRQ handler (Code Generation)
With this configuration, I get the handler and the GPIO_Init() routines enables the interrupt
If I do not check the Enabled box on the NVIC configuration page, I don't get the interrupt handler emitted when the code is generated.
Using the init sequencing moves the interrupt enables to their own file but it is still within the sections of code overwritten by CubeMx. Thus, I would need to keep making changes every time i emit code from CubeMx.
Is there a way to have cubemx generate the interrupt handler and have the interrupt start disabled that does not require post processing the code?
2017-09-14 05:53 PM
Hello Ed!
To generate an EXTernal Interrupt, should coexist three factors at the same time.
1. NVIC EXTI interrupt enabled. It's done by CubeMX automaticaly as you mention above.
2. Relevant bit set in EXTI_IMR register. It's done by CubeMX automaticaly inside GPIO's init code.
3. External trigger to the relevant pin. Rising edge or/and falling edge.
There is not formal way for cubemx generate the interrupt handler and have the interrupt start disabled. If for example, you don't call the MX_GPIO_Init() inside main function, the next initialized devices that use GPIO pins, will affected.
A different approach is to clear the relevant with GPIOpin, interrupt mask bit in EXTI_IMR reg after initialization, by call
'CLEAR_BIT(GPIOA->IMR, GPIO_PIN_4); ' inside your main function.
In case EXTI interrupt triggered before clear this bit, you can have allready set a global 'EXTI_Uninitialized' flag before call MX_GPIO_Init(). This will used inside EXTI callback function ( ISR), to not do anything if this flag is set.
Just before re-enable interrupt by call 'SET_BIT(GPIOA->IMR, GPIO_PIN_4)' , reset the 'EXTI_Uninitialized' flag.
Regards
vf