cancel
Showing results for 
Search instead for 
Did you mean: 

(SOLVED) STM32F730Z8 USB host OTG-HS on custom board not enumerating

Tokarev.Konstantin
Associate III

Hey guys, I was wondering if someone made the onboard High Speed PHY to work on the STM32F730Z8? No matter what I have tried, I am not able to make it work on HS. I am trying to implement an MSC host to read a USB memory stick. It is working without problem on the OTG FS port, but when i reconnect the usb connector to the HS pins (PB14/PB15), nothing i have tried so far has made any progress (3 days now). Most basic setup from stm32cubemx wouldnt have any effect at all when the memory stick is connected. I implemented the VBUS control thru a switch chip, as well as defined the output GPIO so that HAL can control that pin, and this works fine on the OTG FS.

I have a 3k resistor connected between ground and the USB_OTG_HS_REXTPHYHS pin. The USB connector is getting the proper 5V. The only time I had a different outcome is when i explicitly added __HAL_RCC_OTGPHYC_CLK_ENABLE(); at the HAL_HCD_MspInit() function. After adding this, the gState of the usb handle finally shows that attempts are made to attach and enumerate the device but it just keeps cycling between HOST_DEV_ATTACHED and HOST_DEV_WAIT_FOR_ATTACHMENT over and  over again. The "is_connected" field is showing a "1" as long as the memory stick is attached to the port, but the "PortEnabled" field keeps cycling between 1 and 0 along with the gState. After debugging for a while inside of the USBH_Process (in usbh_core.c file), I can clearly see how the gState cycles between HOST_IDLE, HOST_DEV_WAIT_FOR_ATTACHMENT, HOST_DEV_ATTACHED, and HOST_ENUMERATION. It fails to return USBH_OK from the "status = USBH_HandleEnum(phost);", keeps returning USBH_BUSY state and process repeats. I went further into the USBH_HandleEnum(), in the "case ENUM_IDLE", it attempts to get the descriptors from the device "ReqStatus = USBH_Get_DevDesc(phost, 8U);",  which is returning USBH_BUSY. Within the USBH_Get_DevDesc, the USBH_GetDescriptor() function should return USBH_CtlReq(),  it keeps returning USBH_BUSY. It feels like the host is sending a command to the device to request the descriptors, but gets no response at all and it keeps cycling within this loop of processes.

I need to point out that this is a custom board design which wasnt exactly designed with USB HS in mind, however the D+ and D- traces (PB14/PB15), are pretty short, and i have attempted to solder the usb connector at different points, closest to the actual pins of the stm32 which is within 0.2-0.3 inches away from the stm32 pins, the result being the same, no change in behaviour of the enumeration attempts.

I also attempted as a test, to invert the D- and D+ signal between the stm32 and the usb connector, and to my surprise I got the same result.. no change at all, same alternation of the gState and nothing gets enumerated.

I have also tried changing the USB configuration settings back and forth, with all possible combinations of changes, and nothing is making any progress.

Also as an additional effort I tried to port one of the USB Host examples of the STM32F723 discovery, to my chip.. surprise surprise, same result - alternating gState without enumerating anything, no descriptors are sent.

This brings me to the thought that either the STM32F730Z8 chips have a defective HS PHY (given that noone else online has implemented HS USB on this particular chip.. believe me I literally spent HOURS looking online and all I have been able to find is either inconclusive or unclear, spiced up with typos in the datasheet and reference manuals), or I really need to design a board with impedance matched traces.

One of my questions is whether it is possible that the host wouldnt even enumerate the usb memory stick on a pcb where the usb connector is soldered to the stm32 pins at a no longer than 0.3 inches distance (also tried series resistors 22 ohm, same result), or should it at least show some signs of life? I can design another board, but before doing that I would love to hear some thoughts on the topic from someone who has done something similar with the onboard high speed PHY of the F730 chips particularly.

Thank you in advance for any tips!

Konstantin

1 ACCEPTED SOLUTION

Accepted Solutions
Tokarev.Konstantin
Associate III

I finally solved the issue. It was a combination of 2 things.. on my custom board I used a 8MHz crystal to clock the stm32 (with all the proper clock configuration), however I found out today that in the file stm32f7xx_ll_usb.c, in the function static HAL_StatusTypeDef USB_HS_PHYCInit(USB_OTG_GlobalTypeDef *USBx), there is a section which controls the PHY frequency selection.. there are only conditionals for certain HSE frequencies, which are 12, 12.5, 16, 24, 25 and 32MHz. So I tried changing the crystal to 25MHz, reconfigured the clock config and it immediately started to enumerate the memory stick. Apparently this is not documented anywhere.

View solution in original post

6 REPLIES 6
Tokarev.Konstantin
Associate III

I finally solved the issue. It was a combination of 2 things.. on my custom board I used a 8MHz crystal to clock the stm32 (with all the proper clock configuration), however I found out today that in the file stm32f7xx_ll_usb.c, in the function static HAL_StatusTypeDef USB_HS_PHYCInit(USB_OTG_GlobalTypeDef *USBx), there is a section which controls the PHY frequency selection.. there are only conditionals for certain HSE frequencies, which are 12, 12.5, 16, 24, 25 and 32MHz. So I tried changing the crystal to 25MHz, reconfigured the clock config and it immediately started to enumerate the memory stick. Apparently this is not documented anywhere.

> certain HSE frequencies, which are 12, 12.5, 16, 24, 25 and 32MHz

Are you sure with the 32MHz?

> Apparently this is not documented anywhere.

0693W00000QMX94QAH.pngJW

Hey there, thanks for the reply!

If we look at the actual stm32f7xx_ll_usb.c file, there is actually a define for a 32MHz HSE. Check this out:

I meant that the fact that not all crystal frequencies can be used "out of the box" to get the USB HS working properly, is what is not documented anywhere in a comprehensive manner hehe.

Hi @Amel NASRI​ ,

> If we look at the actual stm32f7xx_ll_usb.c file, there is actually a define for a 32MHz HSE.

Can please this discrepancy between RM and the library be explained?

Thanks,

Jan

I am supposing maybe it is a typo in the reference manual in the PLL1SEL bits selection? Maybe one of the options should be marked as "32 MHz"? The "110: 25MHz", maybe needs to say "110: 32 Mhz" instead?

I do not have a 32MHz crystal to confirm if it would work.