The "-110" error typically occurs when the GSM dongle connects to a 2G 900 MHz network (2G 1800 MHz is not available in our country). In contrast, there are no issues when the dongle connects to a 4G network, although the exact frequencies used in those cases are unknown.
When the "-110" error arises, all devices connected to USB are completely stuck. Although the connected device is still detected by Linux (e.g., through the lsusb command), any communication with any USB-connected device fails completely—no data transfer occurs. This state persists for at least 5 minutes without recovering automatically.
The issue occurs regardless of whether USB communication is in full-speed or high-speed modes. However, in full-speed mode, the frequency of USB hangs is reduced. These registers are used to enable Full-speed:
PFSC in USB_nPORTSC1
RXPWDDIFF and RXPWDENV in USBPHYx_PWDn.
The GSM dongle has its own power supply with a 2A current limit. Despite this high limit, power drops are observed due to the dongle's peak consumption during communication. Other power supplies in the system, including the USB hub, remain stable. Interestingly, these power drops occur even when the dongle is connected to a PC, where communication remains stable.
We tested a USB hub with its own power supply, but the USB hang still occurred. In another experiment, connecting multiple unpowered USB hubs in series resolved the issue only after the 3rd hub (4 hubs total) was added. Additionally, when using an optical USB splitter (with its own power supply) to place the dongle 4 meters away from the device, the USB hang did not occur. However, when the dongle was placed closer to the device, the issue reappeared. These observations suggest that GSM 2G 900 MHz communication interference affects USB communication, whether the interference occurs over the air or via the USB cable.
During debugging, we found that the following register statuses were sometimes (though not always) set when the issue occurred:
UTMI_RXERROR_FAIL_COUNT in the USBPHYx_DEBUG0_STATUS register
UEI in the USB_nUSBSTS register
To restore communication from a stuck state, it will help to reinitialize the USB-PHY peripheral (set the SFTRST bit in the USBPHYx_CTRLn register and then complete the USB-PHY initialization) and also send a reset using the Single-ended zero state (in Linux using USB_REQ_SET_FEATURE with USB_PORT_FEAT_RESET).
We also observed that an external trigger, such as a Single-ended one state lasting more than 1.125 µs (generated using an external signal generator), can lead to a complete USB hang. While the hang does not occur immediately, it manifests after several Start-of-Frame (SOF) packets. The consequences of this issue are identical to those observed with the GSM dongle, but we are not certain if the root cause is the same.
5V input voltage before the dongle power supply in communication with AP:
A closer look at the 5V input voltage before the dongle power supply in communication with AP (Green - 5V power supply, yellow - current from dongle):
Voltage measured on the dongle with PC:
USB stuck at full speed with USB dongl (I don't know what signal appeared after 133 us):
Injection Single-ended one 1.125 µs:
A closer look at the injection Single-ended one:
High-speed levels after USB stuck. Green and yellow D+ and D- USB:
Measurement of interference with USB dongle (yellow - USB communication, green - open input, red - measurement GND with probe) (the interference voltage level may not correspond to reality, the probe was not adapted to measure such high frequencies):
