SWD over USB-C - Page 1
Forum section: electronics / projects

author: openyk
author_rank: Contributor
timestamp: February 04, 2025, 10:47:08 pm
content: For PCBs without extreme space constraints, the ability to SWD by plugging in a USB-C cable from debugger to device is the most convenient possible, especially when juggling numerous firmware revisions across several boards.Comparatively, mass production uses pogo pins to touch an array of pads on the device. With standardized dimensions for the pad array, a common pogo jig can be convenient, with the caveat that you still have to re-align the jig (XY indexing) every time you switch boards (or free-air align every connect/disconnect). With varying pad arrays, re-align the pogo pins too.Since USB-C went mainstream, many people have posted over the years about SWD over USB-C in pursuit of best firmware-dev convenience. I want to discuss this topic with you all to conclusively answer:1. Should we strongly encourage more SWD over USB-C in general to engineers as a best practice, at least during development?The baseline method is discrete jumper wires from programmer to device. If the device has standard SWD/JTAG header dimensions, then an adapter that unifies the several wires into a single plug is nearly convenient as USB-C. That said, orientation is not reversible, mis-insertion risk exists, the male pins are exposed, and gender is not standardized (male/female on device/programmer).A pogo pin jig is expensive if machined metal; time-consuming if 3D printed. Mechanically, it is an overhang frame with exchangeable heads (supporting different pin arrays) and a lowering/latching mechanism. Because jig-to-device contact is free-air, both the device and the jig must be mounted securely to avoid slippage. Re-alignment for different boards adds mechanical complexity; thru-holes can reduce alignment burden and slippage risk, but still requires initial alignment and press-down force.Please offer your opinion on which of these 3 methods (or a 4th?!) should be the best practice going forward.2. What is the best pinout for SWD over USB-C such that we can attempt a comprehensively rationalized standard?The USB standard specifies Debug Accessory Mode for the custom usage of specific pins: primary differential pair (D+/D-), both secondary differential pairs (TX1/TX2, RX1/RX2), and SBU.3 years ago, I posted on reddit with my original design prioritizing memorability (pins in order of signal importance/complexity) and reversibility (of physical insertion). It focuses on the secondary differential pairs:SWDIO (A2, B2) (digital signal, continuously unique, debug data)SWDCLK (A3, B3) (digital signal, single frequency clock, debug data rate)RST (A10, B10) (digital signal, simple momentary, debug start sequencing)VTG (A11, B11) (analog signal, constant, debug I/O voltage setting)Further rationale includes:VBUS is not allowed for alternate use per spec. VBUS is at risk of higher voltage input from incorrect USB connections anyway. Also, VBUS can be used for power input (ex. 15V with USB-PD) to the target module for simultaneous PWR + SWD over a single USB-C port. Therefore we reserve VBUS for PWR.We want to preserve USB2 functionality of these pins in a simple way that does not require muxing (between USB2 and SWD). Therefore we avoid D+/D-. For USB2 in DAM, CC1/CC2 muxing should be optional because original function retention is allowed, but actual compatibility may vary depending on the cable/host USB controller.SBU pins are more likely to accidentally contact the higher voltage VBUS pins. Therefore we prefer not to use SBU, but we can still use it for SWO. SBU is also slightly less memorable than the 4 secondary differential pins.USB3 controllers send polling signals on TX1/TX2. RST is a critical system pin that we want to keep safe on RX1 or RX2. USB3 support requires muxing all secondary differential pins anyway.Please suggest a superior design or confirm this looks like the best possible standard.Side NotesCC1 and CC2 should each be pulled down with 5.1k resistor, to enable USB-C Debug Accessory Mode (DAM) as recognizable by any USB controllers.Some USBC cables may not work because their internal controller may not see both CC pins and may not work with DAM as to pass-thru all 4 key signals.All-passive USB-C cables are guaranteed to work, such as: Same Sky CBLT-UC-UC-1WTAnswersBased on the discussion below, the answer to question 1 is staying with traditional debug headers such as 2x5 JTAG (2.54mm pitch), 2x5 mini-JTAG (1.27mm pitch), 2x3 SWD (2.54mm pitch), and 2x3 mini-SWD (1.27mm pitch) with supporting methods (ex. female headers with male-to-male adapters, shrouded male headers, keying) to reduce pin exposure, reduce misinsertion risk, and accelerate correct orientation plug-in. Traditional debug headers are cost-effective, easy to PCBA, supported by the existing accessory ecosystem, compact, and naturally compatible with production pogo pins (when debug header is not installed).The answer to question 2 is presently stuck on addressing USB safe state compliance. A definite answer is TBD.

