On our custom carrierboard with a ORIN NX running JP 5.1.2, we connected a u-blox ZED-F9P module over a high current USB port.
The device can be acccessed as expected by using the commandsudo cat /dev/ttyACM0 to visualize the GNSS text stream
after executing ctrl-c and acessing the port again with sudo cat /dev/ttyACM0, the GNSS text stream cannot be seen and the port seems to be inaccessible or blocked. The port is only available again after a reboot, which is unacceptable.
The same can be said by accessing the port with minicom -D /dev/ttyACM0. After doing this for the second time, the port does not show any GNSS stream
By removing the driver with sudo rmmod cdc_acm and load it again with modprobe cdc_acm the issue is still present.
Strange enough, by using a ORIN Nano on the same carrierboard, the port is accessible as expected for several times without the need of a reboot
Hi,
Please connect a USB hub with external power supply to the custom board and then connect to the device. To try the setup that the device has external power supply, and see if it works.
Thank you very much for your tip. Unfortunately, this did not help. When I try to open the interface for the second time, nothing happens.
For the moment, the only way to ‘deblock’ the /dev/ttyACM0’ is to reboot the system or to execute sudo usbreset 1546:01a9 which is not really acceptable.
Using the command sudo screen /dev/ttyACM0 9600, after starting the second time, there is no output on the interface.
In addition, running lsof | grep ttyACM0 does not show any hint of another service that is blocking the interface. Again, the module is working on a x86 Platform - or even by using a ORIN Nano instead of the NX on the same carrier board.
I’m writing on behalf of Simon, who is currently out of the office. Please find the dmesg log for the Orin NX attached here: dmesg_onx.log (74.3 KB)
After the timestamp [21.222193], I executed the commands sudo cat /dev/ttyACM0, closed the stream with ctrl-c, and reopened it with sudo cat /dev/ttyACM0. These commands did not result in any additional dmesg messages. Only after executing sudo usbreset 1546:01a9 did the last two lines show up.
For reference, please find the dmesg log for the Orin Nano on the same carrier here: dmesg_ona.log (67.9 KB)
In this case, I executed the commands sudo cat /dev/ttyACM0, ctrl-c, and sudo cat /dev/ttyACM0, but skipped the usbreset, as I had a functioning stream of GNSS data.
Hi Dane,
Thank you very much for the suggestion. Reflashing the device did indeed do the trick and fixed the issue on this device.
From the following lines I would have guessed, that the device is running JP5.1.2:
[ 0.000000] Linux version 5.10.120-tegra (root@janick-jetPack) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2020.08) 9.3.0, GNU ld (GNU Binutils) 2.33.1) #4 SMP PREEMPT Tue Sep 26 15:48:10 CEST 2023
[ 13.451880] NVRM: loading NVIDIA UNIX Open Kernel Module for aarch64 35.4.1 Release Build (buildbrain@mobile-u64-6422-d7000) Tue Aug 1 12:45:41 PDT 2023
However, it’s plausible that JetPack 5.1.2 was only installed on the boot medium, while the Orin NX itself was flashed with JetPack 5.1.1. Could such a configuration discrepancy lead to the observed issue?
Hi,
We don’t suggest upgrade half of the system since it is tested when the system is in complete 5.1.1 or 5.1.2. If you cannot upgrade to 5.1.2, please base on 5.1.1 and upgrade only the firmware: https://developer.nvidia.com/embedded/jetson-linux-r3531