Jet Pack installation jetson TX2

Beware that many lower quality cables have this issue, it is a common event. When these cables are used for shorter periods of time or at lower speeds they work. However, when running at the full USB2 speeds for long duration errors will cause a disconnect. It is very difficult to get a third party micro-B USB cable (usually labeled OTG) which actually works well. This may be nothing more than a cable issue.

Hi varunqd,

Suggest you can remove below path and try download again:

$ sudo rm -r ~/.nvsdkm

Also you can try other micro-usb cables.

Hi…
I have tried with more than 3 usable cable but still showing the same error.
I also removed the path using the given command

varunqd,

Please use the flash script directly instead of sdkmanager.
https://elinux.org/Jetson/General_debug

Let’s see if flash.sh would find your deivce or not.

Hi…
I tried with the flash script .but no use same error.

Hi,

What same error? USB cannot find your device in recovery mode?

Hi…
It showing “cannot probe to the device”.

I got the same error while using tbe SDK manager.

Hi,

I would suggest to change another host machine to try or find another TX2 devkit(if you have one) to test.

If

case 1. Your current host is able to flash another TX2 devkit, then maybe this problematic tx2 has some defect.

case 2. Another host machine is able to flash this tx2.
Then maybe there are some reasons in old host. I would say not to use it at this moment.

Hi Wayane…

I have followed these two suggestions
https://forums.developer.nvidia.com/t/unable-install-any-jetpacks-jetson-tx2/59810/31
https://forums.developer.nvidia.com/t/unable-to-flash-3-jetsen-tx2-units-with-4-2-2/83112/10

By the following above i was able to run the flash script. but as noted in the above posts the script hangs at this point ‘tegrarcm_v2 --isapplet’

[ 0.8208 ]
[ 0.8209 ] Boot Rom communication
[ 0.8237 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml
[ 0.8263 ] BootRom is not running
[ 5.9764 ]
[ 6.9792 ] tegrarcm_v2 --isapplet
[ 1011.8007 ]
[ 1011.8042 ] tegradevflash_v2 --iscpubl
[ 1011.8087 ] CPU Bootloader is not running on device.
[ 2027.6092 ]
[ 2028.6136 ] tegrarcm_v2 --isapplet
[ 3043.4166 ]
[ 3043.4207 ] tegradevflash_v2 --iscpubl
[ 3043.4251 ] CPU Bootloader is not running on device.
[ 4059.2247 ]
[ 4060.2288 ] tegrarcm_v2 --isapplet
[ 5075.0320 ]
[ 5075.0352 ] tegradevflash_v2 --iscpubl

Could you tell us what you’ve done to make it able to flash?
If you could start the flash process, please also dump the UART log so that we could see what get stuck.

Hi waynee…
As discussed in the above forms.

I first put the board to recovery mode,then connect the usb cable at the same time run the flash script.

(Have to try the above setup for 2 or 3 times until it showed the flash script running)

I was not getting any log on UART console.

Hi,

hmm… ok.
So actually the posts you pasted here didn’t give you much help, did it? You just tried the same as before and somehow it can start the flash process now, right?

Please note that this case is different from your previous test. When you see below log, the UART “should” give out log.

[ 0.8208 ]
[ 0.8209 ] Boot Rom communication
[ 0.8237 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml
[ 0.8263 ] BootRom is not running
[ 5.9764 ]
[ 6.9792 ] tegrarcm_v2 --isapplet
[ 1011.8007 ]
[ 1011.8042 ] tegradevflash_v2 --iscpubl
[ 1011.8087 ] CPU Bootloader is not running on device.
[ 2027.6092 ]
[ 2028.6136 ] tegrarcm_v2 --isapplet
[ 3043.4166 ]
[ 3043.4207 ] tegradevflash_v2 --iscpubl
[ 3043.4251 ] CPU Bootloader is not running on device.
[ 4059.2247 ]
[ 4060.2288 ] tegrarcm_v2 --isapplet
[ 5075.0320 ]
[ 5075.0352 ] tegradevflash_v2 --iscpubl

What is your setup of UART? Please give us step.

Hi…
I have used as usb-ttl converter and connected to J21 Pin 8 and pin 10 respectively.

I use to get the log on my console during the normal boot.

If the device is never get flashed by jetpack4.x, it should be still able to boot up the jetpack3.3, right?

Are you able to boot up this device and share the full boot up log?

Also, just want to know do you have other TX2 module or not? We should at least confirm whether your host is able to flash any TX2 modules or not.

Hi…
Yes.The device is still able to boot up the old jetpack(3.3).
Currently i have got only one TX2.

Please find the attached boot log

jetson_tx2.log (102 KB)

I see an i2c error, and I am wondering, is this the dev kit carrier board, or is it a third party carrier board? In the case of a software issue causing this, then it could be an invalid device tree. If you are using the dev kit carrier board, then the device tree should already be valid.

Hi varunqd,
Not sure why i2c gen7 would have error. My guess is same as linuxdev, are you using a non-devkit carrier board?

Also, one test that might not help but could give some hints too.

  1. Is your board still able to flash jetpack3.3?
  2. Are you able to see UART log during flash procedure when flashing jetpack3.3?

Hi…
I am using the carrier board provide with the dev-kit.

But the device tree present in the current module have some slight modifications as we were running the module on separate custom board previously.

I haven’t tried flashing the jetpack 3.3. Will give a try on it.

Will the change is device tree cause any issues with flashing?

Flash itself won’t care what device tree change there is. However, if that change is still present, then it could cause some failure when comes to actual boot and run of the o/s. USB issues during a flash (versus during install of optional packages) will in no way have any issue with device tree no matter what the change is (well, one corner case is that if the new tree is larger than the space permitted, then flash will indeed fail…but it won’t be because of the change in the tree, this would instead be due to disk space being arranged wrong for that size of partition).