We have developed a custom carrier board that mostly follows the Jetson Orin Nano Developer Kit with a few exceptions. The custom carrier board uses a different USB hub chip (Microchip USB7206) from the dev kit (Realtek RTS5420). Are there any custom changes to firmware, device tree, etc. that are required in order to get a different USB hub to work properly with the Jetson Orin Nano?
Currently, the Jetson is working properly in every other aspect on our custom carrier board except it does not recognize/establish communications with the USB7206.
Just to clarify. You are using the USB7206C device?
Arrow uses the USB7206C on our JetCarrier96 reference design. I would be happy to send you the schematics if you want to compare designs. Just send me a PM.
One of the reasons we chose this device was that when we plugged the USB7206C Evaluation Board into a Jetson Developer Kit, it just worked. I can ask, but I do not recall any special device tree changes to make this work.
Thanks for the response. We are indeed using the USB7206C device. We also chose that part because it just worked. While our design is proprietary and I cannot share it without further approval from my supervisors, I will say that our design almost exactly follows the EVB-USB7206 design with the exception of the upstream port being connected to the Jetson Orin Nano rather than an external port.
No problem. Here is the JetCarrier96 page with the majority of the USB7206C circuit.
USB3_HUB_RESET_N and VBUS_DET are fed to a Microchip PolarFire FPGA off page, but are not connected to the FPGA because of no-pop series resistors on these signals. Which means we are not holding RESET_N low on power up other than the RC time on R129 and C88. This is slightly different than the RESET_N circuit on EVB-USB7206.
I2C0_SCL and I2C0_SDA are not connected to USB7206C through no-pop R137 and R139. In other words, we are not modifying the USB7206C configuration registers over the I2C bus from the Jetson module.
Thank you for the schematic. It provided some good insight for us to debug our own carrier board and get this Microchip USB7206C to work with our use case.
The solution ended up being some combination of three hardware modifications on our end, listed here:
The master and slave I2C pull-ups must not be present (I2C pins left floating), otherwise the hub will wait indefinitely for an I2C master to command the hub. The pull-ups were initially included on our first run of these boards, but removing them solved this issue and allowed the hub to initialize properly.
VBUS_DET must be pulled up to 3.3V for self-powered, permanently attached applications (as described by the datasheet). A voltage divider was copied from a previous example circuit that did not meet this requirement.
Power must be sequenced such that 1V1 turns on after 3V3. This interaction was missed when translating NVIDIA’s dev kit and combining it with the USB7206C. We now have 1V1’s enable line connected to 3V3’s PG line.
Thank you @bshay for providing insight into this integration. We are pleased to be able to move forward with this hardware selection.
