[Jetpack 3.2] Problems flashing TX2 using native Ubuntu host machine

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi,
I’ve been trying to flash the TX2 devkit using Jetpack 3.2 with no luck. The download and install steps on the host machine are completed correctly but the problem arises when I try to flash the os to DevKit.

I’ve gone through other threads relating to this issue, but I could not find any thread which was closed with a proper solution.

The same devkit can be flashed with another machine so I am thinking that the problem is with this host machine itself rather than Jetson Devkit.

Also please note that, I am able to put the devkit in Recovery Mode and can verify that running

lsusb

is showing the device detected.

While flashing I receive the following error

###############################################################################
# L4T BSP Information:
# R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t186ref, EABI: aarch64, 
# DATE: Fri Mar  2 04:57:01 UTC 2018
###############################################################################
Error: probing the target board failed.
       Make sure the target board is connected through 
       micro-B USB port and is in recovery mode.

even though I can clearly see it in the output of lsusb

Kindly help me resolve this issue.

With regards,
Vedant

2

Are you sure you are using the same USB to micro-USB type B cable ? Can you try another one ?

If it doesn’t improve, and if your host is an old PC, you may also try to add a recent USB hub between host and Jetson. Not sure at all, but in some case I succeeded with this on an old host motherboard.

3

Unfortunately I don’t have the same cable that provided with the devkit, but the cable that I’m using works fine with other host machine. Nevertheless, I’ve tried with 2-3 different usb cables, including a Amazon Basic usb cable (which I suppose has good reliability for data transfer).

Also the host machine is not a older one. I’m using a Dell Latitude 3470 laptop with Ubuntu 16.04 installed.

Regards,
Vedant

4

It isn’t uncommon for the micro-B cables sold with cell phones and other devices normally only used for recharging to not be very good quality for data. Even if the cable works on another machine there is a substantial possibility that the cable is still an issue on another host. It would probably be worth your time to get another cable specifically marketed for data.

5

I am having trouble flashing TX2 using other carrier boards also. The situation is similar there, I’m able to get the acknowledgement that TX2 is in recovery mode, as it is showing up on ‘lsusb’ but not able to flash the module. Getting the same error in the log as in the opening post of this thread.

I don’t think that cable could be a problem now, as the other carrier boards have to flashed using other cable itself (as there are no Nvidia usb cables for USB Male to USB Male for example)

Could you suggest what could be wrong with my Host Machine Ubuntu. Is there anything I can do to resolve this issue.

With regards,
Vedant

6

Any adapter is suspicious. Signal quality can suffer, some work, some don’t. Make sure any adapter for conversion is for type-B at the micro end and type-A at the full-sized end (though I doubt lsusb would work if it is the wrong type, I have samples sitting right next to me where one works and one does not even with the same spec). A cable going directly from type micro-B to full-sized type-A without an intervening adapter is best.

If lsusb works, but data transfer fails, and if the operating system is otherwise good with respect to USB hardware and software, then odds are very high there is a signal quality issue (unless you have a signal analyzer there isn’t much you can do to figure out if it is signal versus software). Can you describe more about your host, such as whether it is under any kind of load during the flash (shouldn’t matter much, but it might), whether you are using a HUB and what other devices are on the HUB, so on? Run this while the Jetson is not connected, and then again while it is connected in recovery mode (this will allow comparing the tree with and without the Jetson):

lsusb -t
7

The cable that I’m using is a cable going directly from type micro-B to full-sized type-A without anything in between. There is no hub present in my setup. Also, there is no load on the host machine while the jeston is flashed.

Please find the diagnostic information below

Without Jetson connected to the host system

it0145@it0145:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 064e:9209 Suyin Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
it0145@it0145:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 6: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M

With the Jetson connected to host and in Recovery Mode

it0145@it0145:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 064e:9209 Suyin Corp. 
Bus 001 Device 045: ID 0955:7c18 NVidia Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
it0145@it0145:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 3: Dev 45, If 0, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 6: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M
8

From what I can see it should be working. Unless there is something odd about the host (such as being a VM) I can’t see why it would be failing. The fact that the Jetson can be flashed from different hosts, and yet not with this host, is puzzling. VMs always give problems, but a natively installed Ubuntu 16.04 would rarely be a problem. As long as the Jetson can be flashed from other hosts it isn’t likely to be a Jetson hardware failure. Is there anything at all odd or unusual about this host?

9

I’m having this exact same problem!

I can see the Jetson board via lsusb when I put it in recovery mode.

