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.

[mƎALLEm]

Hello,

I created a FreeRTOS project with CubeMx 6.11.1 based on STM32F4 Cube package 1.28.0 and STM32F469-EVAL board, inserted HAL_Delay() (based on TIM6) before osKernelInitialize() and I didn't face any issue. The kernel has started and the LEDs are toggling.

I'm attaching my project.

 

 

[MGall.11]

Hello,

I'm sure that TIM6 works on the evaluation board. What I'm trying to understand is why it doesn't work on my board and why it worked with the old HAL_InitTick function. When I run my project this function return HAL_OK so the initialization seems correct

Are there any differences between the new version of HAL_InitTick and the old one that I need to take into account?

[mƎALLEm]

Hello,

---

I'm sure that TIM6 works on the evaluation board. What I'm trying to understand is why it doesn't work on my board and why it worked with the old HAL_InitTick function.

---

---

Its doesn't make sense to me as it's is basically a Timer running.

Did you just do a simple test with TIM6 running a time base in baremetal ? create a project without RTOS configure Time base source as TIM6 and toggle a LED.

[liteyear]

I was going to start a new topic, but this one captures it.

 

Why did the default system tick timer priority change from 0 to 15? This is a pretty dramatic change, and contradicts vast reams of documentation out there. I think it warrants some breadcrumbs at least, on what the motivation was, and what the implications are.

 

FWIW, I also discovered it adding FreeRTOS, but it turns out FreeRTOS is irrelevant - if I start a fresh project in CubeMX 6.15.0 for the STM32F413VGTx, "Time base: System tick timer" is priority 15 out of the box:

 

 

Furthermore, if I then change "Timebase Source" to TIM1 instead of Systick, then both interrupts get priority 15!

 

 

At the very least, this means that by default the HAL's tick count wont increase if any other ISR is running. That's fine if you know about it, but given the opposite assumption has been true since the dawn of time, it would seem this would cause umpteen issues. What have I missed?

[gbm]

There is nothing wrong with it. No Delay() of any kind should be used in any ISR. Both SysTicks - RTOS and HAL one may safely have the lowest priority, as none of their ISRs takes more than few us to execute which leaves plenty of time in 1 ms time slot for both of them.

[liteyear]

---

@gbm wrote:

There is nothing wrong with it.

 

That's beside the point. I think I was pretty clear about that in the post, even using the phrase "that's fine". But the point remains.

 

No Delay() of any kind should be used in any ISR. Both SysTicks - RTOS and HAL one may safely have the lowest priority, as none of their ISRs takes more than few us to execute which leaves plenty of time in 1 ms time slot for both of them.

---

No. Interrupts are not scheduled by the time they take, but by their priority. So the opposite is true for the HAL one (it's short, yet can be displaced by any other interrupt). And the rational for the RTOS one is different - its duration is variable and can trigger other interrupts. If it could displace higher priority interrupts it would undermine the requirements of a real time operating system. They really do represent vastly different requirements from a priority point of view.

I fear these misunderstandings are being perpetuated by changes like this.

Can you see the point now, or should I try to make it clearer?

[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.