cancel
Showing results for 
Search instead for 
Did you mean: 

Code Stuck in tx_application_define() Function During USB Initialization

saikumar
Associate III

Hello,

I am working with [STM32 MCU model, e.g., STM32U5G9ZJT6Q], and I downloaded code from GitHub (link:

https://github.com/STMicroelectronics/STM32CubeU5/tree/main/Projects/STM32U5G9J-DK2/Applications/USBX/Ux_Device_CDC_ACM ).

While running the project, the code gets stuck in the tx_application_define() function, specifically in the while(1) loop after the USB initialization MX_USBX_Device_Init().

Here is the relevant portion of the function:

VOID tx_application_define (VOID *first_unused_memory)
{
        UINT status = TX_SUCCESS;
         VOID *memory_ptr;

  if (tx_byte_pool_create( &tx_app_byte_pool,  "Tx App memory pool",  tx_byte_pool_buffer,     TX_APP_MEM_POOL_SIZE) != TX_SUCCESS)
  {
      while(1);
  }

    memory_ptr = (VOID *)&tx_app_byte_pool;
    status = App_ThreadX_Init(memory_ptr);
    if (status != TX_SUCCESS)
   {
    while(1);
   }

    if (tx_byte_pool_create(&ux_device_app_byte_pool, "Ux App memory pool", ux_device_byte_pool_buffer, UX_DEVICE_APP_MEM_POOL_SIZE) != TX_SUCCESS)
    {
      while(1); 
    }

    memory_ptr = (VOID *)&ux_device_app_byte_pool;
    status = MX_USBX_Device_Init(memory_ptr);
   if (status != UX_SUCCESS)
   {
     while(1);  // Getting stuck here 
    }
}

1 ACCEPTED SOLUTION

Accepted Solutions
FBL
ST Employee

Hi @saikumar 

You mean in this line?

FBL_0-1732027751848.png

The example is working on my end using MB1860-A02! Which revision is your board? 

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
FBL
ST Employee

Hi @saikumar 

You mean in this line?

FBL_0-1732027751848.png

The example is working on my end using MB1860-A02! Which revision is your board? 

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thank you for your reply Sir/Mam!

Yes, I am also using the same STM32U5G9-DK2 board, but I am encountering some issues:

1.  We haven't made any changes to the provided code and the hardware configuration.
2.  When we dump the code, only the ST-Link cable appears in Device Manager, but the USB application cable does not show up as expected.
It seems to be working on your side. Could you please let us know what changes you made to get it working?

I am sharing a photo of my board for reference. Is there any pin configuration or jumper setting that could be causing this issue?

Thank you for your assistance!

FBL
ST Employee

Hi @saikumar 

No modifications have been made by my side. Ensure that you are using the latest version of the STM32Cube firmware package and USBX middleware. Do you connect the STM32U5G9J-DK2 board CN15 to the PC through "TYPE-C" to "Standard A" cable? You should see the LD5 lights up when powered by a USB host. 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thank you for your response!

I have not made any modifications either. Now, the USB application COM port appears in the Device Manager, indicating that the board is recognized.

However, I'm not seeing any data transmission or reception in Tera Term or Hercules.

Additionally, the code appears to get stuck in the scheduler under the following sequence:

When the control reaches _tx_thread_schedule(),

it transitions to VOID usbx_cdc_acm_write_thread_entry(ULONG thread_input).
Inside this function, when calling:

if (tx_event_flags_get(&EventFlag, RX_NEW_RECEIVED_DATA, TX_OR_CLEAR,
&receivedataflag, TX_WAIT_FOREVER) != TX_SUCCESS)
{
     Error_Handler();
}
The control eventually gets stuck in the following assembly block located in the tx_thread_schedule.S file:

#ifdef TX_PORT_USE_BASEPRI
LDR r1, =TX_PORT_BASEPRI // Mask interrupt priorities =< TX_PORT_BASEPRI
MSR BASEPRI, r1
#else
CPSID i // Disable interrupts
#endif
LDR r1, [r2] // Pickup the next thread to execute pointer
STR r1, [r0] // Store it in the current pointer
CBNZ r1, __tx_ts_ready // If non-NULL, a new thread is ready!


Moreover, I noticed another issue on my side. For the code to run successfully, I had to manually add the following line in SystemClock_Config():

__HAL_RCC_SYSCFG_CLK_ENABLE();

Without this, the code gets stuck in the CoreReset() function.

This behavior is puzzling since we are using the same board, code, and firmware versions, yet you don't face this issue. 

Any insight into these issues would be greatly appreciated!