STM32H7 USBX hub class flaky - Bug???

[matt-crc]

There seems to be a bug when using the USBX hub class.  Sometimes it works, but most often it does not.  The problem appears to be with file: ux_host_stack_enum_thread_entry.c.  The code:

VOID  _ux_host_stack_enum_thread_entry(ULONG input)
{

    UX_PARAMETER_NOT_USED(input);

    /* Loop forever waiting for changes signaled through the semaphore. */     
    while (1)
    {   

        /* Wait for the semaphore to be put by the root hub or a regular hub.  */
        _ux_host_semaphore_get_norc(&_ux_system_host -> ux_system_host_enum_semaphore, UX_WAIT_FOREVER);

#if UX_MAX_DEVICES > 1
        /* We try the hub first. For this we look into the USBX project
           structure to see if there is at least one hub.  */
        if (_ux_system_host -> ux_system_host_enum_hub_function != UX_NULL)
        {

            /* Yes, there is a HUB function, call it!  */
            _ux_system_host -> ux_system_host_enum_hub_function();
        }
#endif

        /* The signal may be also coming from the root hub, call the root hub handler.  */
        _ux_host_stack_rh_change_process();
    }
}

on line 16: if(_ux_system_host -> ux_system_host_enum_hub_function != UX_NULL) 

it assumes that the ux_system_host_enum_hub_function was originally initiated, and/or it expects that the ram was cleared on startup (which CubeIDE does not seem to do).

To fix this problem, all memory has to be zeroed for this code to work.

Question: is there a way to clear all ram on startup using CubeIDE, or do I have to do it manually?

[FBL]

Hi @matt-crc 

Would you attach screenshot detailing the failure? We need to reproduce before reporting the issue. Some checks are needed as well:

• Ensure UX_HOST_ENUM_THREAD_STACK_SIZE and UX_THREAD_PRIORITY_ENUM are set correctly.
• Confirm that _ux_system_host -> ux_system_host_enum_thread_stack is properly allocated.

Maybe your startup code is missing something. Check the startup code. It should correctly zeroes the BSS segment during the startup process as follows.  

ldr r2, =_sbss
ldr r4, =_ebss
movs r3, #0
b LoopFillZerobss

FillZerobss:
  str  r3, [r2]
  adds r2, r2, #4

LoopFillZerobss:
  cmp r2, r4
  bcc FillZerobss

The linker script defines the necessary symbols, and the startup code uses these symbols to perform the zeroing operation.

[matt-crc]

Hi @FBL 

UX_HOST_ENUM_THREAD_STACK_SIZE  (2 * 1024)

UX_THREAD_PRIORITY_ENUM  20

yes, _ux_system_host -> ux_system_host_enum_thread_stack is properly allocated

it  is not allocated in .bss, it is using threadx pools, and the demo put it here:

#if USE_USBX_HOST == 1
__attribute__((section(".UsbxPoolSection")))
__ALIGN_BEGIN  static UCHAR ux_host_byte_pool_buffer[UX_HOST_APP_MEM_POOL_SIZE] __ALIGN_END;
static TX_BYTE_POOL ux_host_app_byte_pool;
#endif

  /* Used for USB OTG */
  .UXApp_region 0x24035000 (NOLOAD):
  {
    *(.UsbHhcdSection)
  } >RAM_D1

  .UXApp_region_pool 0x24036000 (NOLOAD):
  {
    *(.UsbxAppSection)
  } >RAM_D1

  .UXApp_region_pool_app 0x24050000 (NOLOAD): 
  {
    *(.UsbxPoolSection)
  } >RAM_D1

the ux pool is 128K (your demo was at 120K). from 0x24050000 - 0x2406ffff

One of the problems is the main structure (pointer) _ux_system_host is not initialized.  The address for _ux_system_host is 0x00000, so it is storing the values of the structure in the ITCMRAM section and it is not using the pool like all the other variables.  I don't know if this is where you intended to keep the structure, but I had to turn off the icache so it didnt over run the structure.

Also, the _ux_system_host_enum_hub_function is not set properly... it should be ux_host_class_hub_activate, but for some reason there is a +16 added to the function, so when it tries to jump to the hub function, it gives an address error.

[matt-crc]

@FBL 

semaphores seem to be setup properly:

 

memory pools look ok.  They are where I expect them to be,

[FBL]

Hi @matt-crc 

Thank you for all the details. An internal ticket is submitted to our experts 205016.

One more question, are you interfacing Low Speed device? The is a known issue with supporting low-speed (LS) devices over a hub when connected to the full-speed (FS) PHY on the STM32H7. Check errata sheet section 2.25.3 for reference.

[matt-crc]

@FBL 

Re: USB Fs:  Oh, great....(not).... but that will be next weeks problem.  thanks for the heads up.

BTW, how long does it take to get a response from your expert and ticket 205016?

[FBL]

Hi @matt-crc 

Unfortunately, I don't have visibility. I will get back to you as soon as I get an answer.

[matt-crc · Accepted solution]

Ok, I finished re-writing the Host Only and Device Only drivers, and it seems to be working properly now.   The H7 works with a hub and multiple devices on the host side.  I still have to test the Device side next week, but hopefully that will be a bit easier.

ST should update their middleware code so users don't have to go through all this pain.