2025-12-12 11:41 AM - edited 2025-12-12 12:19 PM
Hello, I have a problem that I am having a hard time figuring out.
My project is using an STM32H743 as a USB host on a custom PCB. Both OTG_HS and OTG_FS ports are connected to different devices. OTG_HS is using the internal PHY and operating at full-speed. An LTE modem located on the same PCB is connected to the OTG_HS port, and a CP2105 located on a separate PCB is connected to the OTG_FS port via a 10ft cable (D+ and D- wires are twisted and shielded). The CP2105 and host exchange ~1KB of data via bulk transfer every 1 second, while communication with the LTE modem is currently only during manual testing aside from enumeration. I used the USB host drivers generated by STM IDE and modified them to work with each device.
The problem I'm running into occurs with the OTG_FS port. Occasionally, the communication will come to a complete halt. The URB state returns as URB_IDLE after the host tries to transmit data. Looking at the data signals, there is no data being transmitted from the host but the SOF packets are still being sent every 1ms. Resetting the USB core does not fix the issue and will cause continuous enumeration failure after the core is re-initialized. Debugging the enumeration failures, it looks like the host is able to receive the first 8 bytes of the descriptor from the CP2105 in order to set the MaxPacketSize, but when it tries to request the full device descriptor, the request is never sent. Unplugging and re-plugging the CP2105 cable also results in repeated enumeration failure. Only power cycling the MCU seems to fix the issue, and sometimes it requires multiple power cycles. While the OTG_FS port is in this state, the OTG_HS port still works just fine. I've implemented some solutions to try and prevent the problem from occurring such as redesigning the cable as the signal voltage seemed a bit low, as well as making the PCB traces as short as possible. I'm wondering if there's anything I can do on the firmware side to recover without power cycling if the problem continues happening in the future? It can sometimes take weeks before the problem manifests so I'm not confident saying that it's fixed with just the hardware changes.
Any insight would be appreciated, thanks.
2025-12-12 2:02 PM
While waiting for more useful replies - what if you connect the CP2105 to the HS and test it alone without the modem? This would help locating the problem.
2025-12-12 2:44 PM
It would be very difficult to connect to the other port as I would have to cut the PCB traces and attach jumper wires since the modem is on the same PCB as the MCU. I suppose I could try disabling the OTG_FS and using its GPIO pins as OTG_HS in the firmware. I might just try doing that with a few units and seeing if the problem manifests over the next month. Ultimately I'd like to have a possible workaround in the firmware in case the problem manifests as it's so difficult to reproduce so I can be confident that if it does happen then my system can quickly recover.
I should add that power cycling is not ideal since I have other devices on the PCB which are enabled by the MCU GPIOs and power cycling the MCU means every device gets reset and some can take up to 10 seconds to reach a steady state.
2025-12-15 7:26 AM
Hi @george_wgt
Would you provide full software setup? Did you reproduce the issue using CubeH7? X-CUBE-AZRTOS-H7?
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.