author: moffy
author_rank: Super Contributor
timestamp: February 04, 2025, 11:45:05 pm
content: After recently looking at a Superspeed layout, I learnt that the Superspeed traces/pins are very sensitive to extra loading/impedance mismatch, I think it would be safest to leave them alone and only use the D+ & D-.

author: ataradov
author_rank: Super Contributor
timestamp: February 05, 2025, 12:46:46 am
content: I would not do that at all. It provides little benefit to the end user and for development having a programming port is fine.It is fine to reuse D+/D- for SWCLK/SWDIO assuming you are not using actual USB functionality in your product.Also, using USB3 signals would require using full USB connectors instead of more common 16 pin ones. This increases the cost and complicates assembly process.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 05, 2025, 01:37:17 am
content: Debug Accessory Mode was defined exactly for this kind of purpose, but it's relatively loosely defined, leaving a lot to the actual specific implementation.You can basically reuse all pins except the VBUS and CCx pins when identified as a debug accessory.From what I remember, the spec recommends the use of custom adapters (so direct plug-to-plug connection) or custom cables, but not general-purpose cables (which have too many variants to guarantee the proper use of DAM).So the pins you use don't matter as they're not supposed to be shared with their original purpose. I understand the idea of willing to change that, but I'm not sure it's that good of an idea either. It overcomplicates things.As ataradov said, a dedicated debug port is much simpler and with much less hassle.If you don't have space constraints, you can precisely add a dedicated debug connector. I usually add either a mini JTAG header (2x5, 1.27mm pitch) which is standard, or a fooprint for a TC2030 cable. If the board is going to be tested in a test jig, then test points are often the way to go otherwise (and the test jig will include a SWD adapter).So not sure I really see the point, as USB-C is not particularly small, would require specific probes/cables (while the above is already standard and so widely available), and for firmware update, using a USB bootloader is usually the way to go (if it's for firmware programming only, not talking about step-by-step debugging).

author: openyk
author_rank: Contributor
timestamp: February 05, 2025, 04:47:50 am
content: Although superspeed is more sensitive, losing USB3 seems preferable to losing USB2.That said, using the D+/D- pins is indeed compatible with 14-pin/16-pin USB-C for a major PCBA advantage and minor cost advantage.I've personally faced the PCBA issue so I strongly resonate with this point. Some 24-pin USB-C connectors are really difficult to reflow/rework with the looser production tolerance of in-house prototyping tools.But we lose USB2 and reversibility. USB2 firmware programming or USB2 normal operation would require a separate USB-C port. Re-orientation is inconvenient but acceptable if wrong-way detection is quick or somewhat preventable with a marked port/plug. Overall, the gap against the 2x5 JTAG header narrows.Overall, the comparison is one-time non-trivial PCBA hassle vs many-time trivial re-orientation hassle and conditional double porting.The resulting design loses reversibility:SWDIO (dp1)SWCLK (dn1)RST (dp2)VTG (dn2)If we break the VBUS restriction and accept SBU for primary use, we can restore reversibility while maintaining intuitive function-pin mapping (though we use up all pins; no SWO):SWDIO (dp1/dp2)SWCLK (dn1/dn2)RST (SBU1/2)VTG (VBUS1/2)This sacrifices VBUS power input (and USB2) to eliminate the 24-pin PCBA hassle.Comparatively, on the 2x5 JTAG (standard 2.54mm pitch, mini 1.27mm pitch) or similar header (ex. 2x3 SWD at 1.27/2.54, not as standardized) method, using female on the device side eliminates pin exposure; male-male or male-female adapters can allow base-female also on debugger side; guided or shrouded male header reduces pin exposure and prevents mis-insertion; keyed header prevents mis-insertion and accelerates correct insertion.OverallI am leaning that the answer to question 1 stays traditional headers. Cost-effective, compact, easy PCBA, re-orientation still necessary but trivial. Compatibility with standard probes and cables is indeed extra boon. Safety of not having to deal with accidental connections to standard USB-C hosts also significant.USB-C undoubtedly has superior convenience. But size, PCBA, and adapter availability are issues. The pragmatism of traditional headers persists. That said, conditional superiority justifies the answer to question 2 as important.For the answer to question 2, the USB-C advantage (over JTAG headers) is reversible and easier to plug in (ex. blind USB-C easier than blind JTAG) for high convenience and satisfying niche physical accessibility cases. The key disadvantages are size, PCBA hassle, and connection safety. The 16-pin reversible design seems like a good compromise to address PCBA, but connection safety adds subcircuit hassle and increases the size issue.To use SWD over USB-C, the only accessories required are a passive USB-C cable and USB-C to debugger adapter board (USBC port connected to debugger-specific connector or generic header for jumper wiring to debugger).

author: ataradov
author_rank: Super Contributor
timestamp: February 05, 2025, 04:52:33 am
content: Quote from: openyk on February 05, 2025, 04:47:50 amThere is only one wire for D+/D- in the cables, so you would have to make custom cables. And if someone uses a standard cable, they would connect random signals to the host.Also, driving VTG on the data lines is a horrible idea. This whole idea is really bad. Like even cheapest Chinese junk from Temu does not do that bad.And reversibility only works when DP/DN pairs are shorted. Otherwise your whole system even with a custom cable will only work in one orientation.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 05, 2025, 05:27:11 am
content: Yes to the above, the two D+/D- pairs are for making the connector orientation-agnostic, but there is never a double pair in any USB-C cable. And as ataradov said, making each of the 4 signals specific would anyway prevent reversing the connector, unless the debug adapter can detect orientation and change the role of the pins accordingly, but that looks a bit convoluted.Also, I'm personally not a huge fan on passing separate single-ended digital signals on a twisted pair due to the potential cross-talk as a twisted pair is intended for symmetric signals but may give nasty results for uncorrelated signals. (So that would prevent using a regular cable, but the above point already does.)

author: openyk
author_rank: Contributor
timestamp: February 05, 2025, 05:31:04 am
content: Quote from: ataradov on February 05, 2025, 04:52:33 amI've added a reversible 16-pin design to my response above that also shifts VTG to VBUS (though this isn't great either when accidental 5V comes into <=3.3v VTG).USB-C is undoubtedly more convenient to use than traditional debug headers. In this light, the idea is good.Size, PCBA, and accessory ecosystem aside, it appears the remaining loose end is ensuring safety from accidental connections in consideration of stray signals and voltage differences. Absolutely agreed on this point.

