In a custom design, STM32H7 + USB3318 phy as a VCP device, if full-speed works but high-speed doesn't, what do you think would be the culprit?

[Jim Frederick_2]

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.

[Jim Frederick_2]

Found it!

In the connection between the USB phy and the USB B connector, there was an RC low-pass filter designed for FS operation and it was killing the HS signal. Defeating this RC filter allowed HS and FS to work. The problem was not STM nor ULPI nor the phy chip.