Custom carrier board not entering into force recovery mode

We have designed a custom carrier board for Jetson AGX Orin module. In the custom carrier board we have used type-A connector(as shown below) instead of USB Type-C port(Part 10 as per development kit layout) which is available in the Jetson AGX Orin development kit.

We have placed a recovery 2-pin jumper on the custom carrier board. We have followed below steps to place the custom carrier board in force recovery mode.

  • Connected jumper(shorting to ground).
  • Turn on power supply to the custom carrier board.
  • Remove the jumper after 10secs of power supply on.

But we are not seeing any messages in dmesg output on Ubuntu host PC. In case of Jetson AGX Orin development kit we could see the following messages in dmesg on Ubuntu host PC, when the development kit placed in force recovery mode.

Do we need to perform any changes as we are using USB type-A in our custom carrier board instead of USB type-C?

Note: We don’t have any EEPROM in our custom carrier board, so we made the cvb_eeprom_read_size as 0x0 in tegra234-mb2-bct-common.dtsi.

You design looks ok for USB0 recovery. Is it possible to try USB0 only without other signals?

You are suggesting to use only USB2.0(i.e USB0_P and USB0_N signals)? The lines are inside PCB, so it will be difficult to disconnect USB3.2(UPHY) lines on the board. We are connecting the custom carrier board to Ubuntu PC USB2.0 port, so I think only USB0 will be used.

Is there any possibility to enable debug from software side for getting logs on UART3_debug when the SOM module entering to recovery mode.

No, recovery mode is not controlled by sw. No idea about this, maybe you need to check all of your other designs based on the reference and checklist in DG.

There was an issue at the hardware USB side, now it is working fine. Thanks.

Could you share what the issue is? Is it related to your schematic design?

It is not schematic design issue, one of the component was not placed properly during assembly, due to this USB2.0 data lines were shorted.

Got it. Thanks.