Illogical EXTI code generation in CubeMX

[Clonimus74]

Posted on November 01, 2017 at 10:50

Hi all,

I find the code generated by the CubeMX for EXTI line illogical.

Every EXTI ISR (e.g. EXTI0_IRQHandler, EXTI1_IRQHandler calls for the same function: HAL_GPIO_EXTI_IRQHandler, which in turn also calls for the same function: HAL_GPIO_EXTI_Callback.

That means that both must be re-entrant functions, which makes the implementation riskier.

With HAL_GPIO_EXTI_IRQHandler I understand, since it should not change and it relies on HAL_GPIO_EXTI_Callback.

The thing is that if I want to not rely on HAL_GPIO_EXTI_Callback and prevent using re-entrant code, I need to check the flag (__HAL_GPIO_EXTI_GET_IT) in the specific ISR (e.g. EXTI0_IRQHandler), the flag is checked in a not so logical place, in HAL_GPIO_EXTI_IRQHandler after some of my code was already executed in the specific ISR.

I would think a specific callback for each EXTI should have been generated to prevent the risk of re-entrancy.

Thoughts?

[Alan Chambers]

Posted on November 02, 2017 at 12:01

>> How do you set this register in regard to preemption and sub-preemption (e.g. I have 1 bit for sub and 3 bits for preemption)?

Good question. I don't use sub-priority. I suspect BASEPRI relates to all the priority bits (in this case 4 bits), so that setting it to 15 would disable interrupts with pre 7 sub 1 but not interrupts with pre 7 sub 0, but setting it to 14 would disable both. Or I might be talking out of my hat.