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.

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