author: ataradov
author_rank: Super Contributor
timestamp: February 05, 2025, 05:42:13 am
content: But with this you will need active switch circuitry on the debugger side. This ensures that D+/D- are automatically flipped, but SBU1/2 will be in a random orientation.None of this is compliant with the standard and I really hope to never run into a design that uses this.If you need this for quick production use, then skip reset and VTG entirely. You know your target, you know what voltage is uses. And you don't need reset in most cases, especially with fresh devices.Then just using SWD signals on D+/D- would be fine.

author: openyk
author_rank: Contributor
timestamp: February 05, 2025, 05:57:27 am
content: No switching needed on debugger side with the naturally reversible 16-pin design (SWDIO dp1/dp2, SWCLK dn1/dn2, RST sbu1/2, VTG vbus1/2). DAM-compliant but the VTG on vbus not usually compliant.Good suggestion with secondary function-dropping. Perhaps then just 3-function SWDIO dp1/dp2, SWCLK dn1/dn2, RST sbu1/2 for full compliance. But resolving VTG separately is a hassle too.

author: ataradov
author_rank: Super Contributor
timestamp: February 05, 2025, 05:59:36 am
content: SBU1/2 will flip depending on the orientation. There are not a pair of pins for each signal like you get for D+/D-. There are only two - SBU1 and SBU2. Depending on the orientation you will get RST and VTG on either of them.Also, you can't short SBU1 and SBU2 like you do with DP/DM pairs. This will not be compliant and may cause issues.

author: openyk
author_rank: Contributor
timestamp: February 05, 2025, 06:12:16 am
content: Shorting SBU1/SBU2 with RST will produce no issues with passive USBC cable into debugger.As long as any issues with accidental USB connections are not catastrophic, seems functionally ok. Trade-off is compatibility with cables with chips that would DAM pass-thru correctly but hindered by the SBU short somehow. RST is an input so absence of SBU signal will not cause issues. So unless cable chips proactively send signals into SBU1/2 (and they should not especially in DAM), no issues. No USB controller exists at all on debugger side.SBU1/2 shorting should be compliant in DAM, no?

author: ataradov
author_rank: Super Contributor
timestamp: February 05, 2025, 06:18:34 am
content: You are only thinking about your device and debugger. What happens when the user plugs in your device into a PC? Your SBUx signals with end up shorted on a PC. It may or may not cause any issues in practice, but this is certainly not up to spec.Also, DAM is not just a name, you actually need to actively negotiate that mode before you can do anything with those pins. You can't just passively short them.

author: openyk
author_rank: Contributor
timestamp: February 05, 2025, 11:44:39 pm
content: https://www.usb.org/document-library/usb-type-cr-cable-and-connector-specification-release-24The USBC standard says:QuoteIn standard USB operation, the SBU pins are not typically used for signaling before an alternate mode is established. It seems shorted SBUx will be fine as long as it's pulled down.QuoteRST as an input pin is fine with SBUx (USB safe state under 1.5V).That said, SWDIO, SWCLK, and VTG may not be compliant as a pure connection. This connection safety and compliance loose end is an issue. Before DAM, these 3 output signals must be disconnected. The debugger typically requires VTG to be provided first, before doing anything. The MCU cannot be relied on as it may be in a blank or bad firmware state (chicken and egg problem too). I don't see a straightforward way to detect when USB-C DAM has been entered either. The remaining method is manually (ex. jumpers, DIP switch) after USB-C plugged, which defeats the convenience purpose of USB-C.I don't see an obvious toggle subcircuit design that complies with the USB safe state requirement (1.5V max). This is problematic at all 3 typical MCU voltage levels: 1.8V, 3.3V, 5V.

