I’ve been working on a custom board design centered on the Jetson Nano.
So far, most things have worked without issues or I have been able to track them down to some software error (usually dts or some device driver).
Unfortunatelly, I could not find whether I’m missing something with the USB2-2 port, mainly due to the lack of a schematic for the Jetson Nano SoM.
In the absence of such schematic, I am unable to confirm (or discard) if there exists a pin which could be turning off the signal in question.
In conclusion, I would like to confirm if the USB2-2 port should be expected to work out of the box or is expecting the assertion of some internal or external signal (maybe BT_M2_EN or BT_M2_WAKE_AP).
In order to get the best reply possible, I decided to add a little more info.
Our custom board has a USB2514 2.0 hub connected to USB2-1 which is working as expected.
It also has a USB5532B 3.0 hub connected to both USB2-2 and USB3-0 with only the 3.0 part of the hub working as expected.
I’ve already checked the documents available as well as the dts and pieces of the source code.
Since I could not find any issue, I started wondering if I missed something regarding the SoM.
I’m curious that you mention the vbus pin here since both hubs have their VBUS_DET pin wired to 3v3 and this pin should not be required.
If I’m mistaken on that regard, I’d like you to explain more about that.
Hi @DaneLLL ,
Since I’m still stuck on the same error, I decided to test the pins on USB2-2 in a more direct fashion.
In order to do that, I followed the steps on “Jetson Nano USB2.0 Tuning Guide” and used the “Test J” and “Test K” patterns.
The test patterns allowed me to see if the pins where toggling correctly and measure the voltage levels on them.
I’ve been able to confirm that the pins toggle as expected for both patterns. They also appear to be toggling when the xhci driver attempts to set the hub address.
What I found strange was the voltage level on D+ and D- pins, which was around 1V.
I tried this on 10 different boards, so I’m certain it’s not something specific to one of them.
I would like to confirm whether this is the expected behavior or not.
I also wanted to know if this value is set somewhere on Nvidia’s dts and where would that be.
The file you mention “hardware/nvidia/platform/t210b01/porg/kernel-dts/porg-platforms/tegra210b01-porg-fixed-p3448-0001-a01.dtsi” does not exist.
From what I have seen (and I’ve seen a lot of dts files on Jetpack 32.1, 32.3.1 and 32.4.2 sources) the files for all iterations of Jetson Nano Devkits have the form tegra210-p3448-0000-p3449-0000-xxx.dts or tegra210-p3448-0002-p3449-0000-xxx.dts so far. All those files include a gpio dts file, a pinmux dts file and tegra210-porg-p3448-common.dtsi.
One would assume that tegra210-porg-p3448-common.dtsi has the common parts for p3348 SoM. Further inspection shows it also includes some includes for p3349 devkits in the form of overlays (some of those get enabled based on the som model when they should be enabled based on the devit model).
In my custom board, the working hub has DP connected to pin 117 and DM pin connected directly to pin 115. This hub has the VBUS_DET pin connected to 3V3, leaving it enabled.
In a similar fashion, the broken hub has DP connected to pin 123 and DM pin connected directly to pin 121. This hub also has the VBUS_DET pin connected to 3V3, leaving it enabled.
To take things one step further, the team decided to completely remove the hub and plug pins 123 and 121 directly to a pendrive. The pendrive was also connected directly to the main (5V) power supply.
Under the previously mentioned conditions, the pendrive did not work at all.
We have already confirmed this unit to be working on port 0 with a similar configuration.
From this test it seems like the Jetson Nano Module does not detect changes on the data lines at all.
Since my current line of thought seems to be taking me nowhere, I’ll try a different approach.
So far, every step involving the pull-ups and pull-downs for usb port 2-2 seem to be working (at least when the system boots).
I have checked with an oscilloscope what seems to be the device connection, detection and enumeration exchange.
First, I would like to confirm whether this hypothesis is true.
I think the “new full-speed USB device number %d using tegra-xusb” should do fine.
However, I would still like to know if there are any additional checks I can perform from the software side.
Second, assuming my previous hypothesis is correct, I would like to know how to confirm with 100% certainty that the Nano is properly configuring and enabling the HS Driver and Receiver.
In order to do that, I would appreciate if you could list all the steps you consider necessary, whether it be reading logs, checking /proc or /sys, reading system memory with devmem or anything else.
Hi @WayneWWW, @DaneLLL,
Thanks for your patience so far.
I finally found the error and it was indeed a software error.
Or maybe, it would be more accurate to say it was a firmware error.
For some reason, the file tegra210b01_xusb_firmware got renamed to tegra21x_xusb_firmware and then it was placed in a folder where it would overwrite the real tegra21x_xusb_firmware every single time.
Since it seems like tegra210b01 shares many similarities with the soc on the nano, most usb ports worked fine, with the exception of usb2-2.
In the future, in addition to suggesting it might be a dts error, you can also direct people to check if they got the firmware files from whatever place you consider to be most reliable.
Hi @WayneWWW, @DaneLLL,
Maybe I didn’t express myself as clearly as I thought. The firmware on Nvidia’s side is fine.
Since I use a custom build based on buildroot, I had the wrong file at the right place (the xusb firmware file for tegra210b01 was replacing the firmware file for the Nano).
What I tried suggesting was that, should someone else run into a similar issue, they could be using an incorrect firmware file like I did.