jetson tx2 usb otg cannot find any device on my customized carrier board

Dear Nvidia FAE
As the title we cannot find any usb device through our customized carrier board but when we remove the same tx2 module to Nvidia’s offical carrier board otg works well.
So it seems like the problem comes from our carrier board.
It’s really weird and I have a hard time ID this problem. Except signal USB0_ID_IO_CONN is there any other thing on Hardware might disable otg function?

Hi,
Is it usb0 and same usb_id connection on your carrier board with reference P2597?
How about your VBUS, is it also control by USB_VBUS_EN0?

yeah,it’s USB0 and the same USB_ID signal design(with ID signal connect to microUSB socket with a 0Ω res) from p2597_c02 and i had already have VBUS connect to DC5V directly.

Hi,
Jetson TX2 carrier board use USB_VBUS_EN0 control VBUS, can you try probe VBUS on Jetson TX2 carrier board when you install OTG device?
Software may turn on/off VBUS to init device, as many device have power-on-reset, VBUS always on is not a good case.

Today,I can’t help but remove the load switch IC the one we mount on our carrier board is TPS2051BDBV and find out when i insert a USB device the USB0_ID_IO_CONN signal turns low and USB_VBUS_EN0 remain low,normolly USB_VBUS_EN0 will turn high.
It feels the OTG function is not working at least it cannot detect an insert event

Is there any way we can e-mail our carrier board schematics to you and you do a quick review and offer us some suggestion?
Many thanks !

You can paste the schematic picture of necessary parts here for check.

We are currently having the same exact problem on a custom config#5 carrier board. Flashes work fine on reference board, but not on our carrier board. We discovered yesterday that if we flash the standard nVidia config#2 image (used in the reference board) to our pcb the flash process would complete. However with our custom config#5 image, we upload 3 blobs and the process fails right after the 3rd blob.

Our OTG circuit is nearly identical to the reference design, except we use 1/2 of a TPS2561QDRCRQ1 to implement our VBUS… it behaves like the APL3511 IC that nVidia uses on it’s reference design.

I’m looking into what we may be changing with regards to VBUS0 signal. It is strange that we can flash a config#2 reference design image to our carrier but not our own config#5 image.

Possible issues:

  1. I noticed in the PINMUX document that nVidia has setup the control signal USB0_EN_OC# (pin A17) setup as an “OUTPUT” of drive strength drive0. This is a surprise because the nVidia design guide clearly shows this pin to be an open-drain, or open-collector… with a module pull-up of about 100Kohms. Have we discovered an error in the PINMUX?

If USB_EN_OC# is setup as a driver (as opposed to open drain), then the OC# output of the current monitor IC can’t push down USB_EN_OC# as required when a connected host VBUS takes control of the OTG bus… I think.

  1. USB0_VBUS_DET in the PINMUX is an INPUT with “Int PU” set as an interrupt. Maybe we somehow are disabling USB0_VBUS_DET interrupts? How can I check to see that these interrupts are working?

TIA, -al

Are you using same enable signals and same sw with dev kit to control vbus load switch? If so, then no need to worry about the pin setting.

Did you follow the adaptation guide to do USB porting and flashing guide in L4T documentions?

If all above seems no problem, please attach your schematic here for check.

Experiencing the same Problem as whdstv. Why is there no further solution. How can it be a flashing problem when the same configuration works on the devkit? Does the devkit give any additional signal that is required to enable usb?
I posted my schematic, it not a beauty, but shouldn’t it work just like the devkit?

Hi msutter,

Sorry I never got back to posting our solution. Yes, OTG works now every time. Your case may be different. I’m not sure if it’s the same exact problem that whdstv was speaking of. Your schematic drawing looks good to me assuming you’ve connected it to the TX2’s OTG port, USB0…if this is the OTG port, your schematic net lines are labeled USB2… not USB0.

Background: In our design we have a pair of hubs connected to 1) the usb3.0 port (config 5) and 2) to one of the OTHER non-OTG USB2.0 ports. So on the TX2i, there are 3 USB 2.0 ports and one USB3.0 port (in config5). One of the USB2.0 ports from the TX2(i) is USB2.0 port 0, the OTG port, which we could not get working for force recovery; for our design this port is designed nearly identical to the TX2 reference design and there is no hub on our OTG port.

Problem: Anyway, we discovered that when we attempted to jump into ‘forceRecovery’ mode, or OTG mode, we locked up after a two or three bundles were sent to our device. We thought for a very long time that the issue was connected to VBUS control or VBUS itself, but the problem turned out to have NOTHING to do with the VBUS detect of the TX2i, and it also had nothing to do with the control of our 5V output circuit.

Solution: The problem was caused by our USB hub initialization activity. In a normal boot (not force recovery mode) at power-on reset, the USB3.0/USB2.0 hub reset lines are deasserted so the hubs can do initialization. We discovered that we needed to hold that hubs in reset whenever we needed to do a force-recovery. If we don’t hold the hubs in reset they become active and cause havoc willy-nilly as they try to initialize on their own; this messes up the force recovery and the TX2i becames confused in some fashion. Please note that these USB hubs are part of our design customization and the nVidia reference design does not have native USB hubs… so yes, at the system level, they constitute a difference between our design and the nVidia’s reference design. Although the USB OTG port design is (nearly) identical, in the context of the whole system, nVidia’s reference design does not have hubs to mess things up.

Fortunately: In our design, we have an external processor which is in charge of power-rail sequencing and also system monitoring once things get up and running. One of the other signals it has access to is ‘forceRecovery.’ I think we had to do a level translation on force recovery to our external processor. So we programmed the external processor to monitor the force recovery line, and when the force recovery line becomes asserted, the external processor asserts the reset lines for both of our on-board USB hubs (the 3.0 and the 2.0) keeping them quiet.

Hope this helps.

Summary: Force Recovery, OTG mode, doesn’t like USB activity on any of it’s other USB ports when it’s being asked to do a force recovery, and you may need to hold other USB hubs in reset… assuming you have them.

-al