In a custom design using a STM32H733vgt and a USB3318 phy, operating as a virtual com port device, full-speed works but high-speed doesn't work.
If full-speed works but high-speed doesn't, what do you think would be the culprit?
I'm using virtual com-port code, with USB_DEVICE Middleware generated by CubeMX. A similar project setup for STM32F723E-DISCO works ok in high-speed mode and one significant difference is that the F7 on the DISCO has an internal USB high-speed phy whereas my custom design based on an H7 relies on an external phy connected via an ULPI interface.
I can successfully run the high-speed phy in full-speed mode using
`hpcd_USB_OTG_HS.Init.speed = USBD_HSINFS_SPEED;`
It enumerates successfully on Windows as a com port and sends its Hello World message in response to a character received. This implies that several aspects of the design are functional: firmware, the ULPI interface, the phy chip and the connection to the USB device-side connector.
To switch to high-speed mode, I change
`hpcd_USB_OTG_HS.Init.speed = USBD_HSINFS_SPEED;` to
`hpcd_USB_OTG_HS.Init.speed = PCD_SPEED_HIGH;`
After enumeration, Windows shows an 'Unknown USB device'. A USB sniffer shows chirps and a transition from full-speed to high speed mode but shows no response sent from the USB device in response to a setup command requesting the device descriptor. On the firmware side, in the debugger, I see the OTG_HS_IRQHandler() handle interrupts for Connect and Reset but no interrupts related to data.
Some things tried to resolve the high-speed problem
- Tried enable and disable for Link Power Management, Low Power mode and DMA.
- Tried enabling xcvrdly i.e., USBx_DEVICE->DCFG |= (1<<14), as mentioned here: https://github.com/stm32-rs/synopsys-usb-otg
- Tried setting a USB_DEVICE middleware flag `USBD_DEBUG_LEVEL` to 99 to see if log messages reveal insight but the log messages show no errors which seems to imply that the firmware/ULPI/phy interface is functional.
- Comparing USB sniffer logs between the 'bad' design and a 'good' Nucleo board, the first significant difference is when the device ACKs a setup command request for the device descriptor. The bad design never ACKs in high-speed mode. However, In USBD_HSINFS_SPEED mode, the bad design will ACK and send subsequent device responses.
- Checked errata - this post mentions an incompatibility between some STM32Fx devices and USB33xx phys: https://community.st.com/s/question/0D50X00009XkZUeSAN/stm32f2f4-problems-with-various-ulpi-usb-phys however the errata for our STM32H7xx (https://www.st.com/resource/en/errata_sheet/es0491-stm32h72xx73xx-device-errata-stmicroelectronics.pdf) doesn't mention this problem
- Checked signal integrity on the ULPI interface but signals and phasing look 'somewhat ok' on an o'scope.
