ROCK 5C USB host controller accepts corrupt USB packets

#1

I am using a rock 5C board with a USB device (canon camera).

Camera is connected by an unshielded 4-wire cable to a USB2.0 port on rock 5c (mentioning this because I believe the problem is caused by interference with this cable).

I’m also using a unbranded 4g modem plugged into a USB3.0 port.

I’ve noticed that transmitting data using the 4g modem (e.g. downloading a large file) can end up causing failures with the USB bus. In particular, the Canon camera will occasionally receive a corrupt USB packet and crash, in other cases I’ve seen the on-board AIC8800 wifi module crash.

The failures are strange in that they seem like bit errors, e.g. receiving a corrupt USB data packet. This should not be happening given that USB packets carry a CRC and should be rejected when CRC does not match.

Unfortunately I do not have a way to analyze USB traffic and can only go by what I see in the linux userspace (libusb).

Any help would be appreciated, in particular if there is any way to debug this from within linux on rock 5c.

#2

Please try to use a usb hub with external power supply, the rock 5c has a common 1.5A current limit for each of the two usb ports.
Also for Canon camera cables try to use a cable with a shield and as short as possible, I personally have a Canon camera and I’ve been plagued by poor quality cables.

#3

Hey!
Regarding the power / external hub - in this case the camera is not drawing any power from the port. It runs off its own power supply, only the data lines are used.

I’ve made my own cable (and soldered directly on the radxa board) as I’m not able to use the connector due to space constraints. I’ve switched to using a shielded cable with twisted wires and this seems to help.

However what I’m really surprised is that I’m seeing data corruption in the packets that are received within user space, namely my libusb-based implementation of the PTP protocol

I found that for e.g. Raspberry pi 4 has an issue that it will accept USB packets with invalid CRC - perhaps that is the case here too. I just don’t have a way to inject such packets to test this theory.

So I was hoping for some insight on whether this theory is plausible and/or ways to test this.

Meanwhile, thanks for the ideas so far.