Flashing fails

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
23 
> I2C: Could not write 0 bytes to slave: 0x00ac with repeat start true.        
E> I2C_DEV: Failed to send register address 0x00000000.                         
E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xac at 0x0000000.
E> eeprom: Failed to read I2C slave device                                      
C> Task 0x0 failed (err: 0x1f1e050d)                                            
E> Top caller module: I2C_DEV, error module: I2C, reason: 0x0d, aux_info: 0x05  
I> Busy Spin

The i2c error from 0x00ac is the address of the carrier board eeprom. Most of custom board wonā€™t have this enabled.

You should check with the board vendor if this is not a board made by you. They should provide a customized BSP for you to flash.

24

I found the BSP + instructions from the vendor. Still experience issues thereā€¦ but I assume, they will provide support.

Thank you very much for your time, Wayne.

1 Like
25

It could be that you bypassed one error but still hit another one later.

For example, I believe their BSP shall bypass above error but hit something new.

However, as no log is provided, I am not sure.

26

If you donā€™t mind: excellent. Find below the cdl-log and the UART-log.
Please mind that I 1) entered miniconsole 2) flashed using the vendors tool. 3) rebooted (RCM).
log01.txt (11.5 KB)
log02.txt (48.7 KB)

27

Hi @dejhost

Just a reminder that. I totally didnā€™t see any flash successfully log from your so far.

You have to learn how to tell whether a board got flashed or notā€¦ A successful flash requires to take about 15 minsā€¦
If you hit error right after flash command, it wonā€™t be a successful oneā€¦

28

Only this one has successful flash log. The rest are not.

29

Also, are you sure the flash log on host and device side you shared are paired? But not separate one?

30

Sorry for the confusion. I see now that that was a poor choice of words. I should have written ā€œ2) initiated flashing using the vendors tool.ā€. I failed after a few seconds, so no flash happened.

First time I attempted to flash using the vendors tool, I had not enabled miniconsole. So once I realized flash failed, I enable miniconsole and repeated the attempt. Thatā€™s why there might be different timestamps.

31

Hi,

If you saw the host side error log is USB timeout with sending bct_br, then it is as my previous comment. You need to disable the usb auto-suspend on your host PC.

[ 0.5249 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
[ 0.5277 ] BR_CID: 0x80012344705DD787800000000BFF0280
[ 0.5294 ] Sending bct_br
[ 0.5298 ] ERROR: might be timeout in USB write.
Error: Return value 3

32

I disabled the autosuspend earlier. The File /sys/module/usbcore/parameters/autosuspend shows -1.
I repeated the process:

  1. Disabled autosuspend
  2. unpluged usb cables
  3. rebooted into RCM
  4. plugged in USB cables
  5. enabled miniconsole
  6. Initiated the flash-tool from the vendor, which failed after a few seconds.

The logs are identical to the previous ones. I attach them here.
log2b.txt (12.5 KB)
log2a.txt (3.2 KB)

So either the USB-autosuspend feature isnā€™t the issue, or the fix is not applicable.

33

Hi,

Just another clarification.

Disabling auto-suspend is only for the error ā€œSending bct_brā€ and then usb timeout.

Your new error indicates this is not ā€œSending bct_brā€ error anymore. So disabling auto-suspend works. But a new error comes afterwards.

I believe this new error comes from a wrong flash command implemented in that vendor tool.

34

Thank you for clarifying.
Iā€™ve sent an email to the vendor earlier. I will report back to you if/once they contacted me.
Thank you once again for your time.

1 Like
35

Brief update: I got support from the vendor. They did not manage to flash the board neither (using remote access to the host). Also strange: the board does not leave RCM. A new board one is on the wayā€¦

36

I finally managed to flash. Here are the key-issues:

  1. Ubuntu 18.04 does not seem to be compatible. Ubuntu 20.04 worked.
  2. The command lsusb returns always ā€œNvidia Corp.ā€, as long as the board is plugged in (USB) and powered on. lsusb does not show whether the board is in recovery mode or not.

Hopefully, this saves other developers some troubles.

37

Honestly, I doubt the ā€œkey issuesā€ you are talking about here.

Didnā€™t the key point here is you change to another new board?

For example, other usersā€™ ubuntu 18.04 does not hit the issue you hit.

38

Mhmm, here, someone had the same issue: Cannot flash OS image to Orin Developer Kit via SDK Manager

Both my boards had the issue, that they left me with the impression that they cannot leave the recovery mode - because lsusb always returs the ā€œNvidia Corpā€.
The support from the vendor, who remote controlled the ubuntu host, experienced the same issue - and initiated the exchange of the board.

39

Hi,

Just to clarify.

  1. Actually, I deal with lots kind of flash problem everyday. I always see some users give another post from somewhere else and said ā€œhey, there is similar postā€. But turned out they are not same issue at all.
    For example, the whole error logs you shared in these 37 comments in this topic does not give ā€œprobing the target board failed.ā€ error.
    The post you think is same issue does not provide full log at all. His case is also based on VM. A VM means a unstable connection. I donā€™t know if you still used 18.04 VM or not. You said you are not using VM, then I trusted you.
    Also, the post you shared may not be using ConnectTech carrier boardā€¦

  2. Since this issue is on custom board, maybe the vendor should review if any problem on their design. A recovery mode is a pure hardware event. When the board is in recovery mode, there is no software running on the board itself.

40

Hi,
You are certainly right: the post I linked to is not a perfect fit. However, we both got [ 0.0805 ] ERROR: failed to read rcm_state. when the flash procedure starts. Switching to Ubuntu 20.04 solved the problem in both our cases.

Neither me nor the support from the vendor realized this error [ 0.0805 ] ERROR: failed to read rcm_state at the beginning of the log, because there are indication for USB-timeout further down in the log. We focused on (and failed) troubleshooting only the most recent errors, and eventually replaced the board.

I switched from VM to ā€œbare metalā€ (Ubuntu 18.04) straight after you recommmended to do so ((see my post 01.10.23). Only yesterday, I switched from Ubuntu 18.04 to 20.04.

I already sent an email to the vendor support. I assume they will come back to me with more questions, if they want to dive into it.

Hope this clarifies a bit from my side.

41

0.0805 ] ERROR: failed to read rcm_state .

This actually does not matter. Even the successful flash log may have this print.
Unless you didnā€™t see it in successful flash log, I donā€™t think it is the cause hereā€¦

42

JetPack/SDKM works from more releases than what can be used. The particular L4T release being flashed, and the hardware being flashed, will limit the host PC release to a subset of what JetPack/SDKM works with. In the case of Orin Ubuntu 18.04 should work, but 20.04 is recommended. In all cases, regardless of what is being flashed, a VM tends to get in the way. VMs need to correctly handle USB passthrough even if there is a disconnect and reconnect, and this quite often fails. VMs are a major point of USB failure during flash.