Segger J-Link vs. JTAG Programmer?

ARMs use either JTAG or SWD, and most common microcontroller ARM cores are the Cortex series, which are almost exclusively programmed and debugged over SWD.

Both JTAG and SWD are well defined, and most vendors describe how to enter and manipulate the Debug Access Port (DAP) which is how you usually access the internal buses, CPU, memories and peripherals. The physical interface between the PC you're using to develop/debug and the JTAG/SWD port of the micro is the adapter.

While it's true that you can use practically anything to connect to the port and manipulate the SWD interface, most vendors will have their own "flavour" of adapter. Using the vendor's recommended tool is usually the path of least resistance, as the vendor will support their adapter, their recommended software will work with their adapter and things should be documented reasonably well, making things as smooth as possible.

That being said, my experience with vendor tools is that they are substandard, quick and dirty tools. I often have trouble with OpenOCD and vendor tools (mostly ST-Link, Olimex, OpenSDA, etc.), particularly with debugging. Let me tell you: nothing is more frustrating than finally getting an embedded system to exhibit a bug under a debug environment and something between the debugger software/ide (gdb, eclipse, etc.), OpenOCD, the vendor driver and the vendor adapter getting out of sync, dropping the debug connection and requiring a hardware restart to try again. This frustrating environment instability opens the door to vendors such as Segger, who make their own JTAG/SWD adapters, provide excellent support and whose tools work with many different vendors. There is something to be said for a single unified interface to use with practically all the devices you work with.

I spent a lot of time avoiding J-Link because of the price and because I preferred to use open software and vendor tools. I started using the J-Link adapters a few years ago on one project which already had them and have not looked back. Their tools are all multi-platform and their standalone debugger, Ozone, is amazing. I've rarely had that "middle of debugging instability" issue with OpenOCD and J-Link, and have never had it with Ozone.

Segger has also taken the rather nice step of offering a free "upgrade" to any on-board debugger on a dev kit which turns the vendor-specific debugger into a licensed J-Link. This is of course to get you trying and using their tools so you will buy them for use on your own boards, but it's a brilliant tactic. More info here for ST-Link, follow their "Models -> Other J-Links" links for other vendors. They also have educational discounts and J-Link "lite" hardware which is very reasonably priced (USD$50 I think?) and is restricted to Cortex processor cores.

Now Segger isn't the only third-party adapter out there: an open-source debugger specifically targeting gdb is available. It's the Black Magic Probe. They sell hardware but also have full schematics, layouts and software released under GPL. I haven't had an opportunity to use these yet but I'm very excited to try this debugger out. Implementing the GDB protocol on the debugger should improve stability considerably. There are of course other higher end systems too such as Lauterbach and the (now defunct) Abatron BDI2000 and BDI3000 adapters. The fancier/more expensive tools are usually networked instead of direct-connected to the debugging PC, offer (much) faster JTAG interfaces and oftentimes also have separate trace ports available which, with compatible MCUs, give you a detailed log of every instruction executed, the time it was executed and the internal processor states after every instruction.

You could always implement your own as well. I've embedded my own SWD interfaces in Cypress' PSoC5LP to solve a particular problem which allowed me to program an entire chain of devices through one USB connection for manufacture. You could use a parallel port or pair of GPIO lines to wiggle the signals out as well. It all depends on what you're after.

Wasnt this question just asked.

ARM makes the cores, the cores have an SWD interface, which is now openly documented, and there are many solutions. Yes you can use an stlink to communicate to chips other than the stm32. Likewise the one arm is pushing, cant remember its name, found on the newer ti launchpads for example the msp432 board(s) I think has one. And you can get j-link clones on ebay for a few bucks that work just fine. You can go into openocd and on the parallel backend implement whatever you want, can bit bang say through an ftdi device used as gpio, slow but works perfectly fine. as well as some folks have simply implemented swd tools using various boards, mcus, etc.

some vendors NXP and ST in particular continue to have a uart based bootloader which is completely independent of arm and the swd interface into the arm core, these bootloaders are simple protocols that you can bang out your own tool in a half an hour using a usb to uart on your development machine (ftdi, etc) or there are many already written ones. atmel sadly has given up on samba, they offer one you can download to the samd parts, but you have to be responsible not to erase it and that part is super easy to erase the flash, disturbingly easy. so that is a bit of a fail for an interface like the other vendors you used to be able to rely on being there.

there are basically too many choices to choose from if you want to look at it from that perspective. not to mention if you buy a development board from the chip vendor and download their software it is expected to just work with a mouse click or few.