It seems that the USB driver has been installed well (I’m not sure), because when I type ‘dmesg|grep tty’ then terminal says something to the effect of : 'ngpsser converter now attached to ttyUSB0 ngpsser converter now attached to ttyUSB1 ngpsser converter now attached to ttyUSB2’
And Opening serial port with serial terminal program (I used cutecom and python with pyserial) works very well.
But the problem is: After opening the port, I tried to serial write to or read from Novatel GPS device but it never responded.
And oddly enough, if I open the serial port just when GPS device turned on and finished the boot sequence, serial writing and reading is working well without any problems .
Of course, if I open the serial port except at that time, the opening process looks fine but serial writing/reading is not working.
I also tried that above with Windows and Ubuntu desktop both, but this mess is only on Jetson TX1.
Is this driver problem? or from another?
And how can I handle this USB serial communication problem?
I hope someone could help this matter.
Thanks in advance :)
Hi rksa1234,
Not sure but it looks like an issue in power-up sequence. Per your information, it works only when the port is opened whiling GPS just turned on. If the timing gets missed, it never works.
Do you see any difference in the logs of working and not working cases? Are you on r24.2.1 and inserting the device to USB3 port?
I’m sorry but would you tell me what kinds of logs you want is? I don’t know how to gather the logs and what you want to see.
Novatel GPS has 3 USB port. Each name is [USB1], [USB2], [USB3].
For example if I using the 2nd port, [USB2] in working case,
when I send the command like ‘log version’ I can see the response like below:
[USB2]
<OK
[USB2]<VERSION USB2 0 84.5 UNKOWN 0 53.542 004c0800 3681 13306
…(responses)…
[USB2]
And if I send the inappropriate command in working case, the response is like
[USB2]
<ERROR:Invalid Message ID
[USB2]
But in not working case, whatever I send the command which is proper or not, that responds nothing. The responses message window is empty.
And on [USB1] port GPS device sends consistently some information without any my command. I can check that Information in working case but I cannot in ‘not working case’. Message window is also empty on this port in not working case.
I’m using r24.2.1 and insert the device to USB3.0 port on TX1 developer kit :)
ubuntu@tegra-ubuntu:~$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M
|__ Port 3: Dev 16, If 0, Class=Vendor Specific Class, Driver=ngpsusb, 12M
I connected usb hub with external power and I tried same as before.
ubuntu@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=ngpsusb, 12M
|__ Port 4: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 7, If 2, Class=Human Interface Device, Driver=usbhid, 12M
Problem is occurred same whether using usb hub or not.
Communication problem is only on TX1, not on Ubuntu desktop or Windows. So I think there might be a problem with GPS device’s driver, but I don’t have any knowledge about that. How do you think about that?
One of the best ways to do something easy is to monitor dmesg while unplugging and plugging the device…and to monitor while using a sequence that works, versus from a sequence of operations which fails. Try:
It’s also work just after plugging the device to TX1’s USB port, not only just after power on the GPS device.
I think the operating condition is opening the serial port while TX1 recognizing the GPS device.
To linuxdev, thanks for your help but I can’t find any difference in log between working and not working.
I tested with carrier board ASG003, so there is something ‘reg-fixed-sync-voltage’ in the log. I don’t know what that message refer to, but it seems that is not relative to our issue.
Here is dmesg --follow log in not working case.
[ 218.299644] usb 1-3.1: new full-speed USB device number 6 using tegra-xhci
[ 218.327796] usb 1-3.1: New USB device found, idVendor=09d7, idProduct=0100
[ 218.327923] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 218.328011] usb 1-3.1: Product: Novatel GPS Receiver
[ 218.328086] usb 1-3.1: Manufacturer: Novatel Inc.
[ 218.328154] usb 1-3.1: SerialNumber: BMEW15300017M
[ 218.346620] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.351080] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.352041] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.352745] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.353421] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.354060] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.354703] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.355266] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 218.355381] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.356023] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.356668] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 218.357228] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 218.357342] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.473546] usbcore: registered new interface driver ngpsusb
[ 219.473842] usbserial: USB Serial support registered for ngpsser
[ 219.474116] ngpsusb 1-3.1:1.0: ngpsser converter detected
[ 219.475197] usb 1-3.1: ngpsser converter now attached to ttyUSB2
[ 219.476316] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.477781] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.481427] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.483626] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.485268] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.486851] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.488247] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.491544] usb 1-3.1: ngpsser converter now attached to ttyUSB3
[ 219.491717] usb 1-3.1: ngpsser converter now attached to ttyUSB4
[ 219.491737] ngpsusb: v1.1.0: NovAtel GPS Receiver virtual serial port driver
[ 219.494342] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 219.494472] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.496256] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.497337] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.497569] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 219.497617] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.497819] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.498002] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.498176] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.500373] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.500734] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.500933] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 219.501110] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 256.449935] usb 1-3.1: USB disconnect, device number 6
[ 256.455617] ngpsser ttyUSB2: ngpsser converter now disconnected from ttyUSB2
[ 256.457937] ngpsser ttyUSB3: ngpsser converter now disconnected from ttyUSB3
[ 256.466009] ngpsser ttyUSB4: ngpsser converter now disconnected from ttyUSB4
[ 256.466662] ngpsusb 1-3.1:1.0: device disconnected
[ 275.410122] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
And this is working case
[ 307.158597] usb 1-3.1: new full-speed USB device number 7 using tegra-xhci
[ 307.180815] usb 1-3.1: New USB device found, idVendor=09d7, idProduct=0100
[ 307.180823] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 307.180828] usb 1-3.1: Product: Novatel GPS Receiver
[ 307.180833] usb 1-3.1: Manufacturer: Novatel Inc.
[ 307.180836] usb 1-3.1: SerialNumber: BMEW15300017M
[ 307.182455] ngpsusb 1-3.1:1.0: ngpsser converter detected
[ 307.182599] usb 1-3.1: ngpsser converter now attached to ttyUSB2
[ 307.182736] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 307.182835] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183036] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183167] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183274] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 307.183298] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183423] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183544] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183660] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183777] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.183894] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184008] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184124] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184254] usb 1-3.1: ngpsser converter now attached to ttyUSB3
[ 307.184481] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 307.184514] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184645] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184762] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.184864] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 307.184883] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185006] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185122] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185319] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185438] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185550] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185665] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185778] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.185889] usb 1-3.1: ngpsser converter now attached to ttyUSB4
[ 307.186098] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 307.186131] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186265] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186382] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186486] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 307.186510] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186637] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186761] platform d.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186878] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.186997] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.187125] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.187250] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 307.187384] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 325.699991] usb 1-3.1: USB disconnect, device number 7
[ 325.705042] ngpsser ttyUSB2: ngpsser converter now disconnected from ttyUSB2
[ 325.706785] ngpsser ttyUSB3: ngpsser converter now disconnected from ttyUSB3
[ 325.708343] ngpsser ttyUSB4: ngpsser converter now disconnected from ttyUSB4
[ 325.710123] ngpsusb 1-3.1:1.0: device disconnected
In all cases there is creation of “/dev/ttyUSB2”, “ttyUSB3”, and “ttyUSB4”. This means the serial driver did what it is supposed to do and USB through serial driver chain of events are fully functional. I would tend to lean towards the idea that port settings are the point of failure. Does your GPS documentation mention anything about serial port settings, especially does it mention if flow control is used/needed/possible? If any part of the serial port software is changed or incorrect during operation then text flow would either corrupt or stop.
I can configure serial port settings - baudrate / parity / databits / stopbits / handshaking / break detection.
I changed only baudrate from default settings. So current setting is 'baudrate=115200 / parity=None / databits=8 / stopbits=1 / handshaking=None / break_dtection=ON.
So it doesn’t use any flow control.
It works normal with same settings in Windows or Linux Desktop. Only TX1 has that problem.
If you have the ability to tell the device to use CTS/RTS flow control I’ll suggest doing so. If not, it seems it should be working. Having things start to work and then just stop seems a lot like signal issues (and CTS/RTS flow control can help with that).
I use several USB serial devices. but I can’t see this issue except that GPS device.
What I’m using are FTDI RS232 to USB converter, cp210x RS232 to USB converter, UTS2009 RS232 to USB converter, Novatel OEM617 GPS device (GPS device dosen’t need any converter.).
FTDI and cp210x is working very well, no problems. Their drivers are included in L4T kernel source, so I could install those easily.
But UTS2009, which uses mos7720 driver, has been failed to installing. It is not shown at dmesg so I couldn’t open the serial port.(I’ll search for that a little bit more and create some topic about that later unless I find the way.)
To sum up, I can’t reproduce our issue in other usb devices. Our issue is only on that GPS device.
But I appreciate for your interest in my issue. Thanks for your help.
To linuxdev,
I tried to fix my issue to changing several serial port settings, including CTS/RTS flow control, but I can’t. Whether changing settings or not, that issue remains same. Flow control was not helping our issue.
There is no overrun. Just there is no TX/RX when the issue arises (I’d been monitoring on the GPS device). But opening the port is working very well.
What is the exact cabling and any chipset between the relevant GPS serial wires and the Jetson? Also, are you using 3.3V TTL levels? I ask this latter because a true RS-232 converter for a 9-pin D-sub connector uses levels which might not work correctly when it sends, but possibly unreliably succeed when it receives. True RS-232 is both a hardware and software specification, most of what you see on the Jetson is a subset at 3.3V only. A few adapters are also 1.8V, and these would not work unless the port is on a non-default setting (some of the I/O pins are 3.3V unless jumper J24 is set to the 1.8V position…3.3V is the default).
It might be nice to check the Jetson side looping back to itself to at least eliminate inability to work at those settings; I doubt the GPS has a debug mode for just echo or generation of characters, but if it does, then I’d try that too. In the case of loopback on your Jetson side, you’d connect RX to TX, and for hardware flow control, you’d also connect CTS to RTS.
The fact that things start to work and then stops makes me wonder if there is some sort of data going across that brief data exchange, and the data causing the GPS to stop responding. Whatever you do now should probably be divided into determining serial issues on individual ports, then any kind of indication that there is a state in the GPS which would cause it to stop if individual ports are validated under loopback at the given settings.
Disabling it should not prevent any usb device from running. Furthermore, it could avoid potential problems.
USB autosuspend purpose is to save power when there is no activity on usb bus.
Unless you are powered with battery, I would suggest to keep it off.
@rksa1234: Are you using last L4T release ?
I don’t know the details of its implementation, but what looks strange to me is that it seems to leave the USB hardware or drivers in some state where TX1 will fail to communicate with some devices (while working with some others). Furthermore, it seems that desactivating usbcore autosuspend after boot through sysfs doesn’t fix the problem.