Jetson Nano Development Kit USB Direct Mode

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Again, I can’t seem to find the proper category to select. I’m really sorry I’m so stupid.

Anyway, I’ve been happily running through the Building Visual AI applications to the point where I can monitor my own detected objects. But when I try to power up and reconnect to continue with the tutorial, I can no longer connect to 192.168.55.1 with my user name and ssh. Unfortunately, nothing has changed to provide me with any clues. Any suggestions on how to fix my board or network from overnight gremlins??

2

Hi,

is your device still booting up properly?
I mean check the UART log and see if you can login via UART.

Also check the micro USB cable in case you forgot to connect it.

3

I’d also like to ask what kind of connection methods are available, e.g., local monitor and keyboard (serial console is just one of those methods which are insanely useful and reliable, but requires a serial UART cable). Also, is your host that you are connecting from Linux? If not, what host?

4

Thanks for the reply. Some additional detail I can provide.

  1. The Dev Kit boots up successfully with a monitor, keyboard, and mouse directly attached.
  2. I can connect to the internet through the ethernet cable.
  3. I connect the microUSB port through a data cable(tried 3 different cables) to my desktop PC. None are recognized by a “connect alert” sound.
  4. Ping request in a Windows Power Shell times out to 192.168.55.1
  5. ssh to 192.168.55.1 using my username just hangs with no response
  6. My little USB tester tells me there is no circuit(very high ohms) between the PC and the Dev Kit.
  7. USB tester confirms transmission monitoring plugged into any USB port with activity.

I don’t know how to get connected again to the Dev Kit. The power jumper is installed and I am using a Canakit 3.5A power supply connected to the barrel jack. ALL of this was working. Any other way to monitor activity?

6

Hi,

So you can get the GUI after powering on the device?
Also network is working?
Then why don’t just check the IP address on eth0 of the device, and SSH into that address?

USB device mode should work on Windows, but we don’t use Windows in our daily work, so we can’t provide much comment.

7

There is no IP address in the eth0 data when using ifconfig.

My laptop is running Ubuntu 20 and it also does not recognize the board. No additional info when using lsusb.

8

Then what do you mean with this?

9

I can use the monitor and keyboard and mouse directly connected to the Dev Kit and an ethernet cable connected to my home network and the Dev Kit and launch a browser from the Dev Kit desktop and browse the internet. Unrelated to my USB problem but added it as an observation.

10

What do you see from “ifconfig” (or “ip -s addr”) and “route” (or “ip route”) of both the Jetson and the laptop host when the USB cable is plugged in? Especially, on the host laptop, if you monitor “dmesg --follow”, when new log lines occur from plugging in the USB?

11

This is a picture of ifconfig on the Dev Kit.

This is a picture of iconfig on my laptop. No eth0 category.

This is a picture of route on the Dev Kit.

This is a picture of route on my laptop.

Lastly, I used dmesg --follow on my laptop and here is a picture.

Thanks for the instructions. I hope the picture links are valid.

Joe

12

Note that this can be appended to any command line to save a log (files can be attached, and are much easier to read…plus we can copy and paste):
2>&1 | tee log_something.txt

You could just attach the actual logs, e.g.:
ifconfig 2>&1 | tee log_ifconfig.txt

Of note, your laptop has a lot of 172.x.x.x subnet addresses. The laptop has a 10.x.x.x Wi-Fi address. I don’t know why ifconfig did not list that.

The Jetson shows the the virtual USB wired ethernet works, but the plugin events on the laptop show it was rejected. Apparently there is some sort of network security issue.

The ifconfig screenshot of the Jetson cuts off part of the interfaces, and it shows USB working (though the laptop rejected it), and wired ethernet is not set up.

With the cut off views it is difficult to tell, but I have to ask, are both laptop and Jetson using the same Wi-Fi router? I’m asking because I’m wondering if subnets pass through. They might, it is just hard to tell with incomplete information.

