Segger’s Awkward USB-C Issue With The J-Link Compact Debugger

Theoretically USB-C is a pretty nifty connector, but the reality is that it mostly provides many exciting new ways to make your device not work as expected. With the gory details covered by [Alvaro], the latest to join the party is Segger, with its J-Link BASE Compact MCU debugger displaying the same behavior which we saw back when the Raspberry Pi 4 was released in 2019. Back then so-called e-marked USB-C cables failed to power the SBC, much like how this particular J-Link unit refuses to power up when connected using one of those special USB-C cables.

We covered the issue in great detail back then, discussing how the CC1 and CC1 connections need to be wired up correctly with appropriate resistors in order for the USB-C supply – like a host PC – to provide power to the device. As [Alvaro] discovered through some investigation, this unit made basically the same mistake as the RPi 4B SBC before the corrected design. This involves wiring CC1 and CC2 together and as a result seeing the same <1 kOhm resistance on the active CC line, meaning that to the host device you just hooked up a USB-C audio dongle, which obviously shouldn’t be supplied with power.

Although it’s not easy to tell when this particular J-Link device was produced, the PCB notes its revision as v12.1, so presumably it’s not the first rodeo for this general design, and the product page already shows a different label than for the device that [Alvaro] has. It’s possible that it originally was sloppily converted from a previous micro-USB-powered design where CC lines do not exist and things Just Work™, but it’s still a pretty major oversight from what should be a reputable brand selling a device that costs €400 + VAT, rather than a reputable brand selling a <$100 SBC.

For any in the audience who have one of these USB-C-powered debuggers, does yours work with e-marked cables, and what is the revision and/or purchase date?

2 thoughts on “Segger’s Awkward USB-C Issue With The J-Link Compact Debugger

    1. Type C fits in well with smartphones: jack of all trades, master of none.

      In that scenario it makes sense to have a miniature “do everything” connector, but on a laptop or especially a desktop host I’d rather have specific connectors for different interfaces, that are less of a compromise for a given task and a whole lot simpler to implement. Less stuff for manufacturers and hobbyists alike to screw up.

      Shouldn’t the focus of your project be about getting the widget itself doing its thing instead of debugging Type C handshake and ID problems?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.