HAL_Delay problem when adding ThreadX to the project

[wMESTIRI]

Hello everyone,

I'm working on the µc STM32H5, I have an application that runs correctly, and when I configure the threadX in the project for which I've configured the TIM6 as the basic timer and I've released the SysTic for the threadX using CubeMx. I've had a problem with the HAL_Delay API, which doesn't work outside my configured tasks because the TIM6 handler isn't triggered and consequently the uwtic doesn't increment any more.

In NVIC I've configured a priority of 15 for the TIM6.

After debugging I found that the TIM configuration is correct but the Handler is not triggered.

 

 

Any feedback is appreciated!

[Sarra.S]

Hello @wMESTIRI, 

Start by verifying TIM6 configuration, clock is correctly set, interrupt enabled, also check if the interrupt Handler is in the generated code in the stm32h5xx_it.c file 

[wMESTIRI]

Hello @Sarra.S,

Thanks for the answer,
I mentioned in my previous comment that the TIM6 configuration is correct.
If I don't use the HAL_Delay outside my threads, the handler of TIM6 triggers and works correctly. But the problem is that when I add the HAL_Delay outside ThreadX tasks, the code gets stuck in this construction and prevents the TIM6 handler trigger.

Below is TIM6's config:

 

 

[TDK]

> In NVIC I've configured a priority of 15 for the TIM6.

Which is the lowest priority. It should be configured with priority 0 if you want to use it in interrupts with priority 1 or greater.

[wMESTIRI]

I tried to configure the TIM6 with a high priority and had the same problem.

[wMESTIRI]

Hello,

I managed to solve the problem I was experiencing with the HAL_Delay() function.
As a reminder, the HAL_Delay() function didn't work outside ThreadX tasks. After some investigation, it turned out that the problem was linked to the SysTick configuration.
My bootloader configures and uses the SysTick timer for its own purposes. However, this configuration is not compatible with the requirements of my application. When the bootloader left the SysTick in a state incompatible with the application, this led to malfunctions, including the blocking of HAL_Delay().
The solution was to disable the SysTick in the bootloader before switching to the application. And to activate the global interrupt at the start of the application so that the TIM6 trigger will work. This allows the application to take control of the timer and configure it according to its needs, thus avoiding potential conflicts

 

thanks to all