I haven't developed with an ARM, and I'm a little confused on the programmer.
I've been coding with PICs and 8051s and both use loaders that are from the manufacturer. No confusion.
But ARMs are a bit different since the cores are mostly the same?
Do you have to buy a Segger "J-Link" JTAG programmer to program ARMs? I see the professional Segger loaders are like multiple hundreds of dollars. Seems a little harsh…
I see ST makes a JTAG programmer the "ST-Link" for much less than the "J-Link" — what gives?
What is the deal with the loaders for ARM Cortex M? Are the loading tools from ARM MCU makers locked to only work with their MCUs?
Can the ST-Link program another ARM Cortex M, if you pinned it up correctly?
I'm trying to ultimately have a compatible loader for an ARM Cortex M3, whose manufacturer does not make a loader…
Best Answer
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.