Note that you request without any politeness such as thank you, please…
So before saying others are impolite, you may wonder about your own behaviour.
I’m only solving technical issues for free here, I’m not looking for more.
I’m not looking for money here, but I think that respect is important.
Again, better try before posting and post with data rather than with your feelings.
Please don’t try to blame me. Don’t do this. Don’t add this subtle form of manipulation to the discussion. Don’t try to make me feel guilty. I haven’t been a not empathetic / unsensitive or unpolite person. I have only asked a deeper form of support because I was / I am confused. This can’t be called unpolite behavior. This is a place where to ask support. This is what I did. That’s all.
PS : why can’t I express my emotions ? Am I a robot ?
If the issue is one of trying to reach recovery mode, then there is something in common across all Jetsons: There is a pin on the carrier board or module called the “recovery” pin. On a full TX2 dev kit there is actually a button. Regardless of model or revision, that pin is inactive when floating, or active when grounded. Recovery buttons are “normally open”. Models without a button tend to have a ground pin next to the recovery pin for convenience.
The recovery button is used like the “shift” key on a keyboard. By itself the button does nothing. However, if the button is held down (grounded) while another button is momentarily pressed, then you get the other button to modify its behavior (think capital letter instead of lower case). The recovery pin modifies either of:
The instructions to reach recovery mode are essentially saying to make sure the recovery pin is active (grounded) either during the moment of power on or the moment of power reset. It won’t matter how long the pin is grounded so long as it is held to ground at the instant the power state changes.
This is what worries me:
This indicates you are probably using a VM. @WayneWWW mentioned this in post #7. VMs are notorious for not correctly routing USB to the VM. Without this being correct you’d never know that the Jetson succeeded in reaching recovery mode for the purpose of flashing; similarly, the serial console quite possibly would act like it is failing and nothing would come through even if it is working 100% correct. Even if the VM initially works properly, USB performs a disconnect/reconnect during flash, and so anything starting out correctly in a VM will then fail as if the wires were cut (and this is programmatically exactly what happens).
VMs are often used for running suspicious applications because the program being run has no access to VM configuration. The software (in this case flash software) can never configure the VM and even if it could, then the instructions for configuration are different to repair the configuration for different vendors.
Any use of VM really must be eliminated. If not, it certainly can work, but you’d have to have more knowledge of your particular VM (which is the realm of the help forms for that VM vendor).
It is also worth noting that on some models of Jetsons both the barrel jack and a device mode USB jack could be used for power. On those models you should find that there are a pair of pins which have to be jumpered for the barrel jack to work, and unjumpered for the USB to work for power (depends on the model).
Nope. I’m not using a VM. I’ve installed ubuntu 18.04 physically on the disk. Can you elaborate more what make you think that I’m using a VM ? what’s wrong with :
[ 4137.430787] usb 1-13.1: Product: APX
what’s the string that make you think that’s a VM ?
The “APX” of that normally only appears when run in a VM.
That’s interesting,then. In some way,some elements of a VM gone inside the physical installation system files.
If you’ve previously used a VM, but are no longer using it, then perhaps some of the configuration is still present. That configuration could be mistakenly attempting to route the USB to a non-existent VM.
For sure someone could have tell this to me before. So,I will try to reinstall ubuntu from scratch.
I’ve never seen that before from an uninstalled VM. I doubt anyone else here has either. The “APX” though is a “giveaway” of running in a VM. Don’t know how it is still there if the VM is removed.
Ok. I have reinstalled Ubuntu 18.04 physically and I’ve repeated all the steps to put the board in recovery mode :
Connect the micro USB cable to the micro USB port on the Jetson Nano, without pluggin the other end to the PC yet
Connect the Jetson Nano to the DC jack J25
Connect the other end of the micro USB cable to the PC
Remove the jumper wire from the FRC pins. (I have also tried without doing that)
Unfortunately the board is not recognized after a lot of tries.
# lsusb | grep -i nvidia
nothing
If the USB cable is good (about 2/3 of “charger” cables fail…they don’t really build the data wires very well), and the NVIDIA cables are good (very very few of them are bad). Assuming you saw the power LED indicate it was powered up, and you don’t see the AGX, then I’m going to have to say probably the hardware is bad. Do try a different port on the PC, and do try a different cable just to make sure.
If you’ve tried to place the Jetson in recovery mode, but have not yet connected the USB cable, and on the host PC you monitor “dmesg --follow”, do you see anything on the host PC logs as you plug in the USB for a Jetson which is presumably already in recovery mode? I’m trying to find out if USB data side is showing any presence at all…it doesn’t need to actually know which device is connected, I just want to know if all log messages are entirely missing.
I’ve recorded two short videos to show what I do :
https://drive.google.com/drive/folders/1jY_kWhrgRBaS8gSHA6o7ZnLMtcNuHxc-?usp=share_link
maybe you see some mistake that I don’t see. Do you want to give a look at them ? on the first one you see that I have prepared everything : the jumpers are at the right place,the usb cable is connected to the pc and the power cable is attached,but nothing is detected on the dmesg log. On the video n. 2 you see that I have removed the jumpers 9 and 10 and again,nothing is detected on the dmesg log. The last thing I want to try is to use another usb cable. But,since I have tried several cables that I have here and they haven’t worked,I would like to be sure to use a working one. I’m avalailable to buy one new cable. Do you want to suggest to me one usb cable to buy ? on amazon is good. thanks.
I’ve followed a different procedure and something new happened. These are the steps I taken :
Connected a jumper on pins 9 and 10 of header J50
Connected jumper across J48
Connected the micro USB cable to the micro USB port on the Jetson Nano
Removed jumper across J48
and at least,something happened :
[ 1649.722340] usb 1-13.1: new full-speed USB device number 14 using xhci_hcd
[ 1649.802364] usb 1-13.1: device descriptor read/64, error -32
# lsusb | grep -i nvidia
nothing
I don’t have a specific micro-B (OTG) cable to purchase. The one I know of which is quite reliable is the one NVIDIA makes for Jetsons (but I don’t think you can purchase those separately). In the outside world, I think if you buy 3 different brands, then 1 will work. The fact that you got a USB response on the host PC says the device is not entirely dead.
I don’t have access to the specific descriptor read error numbers. It is quite possible that this is due to signal quality being low. It does give hope though. Sometimes going through a HUB can act as something of a signal adapter, so I’d see what happens if you get a HUB. Start by monitoring “dmesg --follow” on the host PC, and then plug in the HUB to see what messages appear. If you got around the descriptor read error, then you know the host PC side USB is good to go. Then plug the recovery mode Jetson into the HUB, and watch the new “dmesg --follow”…it might then work, or you might get another read error.
Normally I suggest a powered HUB, but Jetsons are self-powered, so that won’t matter.
Actually I’m using an USB 2.0 cable,but the Jetson nano USB port is 3.0 . Could it be the problem ? thanks.
That might be a problem. Often it is not, unless the device you attach is USB3 only.
A USB3 cable adds extra wires. Let’s say your device is capable of USB3. That means the device will provide plug-in information for drivers, and that information includes “superspeed” capability. If the USB host or hub supports USB3, then it routes to a USB3 controller (root HUB). If the wires are missing, or if signal quality is insufficient, then the device reverts to USB2 mode, and those extra wires are not used; the data reroutes to a USB2 root HUB.
Not all USB3 device have a USB2 mode available. Most do. An example of a device not having that mode is a high resolution camera (sometimes). For a camera which is intended to put out a lot of data, a USB2 connection might not be able to support that bandwidth. There is no reason for the manufacturer of that high resolution camera to put in a USB2 mode since the camera is not capable of slowing down that much and running at either such a slow frame rate or reducing its resolution. In that case the device would fail and not stand a chance of working.
A USB2 cable used with a USB3 device, whereby the device has the ability to revert to USB2, will work like that.
Also, there are cases where the root HUB and cable and device are all USB3, but some issue degrades quality of signal at USB3 speeds. It is possible the device will be reverted to USB2 mode and still function even if the hardware is all technically 100% functional. Signal quality is a complicated topic since we’re not dealing with pure sine waves. Signal quality isn’t the only possibility since USB cables are sensitive to length of cable (this topic is not about cable loss; instead, it is related to signal timing and delays from the added length…USB repeaters/bridges/extenders exist because of timing issues, and not generally because of cable resistive loss).
Do you have a desktop PC Linux system with a USB3 port (and a USB3 cable)? If so, then you could use that to query the device and literally ask it what it is capable of. If this device is something like a keyboard/mouse, then there is no chance it would ever fail on either USB3 or USB2 (it’d revert all the way back to probably USB1.0 or USB1.1).
I have connected my USB 2.0 on the USB 3.0 port of my PC. For sure that I tried even this. Nope,it didn’t work. Yesterday I’ve bought this cable :
hoping that it will work. They say :
The **5V 3A USB A to Type-C Cable** is a 5V/3A USB-A to Type-C cable supporting large current charging and data transfer, and compatible with all USB type-C-enabled mobile phones or controller boards like Raspberry Pi 4B, Jetson Nano developer kit, etc.
so,it should be compatible with the jetson nano developer kit.
In theory a 1 meter long USB-C to USB-A cable is not an issue. However, nobody would create such a cable if it did not also support USB 3 on the type-A connector. Here is a picture of a type-A plug from wikipedia:
https://upload.wikimedia.org/wikipedia/commons/c/c4/USB_3.0.png
Notice in that picture that the pins numbered 1 through 4 are an exact match to any USB 2 type-A plug. Pins 5 through 9 are harder to see on a real plug, but if you look closely at your type-A, then I’m thinking you’ll see a total of 9 pins instead of 4 pins. This enables USB 3.1, gen. 1 (a.k.a., what used to be called only “USB 3”; this is 5 Gbit/s, gen. 2 is capable of over 5 Gbit/s).
On the other hand, for $1.95, I can’t imagine any quality in that cable. There are a number of really inexpensive cables out in the wild which literally have 2 tiny strands of copper in the data side (32 gauge or 34 gauge…unbelievably fine and inadequate copper). I would not trust that cable. There is a reasonable chance that the cable is at fault. It is worth getting a better or different cable to try; and to try on different ports. The cable is compatible on paper.
Point me to the link of a working cable sold by an online shop (amazon).
I don’t have any I’ve tried that I can directly guarantee work. What I have was actually provided by NVIDIA. However, there are certain brands I trust more. I’ll start with something not from Amazon, but instead by DigiKey (DigiKey tends to stock quality items):
https://www.digikey.com/en/products/detail/assmann-wsw-components/A-USB31C-31A-100/5869734
Another suggestion is that Tripp Lite tends to provide quality cables. Here are some USB type-A male to type-C male cables with shielding from Tripp Lite:
https://www.digikey.com/en/products/filter/usb-cables/455?s=N4IgjCBcoBwAxVAYygMwIYBsDOBTANCAPZQDaIALHAExwDMEAuoQA4AuUIAymwE4CWAOwDmIAL6FaAdkQgUkDDgLEyIOnACsU6hRDMQ7TjwEjxhOgE5qs%2BYryESkchTAwAbHBmEKbi2DdeIFJgUjQaIN6ubtRMrByQ3HxCohLgFjAWNmhY9ipOIAiMqdQaFnRZCjnKjuQ6MBSlEUF0dBpuenFGSaapALQQ0HLZSg6qFuFFqeGDLFBgrLOQYHBwYmJAA
You won’t find Tripp Lite USB cables on Amazon (so far as I know), but here’s a general search of a couple of better brand cables:
https://www.amazon.com/usb-c-cable/s?k=usb+a+to+usb+c+cable&i=electronics&rh=n%3A172282%2Cp_89%3ABelkin%7CSAMSUNG&dc&ds=v1%3AZTbV9y9ANpzdSxfLdgwZn96aHA0YTHHVwXKlIt%2BDwso&qid=1685120898&rnid=2528832011&ref=sr_nr_p_89_4
Note that the Amazon search isn’t very strict, and I tried to search for type-A to type-C, but the search sometimes ignores my search terms.
Also, keep in mind that the cable might not fix this. I don’t think it is possible to solve this with the cable you do have though; it is necessary to have an actual known high quality cable under the circumstances. Shielded cables are quite helpful for that purpose, and it isn’t just because of a shield; manufacturers who sell a cable with shielding tend to also have reasonable copper content in the data wires. Companies like Tripp Lite don’t want the products the cables are used with to fail, so they tend to have even better quality. It is hit and miss though.
