Jetson Xavier NX Failure to Flash "Task 50 or 0x4d Failed" (Jetpack 4.6.1 and Jetpack 5.0.2)

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

We have recently come across a failure to flash in a way that we haven’t seen before.

When using our Jetpack 4.6.1 mfi to configure Xavier NX modules, we have seen the following message show up for three of our modules:

image
image1920×897 202 KB

Investigating the failed modules further, I tried flashing the modules with JetPack 4.6.1 using MFI on my Ubuntu 18 system and my Ubuntu 20 system. The UART logs for each module showed the same thing:

Jetpack 4.6.1 (same message when tried from sdk manager or mass-flash):

[0013.519] E> Task 50 failed (err: 0x7979061c)

[0013.523] E> Top caller module: ALIASCHECKER, error module: ALIASCHECKER, reason: 0x1c, aux_info: 0x06

[0013.532] I> MB1(1.5.1.9-t194-41334769-73a9b7ef) BIT boot status dump :

0000000000011111111110000111111111111110011000111110000000000000000000000000000000000000000000000000000000000000000000000000000011001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[0013.562] I> Reset to recovery mode

Jetpack 5.0.2 (tried only from sdk manager):

[0021.979] C> Task 0x4d failed (err: 0x8c8c011c)

[0021.983] E> Top caller module: MB1_MSS, error module: MB1_MSS, reason: 0x1c, aux_info: 0x01

[0021.991] C> Error: 0x8c8c011c

[0021.994] C> MB1(2.3.0.0-t194-41334769-0a17edc1) BIT boot status dump :

0000000000111111111001000000000001111011111100000011111111111111001110001111100000000000000000000000000000000000000000000000000010100000000001010000000000000101000000000010100000000000000000000000000000000000000000000000000000000000000000000000000000000000

[0022.024] I> Reset to recovery mode

All forum posts I could find on this topic stated the modules needed to be RMA’ed.

Is this caused by a hardware issue with the module? If so, what specific hardware issue is this referencing?

Full UART logs from two different Xavier NX modules experiencing this failure here:
Flash_Failure_02 (2.2 KB)
Flash_Failure_01 (4.0 KB)

3

Hi,

  1. Is this issue happened to single module or more than one?

  2. Was this module able to get flashed before or it is a new one?

  3. Please share host side log as text file too.

4
  1. Is this issue happened to single module or more than one?

We have flashed dozens of modules using these same files, this issue has only been seen on 3 modules.

  1. Was this module able to get flashed before or it is a new one?

All modules that experienced this problem were brand new

  1. Please share host side log as text file too.

I will grab logs from host computer today.

5

Logs attached below from two different module exhibiting this behavior. These are the same modules that produced the UART logs that are attached in my first comment on this post.

Module01 produced UART logs from Flash_Failure_01
Module02 produced UART logs from Flash_Failure_02

We usually flash modules in our custom carrier PCB, in this case, I tried flashing both modules in our custom carrier PCB as well as the nVidia provided Xavier NX devkit

I tried using massflash from 4.6.1 and 5.0.2 on each module.
Module02_4.6.1_mfi_host.log (3.6 KB)
Module02_5.0.2_mfi_host.log (22.0 KB)
Module01_5.0.2_mfi_host.log (22.0 KB)
Module01_4.6.1_mfi_host.log (3.7 KB)

6

Hi,

Please just use flash.sh and NV devkit for the validation and sharing logs.

Using your board and massflash is just making more noise in debug.

Please share host result and uart log based on this condition again.

Also, share the serial number of your good module and all 3 NG modules.

7

I re-pulled the UART and host logs with the same two modules connected to the nVidia devkit while using the following command to flash JetPack 5.0.2: sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

Same issue is present.

Module02_5.0.2_flash_UART.log (4.2 KB)
Module02_5.0.2_flash_host.log (56.4 KB)
Module01_5.0.2_flash_UART.log (4.2 KB)
Module01_5.0.2_flash_host.log (56.3 KB)

Serial number of the two modules below, third module is on our production line, I will add that serial number later
Module 1: 1653921000893
Module 2: 1564321004910

8

There are actually two more modules pulled from our production line that have experienced a similar failure, I have attached the logs and serial numbers below. These logs were captured in the same enviroment as the modules in my reply above, from an nVidia devkit using the same flash.sh command on JetPack 5.0.2.

Module03_5.0.2_flash_UART.log (4.2 KB)
Module03_5.0.2_flash_host.log (56.3 KB)
Module04_5.0.2_flash_UART.log (6.9 KB)
Module04_5.0.2_flash_host.log (56.3 KB)

Serial numbers:
Module 3: 1421122098077
Module 4: 1653921000888

9

Hi @lphillips

Thanks for sharing this info. May I request one more log that… is any of module from these 4 able to get flashed on your custom board? If so, could you share me the flash log (host +uart) of this successful case on your custom board?