author: ataradov
author_rank: Super Contributor
timestamp: February 06, 2025, 12:03:31 am
content: I don't see how this implies that shorting them fine. They individually can be floating or individually can be pulled down. Connecting them together is not either of those things.But you can do whatever. Ultimately it will be your problem when it causes issues to your customers.

author: coromonadalix
author_rank: Super Contributor
timestamp: February 06, 2025, 05:02:41 pm
content: not sure if this could be relevant or helpful ?https://github.com/alvarop/debugotronhttps://electronics.stackexchange.com/questions/622202/swd-over-usb-c-connector

author: bson
author_rank: Unknown
timestamp: February 07, 2025, 10:06:11 pm
content: If it's ARM and you need debug, use the standard FTSH 2x5 .050" header. The footprint is tiny - smaller than TC2030, and you can populate it with pretty much any .050" 2x5P SMT strip, or the pins you actually need. I'd use TC2030 for production, where I expect to rarely attach a debugger, but where doing so without first mounting a header is desirable. On the flip side, TC2030 doesn't play as well with conformal coatings as an FTSH (if installed).Use USB to flash devices.Avoid Franken-USB horrors like USB-C with positional sensitivity and power on data pins. That's just... bizarre.

author: silly sausage
author_rank: Regular Contributor
timestamp: February 08, 2025, 10:57:52 am
content: what the hell is swd?

author: Gyro
author_rank: Super Contributor
timestamp: February 08, 2025, 11:04:25 am
content: Quote from: silly sausage on February 08, 2025, 10:57:52 amIt doesn't sound as if you can make a useful contribution to the thread.

author: moffy
author_rank: Super Contributor
timestamp: February 08, 2025, 12:04:56 pm
content: Quote from: silly sausage on February 08, 2025, 10:57:52 amSWD or Single Wire Debug.

author: thebuckmaster
author_rank: Newbie
timestamp: February 14, 2025, 01:37:03 am
content: I personally would love to see SWD over USB-C using DAM emerge as an informal standard.Quote from: openyk on February 04, 2025, 10:47:08 pmI find table E1 confusing - maybe someone here has some insight. Why is the limit expressed only as a limit on common mode voltage for pairs of pins? Seems to imply that if we held SS_TX1_N at 0V in an application, then we could put a 3V single ended signal on SS_TX1_P for example. Or just apply -100V and 103V DC! Obviously, this wouldn't be good.I suspect the intention is "you can never apply more than 1.5V between any of these pins and ground" - thoughts?

author: Gnarflord
author_rank: Newbie
timestamp: April 04, 2025, 08:12:26 am
content: So this idea of debugging over USB-C was stuck in my brain for some while.According to Appendix B of the USB-C standard, the DTS (=Debug and Test System, our programmer) may expose different CC pullup resistors on CC1/CC2 such that the TS (=Target System) may detect the cable orientation by looking at what CC-line has the higher voltage. Then, a multiplexer could flip the signals around to match the cable orientation (*).Most of my devices already have USB-C and only need two wires for programming, SWIO and SWCLK. I can do resets via the SWD layer and the target voltage is known beforehand. So I propose a circuit like in the attachment. Only SBU1/2 are used for debugging and the signals are only exposed if both CC lanes are high (=DAM mode active), which means a 16-pin USB C receptacle is sufficient and USB D+/D- is not used. As far as I understand all of that is USB-C compliant. The overhead on the target device is only two ICs (which are available as QFN if space is crucial) and some passives, which isn't that bad for the added convenience. I haven't tested the circuit yet, so there may be bugs in there.An issue is that access to both CC lanes is required and all proper USB-C cable only transmit one. But using a USB-C extension cable and a USB Type-Cplugon the debugger PCB should work to expose both lanes. These ones from The Pi Hut are known to transmit both CC lanes:https://thepihut.com/products/usb-c-extension-cable-for-raspberry-pi-4I could imagine extending this in-house standard to more complex devices which require further periphery. These would require a 24p USB-C receptacle but may expose more lanes. Maybe a UART and RST/VTG/SWO. CAN bus would be super nice for my applications, but I don't see an easy way to switch a CAN bus with an analog multiplexer, as they may have quite high common mode voltage.(*) KiCAD only had a symbol for 3.3V TI multiplexers, so imagine a 5V one from TI in its place