I have the issue that I can’t bring two Xavier NX SOMs in Force-Recovery mode.
My setup is a Jetson Nano Devkit, connected with USB to my flashing PC and to UART. The Force-Recovery is permanently connected to ground.
When I insert an Orin NX 16GB, it is going in Force-Recovery and showing up as an USB device on my PC, just as I would expect it.
I have two Xavier NX boards. One old one with the old SK hynix RAM, one newer one with the Micron RAM.
Both are starting to boot after Power-ON and send serial ĺogs instead of going in Force-Recovery.
I made sure to not touch or move the Jumper cable connecting Force-Recovery PIN with ground between switching the SOMs. I also repeated the swap several times.
Regarding the newer Xavier, I have a small additional question: I flashed it with L4T Version 35.5.0 which after reading PCN21114 should not have worked?
Do you have any idea, how I can bring these SOM in the Force Recovery mode?
Do you need additional information, that I can provide you?
Force recovery acts like a “SHIFT” key modifying any power on or power reset. It shouldn’t be kept grounded, but it also would not hurt it for most cases. The goal is to hold the recovery pin grounded, and then either tap power on (if it was off) or power reset (if it was already on); then let go of the recovery pin.
Maybe someone else could answer something I do not know the answer to: Is the Orin NX 16 GB module compatible with the Jetson Nano Devkit carrier board? I would think that the older Nano carrier board is probably slightly different than the Orin Nano carrier board.
Those carrier boards are not compatible with the module you are using.
Also, I want to clarify that if you just could not enter recovery mode, then it has nothing to do with PCN or any software configuration. It is just the wrong hardware might be used.
I repeated my test with an Orin Nano Devkit and our custom carrier board.
With the two devkits, i always get the same results.
With our custom carrier board, i also cannot get these two Xavier SOMs in recovery mode.
But i have an identical carrier board in an assembled Edge-PC with a XavierNX, that can be put in force recovery.
Also, my hardware colleague means, that regarding the force-recovery and the power sequence, the Xavier is compatible.
It would be good to know, if there in fact is a difference and what it would be.
Since force-recovery is working with our carrier board and a Xavier, as well as Orin Nano and Orin NX, the difference can’t be that big.
I now did some more testing.
Unfortunately, we don’t have a Xavier NX devkit.
But following this post, our Jetson Nano Dev-Kit should work, when provided with enough power (i give it 5V with 4Amps):
So, to sum it up:
I have two Xavier NX, both 900-83668-0000-000.
One is going in Force-Recovery when i use either our Carrier-Board or the NVIDIA Dev-Kit for Jetson Nano (945-13450-0000-100). Same with the Dev-Kit for Orin Nano (945-13766-0005-000).
The other one is not going in force recovery in any of my tested boards and instead starts booting and producing serial debug log.
If the module is blank and erased before shipping then it should enter force recovery mode as the SW image is blank. If there is SW flashed already then it will boot normally and you would get UART logs. Are you able to enter force recovery mode on all these modules?
All involved SOMs have already been flashed, so they boot up by default.
No, i don’t get two Xavier NX modules in force recovery. I have only one Xavier NX, that works as expected. Even if i put the SOMs in the same Carrier board without changing anything else.
I measured the SYS_RESET Pin with Channel 1 and the FORCE_RECOVERY Pin with Channel 2.
While triggering on the positive edge of SYS_RESET, i turned on the power to the carrier board.
Need to keep Force_Recovery held low before release the sys reset and then release Force_Recovery. As the Force_recovery is High in your case, the module will not enter flashing mode.
Of course i did not pull the force recovery to ground for this measurement.
When i do so, it stays low.
I thought you mean scoping during operation without force-recovery pulled to GND because i would otherwise scope a “signal” pulled to the reference of the oscilloscope, which will always be exactly zero.
From the serial numbers the modules seem to be from 2022. Do you know the history of these modules, timeline when they were purchased and put to first use?
Ok, Thanks. Could you help comment on, From the serial numbers the modules seem to be from 2022. Do you know the history of these modules, timeline when they were purchased and put to first use?
How long they have been in use? Suspect Electrical Over Stress (EOS) damage to Force_Recovery pin could be caused by ESD. Do you have ESD protection on your carrier board?