If not, then do you have the successful flash log of other module on your devkit?

We will check these 4 logs on our side first.

10

@WayneWWW None of the four modules were able to be flashed on the custom board or the nVidia devkit, same error showed in UART logs when using our custom board and our devkit (task failed 0x4d).

I have attached logs of a successfull flash from a different Xavier NX module on our custom board and in devkit.

goodModule_5.0.2_flash_UART_devkit.log (79.1 KB)
goodModule_5.0.2_flash_host_devkit.log (457.1 KB)
goodModule_5.0.2_flash_UART_customPCB.log (83.5 KB)
goodModule_5.0.2_flash_host_customPCB.log (455.4 KB)

Please keep in mind that on our production line we use JetPack 4.6.1 massflash as described in the first post, we see the same problem. I am using Jetpack 5.0.2 in this post for debugging purposes only.

11

Hi @lphillips

  1. please just share logs based on flash.sh for now. massflash does not help here.

  2. could you put one of NG module and one of good module to devkit and both flash with same jetpack version and share me the host/uart log? And also the serial number of these two module.

12

@WayneWWW The logs I shared above were using flash.sh
The logs I shared in this response are from the no-good modules in the devkit. Jetson Xavier NX Failure to Flash "Task 50 or 0x4d Failed" (Jetpack 4.6.1 and Jetpack 5.0.2) - #7 by lphillips

14

please try if any of these module could be flashed by rel-32.7.3 jetpack on devkit + flash.sh.

15

I ran sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1 on a couple of failed modules with rel-32.7.3 with the same problem.

Capturing UART + host logs is time consuming, I have attached the logs from serial# 1653921000893 module below, the error was the same on the other failed modules.

Please let me know if there is any diagnosis as to what the problem is. I would like if this issue could be root-caused. Let me know if RMA is the easiest path forward. It has been over a week with no progress.

Module01_4.6.3_flash_host.log (50.8 KB)
Module01_4.6.3_flash_UART.log.log (4.6 KB)

18

Hi,

One of the module here is not same as the other.

Module 1: 1653921000893 //8GB Module RAM_CODE: 0,
Module 2: 1564321004910 //8GB Module RAM_CODE: 0,
Module 3: 1421122098077 //16GB Module RAM_CODE: 2,
Module 4: 1653921000888 //8GB Module RAM_CODE: 0

It seems some of your ramcode value from log is not expected. Are you sure it is devkit?

20

We use production modules in our product (the emmc varients of the xavier nx). We have both 8gb and 16gb RAM modules in our inventory and both are flashed using the same process.

I have either placed the modules in our custom PCB or the nvidia provided devkit (in previous responses, I specify which carrier board I place the module in) in order to capture the logs that have been shared in this thread.

21

Do you still have other modules which can get flashed fine and you could check the log?

For example, other fine 16GB module, flash it and check the ramcode in log.

22

I can pull some logs from a known good module, I am not sure I understand what you’re asking me to do.

Do you want me to place a 16gb RAM Xavier NX module into the nVidia devkit and flash it using the same command and pull the logs?

23

Let me explain something. Our xavier nx has multiple kinds. For example, 8GB and 16GB DRAM.

And even “8GB” has DRAM from different vendors (Micro/Hynix…etc) because their product may stop manufacture or something else that make us have to change to another DRAM.

The “RAM code” is a hardware pin that we use to decide which DRAM is in use during flash.
If the RAM code goes wrong, then flash and boot may not succeed.

Some problems I saw on your log is. For example, Module 3 should use ram code 2 after what I check with your S/N. But your log indicates it is using ram code 0.

[0065.259] I> Bootrom patch version : 15 (correctly patched)
[0065.265] I> ATE fuse revision : 0x200
[0065.268] I> Ram repair fuse : 0x0
[0065.271] I> Ram Code : 0x0
[0065.274] I> rst_source: 0xb, rst_level: 0x1
[0065.279] I> USB configuration success
[0068.182] I> bct_bootrom image downloaded
25

Thanks for this information @WayneWWW

I haven’t had time to re-create our flashing setup with these known-bad modules.

I think I understand what you’re saying. The RAM code is possibly being set incorrectly on these modules, which could be the cause of this issue?

Is this RAM code supposed to be set automatically by the flashing software? I was under the assumption that the massflash tools from nVidia should support all varients of the Xavier NX module, regardless of the RAM code.

26

Hi @lphillips

The RAM code is actually decided by hardware. That is why using devkit to validate this issue is needed.

We also had a software bug for ramcode on rel-32.5 and rel-32.6.1. But that issue has been fixed with rel-32.7.

Thus, if you still have flash problem with 32.7.1 ~ 32.7.3 + devkit, I would suggest a RMA.