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.

[KOkun.1048]

ThreadX (also FreeRTOS) uses System-Tic interrupt in the OS porting layer implementation. And, the tick period is configurable. On the other hand HAL tick period expects 1msec. So, System-Tic is not suitable as HAL tick, I think.

In tx_initialize_low_level.s, interrupt priority 4 is set to SysT and priority max(the lowest) is set to PendSV. So, I think the CubeMX should change the default interrupt priority value for timebase, at least when OS is enabled.

[GreenGuy]

Haithem Rahmani ,

Could you please instruct how to implement your answer" 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."

Is this done by modifying existing library code, via CubeMX settings, What?

[Haithem Rahmani]

Hi @Community member​ 

Sorry for the delay.

Indeed you can configure this via STM32CubeMX as below.

1. Enable the BasePRI support in the ThreadX config panel, then set the BASEPRI value to "8" for example as shown below:

2. go to the NVIC config panel and set the TIM interrupt priority to any value greater than "8"

doing that the threadx will not mask the TIM 6 any more, but this may impact the overall behaviour of you application as each 1ms a TIMER interrupt will be received and needs to be managed.

regards

Haithem.

[Riscy]

I had the same issue with the STM32U5A5 Eval board, where HAL-Delay() seems to run strangely when ThreadX goes to standby with peripheral interrupts disabled (is this a correct assumption?). I fixed this by pushing TIM6 to priority level 14 from 15 and enabling BASEPRI Support with level 15. I wonder if there are certain guidelines or good practices to determine the correct setting. 

Is Microsoft really answering ThreadX query related to STM32, so far no answer for 2-3 weeks from several queries?, does the STM32 team continue to insist on deferring all Azure things to Microsoft rather than STM32? 

[Pavel A.]

> Is Microsoft really answering ThreadX query related to STM32

Microsoft will support the last milestone version of Azure RTOS for 5 years. The last milestone is 6.0 released in May 2020 so the support will last until May 2025. The last minor release is 6.1.3 (January 2021), these releases are supported for 2 years, so already out of support. In 2024 Azure RTOS will transition to Eclipse Foundation and won't be Microsoft's concern anymore. IIRC ST hasn't disclosed their plans for the Eclipse-branded ThreadX yet.

HAL_Delay is ST library function so you are in the right place to ask about this.

(short answer: your workaround is OK, and yes there are good practices to combine a RTOS with libraries like the ST "HAL", this forum is a good place to discuss them).

[Riscy]

Thank you for your quick reply. I wish you a Happy New Year 2024. My fingers are crossed for STM32 to support the Eclipse-branded setup. For Azure in general, I do like the concept of integrated implementation; however, we could do better with improved documentation and examples as well as by keeping them updated with revisions. It would be handy to indicate which revision version is used by example at the header.    

[PR.10]

Hi @Haithem Rahmani @KKorn.1 

Correct me if i am wrong, but effect of basepri is to allow preempt even OS interrupt and OS critical section by interrupts sensitive to latency. Because those interrupts are outside of OS control you MUST NOT! call any OS function from them. Usefulness of this would be very limited then. You can not do any calls like writing or reading data to OS queue, or triggering a task from that interrupt.

If that is true, the solution is to use lowest interrupt for OS tick. For my project it is 15, and set any application interrupt < 15. CubeMX should set 14 for other by default with azure RTOS.