2021-07-08 01:32 PM
I’m using STM32Cube MX 6.2.1, STM32Cube IDE 1.6.1 and STM32Cube_FW_H7_V1.9.0 for a STM32H7A3 project. As recommended, I configured the HAL time base source to a timer other than systick. (TIM17) If I understand correctly, FreeRTOS uses systick and sets its interrupt priority to lowest. (15) So far, this makes sense to me. One interrupt handler for this project needs to have a priority higher than FreeRTOS. So, I set the FreeRTOS parameter LIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY to 5 in MX. The handler won’t use any FreeRTOS FromISR functions. MX locks the TIM17 interrupt priority at 0, presumably because some HAL functions use the tick (uwTick) and would stall if it didn’t increment. Unfortunately, this is enough to mess up the timing of my high priority interrupt handler. As a workaround, I plan to adjust the TIM17 interrupt priority lower (to 4) after the MX generated init code runs. Is this a safe solution? (As long as the high priority interrupt handler doesn’t call any library code that uses uwTick.)
2021-07-09 03:57 AM
Hello @AMacI.1 ,
It is perfectly safe to have an interrupt, other than that used for HAL tick tracking, in higher priority if you have no need for it there as you've deduced. Otherwise, MX might overwrite your settings if you regenerate the project.
Best regards,
@SBEN .2