When plugging the jetson in to a host machine, the host machine reports “over-current protection condition” whenever the device is connected via Micro-USB. This results in all other USB ports in that group on the host being disabled.
This has been tried both with and without the barrel jack connected and this has also been tried across multiple USB 3.0 and USB 2.0 ports. Along side this, no other ports on the Jetson respond, and there is no light activity from the Ethernet port when a cable is connected.
This was discovered when tailing the USB devices with dmesg on Ubuntu 20.04 LTS as shown in the attached output below.
Are you powering the Nano via that cable? If so, then it is in a power mode exceeding the specification for the output of a regular host port. You could (A) run the Jetson in a lower power mode, or (B) use an external HUB which is self-powered (the HUB would then be what supplies power to the Jetson, and this power specification is higher than that of what comes directly from an ordinary host port).
Keep in mind that if you have a HUB already, but that HUB is not self-powered, then everything on that HUB is drawing power. This combined power could be exceeding the output limits of the USB spec. I’m guessing this is what is happening. The next possibility is unlikely to matter…
If the USB port on the Nano is device mode (which is when you use a micro-B USB cable on it), then in theory it is possible it derives its power by drawing from the host port (the host PC which has the type-A connector). Mostly this won’t happen even then because much of what is inside of the Jetson is self-powered. Still, it is possible that the serial UART might draw current. However, even if this were the case, the amount of power draw from a serial UART is tiny. Probably less than a mouse, and close to the same as a keyboard.
Thanks for the detailed response, Linuxdev. I’ve been powering the board via the DC connector as it seems impossible to get power via the Micro-USB cable.
I forgot to mention that when trying to get output from the board via HDMI, the system stays blank and never boots with no monitor activity. I’ve noted the heatsink on the Jetson module does get warm though when connected via DC. This has been tried with multiple Micro-SD cards with the Jetson image applied using Etcher and always results in the same outcome.
I’ve tried with a USB-C hub powered from the wall, and a USB wall outlet directly to the Nano, however these also fail to power the device. The Nano will also shut off the USB Hub, and also the ports of other host devices (like laptops) when it is connected.
Is there any other way of gathering in-depth logging info from the Jetson (maybe using the UART?) or does it look like the board may need to be returned to Nvidia?
There is a jumper present when it uses the barrel connector. Using the micro-B connector is less useful since it can’t handle as much current, but if you wanted to use this, then you’d have to remove the jumper.
Being that this is booted using the barrel jack (assuming the jumper is present…if not this might be why the unit is consuming USB power), then the micro-B USB to host PC should not cause power consumption. Assuming this is as it seems (and there isn’t something odd going on with the power jumper), then there is probably a hardware failure.
In terms of knowing if it booted, the HDMI is the least useful of all methods. What you really need is a serial console boot log before anyone can know what is going on. However, I would not expect to be able to do that until the USB issue is resolved. The SD card would be unrelated to how much power the host PC sees being pulled over USB. Can you verify that the jumper is correct for use with the barrel connector?
I can confirm the DC enable jumper is present for the barrel connector and that the barrel connector is functional as the green light turns on when this is plugged in, and does not when the jumper is not present.
In that case connecting the micro-B USB cable to the Jetson and the full sized type-A to the host PC should in no way cause an overcurrent unless there is an electrical fault. If you were to use that port on the host PC with some known working USB device (for example, a mouse or keyboard), does it work correctly on the PC? You’d want to monitor “dmesg --follow” on the PC to see if error messages show up as you plug in that test item. If the port works correctly, then it means there is probably an error on the Jetson hardware side.
The first post is an example of using dmesg --follow with the jetson. You can see where it was unplugged and the plugged back into another port, still resulting in an overcurrent issue repeatedly until being disconnected. The USB port on the host machine itself functions without issue with other devices like a keboard and mouse, so the ports are not the issue.
Please keep in mind that overcurrent on a root HUB (the HUB inside the Jetson itself, the parent of all USB nodes) is complaining about the sum total of current draw. This can be from one device or the combination of many devices. A keyboard or mouse will be trivial so long as it isn’t malfunctioning. Many other devices though might draw a lot, e.g., network devices, external storage devices, audio devices, so on. The real test is if you use an external HUB and the HUB itself has its own power source, does it still complain about overcurrent? If it does, then there is probably a fault in the Jetson itself. If it does not, then this is likely the result of an external device (either a single malfunctioning device or a combination of too many functioning devices).
There is nothing plugged into the Jetson Nano other than the DC barrel jack and the MicroUSB cable. This has been tried in various arrangements, including trying to power the nano via an external USB-C hub connected to wall powered by a suitable USB-C power supply.
After deciding to probe the MicroUSB connector (with the MicroUSB fed via a suitible and working, known-good 5V USB wall adapter), I can see the USB port is rapidly cycling between 0v-300mV. This happens also when measuring to ground, across to R45, R8, C147, and D11.
Furthermore, when doing a continuity check, all four of these components show as connected to ground. When measuring across C318, the erratic mV flucations are present although this component doesn’t appear shorted to ground when testing for continuity. From here, moving on up to the 3.3v and 5v GPIO pins report an unusually low mV.
When disconnecting the USB port and only powering via the DC connector, I can get a reading of a solid 3.3v and 5V from C318 and the respective GPIO pins. Likewise, the DC connector is reading 5V when measuring across it.
I can only conclude there is a short to ground either with the MicroUSB connector, or with one or more of the surface mount components resposible for handling the power from this port.
Since the overcurrent is on the host PC, then I assume the short is between PC PHY->cable->Jetson PHY, but it seems like there is a hardware fault. However, if the Jetson booted, then the wired ethernet should still work. Are you able to ping or sshthe Jetson from the host PC if ethernet is connected? Obviously you’d need to know the IP address, but if you don’t know that already, then your router should be able to tell you.
Also, assuming the type-A half of the micro-USB cable can plug into the host without overcurrent (the micro-USB end unplugged), then it implies the cable is not the issue.
There is no functionality from any of the USB ports, display outputs. nor the ethernet port on the jetson. When connected via ethernet there is no activity either from the port or network switch. This has been tested with multiple cables and also with the jetson left plugged in for an extended period of time.
Should I wait for an official confirmation from an Nvidia technician here on the forums, or can I go ahead and update my support ticket in reponse to this thread, confirming the request for an RMA?
