tx_thread_sleep() hangs forever on STM32F411 with Azure RTOS

[SAID_embadded]

Setup: STM32F411RE + STM32CubeIDE + X-CUBE-AZRTOS-F4 v1.1.0 + TIM4 as HAL
timebase Problem: Thread runs once, toggles LED, then hangs inside tx_thread_sleep(50) and never wakes up. Debugger shows:
System Timer thread → State: SUSPENDED, Run Count: 0
Thread 1 → State: SLEEP, Run Count: 1 System Timer never runs, so sleeping threads never wake up.
Question: Why is the System Timer thread never getting scheduled? Any known issues with X-CUBE-AZRTOS-F4 v1.1.0?

[Khaled_DHIF]

Hello @SAID_embadded ,

The symptoms you see suggest that SysTick cannot preempt your thread, so the ThreadX timer interrupt never runs.

This often happens when the NVIC priority configuration is not compatible with the ThreadX port.

To confirm, could you please tell us:

1. What NVIC priority grouping are you using?
   (e.g. NVIC_PRIORITYGROUP_4, NVIC_PRIORITYGROUP_0, etc.)
2. Do you have any code that calls
   HAL_NVIC_SetPriorityGrouping(...) or sets priority for SysTick, PendSV, or SVCall after ThreadX is initialized?

Kind regards, 

DHIF Khaled

[SAID_embadded]

yes it realy work when i add this ligne :  HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
befor  MX_ThreadX_Init();
it really work but why?? 
in addition when i installed the middleware AZURE and igenerate the code the cube MX it didn't generate this MX_ThreadX_Init(); by default i add it manually by my self but it shall be declared by default i dont know why it not declared by default 

[Khaled_DHIF]

Hello @SAID_embadded ,

In the ThreadX low‑level startup, the following assembly configures SysTick, SVC, and PendSV priorities directly:

/* Configure handler priorities. */
LDR r1, =0xFF000000 @ SVCl, Rsrv, Rsrv, Rsrv
STR r1, [r0, #0xD1C] @ SHPR2: SVC = 0xFF (lowest)

LDR r1, =0x40FF0000 @ SysT, PnSV, Rsrv, DbgM
STR r1, [r0, #0xD20] @ SHPR3: SysTick = 0x40, PendSV = 0xFF

On STM32F4 (4 priority bits) this means SysTick has pre‑empt priority 4, while SVC and PendSV are at 15 (lowest). This setup assumes a grouping with pre‑emption bits (e.g. NVIC_PRIORITYGROUP_4), so SysTick can preempt threads and PendSV stays the lowest for context switching. If you switch to 0 pre‑emption / 4 subpriority, these assumptions break, and the System Timer thread may never run, causing tx_thread_sleep() to never wake up.

Regarding your second point, that's most likely an issue from the code generation by CubeMX, this will be reported internally so it can be addressed in a future update of the X‑CUBE‑AZRTOS / CubeMX integration.

Kind regards,

DHIF Khaled