2022-11-07 07:16 AM
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
Solved! Go to Solution.
2022-11-08 02:02 PM
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.
2022-11-08 02:02 PM
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.