USBX Host Controllers FS activation causes HAL_HCD_Disconnect_Callback failure

[Hosung]

Dear ST Community,

I'm experiencing an issue with USBX Host implementation on STM32H573RIT6 where disconnect events stop working after enabling Host Controllers FS in CubeMX.

Problem Description

Environment:

• MCU: STM32H573RIT6 (Custom board)

• Middleware: Azure RTOS USBX + FileX (MSC Host)

• VBUS: External constant 5V supply (no USBPD/VBUS sensing used)

• Connection detection: DP pin based

• CubeMX: UX Host FS + Host Controllers FS enabled

• HAL setting: hhcd_USB_DRD_FS.Init.vbus_sensing_enable = DISABLE

  

Behavior:

• Before USBX activation: Both HAL_HCD_Connect_Callback() and HAL_HCD_Disconnect_Callback() work perfectly with USB memory stick connect/disconnect

• After USBX Host Controllers FS activation:

  • Initial USB memory connection: HAL_HCD_Connect_Callback() works fine

  • USB memory removal/reconnection: No HAL_HCD_Connect_Callback() and
     HAL_HCD_Disconnect_Callback() called

Questions/Requests

• How to maintain HAL HCD callbacks when using USBX Host Controllers FS?
• Recommended settings for VBUS Sensing Disable + DP pin detection environment?
• Method to restore Disconnect events after Host Controllers FS activation?
• Differences between STM32H5 + USBX official examples and my configuration?

 

I suspect USBX Host Controllers FS activation is somehow weakening or overriding the HAL HCD handler's disconnect detection capability. Any insights or known workarounds would be greatly appreciated.

Thank you for your assistance.

Best regards, 

Hosung han.

[FBL]

Hi @Hosung 

 

---

@Hosung wrote:

Behavior:

• Before USBX activation: Both HAL_HCD_Connect_Callback() and HAL_HCD_Disconnect_Callback() work perfectly with USB memory stick connect/disconnect

• After USBX Host Controllers FS activation:

  • Initial USB memory connection: HAL_HCD_Connect_Callback() works fine

  • USB memory removal/reconnection: No HAL_HCD_Connect_Callback() and
     HAL_HCD_Disconnect_Callback() called

 

---

Can you better explain the behavior observed? Do you reproduce using the example provided in CubH5 host MSC  as starting point or custom application code?

 

When USBX Host Controllers FS is enabled in CubeMX, ux_hcd_stm32_callback.c (part of the USBX host controller middleware) is added. In that file, 

HAL_HCD_Disconnect_Callback is redefined in ux_hcd_stm32_callback.c  to overwrite the weak ones which is part of middleware Host controllers. Maybe you tried to redefine the callback elsewhere?

[Hosung]

Hi, Thank you for the guidance. To answer your question regarding the application code, I used the settings from the official CubeH5 Host MSC example as a reference and starting point. However, since my custom hardware does not use USBPD (USB Power Delivery), I have completely removed all UCPD-related configurations from the setup.

Additionally, I have commented out the HAL_HCD_Connect_Callback and HAL_HCD_Disconnect_Callback that I had temporarily created for debugging. I can confirm that these callbacks are now properly handled by ux_hcd_stm32_callback.c.

However, as I look deeper into the generated code, I noticed the usbx_stm32_host_controllers folder. I strongly suspect that the source code within this folder might be performing VBUS-related checks or control internally.

Since my hardware design does not use VBUS sensing (5V is constantly supplied to the port, and I have set vbus_sensing_enable = DISABLE), I suspect this internal USBX controller code might be conflicting with my setup by expecting a VBUS signal state that will never toggle.

Could you please share your thoughts on whether this suspicion is reasonable? If it is, how should I modify or configure the files within usbx_stm32_host_controllers (or the USBX stack in general) to completely bypass these internal VBUS checks and rely solely on the DP/DM data lines for the connection state?

Best regards, 

Hosung han.

I would greatly appreciate your opinion and any guidance on this.