Jetson Xavier AGX Industrial flash issue

Hello,

I am using a custom-made carrier board for Jetson Xavier AGX Industrial module and carrier board has USB type A (USB2.0) for recovery mode and it is connected to the host PC [Ubuntu 18.04]
After powering on the Board, Jetson Module is detected by the host PC using lsusb command.

whenever trying to flash the board using the SDK manager with the below-given configurations:
Target Hardware: Jetson Xavier AGX Industrial
Linux: JetPack 5.1.1
We are able to download the Jetpack but whenever the SDK manager is trying to flash the jetson with the following configurations, we are facing the target is in a bad state error.
Device detection: Jetson Xavier AGX Industrial [3-1]
Manual setup-Jetson Xavier AGX Industrial (First-time Configuration)
OEM Configuration: Run Time
Storage device: EMMC
Please find the error screenshot and please take a look at the UART Terminal log


SDK_Teraterm_log.txt (2.4 KB)


After I tried to flash using the command “sudo ./flash.sh jetson-xavier mmcblk0p1”
Please find the below Host PC log and UART Terminal log.
Host_PC_log.txt (53.9 KB)
CMD_TeraTerm_log.txt (4.4 KB)

In this flashing process, the below-given lines are repeating and it is not going to further operations. please refer above provided Log.
[ 9.3706 ] tegrarcm_v2 --isapplet
[ 1018.6181 ] tegrarcm_v2 --ismb2
[ 2034.4512 ] tegradevflash_v2 --iscpubl
[ 2034.4545 ] CPU Bootloader is not running on device.

@Trumany please help us.

The board config for xavier agx industrial is jetson-agx-xavier-industrial.conf. So your flash command is wrong.

@WayneWWW

we have tried with this command: “sudo ./flash.sh jetson-agx-xavier-industrial mmcblk0p1”
Flashed successfully.

Thank you for quick response.

Can you please explain us the flashing process by using SDK Manager, when we tried with SDK manager we got this error: the target is in a bad state error. Please help us on How to resolve the issue.

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

No idea about that.

SDKM is using similar flash script to flash. Are you still able to reproduce same sdkm issue on your board?