Since we switched over to using the TX2 as our primary means of control, we started using a device called a CANable to connect it up to our CANbus from the Auvidea J120 carrier we use. We’ve tried using the onboard CAN but had a lot of issues with reliable timing using that, which is why we are using the CANable. The CANbus isn’t the issue though.
As a result of using the CANable, we are reliant on USB. Specifically, on the J120 Carrier, we are using the Micro USB port that is available and can act as a host or OTG port. In our case, it’s a host port. Here is where the issue comes from… Occasionally, on boot, we see some dmesg errors like this:
[ 5.899103] gs_usb 1-1:1.0: Couldn’t send data format (err=-110)
[ 5.905246] gs_usb: probe of 1-1:1.0 failed with error -110
The “-110” seems to indicate that the device is attempting to request more current than what is available and then it fails. This in turn means the kernel module doesn’t load properly and we don’t have a CANbus (can0 device) that we can connect to.
What’s interesting is that in the Auvidea J120 manual, it indicates that the power enable signal for that port comes from the A17 pin on the TX2, which in turn enables the USB power for the port (500mA max). The port is listed as USB0_EN_OC.
Our current theory is that something is going on with either the TX2 or the J120 where that port doesn’t have power enabled at the exact moment the kernel module is trying to load so it can’t source the current needed for the device. We haven’t been able to fully confirm this though and we are looking for other people who are aware of any other instances of this or of something to this. Alternatively, any thoughts on other things we can try.
The USB device does enumerate (lsusb shows it) but the kernel module won’t load. We also know that this doesn’t happen all the time and only happens maybe 1 in 30 to 1 in 50 attempts/reboots.
Simultaneous to this, we are also looking at the CANable device to make sure it isn’t trying to source more than 500mA but that seems unlikely from the schematics and what we know.
We have not tried reloading the kernel module when this occurs yet but I have a hunch that will work and might end up being our work-around. We do know that a reboot can fix it and we also know that hot plugging the CANable can fix it so I’m fairly certain unloading and reloading the module will as well.
Any help that is provided is appreciated.