While investigating for the firth evening in the row why OTH_HS USB on STM32U5A9x does not work I reviewed USB registers. There are quite few of them and in HAL some are them are named differently than in RM0456 (details here), but that is not the root problem.
According to RM0456, section 15.2.3 "Configuring the OTG_HS PHY (only for STM32U59x/5Ax/5Fx/5Gx)" the following register fields should be set:
I realized that after when MX_USB_OTG_HS_HCD_Init() was called, the above two register values had still zero values.
Within MX_USB_OTG_HS_HCD_Init() function SYSCFG.OTGHSPHYTUNER2.COMPDISTUNE and SYSCFG.OTGHSPHYTUNER2.SQRXTUNE are not set while they probably should be since the recommended values differ from default ones (RM0456, 15.3.13).
Certainly, setting SYSCFG.OTGHSPHYCR.CLKSEL to a non-zero default value is a must (RM0456, 15.3.12).
The above got me thinking. Was the RCC.APB3ENR.SYSCFGEN set in the first place? It turned out that it was not.
Probably this is another serious CubeMX bug. I seriously doubt anyone succeeded trying to configure USB on STM32U5A or STM32U59 with CubeMX yet. Was it ever tested?
In short: it seems that CubeMX generated code does not call HAL_SYSCFG_SetOTGPHYDisconnectThreshold() and HAL_SYSCFG_SetOTGPHYSquelchThreshold() while it should and does not enable APB3ENR.SYSCFGEN clock first.
> Probably this is another serious CubeMX bug. I seriously doubt anyone succeeded trying to configure USB on STM32U5A or STM32U59 with CubeMX yet. Was it ever tested?
A good point. The examples usually (or often) are not created using the cube-generated code (can you guess why?) so the generated code is less tested and reliable in this respect. => Advice: always start with a ready example; only after getting it working generate your own with cube and use the former as reference.
Not many chips have an internal HS PHY. Previous to the STM32U5, only a few in the STM32F7 line had one. Historically, the robustness of the USB libraries has lagged behind the hardware significantly. They have improved over the years, but expect to go through growing pains when adopting the newest hardware.
The STM32U5 examples are a bit lacking in this department. If the peripherals are the same, you could likely take inspiration from the STM32F7 examples.
@Pavel A. I have tried available Ux_Host_xx examples first, but could not get any of them working.
I am well aware that ST is not a software company and their software testing process, if it exists at all (which often I doubt and by no means I try to be mean), is not perfect and a lot of frustration is to be expected, especially with a new product, but it is frustration nonetheless. No to mention long time to market.
Please note that the STM32U5A or STM32U59 DK board is sink only and user should ensure to inject 5V on Vbus to get USB host working. you could refer to the note on examples readme showing how to configure the HW
@ABOUA If you mean NUCLEO-U5A5ZJ-Q board, than it can be configure to provide USB power using SB8-10 jumpers, although it is not documented and should be done with caution.
True, such configuration is not an option for STM32U5A9J-DK board, which probably you are referring to, but I think powered USB hub can be used.
All the above has nothing to do with incorrect CubeMX USB_OTG IP initialization.
I keep investigating.
Today I did more testing and it gets interesting.
I would think that probably IP clock is not enable (it is AHB2 G1, RCC_AHB2ENR1.OTGEN), but is is enabled by a call to __HAL_RCC_USB_OTG_HS_CLK_ENABLE() and some other registers get set USB_CoreInit() function.
It all does not make sense.