cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7RS USB_HS failure (Device Descriptor Request Failed)

FA1234
Associate III

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:

  1. 0x800 (USBSUSP)
  2. 0x1000 (USBRST)
  3. 0x2000 (ENUMDNE)

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:

  • DMA Mode and Not
  • Data Caching universally disabled
  • Putting hpcd_USB_OTG_HS into noncacheable memory. (Strangely, this prevents any USB interrupts from arriving for some reason)
  • I've tried enabling Activate-VBUS. This changes the behavior (I get SRQSINT, USBRST, and that's it)
  • I've tried initializing as PCD_SPEED_FULL instead of PCD_SPEED_HIGH with no changes.

Possibly relevant details:

  • VDD50USB is driven by VUSB at 5V, and VDD33USB is properly generating 3.3V internally.
  • Everything else is driven by 1.8V, and the internal SMPS regulator is used to generate Vcore, and is producing expected voltages.
  • Calling LL_PWR_IsEnabledUSBReg(), ...HSPHYReg, ...VoltageDetector() all show they are enabled. Also USB33RDY is true.
  • The HSI is driving the PLL3Q, which is divided down to 16MHz. This matches the setting in "OTG PHY reference clock selection". 
  • My SYSCLK is 600MHz, divided down to CPUCLK of 75MHz. All AHBs are running at 75MHz.
  • DVDD is connected to VCAPx which are connected to the output of VLXSMPS (after inductor and caps). (This seems correct from AN5935, page 39, where Vcore connected to DVDD)
  • VCAPx has no per-pin capacitors (this seems correct from AN5935, page 8, VCAP only used for LDO, not SMPS)
  • The USB D+/D- traces come from a USB-C port, are 90 ohm differential pair controlled impedance, and less than 30mm.

Thank you in advance for any help!

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

6 REPLIES 6
Amel NASRI
ST Employee

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.

ABOUA
ST Employee

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

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!

FA1234
Associate III

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?

FA1234
Associate III

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.

 

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.