I have searched high and low (in fact I have spent the recent months on and off trying to find an answer). Maybe I'm not asking the right questions, or am staring the answer in the face, I'm not sure. I have been too nervous to ask, but I am at my wits end, so here goes.

I am creating a project that due to size constraints needs to be very small. That means small MCU and small programming interface. It is also open source so I would like to keep the programming interface as cheap and simple as possible (also as a student I don't want to spend a lot if I don't have to).

This Article I found seems to indicate to me the possibility of a universal solution. Those FTDI chips are a lot cheaper than any other (legitimate) JTAG programmer. Broadly speaking (for posterity), will they be able to interface with and program any ARM MCU that includes an SWD interface?

Specifically (if it's relevant), I am looking to integrate the SiLabs BGM121 SiP module into my project and am trying to figure out how I would program it. I don't even necessarily care about debugging at this point, just trying to figure out a cheap solution. Also between the SiLabs CP2102 and the FTDI FT2232H, which is more likely to work?

  • \$\begingroup\$ Most hardware solutions of appropriate voltage can work if you get the appropriate software behind it, which often means patching (or waiting for someone else to patch) something like OpenOCD to support a specific target. Some hardware approaches merely work faster than others or better handle extreme voltages. The FT2232H is fairly pricey as basic silicon solutions go - you can port the the CMSIS-DAP code to any low end ARM cortex MCU with USB for example, but it will be far slower. \$\endgroup\$ – Chris Stratton Oct 31 '17 at 4:37
  • \$\begingroup\$ That is true on the FT2232H, Somewhere along the way i blurred the lines between the FT232h which is cheaper, but maybe older? Im going to download and install Open-OCD and try to start learning that as well as see what the simplicity studios from SiLabs has on offer. Do you have a suggestion for a cheap hardware solution? I apologize for my ignorance, I am just beginning to learn arm programming, the data sheet for the BGM121 was pretty non descript, but I did find an app note that im reading through from them. Thank you for your answer! \$\endgroup\$ – David Schallock Oct 31 '17 at 5:45
  • \$\begingroup\$ Your edit to the question doesn't make a lot of sense in the context of this site. You could possibly have posted it as an answer - then at least the original question/answers would have made sense. Best is probably to wait till you have a new question relating to the firmware, and ask something new then. \$\endgroup\$ – Sean Houlihane Nov 14 '17 at 14:21
  • \$\begingroup\$ Yea, I dont really know how this site works to be 100% honest. I thought it was the clear dissemination of information for posterity? I answered my own question and edited the question to reflect that, and help anyone who was in the same position as myself, in a (IMHO) clear way. The information is in plain view now. I dont do the whole hand wringing thing, if I find information I am lacking I'm just grateful for the information, not the format. But by all means, I will edit my post, you have more many orders of magnitude more experience here than I do. \$\endgroup\$ – David Schallock Nov 16 '17 at 0:50
  • \$\begingroup\$ and now you have twice the reputation you had before... \$\endgroup\$ – Sean Houlihane Nov 16 '17 at 21:21

The ARM SWD interface is 'generic' in that the interface protocol doesn't care about the target hardware. So assuming that your programming device operates at the right voltage, yes, it can work with any hardware.

Behind the SWD interface, the registers which control debug in the SoC are memory mapped. Although these are standardised in a sense, for any debug toolchain there will often be a degree of customisation required (at the software side). For example, a new CPU will have a new ID code value, and maybe some additional architected control registers.

You basically have the choice of implementing the SWD protocol in software on your PC, and using a USB-to-pins interface, or implementing the protocol in a micro-controller and presenting a USB endpoint which 'does debug'. Doing the latter is what almost all of the dev-boards with a built-in debug interface do, along the lines of SWDAP and the DAPLink software. Often these dev boards are configured so you can break-out the SWD signals and use them to debug your own target hardware in an end product design.

If you chose not to implement DAPLink, you might be more limited in the toolchains which support your interface.

In the past, the SWD protocol documentation has been complicated to get access to, and this seems to have let to a degree of confusion when it comes to generic probes. The old pre-CoreSight JTAG interfaces were also much more device specific, with a TAP controller implemented within the CPU.

  • \$\begingroup\$ Thank you for the answer. Definitely helpful, I think the way to go might be getting an stm32 dev board with the st-link built in which can then be flashed with segger firmware to upgrade it to a J-link. I believe they consider it to be the j-link lite. The same license restrictions apply obviously, but I can use it to get my feet wet and if I do end up trying to sell a project ill figure it out from there. To tie it together this may be the best option for a cheap universal programmer/debugger. Please correct me if I am wrong. \$\endgroup\$ – David Schallock Nov 2 '17 at 0:38
  • \$\begingroup\$ You're referring to restrictions on the hardware being debugged, or toolchain restictions? The mbed cmsis-dap is unencumbered (so far as I know) and can be flashed on many dev boards (probably cheaper than buying dip-dap which is a stand-alone NXP part designed for prototyping). I'm not aware of any extra functionality present in firmware from other vendors (but I've never needed to look). \$\endgroup\$ – Sean Houlihane Nov 2 '17 at 8:32
  • \$\begingroup\$ Sorry I was referring to restrictions imposed by segger for their jlink edu firmware. What you are saying is interesting. So if I buy an stm32 dev board, I can flash cmsis-dap onto the st-link portion of the board? Or is cmsis-dap just a software layer? I may end up doing that in either case. Thank you! \$\endgroup\$ – David Schallock Nov 2 '17 at 17:53

Alright so after more research I believe I have come up with a relatively cheap solution, an stm32 dev board can be flashed with DAPLINK firmware, but I dont believe that the official github firmware will work natively. But I found that the daplink_usb board included with the readbear mk20 is running an stm32 chip, they have released the firmware, which needs to have a line changed to make it compatible with the 8mhz crystal(Detailed in forum post linked below). Otherwise change out the crystal with a 16 mhz one.


Good Forum Resource here.

Redbear Github fork

  • \$\begingroup\$ The thing to be aware of is that a CMSIS DAP built with a full-speed MCU is relatively slow as a cost of the mode used for portability; commercial versions with decent speed are USB high-speed devices, not so much for the transfer speed as because a larger packet size is then permitted. The ST-LINK protocol makes more efficient usage of full-speed USB, so for an STM32 target you probably do not want to replace the ST-LINK firmware. It's also possible to flash at least some other brands via an unmodified ST-LINK with OpenOCD, for example all three generations of Nordic BLE chips. \$\endgroup\$ – Chris Stratton Feb 23 '19 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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