STM32F4 TIM6 initialization

[MGall.11]

Dear all,

I'm working on a project based on STM32F479 and FreeRTOS. In this project the microcontroller is connected via I2C and SPI bus to other devices, such as switch ethernet and spi-uart converter. I run the initialization of these devices before the start of the FreeRTOS scheduler. Startup procedure requires switching some GPIOs and waiting a few milliseconds as described in the devices datasheet. I've manged the waiting part of the initialization using the HAL_Delay function. This project has been generated in 2019 with STM32F4 fw package 1.24.0 and an old version of STM32CubeMX.

Recently I've created a new project for the same hardware using fw package 1.28.0 and STM32CubeMX 6.11.1. I noticed that the initialization of TIM6 in stm32f4xx_hal_timebase_tim.c has been updated and HAL_InitTick function is changed (which you can find in the attachment). Now I'm experiencing a strange behaviour. During devices initialization the program remains stuck in the HAL_Delay function. Apparently TIM6 interrupt is not running before the start of the scheduler, so the global variable uwTick is not incremented and as a result HAL_Delay waits forever. I had to move the initialization of the devices after the start of the FreeRTOS scheduler to solve the issue.

Can anyone help me figure out what I'm missing?

Best regards.

Massimo G.

[gbm]

Sorry, I cannot see your point. Both SysTicks are non time-critical. RTOS SysTick interrupt does not trigger other interrupts (other than PendSV of the same priority as SysTick). All the other IRQs are more critical. In a properly designed system the CPU will never be saturated. With a classic, event loop approach and with RTOS-based approach, SysTicks should have the lowest priority. In some cases higher SysTick priority may be desirable in purely interrupt-driven firmware design, where the lowest priority, software-triggered interrupts logically replace the event loops for time-consuming tasks (so they may require timekeeping services).

[liteyear]

The point is it changed. You may like it better that way, but that is beside the point.

You continue to make an argument about what it should be. That's beside the point. The point is it changed.

I hope that makes it a bit clearer.

[gbm]

OK. When you use FreeRTOS with CubeMX, it automatically adjusts interrupt priorities to make your life easier. So it sets both SysTicks and PendSV to the lowest priority and it sets all the other peripherals' IRQs to RTOS Syscall priority (5 by default, unless you chage it). That's actually quite good as a starting point. You may still change the priorities manually in NVIC settings.