I am connecting gps module to Orin via USB A type. System detects generally ttyACM0, sometimes ttyACM1. However, it is not problem for me. The problem is when I make a serial connection with these ports for my gps module it only works one time. The connection is not stable.
I am using this script in python.
import serial
ser = serial.Serial(port, baudrate=9600, timeout=1)
it get stucks almost everytime in this line ser.readline()
uhubctl does not fix my solution. unplugging and replugging works but then it breaks again a few times later.
I’m also having same problem to read gps data from sudo cat /dev/ttyACM0. It works after replugged but broken sometimes later then freezes and showing nothing. So, the problem is not just in script. Serial connection or sudo cat /dev/ttyACM0 commands break the gps usb port data receiving.
I encountered freezing when entering the command line lsusb.
Im having this problem in both situation if usb is shown in lsbusb or not.
EDIT:
Also, If I enter the command that is sudo cat /dev/ttyACM0 more than one time it freezes and showing nothing.
tried but nothing happens. I think usb ports have problem. Im also using flir camera via usb. in another orin but Plugged usb devices work once but a few times later they are unusable until replug.
When it works, and then again when it fails, what do you see for these:
lsusb
lsusb -t
If you start “dmesg --follow” prior to failing, then it will print log line as they show up. Watch closely, and if it appends new log lines as a result of the point of failure, what log lines show?
Also, are the cameras self-powered, or do they use the USB for power?
when it fails, lsusb command freezing about a couple minutes. then u-blox is missing in the list. I check with uhubctl but it also freezes then it shows as at the related port.
dmesg --follow as below:
[10876.895997] usb 1-4.1: Product: u-blox 7 - GPS/GNSS Receiver
[10876.895999] usb 1-4.1: Manufacturer: u-blox AG - www.u-blox.com
[10876.899150] cdc_acm 1-4.1:1.0: ttyACM4: USB ACM device
[10886.834117] usb 1-4.1: USB disconnect, device number 15
[10887.060355] usb 1-4.1: new full-speed USB device number 16 using tegra-xusb
[10887.167734] usb 1-4.1: New USB device found, idVendor=1546, idProduct=01a7, bcdDevice= 1.00
[10887.167744] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10887.167748] usb 1-4.1: Product: u-blox 7 - GPS/GNSS Receiver
[10887.167750] usb 1-4.1: Manufacturer: u-blox AG - www.u-blox.com
[10887.169890] cdc_acm 1-4.1:1.0: ttyACM4: USB ACM device
[11023.156939] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11023.261002] cdc_acm 1-4.1:1.0: ttyACM5: USB ACM device
[11035.360670] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11035.472630] cdc_acm 1-4.1:1.0: ttyACM4: USB ACM device
[11047.572491] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11047.680355] cdc_acm 1-4.1:1.0: ttyACM5: USB ACM device
[11059.779964] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11059.883985] cdc_acm 1-4.1:1.0: ttyACM4: USB ACM device
[11071.987638] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11072.091737] cdc_acm 1-4.1:1.0: ttyACM5: USB ACM device
[11222.659828] i2c i2c-7: adapter quirk: no zero length (addr 0x0028, size 0, write)
[11332.704861] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11342.253061] i2c i2c-7: adapter quirk: no zero length (addr 0x0028, size 0, write)
[11348.056282] usb 1-4.1: device descriptor read/64, error -110
[11357.391002] i2c i2c-7: adapter quirk: no zero length (addr 0x0028, size 0, write)
[11363.671882] usb 1-4.1: device descriptor read/64, error -110
[11363.863911] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11379.287466] usb 1-4.1: device descriptor read/64, error -110
[11394.907081] usb 1-4.1: device descriptor read/64, error -110
[11395.099078] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11396.111444] usb 1-4.1: Device not responding to setup address.
[11397.335352] usb 1-4.1: Device not responding to setup address.
[11397.546956] usb 1-4.1: device not accepting address 16, error -71
[11397.630959] usb 1-4.1: reset full-speed USB device number 16 using tegra-xusb
[11398.643335] usb 1-4.1: Device not responding to setup address.
[11399.867289] usb 1-4.1: Device not responding to setup address.
[11400.078907] usb 1-4.1: device not accepting address 16, error -71
[11400.087897] usb 1-4.1: USB disconnect, device number 16
[11400.166901] usb 1-4.1: new full-speed USB device number 17 using tegra-xusb
[11415.642536] usb 1-4.1: device descriptor read/64, error -110
[11431.254146] usb 1-4.1: device descriptor read/64, error -110
[11431.446096] usb 1-4.1: new full-speed USB device number 18 using tegra-xusb
[11446.869730] usb 1-4.1: device descriptor read/64, error -110
[11462.493340] usb 1-4.1: device descriptor read/64, error -110
[11462.605965] usb 1-4-port1: attempt power cycle
[11464.421231] usb 1-4.1: new full-speed USB device number 19 using tegra-xusb
[11465.433602] usb 1-4.1: Device not responding to setup address.
[11466.657750] usb 1-4.1: Device not responding to setup address.
[11466.869170] usb 1-4.1: device not accepting address 19, error -71
[11466.953171] usb 1-4.1: new full-speed USB device number 20 using tegra-xusb
[11467.965539] usb 1-4.1: Device not responding to setup address.
[11469.189481] usb 1-4.1: Device not responding to setup address.
[11469.401110] usb 1-4.1: device not accepting address 20, error -71
[11469.407992] usb 1-4-port1: unable to enumerate USB device
I also use pyusb to reset usb port one time at the beginning of the script. If don’t, gps data cannot be read from the serial connection but if I reset more than one same things happens as I mention above.
By the way, I tried another gps with uart connection. There is nothing wrong with it. It works stable.
For reference, vendor ID is 0x1546 and product ID is 0x01a7. If I look up that vendor ID (U-Blox AG) in the a Linux USB ID database, I see this and the product ID 01a7. And so it isn’t a problem of some part of the device not being known. However, I do see a number of errors. What I’m wondering is if the serial UART is part of the same device working over the same cable. Is it correct that the ttyACM and the U-Blox device are integrated as the same hardware? Or are they separate? Also, I see an i2c issue. If this i2c is going over USB, then this might really be just an expression of a USB issue; on the other hand, if i2c is used over a serial UART to an i2c device built in to the U-Blox, and if that is used for configuration, then it might be the reverse: It could be the i2c failure causing what seems to be a USB response error. If it is USB, then it might be a signal problem, but if it is an i2c problem, then it might be a software issue. I don’t know which. I’m going to guess that you don’t have a USB analyzer, but I’ll ask anyway if you have one you can put on the device?
I tried another usb gps but same things happened. Also tested on nx xavier, there is no problem like that. gps works stable on xavier. I also reflashed orin but couldn’t solve the problem.
The only reason I mention i2c is that the error messages have i2c issues in the log at the same time the USB is showing the UART message (which shows several times for unknown reasons…it doesn’t list this as an error). My thought was that perhaps the U-Blox uses i2c internally, and the data traffic is via the UART. Don’t know. However, any i2c dump would need to be relative to that device if it is that device with the i2c, and not the i2c bus of the Jetson. One would need to know what the U-Blox has in it from a developer standpoint to know.
The UART loopback sounds correct. Results from talking in loopback should be valid. However, you didn’t say if a serial console program proper echos back or not when in loopback mode.