Skip to main content
Clonimus74
Clonimus74
Senior II
November 1, 2017
Question

Illogical EXTI code generation in CubeMX

  • November 1, 2017
  • 10 replies
  • 1663 views
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?

    This topic has been closed for replies.

    10 replies

    Alan Chambers
    Alan Chambers
    Associate III
    November 1, 2017
    Posted on November 01, 2017 at 12:26

    The higher numbered pins (5-9, 10-15) share EXTI ISRs anyway, so cannot interrupt each other. If you set the priorities of all your EXTI interrupts the same, none of them can interrupt each other.

    I think it's odd that HAL does not take the opportunity to split out the pins from the shared ISRs. You could have a series of HAL_GPIO_EXTI_n_Callback() functions to implement, rather than having to switch on the GPIO_Pin argument passed to HAL_GPIO_EXTI_Callback(). Not sure how this would solve issues of re-entrancy, though. Aren't such issues generally related to *non-local* data structures which need to be modified atomically? However you slice it, you still need to guarantee atomicity. Briefly disabling interrupts works pretty well, or you can use RTOS synchronisation features.

    Tesla DeLorean
    Tesla DeLorean
    Guru
    November 1, 2017
    Posted on November 01, 2017 at 13:28

    >>

    If you set the priorities of all your EXTI interrupts the same, none of them can interrupt each other.

    Exactly, unless they preempt interrupts will be handled in order.

    With the LRWAN they do actually break down the EXTI into groups using multiple IRQ Handlers. But still call all. It is a generic solution. It allows pin changes at a higher level without having to chase down all the low level nodes.

    Based on my review of the code over the years I'd observe that there is not strong experience with multi-threaded or async stack programming.

    Frequently code in callback (interrupt context) that blocks, or relies on software timers which must preempt. Lot of opportunity for deadlocks or random failure.

    If you think as CubeMX as a rough framing tool you'll be in a much safer place, edit the code to reflect your understanding of what you're doing.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    waclawek.jan
    waclawek.jan
    Super User
    November 2, 2017
    Posted on November 02, 2017 at 09:30

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

    Whatever the design choices in a 'library', inevitably there will be a group of users who find them illogical.

    By using any 'library' or library you voluntarily agree to be bound to a subset of possible functionality.

    JW

    Terms & ConditionsAccessibility statement