Failed to flash Drive OS 6.0.10: Unable to read BCT

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.10.0
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
2.1.0
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Issue Description

Although it used to flash successfully, there is a particular Drive AGX Orin that stopped flashing successfully at some point.

It fails at the “Preserving SkuInfo from Target” step.

Other Drive AGX Orin devices do not encounter this error with the same procedure. Is there a way to recover?

Both Drive OS 6.0.8.1 and 6.0.10 fail.

The flashing procedure is:

root@6.0.10.0-0009-build-linux-sdk:/drive# ./flash.py /dev/ttyACM1 p3710 --clean
2025-03-11 10:48:41 INFO : Setting flash clean to initialize persistent partitions
2025-03-11 10:48:41 INFO : Initiating pre-flash check
2025-03-11 10:48:41 INFO : Checking Serial Port Connection
2025-03-11 10:48:41 INFO : Serial Port found /dev/ttyACM1

...

2025-03-11 10:50:55 INFO : bypassing inforrom for flashing cmd
2025-03-11 10:50:55 INFO : Pre flash script found! Calling scripts/linux_pre_flash.sh
2025-03-11 10:50:55 INFO : Running flash command: sudo -E /drive/drive-foundation//tools/flashtools/bootburn/bootburn.py -b p3710-10-s05 -B qspi -x /dev/ttyACM1 --init_persistent_partitions
2025-03-11 10:50:55 INFO : This may take a few minutes
2025-03-11 10:50:55 ERROR : Flashing failed, please contact provider with logs /drive_flashing/log_w0c4l2h5jk7tbvyasegq38xp6zfm91id.txt and /drive/driveinstaller/driveinstaller.log....

Error String

This is where driveinstaller.log indicates a failure:

