Combined host and recovery USB port for Jetson Orin Nano

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi all,

I’m designing a custom Jetson Orin Nano carrier board, which should also provide a single USB 3.0 host port to the outside. There will be only a single USB port available for the device due to space and cabling constraints. In order to have the recovery functionality available, I’d like to use one port for both features:

  • USB 3.0 host mode (e.g. for a WIFI/WWAN stick or external storage) when booted normally
  • USB 2.0/3.0 device mode when booted with the FORCE_RECOVERY pin strapped

Also due to cabling constraints, there will be a USB A connector on the board, not a USB C connector as present on the devkit. There is no need for USB OTG; when the board is booted normally, the port will always be used as host and never as device, only in the recovery case it is the other way round.

When I check the design guide, I find these two connection examples:

image
image914×778 99.9 KB

What I don’t really understand is why for figure 7-2, it says “Recovery mode is not supported”. Is this only due to the wiring of the VBUS pin, which is not connected as “VBUS detect”? If so, is there anything wrong with adding this MOSFET and connecting it to the GPIO to get both functions at once? Or is it only because a USB A connector is not designed to be used for a device port?

My other question is about the assignment of the individual USB ports of the Jetson. In figure 7-1, the USB 2.0 data lines are connected to “USB0_D_P/N”, which apparently connect to “HS_USB0_P0_P/N” of the SoC. In figure 7-2, the same lines are connected to “USB1_D_P/N”, which are also named “HS_USB0_P0_P/N” for the SoC. At the same time, the USB 3.0 data pairs are named “USBSS_T/RX_P/N” and “UPHY_T/RX1_P/N”. In the devkit schematics, the recovery port’s USB 2.0 pair connects to “USB0_AP_P/N” and the USB 3.0 data pairs (USB-C) after the pin multiplexer go to “USBSS1_T/RX_P/N”. The hub for the USB 3.0 host ports connects to “USB1_AP_P/N” (DP/DN) and “USBSS0_T/RX_P/N”. So it looks like the interface blocks 0 and 1 are exchanged between the USB 2.0 and USB 3.0 data lines, but why? Is this just a naming caveat?

It would be great if somebody could shed some light on this. Due to space and cost constraints, the design should be as simple as possible, with focus on using the USB port in host mode. Device mode in recovery will only be used in rare cases for servicing, so if it works but doesn’t perform exactly according to USB-IF specs, this is acceptable.

Thanks!

3

*** Please note that this reply is generated by LLM automatically ***

The question involves designing a custom Jetson Orin Nano carrier board with a single USB 3.0 host port that can also be used for recovery functionality. The goal is to use one port for both features: USB 3.0 host mode for normal operation and USB 2.0/3.0 device mode when booted with the FORCE_RECOVERY pin strapped.

USB OTG and Recovery Mode

The design guide mentions that the USB OTG port can switch between host and device modes. However, in this case, the port will only be used as a host in normal operation and as a device in recovery mode. This is acceptable, as the USB OTG specification allows for this type of operation.

VBUS Pin and MOSFET

The design guide states that recovery mode is not supported in Figure 72, which is likely due to the wiring of the VBUS pin. The VBUS pin is not connected as VBUS detect, which is required for recovery mode. Adding a MOSFET and connecting it to a GPIO pin can enable both host and device modes. However, this may require additional circuitry and software configuration.

USB Port Assignment

The design guide shows different USB port assignments in Figures 71 and 72. In Figure 71, the USB 2.0 data lines are connected to USB_D_P/N, which corresponds to HSUSB0_P0_P/N of the SoC. In Figure 72, the same lines are connected to USB_D_P/N, but with different names (HSUSB0_P0_P/N for the SoC). The USB 3.0 data pairs are named USBSSTRX_P/N and UPHYTRX1_P/N.

Comparing the devkit schematics, the recovery ports’ USB 2.0 pair connects to USB_APP_P/N, and the USB 3.0 data pairs connect to USBSS_TRX_P/N after the pin multiplexer. The hub for the USB 3.0 host ports connects to USB_APP_P/N, DPDN, and USBSS_TRX_P/N.

It appears that the interface blocks 0 and 1 are exchanged between the USB 2.0 and USB 3.0 data lines. This is likely a naming convention and not a functional difference.

Design Considerations

To achieve the desired functionality, the design should include:

  1. A USB A connector on the board, as a USB C connector is not feasible due to cabling constraints.
  2. A MOSFET and GPIO pin to enable both host and device modes.
  3. Proper wiring of the VBUS pin to support VBUS detect for recovery mode.
  4. Software configuration to control the MOSFET and switch between host and device modes.

Simplification and Cost Constraints

Given the space and cost constraints, the design should focus on simplicity while ensuring the USB port works in host mode. Device mode in recovery will only be used in rare cases, so minor deviations from USBIF specs may be acceptable.

In summary, the design can be simplified by using a single USB port for both host and device modes, with a MOSFET and GPIO pin to control the mode switching. Proper wiring and software configuration are essential to ensure the desired functionality.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

That’s not really an answer but mostly a rewording of my initial posting, so of very little help.

6

This is a typo in the Design Guide. In Figure 7-2, the “USB1” signals on pins 115 and 117 of the SO-DIMM connector should route to the SoC’s HS_USB0_P1 pins. I’ve marked this as an error to fix in the next release.

