Skip to main content
E
enbw
Associate II
August 8, 2025
Solved

H503RB, USBX, ThreadX: Thread blocked by USBX

  • August 8, 2025
  • 1 reply
  • 386 views

Hello,

I have an issue with this setup:

  • STM32H503RB
  • CubeIDE 1.19.0, Win10
  • ioc-Implementations:
    SYS[Timebase Source TIM1]; RCC[CRS SYNC Source USB]; ICACHE[1way]
    Connectivity-> USB[Device only, USB FS Global Interrupt, Internal PHY]; SPI3[FD-Master]
    Middleware-> TREADX[Core]; USBX[Core, Device CoreStack FS, Device Controllers FS, CDC ACM]

Nothing is implemented regarding the SPI port yet.
I succesfully went through this STM tutorial: https://www.youtube.com/watch?v=LdY2bieaPwk 

Success means: when I switch the PC13 button, the string "Hello World" is transmitted to the terminal on my PC.

Here is the But:
A thread for the blinking of an LED is not running anymore:

VOID LD1_thread_entry(ULONG initial_input){
	(VOID)initial_input;
	while(1){
		HAL_GPIO_TogglePin(LED_RD1_o_GPIO_Port,LED_RD1_o_Pin);
		tx_thread_sleep(8); // 1tick per 10ms
	}
}

I know the workaround already:

  • Priority of usbx-write-thread is [Prio,Subprio=] 9,9
  • Priority of LD1_thread is 15,15
    => just decrease from 15,15 to lower values and it works. With values of 9,9 or lower the LED is blinking.

But my understanding is lacking here:
The usbx process is just this:

VOID usbx_cdc_acm_write_thread_entry(ULONG thread_input)
{
	UX_PARAMETER_NOT_USED(thread_input);
	ULONG actual_length;
	while(1)
	{
		// wait for button press
		tx_semaphore_get(&semaphore, TX_WAIT_FOREVER);

		// transmit data
		ux_device_class_cdc_acm_write(cdc_acm, (UCHAR *)(&Tx_Buffer), (strlen(Tx_Buffer)), &actual_length);
	}
}

So all the time while I am not pressing the button, usbx_write_thread is just waiting for the semaphore. By definition is "sleeping" until semaphore wakes the thread up.

But how can this sleeping-process prevent a (low priority) task (LED blinking) from being executed?
The concept of ThreadX is that exactly this should never happen.

I would be grateful if someone knows where "the bug" is.

In case you need more information about the background/code/... just let me know. Right now my code really looks like in the tutorial plus the LED stuff.
Thanks in advance!
Enrico

Best answer by enbw

Bug was fixed:
the issue was a while(1) loop. In the tutorial this while(1); was suggested in the function app_ux_device_thread_entry() in app_usbx_device.c by the tutorial. But it blocks the other (low priority) tasks from being executed.

This function is just for configuration so, the while(1) can simply be deleted.

1 reply

E
enbwAuthorBest answer
Associate II
August 12, 2025

Bug was fixed:
the issue was a while(1) loop. In the tutorial this while(1); was suggested in the function app_ux_device_thread_entry() in app_usbx_device.c by the tutorial. But it blocks the other (low priority) tasks from being executed.

This function is just for configuration so, the while(1) can simply be deleted.

Terms & ConditionsAccessibility statement