13

  1. ifconfig files are attached. ifconfig0 is the dev kit and ifconfig is my laptop.

  2. Jetson Nano Dev Kit does not have a WiFi adapter.

  3. The laptop is connected to my only router, an Xfinity cable modem.

  4. I completed the Getting Started with AI on Jetson Nano successfully having no problems connecting.

  5. I completed the Building Video AI Applications at the Edge on Jetson Nano up to Introduction to DeepStream SDK. When I tried to continue the following morning, I could no longer connect.

  6. Are you trying to determine if my network or laptop changed during the night?

log_ifconfig.txt (2.64 KB)

log_ifconfig0.txt (2.3 KB)

14

I sincerely apologize for taking this paragraph from Setting up your Jetson Nano:

In addition, we will further simplify the configuration by using “USB Device Mode” . In this mode, your Jetson Nano Developer Kit connects directly to your computer through a USB cable. This eliminates the need for a network connection on the Jetson Nano, as well as the need to determine the IP address on your network. It is always 192.168.55.1 in this mode.

Overnight, because of cramped quarters, I disconnect the ethernet cable unaware that it is actually REQUIRED and not just the first time to download containers. For some reason, I decided to connect it again for shits and giggles as us old timers would say. Lo and behold! My problem went away and I can now connect.

Sorry folks. I learned the community is very smart and helpful. You were the sledgehammer I needed on my thick skull before I recognized that perhaps I should try the ethernet cable. I also thought about asking you about it.

Can’t wait to move forward. Thanks.

Joe

1 Like
15

The layout of network information helps a lot. The physical layout requirements, as you have mentioned, should work. I am assuming this, which sounds like what you have:

  • Laptop Wi-Fi to the router.
  • Nano possibility 1: Wired ethernet to the same router. We won’t consider this since you are interested in the USB side, but beware you could easily plug the wired side of the Nano directly in to the router or to a switch going to the router, and the DHCP should “just work”.
  • Nano possibility 2: USB virtual ethernet to the laptop. I will assume this because you are interested in the “USB Device Mode”, which is what the virtual wired USB is.
  • Nano not using Wi-Fi (it could, but you’ve established it isn’t).

The DMZ of the router is the 10.0.0.0/24 subnet (specifically, the IP is 10.0.0.190, and the “/24” is another notation for “255.255.255.0”…24 of 32 bits are 1 on the most significant bit). Your Jetson will not use this due to the USB being wired to the laptop. If the USB goes to the router, then I expect it to fail since the router itself provides addresses, and does not accept them unless you have admin access, and perhaps not at all on a Comcast modem.

The way some of the “temporary” connections work (they are intended to go up and down, e.g., Wi-Fi at different locations) they get a bit more complicated. The bridge (“l4tbr0”) is the address at the Jetson end, so the Jetson is identified with address 192.168.55.1, which is expected. The Jetson provides a router function which responds to DHCP requests over USB, and when asked, it assigns address 192.168.55.100 at the other device (at the laptop). So the Jetson can ping itself at 192.168.55.1, and if working, the laptop can ping itself at 192.168.55.100. If self ping works, then each could ping the other with the address at the other end.

I do not see anything on the laptop responding to the USB. So this is the less detailed answer to what the problem is.

Going into more detail, I think the Jetson side is working, and some setup is needing update at the laptop side. I am going to have you monitor “dmesg --follow” on both the Jetson and the laptop, with no USB cable connected. You can ignore any log lines which exist at that point; the purpose is to see what occurs upon plugin. Also, get a copy of “ifconfig l4tbr0” on the Jetson prior to connect (the device won’t be on the laptop yet, so it is unimportant at this point). There will be a list of various bytes, e.g., TX and RX count. I’m looking for a change in those bytes (or errors) upon plugin.

