Environment: Jetson AGX Thor Developer Kit (P4071), L4T R39.2.0, kernel `6.8.12-1021-tegra`, stock image.
Symptom: On a stock, unmodified image, plugging any device into the left USB-C port (J82) produces nothing, no enumeration and no `dmesg` activity whatsoever. Same devices/cables work fine elsewhere.
I am wondering whether or not I should submit an RMA for my device. After looking through forum posts it seems like a dysfunctional J82 USB C on Jetson Thor is quite common.
The original solution seemed to be to apply the following patch: e2611e3.diff
However, the recommendation began to change to RMA after notes of instability:
So we read these threads on enabling the on-board Cypress CCG8 (CYPD4226) Type-C controller (the reference patch `e2611e3`) but as I mentioned it was walked back, and staff have described the devkit’s CCG as not fully enabled due to known bugs. Because this is a unit we rely on, we’re reluctant to apply a patch with known stability issues.
Instead, we did a separate investigation to understand the failure (full logs available on request):
- The CCG8 is present and ACKs on I²C (`i2cdetect` at 0x08 on i2c-2).
- It reports UCSI 2.0, which kernel 6.8’s UCSI stack predates.
- Once the stack can talk to it, the controller intermittently reports a connection (CONNECTED/SOURCE) but never actually brings the port up. The xHCI host controller never registers a device (`PORTSC` stays at `RxDetect`). Then the controller drops the connection within ~1 second. In our testing this is independent of the host driver.
Our questions:
- Is there a supported path to a working USB-C host port on J82, whether that’s a newer JetPack, an official DT patch, or a CCG8 firmware update for P4071 devkits?
- Is the walked-back CCG enablement safe to use host-only, or is the underlying CCG firmware known-broken such that it won’t help?
- Is this a per-unit hardware fault (i.e., would an RMA resolve it), or a known limitation common to P4071 devkits? We’d rather not RMA into an identical result.
We can revert to a fully stock image and post a clean baseline `dmesg` on request.
Hi,
I don’t think this situation needs to do the RMA.
How do you provide the power supply to your Thor devkit if using J82 to test the USB?
Hello Wayne,
I’m glad to hear that.
So far I have only used J81 for supplying power using the AC adapter provided in box with the developer kit.
I am trying to use J82 to connect an Arducam camera.
So to answer your question directly, I do not use J81 to test the USB I use J82 to test the USB. Do you recommend I try swapping? If I remember correctly, I tried this once, briefly. I powered down the device and connected the power supply to J82 via USB C and it powers on just fine. Then I plugged in a USB C device into J81 and also saw nothing appear in dmesg. I can always try again or provide other logs if you’d like.
Sorry. Just a typo. I was trying to ask the power to J81 and USB on J82.
Have you tried other kind of device than Arducam cam on J82 before?
No worries! Yeah so we power it via J81, usb on J82.
I have tried many devices. I tried a small Belkin USB C to Ethernet adapter, which enumerates on my regular PC but will not enumerate on the Jetson.
Same goes for another device, a MSL Force USB C hub. It contains a PD, USB2.0, USB3.0, HDMI and Ethernet port. All enumerate fine on regular PC, but silent on Jetson.
When you connect a adapter + usb mouse, will you see the mouse has given power? Just test this simple case only.
Hello Wayne,
Sorry for the delay. If I do the hub plus usb mouse nothing appears in dmesg when plugging in.
However, if I power the hub with external power then a connection can be formed and the mouse connection also works. Is is not possible for J82 to work as a source for the power role? That is desirable for many reasons, but perhaps this is some design choice?
Let me check internally if we could release PD fw out that might fix this issue.
Great thanks! I appreciate that. I also wanted to add a couple more details that might be helpful to the engineers:
In one line: Power role sink works but source doesn’t. Anything self-powered gives me 0x402b (PD contract, board sinks) and enumerates reliably. Anything bus-powered gives 0x403d (board as source, Type-C 3.0A) which collapses to all-zeros in ~300ms. Forcing it with SET_PDR is rejected with UCSI_ERROR_CC_COMMUNICATION_ERR.
I would think this is maybe because it was a design choice to make this port only work with external power. But the weird thing is, after trying to debug this for days I actually had a couple of lucky breaks with just a regular plug-in:
So it’s not dead, it’s just about 3% intermittent. Maybe 5 successes out of ~150 insertions or so over several days. Maybe I should’ve led with this information, but it was just so shocking that it didn’t work out of the box when a functional USB is usually an expected feature. So I thought I would keep my question focused on the fact it wasn’t working when we first got it.
Of my successes, I caught one: bus-powered Arducam at 400mA, SuperSpeed, streamed 33 minutes straight. So the silicon can source power, but it just almost never does. In that same capture GET_CABLE_PROPERTY succeeded, and it fails with UCSI_ERROR_UNDEFINED on every failing attach.
Is there a CCG8 firmware image for P4071 that enables the source path? And is this correlated with carrier revision? Mine is G.1.
Do you have rel-39.2 (jp7.2) BSP on your host? There is USB PD FW flash tool that could help to readout the firmware version on your board.
I don’t have that yet. I will go ahead and download it. In the meantime I read what I think is firmware version of the relevant parts. I used I²C, READ_ALL_VER (0x0010), 24 bytes raw:
09 00 00 36 62 6e 01 00 BOOT
55 01 00 37 62 6e b0 16 FW1
55 01 00 37 62 6e b0 16 FW2
Decoding that as {build, patch, ver}:
The bootloader is 3.6.0.9
Both FW1 and FW2 are build 3.7.0.341, patch 176, v1.6
DEVICE_MODE = 0x96, so it’s running FW2, but from here they seem byte identical.
UCSI version register reads 0x0200 (UCSI 2.0).
Anyway, I’m setting up rel-39.2 BSP on my host now. I’ll let you know when I get it working.
The path of corresponding USB FW tool:
Linux_for_Tegra/tools/nv_ccg_fw_update
So I downloaded the BSP, and I have access to the path of the FW tool. How do you recommend I set up the device for the check?
I am thinking I connect host to Jetson Thor through the debug port and then just run
sudo Linux_for_Tegra/tools/nv_ccg_fw_update -i I2C2 -v
Before I do this I have some questions:
- Does the Thor need to be in recovery mode for this, or normally booted?
- The README’s known-issues section says reset detection fails on USB-C power. I’m currently powering the board from J81 USB-C PD (28V EPR supply). Is -v safe like that, or should I move to the Micro-Fit DC input first?
Hello Wayne, I was able to supply power via microfit port and run the tool. Do you have any recommendations at this time?
i2c = I2C2
fw1_path = (null)
fw2_path = (null)
version_check_flag = 1
Initializing firmware updater…
Serial: TOPOA735A12B
BL_Version = 9000036626e0100
FW1_Version = 55010037626eb016
FW2_Version = 55010037626eb016
FW1 Version Tag: b0.16
FW2 Version Tag: b0.16
Any update? I’ve been able to work around this by powering via J82 and just using J81 and forcing it to host mode with echo host | sudo tee /sys/class/usb_role/usb2-0-role-switch/role after boot. But I feel like the J82 should be more useful than just used for power supply.
For example, we have a microfit cable that we can supply proper voltage on. This frees up both USB C for use. Or it would, it J82 worked. But it doesn’t.
We notice some known issue and still under check how to provide out the fix properly.
Hi @kenny_haak,
If this issue is a blocker to your project, please contact your local distributor for this issue first.
Hello @WayneWWW ,
Thank you for your update. I think I will be able to proceed with my project in this state, so maybe we can close this thread for now.
However, it may become highly necessary to have this fixed in the future. Therefore, is there any resource where “known issues” for Jetson devices are listed? Specifically, a list I can follow and see updates to know when the fix has completed?
I would like to be able to track the progress of this fix and apply the new firmware patch to my USB C controller when the solution is created.
Thank you,
Kenny
You may still contact the distributor for a new firmware. It is unlikely the firmware would be released to forum directly.