This is because the only supported interface for recovery mode is USB0/HS_USB0_P0. The USB2 port in the figure cannot be used for recovery.

Technically the USB A female connector works for device mode for recovery but is generally not recommended in terms of USB compliance (the VBUS issue you alluded to) and possibly negative user experience (needing the less common USB A-A cable). From both hardware and software points of view it is not recommended.

There is no hard requirement for mapping the USB 2.0 and USB 3.0 ports 1:1. To simplify, you could follow the same port mapping as the USB-C example on the carrier reference design with USB0 (USB 2.0) and USBSS1 (“USB 3.2 (P1)” in the Orin NX/Nano Design Guide’s Table 7-3).

The USBSS1/USB 3.2 P1 port would be needed for high speed support in recovery mode but needs additional steps as per Flashing Support — NVIDIA Jetson Linux Developer Guide .

7

Hi Chris,

thanks for the quick response and the clarifications.

Technically the USB A female connector works for device mode for recovery but is generally not recommended in terms of USB compliance (the VBUS issue you alluded to) and possibly negative user experience (needing the less common USB A-A cable). From both hardware and software points of view it is not recommended.

As I noted, it is perfectly fine if the user experience is a bit “impaired” for the USB recovery mode, including the need for a somewhat nonstandard cable and only USB 2.0 support. Chances are that apart from some low-level development/debugging work and maybe initial flashing, it will not be used at all. But it’s still good to have it available, in case something breaks after deployment and must be fixed without physically opening the device to remove the Jetson SOM.

There is no hard requirement for mapping the USB 2.0 and USB 3.0 ports 1:1. To simplify, you could follow the same port mapping as the USB-C example on the carrier reference design with USB0 (USB 2.0) and USBSS1 (“USB 3.2 (P1)” in the Orin NX/Nano Design Guide’s Table 7-3).

I’ll definitely try to match the assignments of the devkit, to avoid any pitfalls in this regard.

So, my plan is as follows:

  • USB 3.0 A female connector, to support direct plugging of USB devices like WIFI/WWAN sticks, USB HDDs, etc.
  • VBUS supplied via load switch controlled by GPIO or recovery strap (OFF in recovery mode)
  • VBUS detection using MOSFET and routed to GPIO00 (87)
  • DP/DN connected to USB0_AP_P/N (111/109)
  • SSTX (9/8) connected to USBSS1_TX_P/N (47/45) → not used in recovery mode, only USB 2.0
  • SSRX (6/5) connected to USBSS1_RX_P/N (41/39) → not used in recovery mode, only USB 2.0
  • And of course all the proper ESD protection, AC coupling on TX, etc.

Does that seem reasonable, or will anything of it get us into trouble, especially when trying to use the USB port in normal (host) mode?

Thanks!

8

Fair enough - just wanted to make sure you’re aware of the USB compliance aspect as well.

You can follow the Figure 7-2 example with the GPIO00/USB_VBUS_EN0 (pin 87) controlling the VBUS load switch. That pin drives 0 at power on reset (POR) to keep the VBUS off. When your software boots it can set the pin high to enable VBUS.

GPIO00/USB_VBUS_EN0 (pin 87) would not be available if you follow the example in the DG as above. But if you choose not to follow that, GPIO00 would not be recommended for a VBUS detection input since it drives 0 at POR. You can use an available GPIO that is z or pu/pd at POR for input.

9

GPIO00/USB_VBUS_EN0 (pin 87) would not be available if you follow the example in the DG as above. But if you choose not to follow that, GPIO00 would not be recommended for a VBUS detection input since it drives 0 at POR. You can use an available GPIO that is z or pu/pd at POR for input.

Ok, good to know. That proposal (GPIO00 as USB0_VBUS_DET#) was because it’s the wiring of the devkit, so I assumed it’s kind of the default function of this GPIO:

image
image1327×136 8.6 KB

But using it as an enable (output) certainly makes more sense given the name of the pin on the SOM. The design guide page 8/9 says

No other signals are required or supported for entering Force Recovery mode. Neither VBus or USB ID detection is needed. If the force recovery strap is held low coming out of reset, Jetson Orin module will configure USB0 as a device and enter recovery mode.
See the USB section (Section 7.1) for an example figure that shows USB0 connected to a USB Micro B connector.

I find that a bit contradicting, given that it says “Neither VBus or USB ID detection is needed”, but the example schematic includes a “VBUS detect”, without giving an indication of which GPIO to use for it.

Is there a list somewhere of the functions assigned to each GPIO with the default devkit installation? I mean not the pins brought out to e.g. the expansion header, but all the ones used on the devkit itself.

10

You could use GPIO00 the same way also but make sure that your detection circuit’s signal that drives it is open drain, since the SoC will drive 0 on it at POR. The pinmux spreadsheet changes GPIO00 to GPIO mode, input direction, and Internal PU enabled (Req. Initial State column) to work as an open drain input.

The configuration set in the Jetson Orin NX Series and Jetson Orin Nano Series Pinmux from the Download Center matches the Dev Kit, so you can see how the GPIOs (and all other available pins) are configured and match them up with the schematics.

11

Perfect, thank you very much for your support!