Already mentioned we’ve tried reboots and multiple computers as the host.
As for USB autosuspend, it’s not an issue we’ve seen. It doesn’t seem to be related also based on description of that post. We have no issues with USB once the target is put into debug mode, but normal mode we have no access to ttyACM.
What did you mean debug mode? recovery mode? put it into recovery mode using the recovery button?
I’ll check the no /dev/ttyACMx issue with our team and get back to you.
Hi VickNV,
In my Ubuntu 20.04.5 host, a physical PC, 0955:xxxx is outputed in lsusb command, but still failed to enter recovery mode. I even tried tegrarecovery & tegrareset commands and then run bootburn.py immediately. But still got the same error:
yang@xps:~/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn$ lsusb | grep 0955
Bus 001 Device 011: ID 0955:7045 NVIDIA Corp.
yang@xps:~/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn$ ./bootburn.py -b p3710-10-s05 -B qspi
****** Starting bootburn/bootburn.py ********
Script directory: /home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn
Parent directory added to path: /home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn/..
********* Starting t23x bootburn py ********
Bootburn Starting with arguments ['./bootburn.py', '-b', 'p3710-10-s05', '-B', 'qspi']
cwd in setBoardConfigPath :: /home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn_t23x_py
trying hardware folder:
/home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/platform-config/hardware/nvidia/platform/t23x/automotive/flashing/board_configs
cwd in loadBoardGoldenRegsFile :: /home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn_t23x_py
Default Schema:/home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn_t23x_py/nv-customer-data-schema-orin.json
Check finished successfully
Done parsing command line
[bootburn]: [getListTargetsInRecovery(3508)] : Bus 001 Device 011: ID 0955:7045 NVIDIA Corp.
[bootburn]: [CheckRecoveryTargets(3466)] : No recovery-target found; Make sure the target device is connected to the
[bootburn]: [CheckRecoveryTargets(3467)] : host and is in recovery mode. Exiting
command line used was:
['./bootburn.py', '-b', 'p3710-10-s05', '-B', 'qspi']
ERROR_TARGET_RECOVERY
Exception caught in bootburn
Traceback (most recent call last):
File "/home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn/../bootburn_t23x_py/bootburn.py", line 288, in bootburn
bootburnLib.CheckRecoveryTargets()
File "/home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn/../bootburn_t23x_py/bootburn_lib.py", line 3468, in CheckRecoveryTargets
AbnormalTermination("ERROR_TARGET_RECOVERY", nverror.NvError_ResourceError)
File "/home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn/../bootburn_t23x_py/flashtools_nverror.py", line 249, in AbnormalTermination
raise OSError(errorCode)
OSError: 15
returning to directory /home/yang/nvidia/nvidia_sdk/DRIVE_OS_6.0.4_SDK_Linux_DRIVE_AGX_ORIN_DEVKITS/DRIVEOS/drive-foundation/tools/flashtools/bootburn
Cleaning up ...
Cleaning temp dir
Please try a clean power cycle by unplugging the power supply, waiting for ~30s, and powering back on. This will exclude issues related to entering a fault state with the previous boot. If recovery mode still cannot be entered after this, either through the push button or Aurix, we may need to get the system back to a closer look.
That was one of the first things we had tried. Full power disconnect, wait, reconnect. In fact, it had gone into a vehicle a bit ago which provides multiple instances of no power for extended periods for vehicle work.
@ibreakthings As discussed offline, once you’re able to take the unit out, please have it a try on bench and let us know if the issue is still there. Thanks.
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