# Is JTAG the standard way to program ARM processors?

Some electrical engineer once told me, that each ARM M3 processor can be flashed the same way, no matter which manufacturer it came from.

I suppose he meant using JTAG, or is there another way?

Btw, I'm meaning to flash an empty ARM processor without a bootloader.

• ARM-based micros are flashed over JTAG or SWD. Some will accept programming over either protocol, while others require one or the other. For example, the Nordic Semiconductor nRF52 is SWD only. And just because all M3s can be flashed the same way does not mean software is freely interchangeable. – CHendrix Jan 3 '17 at 15:14

I suppose he meant using JTAG, or is there another way?

Probably he didn't. ARM has their own debugging bus standard – SWD (single wire debug), that is very well-specified. JTAG, on the other hand, is merely a electrical and shift-register-level standard, and it's up to device manufacturers to give JTAG endpoints and actions a meaning.

SWD programmers can be had for <5€. Look for products called "STLink v2 compatible" or so. The ST in the name stems from the fact that they are based on the protocol that STmicro USB-to-SWD adapters speak between host computer and adapter, but since they only "transport" SWD, they work with every SWD-compatible microcontroller.

On most development systems, you'd want to use OpenOCD as "driver" for these devices, so that you can easily flash images (either directly through OpenOCD or using e.g. GDB's load). If you're stuck with an absurd OS that needs specific drivers even for generic devices, you'd probably have to install ST's tools.

Btw, I'm meaning to flash an empty ARM processor without a bootloader.

Yep, sounds like a classical case for SWD – ARM offers hardware for that in their cores, and most manufacturers choose to use that and assign pins.

Also note that most manufacturers (including ST) ship their "empty" ICs with some kind of bootloader, over which you can load firmware through a serial port or even USB into the device – suuuuper handy for manufacturing.

For a bit of discussion on SWD, I actually recommend (for the pure fun it is to read) PoC||GTFO 0x10, pp. 26, which begins with an introduction of ARM's debugging infrastructure and SWD as a protocol, and then goes on to explain how to use SWD-connected ARMs as sophisticated IO expanders rather than independent MCUs.

• So you can use SWD to flash your program to the processor? I thought it was only for debugging. – user41666 Jan 3 '17 at 14:15
• If production programming via JTAG or SWD, there are devices that support multiple loads at once for greater throughput. Example: elprotronic.com/products?show&id=55. Also, many (most? all?) devices support a serial code upload via USB, UART or whatever the chip manufacturer chooses. This is usually code loading only and no debugging. For most of my products, it's JTAG/SWD for development and then serial update in the production environment, and sometimes getting code pre-loaded by the chip distributor (which is usually serial). – Smith Jan 3 '17 at 14:49
• @MarcusMüller - it's not just the address that changes, the actual procedure for valid programming is device unique - sometimes it is published, other times it is "we aren't going to even tell you how, you have to invoke our ROM routine". Not uncommonly there are additional details, for example Atmel SAM series can have fuse bits that have to be set to enable booting from flash, and can optionally swap the addressing of the flash banks. Yes, openocd encapsulates these things, but the point is there are details to encapsulate, I've had to patch it for uniqueness within a supported family. – Chris Stratton Jan 3 '17 at 19:08
• Wow, that PoC||GTFO is really quite amazing! – bitsmack Jan 3 '17 at 21:04
• So to recapitulate everything, there is NO universal device to flash any ARM processor? If I have an M3 from one manufacturer and another from a different manufacturer, then both may have different ways to be flashed? – user41666 Jan 5 '17 at 10:51