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...

  • \$\begingroup\$ Well.. J-Link is a JTAG programmer. They just have different limited editions supporting different devices (each device has a different JTAG sequence to perform certain tasks) \$\endgroup\$
    – Eugene Sh.
    Commented Oct 2, 2017 at 22:01
  • \$\begingroup\$ what is the loader? and especially a compatible one. Here is one: deere.com/assets/images/common/products/wheel-loaders/… \$\endgroup\$ Commented Oct 2, 2017 at 22:19

3 Answers 3


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.

  • 2
    \$\begingroup\$ Have you had a chance to try the Black Magic probe? Anything to add here? \$\endgroup\$
    – cp.engr
    Commented Jul 15, 2019 at 3:36

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.

  • 3
    \$\begingroup\$ I was wondering if you might be willing to "bang out your own tool in a half an hour" and post it to GitHub with detailed instructions (detailed enough for a 12-year-old beginner to follow) on how to use it, with examples. I think that'd be really helpful. If you are willing to, thanks in advance. It'd be a good learning experience for me to read your code. \$\endgroup\$ Commented Apr 10, 2018 at 18:00
  • 2
    \$\begingroup\$ Also, if this question was just asked elsewhere, posting a link to it would be helpful to tie threads together via cross-links. \$\endgroup\$ Commented Apr 10, 2018 at 18:01
  • 2
    \$\begingroup\$ I appreciate your concern in helping me learn to fish, but I already know how to fish. I've spent about 3000~4000 hrs. doing it in evenings, weekends, and holidays to get to where I am today with microcontrollers and EE, and I'm currently fishing in the STM32 world for other answers, digging through the 6000 pages of documentation I've dug up. So, I see this as a learn by example opportunity rather than a "learn to fish" opportunity which I really don't need. If you show me what you've done you're not giving me a fish, you're teaching by example. I'm not the freebie kind of guy. Your call. \$\endgroup\$ Commented Apr 10, 2018 at 19:33
  • 2
    \$\begingroup\$ At a minimum, a link to your GitHub account would be helpful. If you also have other links readily available I don't see the trouble with you dropping them here. If you don't, no problem, I can google and read reference manuals, application notes, datasheets, blogs and GitHub code as well as the next expert engineer or problem solver, but every expert knows this takes loads of valuable time that someone else could help them save with a little guidance to speed up the process. \$\endgroup\$ Commented Apr 10, 2018 at 19:40
  • 2
    \$\begingroup\$ @Gabriel Staples, know what's funny? I'm working on a TI CC1130 which also uses JTAG. I've been around this a bit more, and honestly I would say that the ACTUAL reason folks buy Segger is that Segger has their drivers on almost all the ARM IDEs for all the vendors. ST-LINK for $25 maybe sorta coulda might work, but the reality is that TI doesn't have a driver for it in their IDE. They do have the driver ready to go for Segger... To say an ST-Link can communicate with any ARM is not totally true, if there is no driver support natively in other platforms. \$\endgroup\$
    – Leroy105
    Commented Apr 13, 2018 at 18:43

Please note that this answer is opinion based.

I think if you are new in ARM you should focus on one manufacturer first.

In my case the best choice was STM. I learned a lot in a short time, because there are buy many inexpensive development boards with diffrent microcontrollers and I could reuse arduino-compatibile extension boards with relays, displays etc.

STM32 are very friendly if you get familiar with "ecosystem" (STM32IDE, CubeMX). Cheap mini-programmers ST-Link V3 are good enough for first year of developlent.

STM offers few kinds of programmers/debuggers:

ST-Link V2 can provide power to target (this does not apply to isolated version).

ST-Link V3 can't power target board if I remember correctly, but it is much faster. It really matters when you debug microcontrollers with huge flash (compared to 8 bit microcontrollers).

ST-Link V3 SET sucks (too much money for not much difference vs MINI variant) and don't buy it if you have no reason. I'm using it and I feel thats unfinished product, or a product manufactured for some unknown company special needs.

ST-Link V3 MINI variants are cheap and do their job (programming and debugging).

SEGGER company has software and hardware tools very useful for debugging intense applications (multitasking, FreeRTOS etc.).

There is a tool called SEGGER SystemView that shows you how much time tasks need for example and how tasks are switched by OS. It can be used with SEGGER J-Link hardware tool or simple UART. This is actually very nice tool that helps to understand what is going on if you use FreeRTOS for the first time. You can see when your tasks run etc. (image below).

image from SEGGER website

There are few SEGGER J-Link (hardware tool) kinds. More expensive variants are faster and have more buffer memory (you can trace/analyze more events at once) or have ethernet or WiFi. Less expensive tools have smaller buffer and you may have to analyze multitasking applications few times because it may not be able to trace all events.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.