2024-10-08 11:43 AM
I cannot get OTG_HS to communicate with a USB host, and I'm out of ideas. Any help would be greatly appreciated.
The problem:
I've instrumented HAL_PCD_IRQHandler to print whenever an interrupt occurs. Right after USBD_Start, I get:
It then repeats 2 then 3 a few times until the OS gives up. I do not get any other interrupts (I'm expecting at least RXFLVL after USBRST to transfer the Setup packet). Windows reports Device Descriptor Request failed. Linux reports "device descriptor read/64, error -71".
Things I've tried:
Possibly relevant details:
Thank you in advance for any help!
Solved! Go to Solution.
2024-11-27 08:43 PM
This has now been confirmed with the help of the MCU Support Team.
There is a bug in the templating which prevents the USBPHY's reference clock source from being set to any value other than 24MHz.
I've worked around this issue by adding the following to usbd_conf.c's HAL_PCD_MspInit() function in the first USER CODE block:
LL_RCC_SetUSBREFClockSource(LL_RCC_USBREF_CLKSOURCE_26M);
Of course, you should set your own CLKSOURCE frequency to whichever one you produce on your HSE or PLL3Q as an input to the USBPHY.
With this fix, you can now run your USBPHY's clock at any of the supported frequencies, rather than only 24MHz.
2024-10-09 06:57 AM
Hi @FA1234 ,
I see that the same request is already submitted in OLS system. Our team will take care to provide required support.
It will be nice to share the relevant and non confidential answers with other community members who may have similar situation.
-Amel
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.
2024-10-10 07:22 AM
Hello,
Could you please recheck the clock configuration for USB OTG HS, make sure to align the clock configuration with the one provided in USB cubeFW USB applications, avoid using HSI with HS PHY it requires an accurate input clock
Regards
2024-10-10 10:15 AM
Does this mean HSI will not work, and it requires HSE? Can you point me to the document that says this?
I was surprised that HSI48 (which is supposedly specifically for USB accuracy) is not routable to the PLL_USBPHY (either directly or through the PLL).
Thanks!
2024-10-31 07:27 AM
Respin complete, but with the same results.
- I can now run either with an external crystal (HSE) or the internal (HSI).
- I've verified the differential impedance.
Am I right in expecting the RXFLVL between the USBRST and ENUMDNE?
2024-11-25 09:06 PM
I believe I have fixed this issue. Despite the USBPHYC Clock Mux saying it can accept 16, 19.2, 20, 24, 26, and 32MHz, it will simply not be detected by the host running at any speed other than 24MHz.
I verified this by purchasing a Nucleo H7S3L8 board. It has a 24Mhz HSE. If I run the 24MHz HSE directly to the USBPHYC, or run it through PLL3Q and produce 24MHz, all works just fine.
However, if I run PLL3Q at 26MHz, 19.2MHz, 32MHz, or 20MHz, the host will fail to detect the USB CDC Standalone device with a device descriptor failure. I've made sure the USB_OTG_HS "Ref Clock Selection" matches whatever value is sent here.
On my own custom board, I have a 26MHz HSE. Running straight to the USBPHYC does not work. Running it through PLL3Q at 26MHz does not work. Only if I run it through PLL3Q at 24MHz does it seem to function properly.
More testing is required, but it would seem to be either a bug in the PLL USBPHY code, or a hardware limitation. Again, I do not believe the USBPHYC can pass anything other than 24MHz.
2024-11-27 08:43 PM
This has now been confirmed with the help of the MCU Support Team.
There is a bug in the templating which prevents the USBPHY's reference clock source from being set to any value other than 24MHz.
I've worked around this issue by adding the following to usbd_conf.c's HAL_PCD_MspInit() function in the first USER CODE block:
LL_RCC_SetUSBREFClockSource(LL_RCC_USBREF_CLKSOURCE_26M);
Of course, you should set your own CLKSOURCE frequency to whichever one you produce on your HSE or PLL3Q as an input to the USBPHY.
With this fix, you can now run your USBPHY's clock at any of the supported frequencies, rather than only 24MHz.