I just got back to this, and wanted to add some more information.
What you have is the NVIDIA developer kit. This is good, it simplifies some things. I actually have one that I think was a pre-release, before it hit the market. So it is possible mine differs in some details, but I don’t know if that is the case or not.
I mention because on most earlier Jetson models (not Orin), in which the serial UART was a dedicated USB port (before that it was two pins exposed to TX and RX of a UART), that this was a micro-OTG USB port to the left side of the 40-pin header (2x20 arrangement). This is what provided the serial console. On my AGX Orin this transitioned to a USB-C. The older micro-OTG used a micro-B cable for signal (often sold as a “charger” cable), but the AGX Orin I have uses USB-C for that. If you have a micro-B “charger” cable, then the cable itself is always suspect as cell phones and such charged through such a cable typically have no more than 2 strands of very tiny copper (e.g., 2 or fewer strands of 32 gauge or thinner wire) for the data part. USB-C does not have that issue. The micro-B cable when NVIDIA supplies on earlier models is of high quality and works well with sustained higher speed transfers.
If you use
gtkterm for the program (and I don’t care for
minicom myself since
minicom has a lot of “AT command” support for modems from the 1980s or similar modems that we just don’t use anymore), and this complicates it.
gtkterm does have the disadvantage though of requiring a GUI, whereas
minicom does not require that. Assuming that the serial port produces “
/dev/ttyACM0” on your host PC upon plugin to the USB port to the left of the 40-pin header, this command will view the port properly:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
(you might need to use
If on your host PC you want your regular users to be able to watch serial console without
sudo, then add your PC user to the group “
dialout” like this (I am assuming your login name is “
user”, adjust for your actual user login name):
sudo usermod -aG dialout user
Note that USB is hot plug, and if the USB UART is powered (either by plugin or by the Jetson, I’ve never checked if the UART needs the Jetson powered…most UARTs are powered by the host plugging in the USB end, but not always), then log messages will occur as a result of plugin. If, on the host PC, you monitor “
dmesg --follow”, then the USB plugin will show a log message. Part of that log message is about the USB pipe itself. Seeing any activity in logs upon plugin verifies the USB side is probably working (unless the log message actually says it is failing).
The USB side itself does not generate the device special file (“
/dev/ttyACM0” is a device special file…it isn’t a real file, it does not exist on the disk, but is instead in RAM as part of the driver and pretends to be a file). When the driver loads there should be another message in the logs…this is the hot plug telling you it associated a driver with the data pipe for the end hardware (versus for the data pipe). If you see a log message that includes
ttyACM0, then your serial console is ready for
gtkterm (or any other serial console program at 115200 8N1 settings, no hardware flow control). The creation or existence of that file implies the driver has loaded for the serial UART and is currently running. The lack of this file suggests no driver loaded, and will occur if either (A) the driver does not exist, perhaps needing install, or (B) the USB pipe has an error.
Be sure to start
gtkterm logging before you apply power to the Jetson (you might need to be sure of the device special file name first, but consider that a test run) if you intend to provide those logs to the forum.
gtkterm might make it so you have to use an existing file name for logging, but you can create an empty file like this (I have directory “
~/Dowloads/deleteme/”, which is where I put stuff that is temporary when I expect it needs to be deleted; use any location you want):
The flash port will be the USB-C cable on the other side away from the 40-pin header. I use a cable provided by NVIDIA which came with the Jetson for the USB-C (the other end of it is USB-A). I use a micro-B USB cable for the serial UART console which is also provided by NVIDIA, but I think it arrived with one of my other Jetsons. Most USB-C will suffice, but be very suspicious of any charger cable (I would say two out of three charger cable designs will fail for sustained higher speed data).
An important thing to know, which most people don’t need to use, is the fact that the serial console is also useful for debugging during a flash. During a flash the jetson does not have login capability (it’s just a custom USB device, and login is from Linux which does not run on the Jetson during a flash until flash completes and the system automatically reboots to a non-recovery mode). However, sometimes if there is an error during flash it is useful to have that log as well (we differentiate this as a flash log, versus a boot log when we boot normally). Just knowing there is no serial console activity during a flash is itself a clue.
I want to also add that for the USB-C I flash via a USB type-A port as well, but it is USB3. I think a USB2 port should be ok as well, though taking longer. Sometimes though USB3 is actually required for some devices. I doubt that the AGX Orin requires USB3 and works with USB2 so long as it is in recovery mode. Just watch the “
dmesg --follow” on the host PC with the USB-C to type-A cable connected, and see if any message is visible. You’ll only see messages about the USB pipe itself since Jetsons have a custom driver (the driver is actually the flash software).
I will say it is possible that an adapter between USB-C and type-A will cause a failure if the signal quality drops, but it is unlikely to fail. It “should” work, but it isn’t a guarantee.