So you then plug in the USB cable. Copy the log lines on both Jetson and laptop which occur as a result of the plugin. Then take the “ifconfig l4tbr0” again on the Jetson; I expect some byte counts to go up, and I’m interested in whether both TX and RX change (RX from the Jetson implies the laptop tried a DHCP request; lack thereof implies the laptop never sent any bytes). If the laptop does see the connection, then it is probably “/dev/usb0” which is added (you’ll see that in the “dmesg --follow” of the laptop). Assuming that laptop device shows up, find the “ifconfig usb0” (or whichever device) so we can see bytes of TX and RX and errors and any address. Most likely “dmesg --follow” will instead show something about failing or refusing this, and in that case, there will be no usb0 (or whatever name it would assign). The “dmesg --follow”, if we know the Jetson end was functioning, should give a very strong clue about what is going on at the laptop end. Or if it is the Jetson, then this too would show up (perhaps the Jetson’s “dmesg --follow” will show a USB error, which indirectly is a virtual network error for this layout).

16

It was my misunderstanding about how to set up “headless mode”. The paragraph I focused on was misinterpreted as the board being configured into USB Device Mode by default and that’s how I had to hook everything up.

My ultimate desire is to have the Dev Kit connect to my WiFi network and be done. I purchased a WaveShare plug in for WiFi and bluetooth for my foldabe keyboard and I’m happy. Without any connections except camera and power and everything is cool.

I wish you could modify your description and add it to the setup procedure. If I missed it, I apologize.

Joe

17

The smaller port is actually an “On the Go” USB port (“OTG”). USB is a one-way connection, and one end is always a device, the other is always a host. If a type-A connector is used, that end is always a host; if a type-B connector is used, that end is always a device. The connector you see on a mouse or keyboard is a type-A, with the type-B being embedded within the device; Jetsons just use a discrete cable. The OTG port is unusual in the ability to accept either of a type-A or type-B micro USB connector; however, there is an ID pin, and the Jetson knows which type is plugged in.

All Jetsons with a micro OTG connector allow a type-B device mode. In recovery mode, only a type-B connector makes sense because a recovery mode Jetson can only be a device, not a host. I think a Nano does not have any host mode software to run as a host even if you were to use a type-A connector (charger cables, and the flash cable are all type-B; you’d have to carefully search to find a micro-A for sale). On other models, which do allow either type-A or type-B, such as the TX2, different drivers are installed and activated depending on which connector type is found. If it is a keyboard, then the connector would identify host mode, and the keyboard device would work. Most Jetsons, if put in device mode while Linux is running (which is quite different versus recovery mode), have example applications for people wanting to use the port for their purposes. Those examples include the wired virtual ethernet device, and a mass storage device that shows up as a README type file on the host with the type-A connector host end.

Headless mode is only indirectly related to flash. In all cases of flash, the recovery mode Jetson eventually completes flash, and then it reboots and is no longer in recovery mode (it is fully operating at that point, and Linux is what you see). Since I don’t think a Nano supports host mode on the micro-OTG connector (someone correct me if wrong), you’d need your Wi-Fi device to go to one of the full-sized USB connectors (which are always host mode).

There is software, upon booting Linux, whereby it wants a first boot account setup. Normally one would be intending to boot to the GUI with a directly attached monitor and keyboard. This would be how you would set up the account name and password. Headless mode is very similar, in that it still boots Linux, but it expects the setup over the serial console instead. Sometimes, if you flash using headless instructions, it actually fails to get to the first boot setup on the serial console. In some cases cycling the power once will get you to that point, but if once does not do it, then it is unlikely more reboots will help.

Can I verify that first boot setup on headless is the main problem? Or are you able to log in, and you are needing help on the WaveShare USB device? Or maybe it is m.2, I’m not sure.

Incidentally, if it is about account setup, then there is a sort of “easy cheat”. The reason NVIDIA does not ship with a default name/pass is because of California law (it’s probably a good law, people with defaults and not knowing to change the pass get hacked a lot). However, you (but not NVIDIA) are allowed to install that password on the host PC’s flash software before flashing. There is a “Linux_for_Tegra/tools/l4t_create_default_user.sh” script which sets this up as though you’ve already completed this before you ever flash. Normally this is used with eMMC models, but if you mount an SD card there, and if the flash software is a release compatible with the SD card, then running that script on the SD card should do the same thing.

18

Thanks for the detailed description. I no longer have any problems.

20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.