Interrupt behavior and its priority

[PPate.9]

Hello,

I have a basic question regarding timer behavior in STM32.

I have a common callback function HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) that handles timer interrupts at defined periods. I have set different priorities for timer global interrupts in my CubeMX NVIC configuration.

My questions are:

1. Does setting the TIMx global interrupt preemption priority configure the priority for all interrupts generated by the timer (e.g., HAL_TIM_PeriodElapsedCallback, HAL_TIM_TriggerCallback, TIMx_IRQHandler)?

2. What is the difference between TIMx_IRQHandler and HAL_TIM_PeriodElapsedCallback?

3. If I use a common callback function HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) and check the timer instance, will it respect the interrupt priorities and return to the currently running task? For example, if a higher priority timer interrupt occurs while a lower priority timer callback is being executed, will the CPU handle the higher priority interrupt first, then resume and complete the lower priority ISR from where it was interrupted?

Thank you!

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
    if (htim->Instance == TIM1) {
        // Handle Timer 1 interrupt
        // Code specific to Timer 1
    } else if (htim->Instance == TIM2) {
        // Handle Timer 2 interrupt
        // Code specific to Timer 2
    }
}

void TIM1_IRQHandler(void) {
    HAL_TIM_IRQHandler(&htim1); // Calls the HAL_TIM_PeriodElapsedCallback with htim1
}

void TIM2_IRQHandler(void) {
    HAL_TIM_IRQHandler(&htim2); // Calls the HAL_TIM_PeriodElapsedCallback with htim2
}

int main(void) {
    HAL_Init();
    SystemClock_Config();

    // Timer configurations
    MX_TIM1_Init();
    MX_TIM2_Init();

    // Set priorities
    HAL_NVIC_SetPriority(TIM1_UP_IRQn, 3, 0); // Higher priority
    HAL_NVIC_SetPriority(TIM2_IRQn, 5, 0);    // Lower priority

    // Enable IRQs
    HAL_NVIC_EnableIRQ(TIM1_UP_IRQn);
    HAL_NVIC_EnableIRQ(TIM2_IRQn);

    while (1) {
        // Main loop
    }
}

[Pavel A. · Accepted solution]

> Does setting the TIMx global interrupt preemption priority configure the priority for all interrupts generated by the timer

Some timers have several interrupt vectors in NVIC. You need to check in the RM, or just look at the list of interrupt vectors in the startup .s file. Then check that against the list of enabled interrupt sources/handlers in Cube.

If a timer has several interrupt vectors or it shares a vector with other timer or something else, obviously you should set the interrupt priorities carefully.

> What is the difference between TIMx_IRQHandler and HAL_TIM_PeriodElapsedCallback?

TIMx_IRQHandler are the lowest level handlers that receive control when a NVIC interrupt occurs. They are defined per the STM32 model and listed in the  startup .s file. If you use the HAL library with Cube,  Cube will create code for all needed TIMx_IRQHandler's and put there call to the HAL library function that will determine the interrupt reason and then call one of callbacks defined in your code: HAL_TIM_PeriodElapsedCallback and others. These callbacks will be called in context of the NVIC interrupt.

If you don't use HAL library you put your own code in the TIMx_IRQHandler and do there whatever you need.

> if a higher priority timer interrupt occurs while a lower priority timer callback is being executed, will the CPU handle the higher priority interrupt first, then resume and complete the lower priority ISR

Of course, yes.

[Tesla DeLorean]

Which STM32, can we narrow it down a little?

CM0(+) has more limited options.

How you setup the NVIC groupings will allow for or limit Pre-Emption, ie the calling of one interrupt whilst in another.

Normally those at the same levels will simply be ignored until the current one completes and the tail-chaining mechanics decide what to do next or recover the prior context.

Books like those from Joseph Yiu have good coverage on how the NVIC behaves, the configuration, and the context stacking. This might be more practical than the TRM (ARM's Technical Reference Manual) material.