I’m just wondering if some over-current condition might have caused something which is sticking around. If there are no devices connected at all to usb, what do you see with “lsusb”? Also, given that the micro port is USB2, when you run “lsusb” you should see the USB2 root HUB:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
You can see detailed information on that specific HUB with:
sudo lsusb -d 1d6b:0002 -vvv
I don’t know if it is convenient, but you might try to run that and see what lsusb shows differently between the on times and off times. You only need a subset of that, so I’m going to suggest you install “gawk” (“sudo apt-get install gawk”), and then run this while also watching the rail voltage:
sudo -s
while :; do echo ""; lsusb -d 1d6b:0002 -vvv | gawk '/^Hub Descriptor/,/Remote Wakeup/'; sleep 1; done
exit
I don’t know if there is something in “/sys” which could be monitored (power rails usually have status there, but I don’t know for this specific rail), but if there is it could be added in that above command. If you see something change, then you could hit control-c and stop the loop. The console should have some history in it and you can scroll back and copy and paste if something changes or looks interesting.
Perhaps there is some other interaction going on, e.g., sleep (I’m just speculating). Another possibility is that when in host mode power is delivered, but in device mode power would normally be consumed (but the device mode is self-powered, so power delivered to the connector would be ignored at the Jetson end and power source would be the host if Jetson is a device). For the case of the Jetson itself being in some sort of power savings mode you might run this before checking rail voltages:
sudo nvpmodel -m 0
sudo jetson_clocks
(in releases prior to R32.1 you need to use the full path to the commands)