ThreadX/AzureRTOS on STM32H7 messing with HAL tick timer. Anyone experienced the same thing?

[KKorn.1]

HAL timebase set to use TIM6. ThreadX uses SysTick.

My code is minimalistic for the test-project when debugging this issue. ThreadX is set up to have 1000 ticks/second as opposed to the default 100 ticks/second.

I have one thread printing out HAL_GetTick() and _tx_time_get() after a tx_delay of 1000 milliseconds.

HAL_GetTick as we all know returns uwTick, which gets incremented by the TIM6 interrupt callback.

ThreadX returns the correct time, while GetTick() returns a value that gets incremented by about 15 for every 1000 ms. My only explanation for this is that ThreadX disables the interrupt that calls the TIM6 IncTick function while it does scheduling work in the background, but I have a hard time believing this as I can't find anyone else facing the same issue online.

[T J]

I Can't help today but tomorrow I will get my H735-Dk

while I'm waiting, I've been trying to compile Azure MQTT without success.

which example did you start with ?

which board are you using ?

Do you have to use Tim6 ?

I just usually install the Systick callback an have no trouble with the H7 on that.

What priority are you using ?

I never use RTOS. having to for the first time now.

I wonder if RTOS is disabling interrupts... is that part of the thread safe locking mechanism ?

[KKorn.1]

I didn't start with an example and the board is custom-made (industrial application).

You don't have to use TIM6, but you shouldn't use SysTick as timebase when implementing an RTOS as the RTOS is given full control over the SysTick configuration, this can lead to unpredictable behavior.

A workaround to my issue is to override the weak HAL_GetTIck() function and make it return the ThreadX system timer once the kernel has started. Since their tick resolution is the same, this leads to identical timing behavior. Would still like to know the cause of this though.

[Haithem Rahmani · Accepted solution]

Hi @KKorn.1​ 

you are right, ThreadX is disabling all interrupts including the TIM6 one. in the ThreadX 6.1.8, there was support for the BASEPRI, allowing the application to define the subset of interrupts to mask. This should fix your issue.

regards

Haithem.

[KOkun.1048]

Hi @KKorn.1​ ,

I think you can resolve your issue by setting priority 14 (less than 15) to TIM6 in NVIC.

[HMcKi]

This also worked for me, i don't understand how this and "ThreadX is disabling all interrupts" can be true though?

[Johannes]

I got the same effect with NucleoU575

STM32U575 which ships azure ThreadX directly integrated into CubeIDE.

Same Effect. I use Timer 7 as Systic.

Timer is configured correctly, but interrupt only occurs every 10th time. HAL-GetTick results in a approx. 10 times slower speed.

Setting TIM 7 IRQ priority from 7 (highest) to 6 solves the problem.

Question remains:

Why is that? What is the purpose of blocking the systick-IRQ. ?

[KOkun.1048]

Hi,

I think...

When ThreadX is in IDLE state, CPU executes __tx_ts_wait called from PendSV_Handler.​ And, the PendSV interrupt is set the lowest interrupt priority. So, while ThreadX is in IDLE state, the lowest priority is always blocked.

[KOkun.1048]

Hi, Johannes,

For your information, 7 is the lowest priority and 0 is the highest priory.​

[Johannes]

It is strange, that azure-RTOS insist on using a hardware timer for systic. But at the same time, the systic is bad, because of the IRQ problem described above.

Is this because azure-RTOS uses the Cortex M System-Tic counter for its purposes, and therefore the Cortex M systic is not available for HAL_Systic?

If so:

A good improvement to CubeMX would be, if it would not set the IRQ of the hardware timer to lowest priority, if you use a hardware timer for HAL-Systic in combination with ThreadX