I’m trying to install the latest JetPack (3.3), and everything goes fine until I come to flash the board - when I get the exact same error as above. I am using the supplied nvidia cable - though I have also tried an Anker cable I had lying around.

The host machine is an Alienware 15 R3 (about a year old) running Ubuntu 16.04, and I’ve not had problems with any other USB device.

I have also tried with an older laptop - but still get the same error :(

Any ideas?

Best wishes,

Alex

10

I’ve also tried the suggestions in this thread:

https://devtalk.nvidia.com/default/topic/1036305/jetson-tx2/error-in-flashing-tx2/

and tried flashing with

sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

But, like the above thread, I only get

###############################################################################
# L4T BSP Information:
# R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, 
# DATE: Thu May 17 07:29:06 UTC 2018
###############################################################################
Error: probing the target board failed.
       Make sure the target board is connected through 
       micro-B USB port and is in recovery mode.

in the log file.

I have done this with both Jetpack 3.3 and also with 3.2.1 and both encounter the exact same issue.

:(

11

I have finally solved this by installing Ubuntu 16.04 and Jetpack 3.3 in a VM!

When it got to the flashing the image stage, I put the Jetson board in recovery mode and attached it to the VM via the VM USB host.

I am using VMWare if it helps anybody else!

Regards,

Alex

12

I am also having this problem with an Ubuntu 16.04 installation.

I am also using a Dell laptop, and can see the TX2 when I do a “lsusb” command.

This does not work with either a TX2 development board or an Orbitty board.

Based on information that I found in another similar question, I learned that the USB connection used to flash the TX2 is USB 2.0. I then tried to do the download by setting the USB back to USB 2.0 from the information I found here:

I got the same results.

I am wondering if others were using a Dell laptop as well?I have a Dell Precision 5520.

13

The port will re-enumerate at times during the flash. If there is a VM involved, then typically it’ll fail to re-associate the port to the running JetPack. Without a VM, then this won’t be an issue…something else could go wrong, e.g., a lot of micro-B cables (mislabeled “OTG” since the cable itself is type-A or type-B and only the port is “OTG”) are designed as chargers and for cheap telephone connection and fail (the included micro-B USB cable works).

So if you are using a VM, find out how to force the port to bind the Jetson to the VM at all times. No matter how many times it disconnects/reconnects, it has to automatically route it to the VM as the same device. If not using a VM, then there is another problem.

14

linuxdev –

thanks for taking the time to reply. As I said, I am using a native ubuntu 16.04 laptop – NO VM.

Someone else on this post mentioned that they had trouble using a Dell laptop, and saw that connection here. I believe that it might have something to do with the USB setup/driver.

Can anyone tell me exactly what to look for in the USB settings, and how to find that information so that I can see if it is something with the driver setup? I cannot find that information anywhere…

15

If it is native, then there is nothing to set up. Any USB2 or USB3 port will work. The driver package itself has no settings and should “just work” on most native host PCs. All of previously mentioned USB settings are only for a VM.

Sometimes making sure the cable is directly connected between Jetson and host helps. Sometimes having a HUB between helps. Making sure that port is not shared with other devices can help (use “lsusb -t” to see the tree listing of devices…multiple physical ports might be using the same HUB…having just the Jetson on the HUB can help). If you are not using the original micro-B USB cable which comes with the Jetson, then this might be at fault (quality of charger cables is often terrible).

16

I’m also having this error
(error probing the target board failed) on jetson tx2 and I use ubuntu 16.04 VMware

Also, Ican see the Jetson board via lsusb when I put it in recovery mode.
But this error apear ( error probing the target board failed)
How I can fix it?
Kindly if someone help me.
Regards

17

Your VM has to be configured to always have ownership of that device. It re-enumerates during flash and will be lost if unplugging/replugging (enumeration) type events fail to always go to the VM. I can’t tell you how to fix this since I don’t actually use a VM.

18

For future reference, it is possible Ubuntu throttles or puts USB to sleep too fast. If it allows flashing or cloning for a second after going into recovery mode, but then after a few seconds it stops then it is probably a linux issue. One program that causes this is “tlp” (TLP - Optimize Linux Laptop Battery Life — TLP 1.5 documentation). So “apt remove tlp” in case it was somehow installed.

19

That would make sense, and I would bet that if tlp is used with a VM it would cause even more problems than on a regular host/laptop.

20

I am facing same issue , I am on Alienware m17 . I dont have tlp installed on my ubuntu18.04 either. Can someone help