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.

[MGall.11]

Hello,

I've commented out the instruction that set uwTickPrio and moved HAL_NVIC_EnableIRQ after HAL_NVIC_SetPriority and it works. Basically that's the difference between the old HAL_InitTick and the new one. I've explored the situation and I noted that TICK_INT_PRIORITY (defined in stm32f4xx_hal_conf.h) has been changed from 0 to 15. This is the parameter passed to HAL_InitTick that finally set the NVIC's interrupt priority register to 0xF0. Conversely, if TICK_INT_PRIORITY is zero than the NVIC's IP is set to 0x00.

Can be this interrupt priority the reason why I'm experiencing a strange behaviour?

[mƎALLEm]

Hello,

I don't have the history of the HAL changes, maybe to check the release notes.

But wanted to confirm my understanding: in the old HAL implementation the systick priority was 0 and in the new implementation the priority is set to 15 which is not working, and setting it to 0 works again?

Note that in the working project I shared with you Systick has the prio 15 (same as TIM6):

[MGall.11]

Hello,

yes, setting TIM6 priority to 0 it works again. Anyway, it's not a change of HAL libraray. It depends on CubeMX version. If I open the old project CubeMX displays a warning since it was created using an old version of CubeMX.

In this version (5.1.0) time base source priority (TIM6) is set to 0 and I cannot change it, as you can see below. System tick timer priority is set to 15.

In the new version, that is the current one (6.11.1), TIM6 priority is set by default to 15, but I can change it. That's the thing I didn't get before. System tick timer priority is set to 15 as before.

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