cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 TIM6 initialization

MGall.11
Associate III

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.

6 REPLIES 6
SofLit
ST Employee

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.

 

 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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?

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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?

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):

SofLit_0-1718811067289.png

 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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.

MGall11_0-1718866211078.png

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.

MGall11_1-1718866310622.png

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.

MGall11_2-1718866542051.pngMGall11_3-1718866581446.png