We have encountered an issue during firmware flashing through USB recovery mode on our custom carrier board. In our design, the USB 3.2 ports are routed to Type-C connectors for connecting peripheral devices. When flashing a new image via the Micro-B connector in recovery mode, the process fails if a device is connected to the USBSS ports — particularly when a USB 3.0 storage device (such as a pendrive) is connected to the USBSS1 port.
This failure is consistently observed under these conditions.
Could you please advise:
Is there any known dependency or limitation that could cause flashing to fail when a device is connected to the USBSS ports during recovery mode?
Are there any official recommendations to avoid using USBSS ports during USB recovery mode operations?
Your feedback will help us better define the flashing procedure and avoid such failures.
Your UART log file will help clarify the situation.
So if possible, please dump the uart log during flash failure.
Orin NX/Nano flash mechanism is different from Orin AGX. So changing usb port design might affect the flash result. The log will help clarifh whether you hit that case or not.
FLASH_FAIL.zip (10.0 KB)
As requested, please find the attached file. This attachment includes both successful and failed flashing logs for your reference.
Kindly review and let us know your observations or if any additional information is needed.
Thank you for the input—your suggestion is very helpful, especially since I come from a hardware background and it’s a bit challenging to understand the software-level differences.
Attached are both the successful and failed flashing logs for your reference.
Kindly review them and share your observations. Please let us know if any additional information is required.
Additionally, we would like to highlight that no failures have been observed when USB 2.0 storage devices are connected to the Type-C ports. The issue also does not occur when connecting peripherals such as a mouse or keyboard.
Please let us know if this helps narrow down the cause?
We would also like to confirm our understanding based on the logs:
In the successful log, the boot_device is shown as RCM, whereas in the failure log it shows boot_device: QSPI_FLASH instance: 0. Based on this, are we suspect that the USB configuration may not be correctly recognized in the failing scenario. Could you please confirm if this interpretation is correct?
Additionally, we would like to know if there are any hardware-level dependencies that could cause such behavior.
Specifically, we are using a tactile switch to force the carrier board into USB recovery mode—could this approach have any impact on the reliability or timing of entering recovery mode?
Additionally, we would like to highlight that no failures have been observed when USB 2.0 storage devices are connected to the Type-C ports. The issue also does not occur when connecting peripherals such as a mouse or keyboard.
Sorry to say that but none of what you are talking about matters here. That is just a success from luck.
You are basically using some software that does not suit for your carrier board…
If you didn’t modify the device tree before, then that thing is originally only for NV devkit.
You are talking about running something for NV devkit directly on your carrier board. And of course that would lead to error behavior.
NV devkit is using type C controller Fusb301 on that usb2-0 port and also combined with another USBSS lane along with it. It is not a micro usb port design as your case. You took that USBSS lane routed to another port as well.
So there is no need to discuss about why sometimes it can work. You don’t need to spend time doing that. The software just does not match to your hardware. Even after you use such method to flash up the board, your usb port might still not work fine in this situation.
If your work is for Orin AGX today and using flash.sh to flash, then this problem won’t happen. But your usb port would still be dead after boot up.
But for Orin NX and Nano which uses initrd flash to flash, then you have to configure device tree to meet your board since the beginning.
This is related to the flash mechanism which may not be related to the solution of this issue itself.
If your problem always only happened with host PC giving you “Waiting for target to boot-up…”, then it has nothing to do with recovery mode. It is pure kernel device tree configuration problem as I told here.
We have tested this scenario on the EVK but did not observe the issue. We will review the suggestions related to the device tree and get back to you shortly.
In the meantime, we are attaching our USB architecture for your reference. However, we are unsure if this design could be contributing to the issue. Could you please review it and advise which architectural elements change might be causing the problem?
Sorry to say that, but I really feel you don’t understand how software runs here.
Device tree running on the board won’t be magically changed just because you changed the hardware there.
We have tested this scenario on the EVK but did not observe the issue.
Yes, of course you won’t see this issue on EVK. The device tree in our Jetpack is for our NVIDIA developer kit (EVK) to use. We wrote the device tree to match our EVK. It won’t work directly just because you pick it up and run on your board. You have to modify it to match your board just as my documentation mentioned.
This is not only for USB but also other interfaces as well. It is just more or less.
In the meantime, we are attaching our USB architecture for your reference. However, we are unsure if this design could be contributing to the issue. Could you please review it and advise which architectural elements change might be causing the problem?
For this issue, it is just simple case as I mentioned. The device tree is not compatible with your device. Your flash port is a micro usb here and our Devkit (EVK) is a type C port that can even support usb3.2. These two things are totally different.
However, for the rest USB design here, I saw some problems that our software would not really support it…
You cannot use a usb2 signal from the downstream of the hub to combine them as multiple type C ports… it won’t work. The function would have problem.
And just to clarify this again. What I just told about your hardware issue does not matter to your flash problem.
If you modify only that usb2-0 port things to micro usb port configuration, then your flash problem would be resolved. But that didn’t change the fact that your type C port 1/2 design have problems.
Your feedback has been very helpful. We are planning to make some changes to our current architecture, and would appreciate your support in gaining a deeper understanding of the USB interface implementation.
As mentioned earlier, our existing custom architecture has been functioning as expected, except for the flashing failures observed when a storage device is connected to the USBSS1 port—which is also used for flashing in the EVK.
Based on our current setup, we have the following questions:
Is there any specific relationship between USB 2.0 and USB SuperSpeed (SS) port numbers? In other words, is it necessary to route matching port numbers together into a single connector?
Is it acceptable to mix and match different USB 2.0 and SS ports for separate purposes?
For flashing purposes, is it mandatory to pair USB0 and USBSS0 into a single connector?
Can USB1 and USBSS2 be combined in a Type-C connector? If so, what specific device tree changes would be required?
Given that in EVK design, USB2 is routed to the M.2 connector and USBSS2 is left unused, is pairing ports strictly necessary, or are there any design constraints we should be aware of?
We look forward to your guidance to help us align the architecture more effectively.
Attaching the architecture diagrams of our custom carrier board along with the reference EVK design for better clarity and comparison.
USB3.0(SS) port must have another USB2.0 port directly from Jetson. And it is one to one mapping.
You cannot take one USB2.0 port for lots of USBSS ports.
You cannot use usb hub to expand one USB2.0 and then for lots of USBSS port
So your board design is wrong.
So for your questions
Is there any specific relationship between USB 2.0 and USB SuperSpeed (SS) port numbers? In other words, is it necessary to route matching port numbers together into a single connector?
Yes, one to one mapping
Is it acceptable to mix and match different USB 2.0 and SS ports for separate purposes?
I don’t know what kind of mix you want here. But it has to be 1:1 mapping.
For flashing purposes, is it mandatory to pair USB0 and USBSS0 into a single connector?
Actually you only need USB0. Not really need to have SS function. Also, it could be any other USBSS port. No need to be USBSS0. NV devkit is not using USBSS0 either.
Can USB1 and USBSS2 be combined in a Type-C connector? If so, what specific device tree changes would be required?
Yes, it can, because it is a 1:1 mapping. Please read the document that I already posted in previous comment.
Given that in EVK design, USB2 is routed to the M.2 connector and USBSS2 is left unused, is pairing ports strictly necessary, or are there any design constraints we should be aware of?
I don’t know why are you mentioning this EVK M.2 design. Yes, USBSS2 left there. So what is the problem then?
