Do you have a J-Link compact and wonder why it only works with _some_ USB-C cables? I looked into why that is 🤬

https://alvarop.com/2025/09/j-link-compact-usb-c-issues/

@alvaro I'd guess the 2 x 10k vs 1 x 5k is a BoM optimisation? But yeah it's funny to see this in the wild on a board presumably designed after the first production rev of Pi 4
@wren6991 @alvaro yea smells like 2x10K parallel being on purpose to save the extra reel and they only ever intended to short the CC lines together.
Wild to still see this error being made 10y into USB-C adoption, really wonder where that comes from, there gotta be some wrong guidance around this somewhere.

@timonsku @alvaro Because an engineer sees this circuit in the spec and says "oh so I only need one of them". It's almost irresistible.

Also the same shortcut is correct in other areas, like in theory the sink detects orientation of CC1/CC2 to select the correct D-/D+ pair, but every USB 2.0 board I see just shorts the two pairs together. As far as I know this is valid.

@timonsku @alvaro The USB C spec should probably lead with "use exactly this circuit with no deviations if you just want 5V" because those are the people who will dedicate the least time to reading the spec. Committees are too excited about their favourite pet feature to think about how people use the docs they write.

That schematic does exist later on (pic), and I understand the point of view that this is a normative circuit and it's your fault if you implement anything different. On the other hand the way the shorted CC lines fail with an e-marked cable is only obvious with the benefit of hindsight, so I sympathise with people who make this mistake.

@wren6991 @timonsku @alvaro to be completely fair i imagine that by the time you finish reading the table of contents most will realize that the spec is not remotely helpful for that usecase

@leo @wren6991 @timonsku yeah, it’s very easy to make the assumption “oh, no cable has both CC lines, so this will always work!”

And in the past, most people would use the cheapest cables they could get away with. These days there’s a lot more eMarked cables.

I’m surprised that in all the testing it never came up, and if it did, that they just left it unfixed when the solution is so simple and inexpensive. Sure you have to spin the board, but cmon…

@leo @wren6991 @timonsku I don’t think “always just use the included cable and only that cable” is a good solution. If that was the case it should be built in.

I’m surprised they don’t have this documented on their website at the very least. There must be some amount of support calls this generates 🤷‍♂️

@wren6991 @alvaro I feel like the type of person too lazy to read a spec in detail (most people really) would just google how to implement USB-C and use the first vaguely reliable looking circuit.
You need to be a weird type of half assing person to want to not do the lazy google route, read the spec but then not fully read the spec to actually implement it correctly :D

@wren6991 @timonsku @alvaro [help me understand]
So the problem is that the CC is measured/forwarded to the sink chip after pulldown resistor and not before?(I don't get the 2x 10k, but I think it boom optimisation is ok, but it has been done wrong.)

I guess the CC shorting is problematic, especially for the ones that just think USB 2.0 and ignore CC/keep a false minimum. So likely devices that were developed for USB 2.0 micro.

And here I'm unsure, the reference has passive sink (apple).

@twosky2000 @timonsku @alvaro The problem is the short across the CC lines at the sink causes the source to see the sink-side 1k resistor on the opposite CC line on an e-marked cable
@twosky2000 @timonsku @alvaro You can't see the problem in this diagram because this type of cable works fine. You need to look at the e-marked cable diagram in Alvaro's blog post
@wren6991 @alvaro Not sure if D-/D+ orientation detection is even suggested, the standard calls for it to be shorted in normal circumstances. For the high speed pairs its mandatory to detect orientation
@timonsku @wren6991 @alvaro as far as I understand the standard, for usb 2.0 it is mandatory to short the d+, and d- pins together. I couldn’t find a way to make this conform to the usb c standard: https://hackaday.com/2021/03/22/cursed-usb-c-when-plug-orientation-matters/
Cursed USB-C: When Plug Orientation Matters

One of the selling points of the USB-C plug is that supposedly there is no way to incorrectly insert it. As [Pim de Groot] shows with a ‘Cursed USB-C 2.0 Device’, reality is a bit more …

Hackaday
@mifune @wren6991 @alvaro my theory is that they are separate pins because they are easiest/best to short on the PCB. You need the pads in the connector for rotational symmetry and having them be individual pads happens by default due to how the construction works. Shorting them in the connector is rather complex manufacturing wise/an additional step and you can't do it in the cable without extra cables or creating an excessive stub via the plug+connector

@wren6991 @timonsku @alvaro

like in theory the sink detects orientation of CC1/CC2 to select the correct D-/D+ pair, but every USB 2.0 board I see just shorts the two pairs togetherThat's incorrect, shorting is exactly to spec and there's supposed to be only a single D-/D+ pair on the cable, orientation detection is only for high speed signals.

@wren6991 @timonsku @alvaro Some citations from USB Type-C spec

Note how there's only one set of D-/D+ pairs on the plug, and how in the diagram D-/D+ just branch into both.
@timonsku @wren6991 @alvaro really shoddy BOM optimisation for a device that costs this much. there's a reason I have thus-far refused to give Segger a single penny.
@gsuberland @wren6991 @alvaro I wish the industry took more care into adopting cmsis-dap+pack. J-link still the least headache for many parts unfortunately. Maybe there needs to be an org vendors can throw money at to add support for their part like they do with Segger.
Quite a few shoddy half done cmsis packs/svd files out there
@timonsku @wren6991 @alvaro I've had remarkably good success with the knock-off J-Link debuggers, but I also haven't gone super deep with it. I guess they just yoink the real J-Link firmware onto it though, so that's probably why it works so well.
GitHub - Jana-Marie/JEGGER_s-link: https://twitter.com/_Jana_Marie/status/1245725762642206728

https://twitter.com/_Jana_Marie/status/1245725762642206728 - Jana-Marie/JEGGER_s-link

GitHub
@gsuberland @wren6991 @alvaro In recent releases they started to detect and reject them unfortunately

@timonsku I'd suggest the Glasgow Interface Explorer designed by @whitequark .

@gsuberland @wren6991 @alvaro