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

  • What's J-Tagg? – Eugene Sh. Oct 2 '17 at 21:55
  • Corrected. That was my first pass. ;) – Leroy105 Oct 2 '17 at 21:57
  • 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) – Eugene Sh. Oct 2 '17 at 22:01
  • what is the loader? and especially a compatible one. Here is one: deere.com/assets/images/common/products/wheel-loaders/… – P__J__ Oct 2 '17 at 22:19
up vote 5 down vote accepted

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.

  • 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. – Gabriel Staples Apr 10 at 18:00
  • Also, if this question was just asked elsewhere, posting a link to it would be helpful to tie threads together via cross-links. – Gabriel Staples Apr 10 at 18:01
  • Sure but the OP failed to do the work of looking for an answer before coming here, rather than try to close this as a duplicate, had additional information to add. – old_timer Apr 10 at 19:04
  • Note I have examples for nxp and stm32 on github, as well as for arduino and perhaps other bootloaders. Very often work at this level is baremetal and the actual programming part of baremetal is the easy part, 99% of the work is research and reading. Should be countless numbers of examples on github as well as other places. Are you ready for this kind of work? I see this as a teach to fish moment rather than give a fish moment. Likewise my links/code can change or disappear at any time so no point putting a permanent link here. – old_timer Apr 10 at 19:08
  • 1
    @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. – Leroy105 Apr 13 at 18:43

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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