I am having an issue with the embedded USB ports on my TX2. When I do a dmesg the system reports:
tigra186-padctl 3520000.pinctrl: tegra18x_phy_xusb_handle_obercurrent: clear port 1 pin 1 OC
xhci-tegra 3530000.xhci: port 1 over-current detected
xhci-tegra 3530000.xhci: port 0 over-current detected
tigra186-padctl 3520000.pinctrl: tegra18x_phy_xusb_handle_obercurrent: clear port 0 pin 0 OC
Also, when I boot up the system I need to have the HDMI unplugged and can only get an HDMI signal if I plug in the cable after the system boots.
I have plugged in a USB3 expansion board into the PCIe slot and that works fine, but when I do an “lsusb” the system takes a long time to post the output.
I feel like there is short or something wrong with the hardware. How can I determine if this is hardware or software and if it is hardware can I start the RMA process?
Thanks in advance!
-Louis
Overcurrent is usually due to what is plugged in (the standards require a means to protect against overcurrent…the implementation can be either passive or active). A keyboard or mouse would never stress the power delivery, but what you might do as a test is to use a powered HUB. This will remove the need for power delivery from the Jetson and offload the power requirements to the HUB itself. Overcurrent, by itself, is not an indicator of where the fault is.
FYI, when using a regular (not self-powered) HUB the HUB itself draws power from the Jetson, and every device connected to the HUB draws power from the Jetson. All of those current sinks combined must not exceed the maximum allowed for a single device since they are eventually terminated in a single port.
I don’t know how much current should be available for your PCIe USB card, but the card itself is limited to what the base PCIe slot allows. In the case of PCIe cards taking more current than the PCIe slot can provide (common example video cards, but multi-port USB3 cards would also apply) among all USB ports combined, then I would expect the USB3 card to fail in the same way.
Can you try a powered USB3 HUB and see if issues go away when power is provided externally?
I don’t have anything plugged into the embedded USB ports and still get the error. I am running a terminal via SSH.
There could be damage. You might look at the USB ports (literally with a magnifying glass) and see if there are bent pins. Or anything which might look like damage. Device tree could be an issue, but on a dev kit which has not been flashed, or even on a dev kit which was flashed, I would not expect to see this with nothing connected. If you do want to RMA, then you can search for “RMA” near the top of this for information:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/
There are plenty of non-hardware possibilities for HDMI (but the USB is likely a hardware issue), e.g., any kind of adapter (especially 15-pin VGA) can get in the way. The earlier releases of L4T were less reliable with HDMI, and newer releases are more reliable. What release are you using (“head -n 1 /etc/nv_tegra_release”)?
HDMI is hot plug, and so if a plug in event is detected it will attempt to reconfigure. The software doing the plug in detect during boot might differ from what sees it later on after boot. In the event of no detect it could be that the default mode later in boot differs from what an early plug in might result in. What do you get from:
sudo -s
cat `find /sys -name edid`
exit
What is the exact cabling?
Thanks for the quick response. I did a physical inspection of the board and it does not seem to have any physical damage. I think an RMA might make most sense as I don’t have a lot of time to debug hardware with which I am not super familiar.
Here is the release info:
head -n 1 /etc/nv_tegra_release
R28 (release), REVISION: 1.0, GCID: 9436269, BOARD: t186ref, EABI: aarch64, DATE: Fri Jul 28 17:04:29 UTC 2017
Thanks again for your help.
-Louis
One last check, just to see if R28.1 is valid:
sha1sum -c /etc/nv_tegra_release
If that is all “ok” I’d go ahead and RMA. The sha1sum is to validate the NVIDIA-provided direct hardware access driver files and libraries. Should those be valid, then it is reasonable to assume the hardware is at fault. Should those not be valid, then we can consider the R28.1 flash was not correct.
Everything returns OK, so hardware issue it is. Contacting support for an RMA now. Thanks!