Phillip Pearson - web + electronics notes

One of the things that confused me the most when moving between the AVR and ARM Cortex-M worlds was what debug/flash interfaces to support. The LPC11U1x series has a UART based flash download method (shared with the LPC810, according to this Adafruit tutorial), and the LPC11U2x/3x chips add in various USB options. STM32F chips have their own method, and I've seen an I2C downloader for WLCSP (very small) versions of Freescale Kinetis chips.

All of these are red herrings! The only interface you need is SWD, an ARM standard that gives you a connection right into the processor bus -- i.e., pretty much full control of the chip. It's active all the time unless you've disabled the SWDIO and SWCLK pins or assigned them to other duties, and has very good open and closed source support across the board.

This PDF from ARM explains the connector you need. It's a 2x5 header with 1.27mm (0.05") pitch. One row of pins for power/ground, another for data. There are some gotchas in there, and here is what I've figured out through trial and error. First, the power row:

1 - VCC - connect this to your MCU power net to get convenient power right from the debug adapter. You might want to put a jumper in series if you'll sometimes want to self-power the board, or leave this disconnected entirely if you'll *always* have the board self-powered.

3 and 5 - GND - connect to your ground net.

7 - KEY - leave this unconnected

9 - GNDDetect - this is for target boards to detect the presence of a debugger. I always leave it unconnected, but if knowing a debugger is connected is useful to you, put a pullup to VDD and feed this into a GPIO.

Now, the data row:

2 - SWDIO - connect this to your MCU's SWDIO pin. Pull-up/down resistors are usually unnecessary here, although check your datasheet to be sure.

4 - SWCLK - connect this to your MCU's SWCLK pin. Add a pull-down resistor to ground, between 10-100k.

6 - SWO/TDO - connect this to SWO (Serial Wire Output) on your MCU if you're using a Cortex-M3/M4. Cortex-M0/M0+ chips don't implement SWO, so I like to connect it to TXD on a spare UART in that case, which gives me a convenient serial console over the debug connector (I have a board that breaks out the UART pins separately so they don't go to the debugger).

8 - NC/TDI - either leave this unconnected, or connect it to RXD on a spare UART if you like my UART multiplexing trick.

10 - nRESET - connect to your MCU's /RESET pin. This usually needs a 10-100k pullup to VDD.

That's the electrical side of things sorted. Now, the physical. You'll find that SMD and thru-hole 0.05" pitch connectors are surprisingly expensive compared to 0.1" headers. After buying a bunch of $0.70 SMD 2x5 connectors and $0.30 thru-hole ones, I found a vendor on Aliexpress who was selling 10-packs of 2x50 connectors (of either type) for about $8, which can easily be chopped up into whatever length you like. This brings the cost of a 2x5 connector down to about $0.10, which seems much more reasonable.

Finally, debug connectors and software. Each chip family, and sometimes each chip, has a different flash controller, so you'll find that you need software for your particular device before you can erase, flash, or debug it. Here's what I've gathered so far:

- The SEGGER J-Link is a very very flexible debug adapter, that supports pretty much any Cortex-M chip, and is supported by pretty much every IDE. It will save you a ton of time to buy one of these, but you'll be paying $400 for a commercial-licensed version if you're doing anything other than educational/hobbyist work (in which case the $60 "EDU" version will do).

- CMSIS-DAP is ARM's standard for SWD over USB. Any CMSIS-DAP compliant adapter should work with any CMSIS-DAP compliant tool. As of now, there aren't a ton of these, but if you buy a development board, there's a good chance you'll be able to reflash the debug connector side of it with CMSIS-DAP firmware, and use it as a CMSIS-DAP dongle for any chip you can find software for (i.e., you're not limited by processor family any more). The firmware is open-source, available on GitHub.

- Free IDEs exist for most chip families. For Atmel ATSAM chips, there's the Visual Studio based Atmel Studio (which requires a J-Link, or the $50 ATMEL ICE adapter, to program chips). For Freescale Kinetis chips, you want the Kinetis Design Studio (which supports J-Link out of the box, or you can hack up a Freescale Freedom dev board and program it with the USBDM firmware). For NXP LPC chips, there's LPCXPresso (which supports CMSIS-DAP, J-Link, and NXP's $20 LPC-Link2, or you can hack up an LPCXPresso dev board).

- I'm a little confused about the STMF32 chips from STMicroelectronics. They have super cheap ~$10 "Discovery" dev boards, which come with an on-board ST-LINK/V2 debug adapter (available separately for ~$20), but as far as I can tell, don't have a vendor-supported free toolchain. However, there's a ton of open-source support, and you can put together a free toolchain without too much trouble. For flashing/debugging your chips, you'll want OpenOCD, which supports pretty much any debug adapter under the sun.

While we're talking about OpenOCD... it is an awesome open source project that I would love to use/contribute to if I find time. It seems like the Right Thing to do, allowing you to debug many kinds of chips with many kinds of adapter. I see it has support for some members of the Freescale Kinetis family, and it was able to connect to a MKE04Z8VTG4 using my LPC-Link2 with CMSIS-DAP firmware, but doesn't have support for the FTMRE flash controller there. Porting the flash code from USBDM into OpenOCD would be an excellent project, and would enable OS X support for more Kinetis devices. Both projects are licensed under the GPLv2.

That said, I'm probably going to buy myself a J-Link soon, because I really like the look of the Atmel ATSAM4S16B -- $5 in single quantities, 120 MHz Cortex-M4 with 1MB flash and 128k sram -- and I want to use Atmel Studio. So far I've been using a Freescale FRDM-KE04Z board with USBDM to debug my MKE04Z8VTG4 and MKE02Z64VLD2 based boards, and an LPC-Link2 to debug my LPC11U14 and LPC11U12 based boards.