Since other flashes worked I’ll assume this is not a VM for host PC and that the USB cable itself is likely working. Someone else will probably have to answer, but meanwhile, consider that you can flash a Jetson module on one carrier board and then move it to another carrier board. Do you have a dev kit carrier board available? If so, then try to flash the module on the other carrier board just to see if it works. If you flash the dev kit software on that other carrier board, then that should boot; if you flash your software on while the module is on the dev kit, and then transfer it to your custom carrier board, then that should also work. If you cannot flash at all on a dev kit carrier board, then you’d probably want to post the serial console log and flash log for the case of flashing NVIDIA’s dev kit software (the serial console on the Jetson can be logged during a flash). If the flash does succeed on the dev kit carrier board, then this is likely a problem with the carrier board; if the flash fails even on the dev kit carrier board, then likely this is a problem of the module (it could be a problem of the USB cable, but you’ve stated other modules succeed in flash with this cable).
We have not changed our carrier board. Jetson Orin modules from previous batch was flashed successfully being plugged into our carrier boards.
Thanks for idea with devboard flashing, I really have one - but I don’t have new modules, we need to send them from manufacturing facilty to me, it’s about 1-2 days. The same for serial console, I have one board with soldered UART connectors.
Sometimes there is a revision on a module, e.g., maybe a new type of memory used, which could require a change to firmware. The serial console log would be one way of seeing if that is the case, so I do not think there is any easy way to debug except if you have the module and carrier board physically there. If the serial console works, even with soldered connectors, then that should be just as useful if you monitor that during a flash. It might show something new, but knowing if it works on on a dev kit board would be very useful for debugging.
I’ve just updated SDK manager to the latest version and tried to flash Jetpack 6.2 again.
1st error I’d got you can see on screenshot - nvme device is not accessible
I will also suggest that due to the “nvme unavailable” you try to plug in the NVMe to another Linux computer and see what shows up. You don’t have to change anything on the NVMe, but do see if it is readable. If the NVMe shows as “/dev/nvme1n1”, then you could do something like this on the machine where that shows up: sudo gdisk -l /dev/nvme1n1
(this is a read-only list of partitions on the NVMe; the idea being to see if the NVMe responds without error)
Sometimes error messages are not entirely descriptive, but since the lsusb shows up it might be worthwhile to first verify the NVMe.
Incidentally, Jetsons are quite picky about power supply regulation quality.
we have just purchased a new batch of Jetson Orin Nano 4Gb - i will call it “new module”
we used Jetson 4Gb modules before successfully - I will call it “old module”
we have our own carrier board which were manufactured in the same batch
We found out some workaround looking a bit weird.
We found one piece of the carrier board is able to flash a “new module” - this is a “lucky carrier”
If this module and SSD then moved to the “new” carrier board - they are working.
The only difference between “lucky carrier” and “unlucky carriers” if the lucky carrier was used before for flashing “old modules”.
In the same time if we get an “old module” and “unlucky carrier” it could be flashed with success.
Question: what the flashing process could change at the carrier board?
I know there is some QSPI flashing stage, where is this QSPI chip located - on the module or on the carrier?
P.S. I still waiting parcel with a new Jetson to start experiments with devboard and UART logs, so don’t have additional information from this side.
