Signals that affect recovery mode?

I am trying to get into force recovery mode. I am using an FPGA to control signals coming from and going to TX2. I connect the micro B plug and follow the steps of holding recovery button, then pressing reset and releasing reset, wait at least 2 seconds then let go of recovery.

I have probed these signals on the oscilloscope and see that they follow the proper power sequence. I see that the TX2 goes into low current mode but I do not see Nvidia when I type in lsusb.

Are there any other signals that needs to be pulled up/down that could be affecting force recovery mode from showing up? This is our custom carrier board, do we need to make modifications in the powertree dt to be able to put the board into force recovery mode?

Is the port operating in USB2 mode? I don’t believe there is any fallback mode to slower modes for this port, and there definitely is not USB3 support during flash.

Yes we are using USB 2.0 when we use the microB plug to the PC. We don’t see the mode but we see current dropping when we perform force recovery mode. Do you have any idea why we don’t see the Nvidia showing up on the terminal?

Is your USB2 port implementation fully OTG compliant?
Specifically, does it sense the cable type and configure the mode correctly?

Hi snarky,

Thank you for the reply. How do we know if USB 2 port is fully OTG compliant? When it goes into recovery mode does the VBUS of the USB 2.0 have to turn off?

We also have the actual TX2 carrier board. How do you check to see if it senses the cable type? I can compare what we have with theirs. Really appreciate the help.

The socket of the micro USB port on the Jetson is “On The Go”. The plug which inserts into the socket must be type-A or type-B. OTG means the socket can accept either.

In a typical smart phone or tablet the pins used when plugging in a type-A or type-B will tell the phone whether the phone should act as a device (a case of type-B being inserted, e.g., phone acts like a hard drive) or if the phone should act as a host (a case of a type-A being inserted, e.g., a keyboard or headphones were inserted).

On the dev board the pin does not change mode…you can set this up in software after Linux boots. When a Jetson is booted in recovery mode this OTG port works only with cables of type-B…the Jetson becomes a device.

If your cable is type-A, then the recovery mode Jetson won’t be seen because the wiring requires type-B. If you use the provided cable this is type-B. If you use a third party cable, then you may have the wrong cable type for your host to see the Jetson. Are you using the provided cable?

A typical third party cable often has an “A” or “B” character on the micro port (this isn’t always the case…sometimes it is instead a logo). If you are not using the provided micro-B cable, does your cable show an “A” or “B”? If it shows “A”, then this would explain everything…a type-A cannot work for flash.

I found a good picture of the different types:

Notice that a micro-B has beveled edges, and a micro-A has square edges.

Hi linuxdev,

I am using the provided Nvidia cable, it has a micro B connector. With the micro B cable plugged into the PC, TX2 knows to go into device mode when we put it into force recovery mode. Is there anyway we can check this aside from checking to see if we are in force recovery mode?

I turned off USB0_EN_OC# from the TX2 to ensure there is no conflict with VBUS. The VBUS is coming from the PC only. I am wondering if there is anything else that needs to be shut off to not interfere with force recovery mode. I am using a custom carrier board everything seems to be working except force recovery. The type B cable is from Nvidia, I used it on TX2 carrier board to test force recovery mode. Thanks for your help.

Having USB respond with a device under lsusb is the only way to know the driver package will see the Jetson.

I do not think there is any direct indicator, e.g., no LED. If you have a serial console this can show a lot regardless of whether recovery mode starts then fails, or if it works, or if anything else is run by the system.

Is the FPGA controlling through a dev board? Or is the carrier for the TX2 some other board? There is a 2-pin header on the dev board which is the same as force recovery button, power button, and reset buttons. If you use those, and recovery does not work, perhaps the voltage drop across the pins (it shorts a positive voltage to ground) is too much (meaning the switch might have internal resistance, e.g., junction voltage on an active switch isn’t really completely grounded).

I figured out why it was not working. The recovery signal needs to be initialized from the beginning since it was controlled by FPGA it was just floating until it was needed for recovery mode.