[2025-03-11 10:50:54,921 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [PreserveTargetSkuInfo(1619)] : Preserving SkuInfo from Target\r\n'
[2025-03-11 10:50:54,982 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [executeShellCommand(163)] : shell command -- /drive/drive-foundation/tools/flashtools/flash/tegrarcm_v2 --instance /dev/bus/usb/001/067 --oem dump bct ./read.bct failed\r\n'
[2025-03-11 10:50:54,983 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [executeShellCommand(165)] : Output: MB2 Applet version 01.00.0000\r\n0000000054220302: E> NV3P_SERVER: Failed to get address for br bct from nv3p helper.\r\n\r\n\r\n'
[2025-03-11 10:50:54,983 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [executeShellCommand(172)] : Return code: 2\r\n'
[2025-03-11 10:50:54,983 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [PreserveTargetSkuInfo(1628)] : Skipped or Unable to Read BCT. The storage may be empty or erased\r\n'
[2025-03-11 10:50:54,984 root DEBUG console_logger.py 17 18910] b'[bootburnTegra-A]: [PreserveTargetSkuInfo(1629)] : Flash along with --customer-data option to have a valid images on storage\r\n'
[2025-03-11 10:50:54,984 root DEBUG console_logger.py 17 18910] b"[bootburnTegra-A]: [PreserveTargetSkuInfo(1630)] : Note, -R option should not be used while flashing a valid bct to storage\r\ncommand line used was:\r\n['/drive/drive-foundation//tools/flashtools/bootburn/bootburn.py', '-b', 'p3710-10-s05', '-B', 'qspi', '-x', '/dev/ttyACM1', '--init_persistent_partitions']\r\n\r\n\r\n\x1b[01;31ms_ERROR_TOOL_TEGRARCM_SKUINFO\x1b[0m\r\n\r\n\r\n"
[2025-03-11 10:50:54,984 root DEBUG console_logger.py 17 18910] b'\r\n\x1b[01;31mException 43 raised in bootburn_active \x1b[0m\r\n'

Logs

flash_fail_logs.zip (25.0 KB)

3

Dear @hidekaz,
Is Devkit’s Aurix and tegra accessible using minicom now?
what is the condition of board before trying to flash?

4

Dear @SivaRamaKrishnaNV ,

Is Devkit’s Aurix and Tegra accessible using minicom now?

For Aurix, it can be controlled via minicom.
However, there is no response from Tegra.

What is the condition of the board before trying to flash?

It works normally and flashing was successful just before.

However, there are no logs remaining, but 2-3 weeks ago, there were instances where Flash kept failing due to adb push failures during bootburn. It’s a somewhat unstable situation where if we retry after a few days, we can successfully Flash

Below is the log from the Aurix side when the Tegra was reset.
Since there is no response from Tegra, no log is available for it:

$ minicom -w -D /dev/ttyACM1
NvShell> tegrarecovery x1 on
Info: Executing cmd: tegrarecovery, argc: 2, args: x1 on
Command Executed
NvShell> tegrareset x1
Info: Executing cmd: tegrareset, argc: 1, args: x1
NvShell> INFO: MCU_PLTFPWRMGR: Reseting Tegra
INFO: MCU_PLTFPWRMGR: VRS11 PG Monitoring disable.
INFO: NVMCU_ORINPWRCTRL: Wait for Safe Shutdown notification...(20 seconds max)
I: RptrID - 0x810B PsCd - 0x22 - VMON Nirq Disabled
I: RptrID - 0x810B PsCd - 0x21 - VMON Nirq Enabled
INFO: BtChn_Cfg: Tegra x1 Boot Chain is : A
INFO: BtChn_Cfg: Btchn Pin ORIN_BOOTCHAIN0 set to 0
INFO: BtChn_Cfg: Btchn Pin ORIN_BOOTCHAIN1 set to 0
I: RptrID - 0x810F PsCd - 0x6 - BootchainCfg Dio set success
INFO: MCU_PLTFPWRMGR: Tegra reset trigger is complete!
Command Executed
MCU_FOH: MCU FOH : Initiate SOC Error Pin Monitoring & SPI communication
MCU_FOH: MCU FOH : Start Monitoring Initiated
INFO: MCU_ERRHANDLER: Published Power State: Power-up complete
MCU_FOH: SOC error pin is asserted
ERROR: MCU_ERRHANDLER: SOC error pin is asserted
MCU_FOH: Spi Transmit Started
INFO: SftyMon_IoHwAbs: PG_VRS11 monitoring started...
INFO: MCU_SWC_FanControl: max_rpm fan2 : 0
INFO: MCU_SWC_FanControl: maxrpm of fan2 has more than 50 percent deviation against rated maxrpm
5

Dear @hidekaz ,
Please check running tegrarecovery x1 off & poweroff & poweron on aurix console and see if tegra is accessible.

Also, please share the dmesg logs on host when trying to flash.

6

Dear @SivaRamaKrishnaNV ,

I attached log file contains 5 files.

minicom_ttyACM0.cap: tegra serial log. The file is empty due to no response.
minicom_ttyACM1.cap: aurix serial log
driveinstaller.log, log_ikf4btsxo37hw0r8p9nye2dj5m1zvcul.txt: flash logs by “./flash.py /dev/ttyACM1 p3710 --clean”
dmesg.log:Complete dmesg logs from the host PC from boot-up until flashing.

flash_fail_logs_with_dmesg.zip (47.6 KB)

7

Thank you for sharing the logs. We will look into it and update you.
Is the board used in car premises earlier? which versions were successfully flashed earlier.
Can you also try changing the bootchain and see if it gets booted.
Please see Using the MCU Console | NVIDIA Docs for usage details. Please

getdfltbtchain x1  # confirm the boot chain. Default is A.
setdfltbtchain x1 B # Set the boot chain B. 
aurixreset #wait 20 secs and issue next command
poweroff #wait 20 secs and issue next command
poweron 
getdfltbtchain x1

Also, see if any additional NVIDIA device is detected when target is set to recovery mode.

#Run below commands on aurix console to set tegra in normal mode
tegrarecovery x1 off
tegrareset x1

#Run below command on host. Host is connected to target for flashing. Make sure there are connections between host <-> target's debug port and host<-> target's left type C port . For connection details check step 2,3 in page 9 of Quick start guide
lsusb

#Run below commands on aurix console to set in recovery mode
tegrarecovery x1 on
tegrareset x1

#Run below command on host to check if any additonal NVIDIA device is noticed.
lsusb

#Run below commands on aurix console to keep tegra in normal mode again
tegrarecovery x1 off
tegrareset x1

As tegra console is not accessed, can you check the minicom setting with CTRL + A +Z followed by O and select serial port and setup and see if the settings are like below

minicom
minicom867×252 34 KB

8

Dear @SivaRamaKrishnaNV,

Is the board used in car premises earlier? which versions were successfully flashed earlier.

No, the board is not used in car premiss.

I succeeded to flash versions were 6.0.8.1 and 6.0.10, prior versions are unknown.

Can you also try changing the bootchain and see if it gets booted.

I tried steps you wrote. However it still failed to flash.
There was a different from serial port settings. “Hardware Flow Control” is “Yes”.
So I changed it “No” before try to flash.

I attached logs.

flash_fail_logs_change_bootchain.zip (49.6 KB)

Here is the complete steps to get above log.

Lauch two terminal

minicom -w -D /dev/ttyACM0 -C ./minicom_ttyACM0.cap
minicom -w -D /dev/ttyACM1 -C ./minicom_ttyACM1.cap

Change bootchain at ttyACM1

getdfltbtchain x1
setdfltbtchain x1 B
aurixreset
poweroff
poweron
getdfltbtchain x1

Close minicom terminals.

Launch docker and try to flash “./flash.py /dev/ttyACM1 p3710 --clean”.

But thhe flashing was failed.

Lauch two terminal again

minicom -w -D /dev/ttyACM0 -C ./minicom_ttyACM0-2.cap
minicom -w -D /dev/ttyACM1 -C ./minicom_ttyACM1-2.cap

And check usb port status following step you wrote

tegrarecovery x1 off
tegrareset x1

# Check the Type-C usb port is correct (left port)
lsusb

tegrarecovery x1 on
tegrareset x1

# Reconnect Type-C usbport
lsusb

tegrarecovery x1 off
tegrareset x1

I attached lsusb logs into lsusb.txt

9

The logs indicates, even you run commands to set board in normal mode, the board still is in recovery mode(additional NVIDIA device noticed in lsusb). Can you please double check it?

10

I have rechecked the “minicom_ttyACM1-2.cap” file. Although I’m not exactly sure where to look to confirm if it remains in Recovery mode, I entered the commands as instructed.

Line 3

NvShell>tegrarecovery x1 off
Info: Executing cmd: tegrarecovery, argc: 2, args: x1 off 
Command Executed
NvShell>tegrareset x1
Info: Executing cmd: tegrareset, argc: 1, args: x1 

...

Line 32

NvShell>tegrarecovery x1 on
Info: Executing cmd: tegrarecovery, argc: 2, args: x1 on 
Command Executed
NvShell>tegrareset x1
Info: Executing cmd: tegrareset, argc: 1, args: x1 

...

Line 58

NvShell>tegrarecovery x1 off
Info: Executing cmd: tegrarecovery, argc: 2, args: x1 off 
Command Executed
NvShell>tegrareset x1
Info: Executing cmd: tegrareset, argc: 1, args: x1 
NvShell>INFO: MCU_PLTFPWRMGR: Reseting Tegra

Since it doesn’t appear to be in normal mode, is there anything additional I can try?

11

If the board is in recovery mode, you should be an additional NVIDIA device in lsusb output on host.

Can you share the host and target connection picture?

12

I attached the picture.

image
image890×899 64.5 KB

There is no difference of lsusb output on the host screen between “tegrarecovery x1 on” and “off”.

13

The board is not going into normal mode. Let me check internally and get back to you.

14

Dear @hidekaz ,
Could you check reconnecting cable wires and give a try if the board can be set in normal mode and recovery mode from aurix console. We notice similar issues like board not going to recovery mode if there is loose connection.
If it works, make sure you put the board in normal mode before trying to flash using flash.py script.

15

Dear @SivaRamaKrishnaNV,

I tried several times, but the Orin does not enter normal mode.

I also connected to a different Orin using the same host PC and cable, and in that case, Flash is completed normally.

In addition, when checking lsusb, only in recovery mode, it displayed:

Bus 001 Device 051: ID 0955:7023 NVIDIA Corp. APX

So I believe the issue is not with the host PC or cable.

16

Dear @hidekaz ,
Could you try to set different bootchain and try tegrareset to see if tegra loads? By default, it boots into bootchain A. See https://developer.nvidia.com/docs/drive/drive-os/6.0.10/public/drive-os-linux-sdk/common/topics/mcu_setup_usage/mcu_setup_using_the_mcu_console.html?hl=using%2Cmcu%2Cconsole%2Cnvidia%2Cdocs for bootchain setting commands.