We have multiple Xavier NX modules ( JL4T R32.5.1 ) that seem to sporadically ( 1 in 100 powercycles ) loose their bootloader after a powercycle.
No output is sent to the serial interface at all in this state and does not seem to do anything. It usually prints bootloader output.
But there seems to be no hardware problem. The device can be put in RCM mode and flashed again without problems.
Is there a way to readback the bootloader via RCM or check it somehow?
Thank you
Hi jwoeber,
Are you using the devkit or custom board for Xavier NX?
Have you also tried with the latest R32.7.5?
Would the reboot recover?
Please share the full serial console log for further check.
Thank you for your quick response @KevinFFF.
We would prefer to debug and find the problem first as we also have a couple of devices in the field ( airborne application ) where a update of the L4T version would be quite difficult. Is there some improvement from 32.5.1 to 32.7.5 in the boot concept that could reasonably fix this problem?
No. The system is only recoverable by flashing it again. A reboot does not recover it.
There is no serial console log. Not a single character is output on the serial console in this state.
Thank you
You can get a local device to reproduce the issue to check if the issue is specific to R32.5.1.
Or if you would still hit the issue with R32.7.5.
Please debug the issue locally first and find out the root cause, then you would know how to deal with the devices in the field. We need the serial console log when you hit the issue for check in further.
Thank you @KevinFFF,
we have newer products which uses R32.7.2 and don’t show this issue. So a l4t update is definitely on our list of things to try but as mentioned it might be hard to roll out. So if there would be a way to specifically debug and fix this issue it would be great.
So is there a way to read back or check the bootloader via RCM.
Thank you
Do you mean there’s no issue with R32.7.2 but having issue with R32.5.1?
They are old release so that it’s hard to find the difference between them.
Please share the full serial console log when you hit the issue to find if there’s any clues.