Cheapest SWD uploaders for SAMD2x

[matseng]

I will send a few prototypes for user testing to some clients and they probably will need to flash new firmware into them a few times during the testing period. Unfortunately stupid me didn't include any externally accessible serial port on the pcb so I could just put a serial boot loader on the SAMD20 for uploading new fw.  I do have the SWD port available though from outside the enclosure, but shipping a $100 ATAMEL-ICE with the prototypes and having them install Atmel studio seems a bit overkill.

Is there any cheap SWD flasher that have a windows app with basically just a Load_binary and a Flash -button or at least something semi-cheap and semi-easy to install and use.  The clients are reasonably tech savvy but I wouldn't want them to endure Atmel studio.

[stmdude]

With "reasonably tech-savvy" recipients, I've had luck with just OpenOCD (for Windows) and a bat-file.

As for a cheap SWD "flasher", have a look at the STLink/V2s if you need then right now ($25 iirc), or just some generic clone thereof for $3 from AliExpress.

[donotdespisethesnake]

I think you already found the cheapest solution. Generally speaking price is proportional to sales volume, and since this is a very niche requirement, don't expect to find an off the shelf solution that is also cheap. SWD is normally used for development or production programming, only hobbyists are likely to deploy it as a field solution.

If you used Segger tools then you could use their command line to create a batch file which could be relatively easy to run by an end-user, but Segger tools are not cheap.

[matseng]

Ollrighy! I've got a a real ST-LINK/V2 in a box that I've never even bothered to open since I purchased it.  The 0.1" pinheader on it is also much sturdier than the horrible newfangeled 0.05" headers that so many seems to like today.

I'll see if I can figure out how to use it from openocd  it and what hex I need to generate from Atmel Studio.  Or will it eat the standard hex and take care of fuses and it all automatically?  You get kinda spoiled and ignorant to the nitty-gritty details when using the "right" tools when working on a project...

I've implemented the Atmel & PIC ICSP protocols on an ESP8266 use for fun so those I know how they work, but I haven't bothered to learn how the SWD works - it might be incredibly complex and timing-sensitive for all I know ;-)

[stmdude]

OpenOCD should eat the hex-files that comes out of Atmel studio.

As for fuses, I have no idea. Never really used an Atmel chip with OpenOCD.. 

[janoc]

Does this actually work? AFAIK Atmel chips have the vendor extensions needed to program and debug them over JTAG/SWD undocumented/proprietary, so a normal JTAG/SWD dongle like ST Link is unlikely to work except for boundary scan.

You will either need an Atmel programmer of some kind or put the Atmel EDBG chip on the board - that does translation between the proprietary stuff and normal CMSIS-DAP over a serial port. OpenOCD then can work with that.

This was actually one reason that drove me to ARM chips - there the protocols tend to be documented and you don't need any proprietary tooling.

[jaromir]

Also, you may want to take a look here:
Cheap and simple flasher hardware - https://github.com/ataradov/free-dap
From the same author - https://github.com/ataradov/edbg - interface to EDBG

[cv007]

Unfortunately stupid me didn't include any externally accessible serial port on the pcb so I could just put a serial boot loader on the SAMD20 for uploading new fw.  I do have the SWD port available though from outside the enclosure

If you have swd connections, what prevents you from using those clk/dat pins as tx/rx for a bootloader? I don't know the samd20 pin/peripheral multiplexing scheme, but it wouldn't surprise me if you could get a serial port to work on those pins. A bootloader solution may end up being more work than an swd solution, but I don't think the bootloader option goes away just because you have some connector labeled as swd.

[technix]

I wonder if those ST-Link clones can be flashed J-Link OB firmware... I know that is running against their EULA really.

[janoc]

Also, you may want to take a look here:
Cheap and simple flasher hardware - https://github.com/ataradov/free-dap
From the same author - https://github.com/ataradov/edbg - interface to EDBG

That is not going to help him unless he has the EDBG chip on the board already. And if he does, he could use OpenOCD already.

[technix]

Also, you may want to take a look here:
Cheap and simple flasher hardware - https://github.com/ataradov/free-dap
From the same author - https://github.com/ataradov/edbg - interface to EDBG

That is not going to help him unless he has the EDBG chip on the board already. And if he does, he could use OpenOCD already.

EDBG... If I recalled it right Arduino Zero and Arduino M0 Pro boards both have one connected via SWD to their respective onboard ATSAMD21 microcontroller, and there is a conveniently placed CMSIS-DAP style connector for those pins next to the main MCU, and those don't cost $100 each - $42.9 each from their website (sold out) and maybe slightly more elsewhere. Maybe get one of those and use a hot air gun to remove that main MCU so it can be used as a makeshift EDBG?

[ataradov]

That is not going to help him unless he has the EDBG chip on the board already. And if he does, he could use OpenOCD already.

I also sell the hardware based on Free-DAP - https://www.tindie.com/products/ataradov/cmsis-dap-compliant-swd-debugger/ .  And all the designs are open, so it would not be too hard to mass produce, especially given shipping to Sweden.

As far as I know this is the cheapest CMSIS-DAP SWD programmer, but admittedly it is probably not the best value. LPC Link 2 is the best value at the moment as far as I know. And Chinese clones of STLink are hard to compete with on price, but I have never tried them.

[ataradov]

Does this actually work? AFAIK Atmel chips have the vendor extensions needed to program and debug them over JTAG/SWD undocumented/proprietary, so a normal JTAG/SWD dongle like ST Link is unlikely to work except for boundary scan.

No extensions, nothing is proprietary. You do need to have device support in your programmer. So utilities designed to program only ST parts will not recognize or program Atmel parts, of course. But that is standard for ARM ecosystem. They won't work with NXP or any other chips either.

[janoc]

Does this actually work? AFAIK Atmel chips have the vendor extensions needed to program and debug them over JTAG/SWD undocumented/proprietary, so a normal JTAG/SWD dongle like ST Link is unlikely to work except for boundary scan.

No extensions, nothing is proprietary. You do need to have device support in your programmer. So utilities designed to program only ST parts will not recognize or program Atmel parts, of course. But that is standard for ARM ecosystem. They won't work with NXP or any other chips either.

I don't have first hand experience with Atmel ARM chips but their AVRs and XMegas have the debug protocols closed/undocumented. And if you want to program using JTAG (on parts that have it), it is the same story, the information necessary to implement it is available only under NDA to partners. So you have to use their proprietary tools.

The EDBG chip is meant to handle this and translate the many Atmel-specific protocols (DebugWire, PDI,  Atmel's JTAG/SWD) into CMSIS-DAP over a virtual serial port.

Can you actually program a SAM21 (or similar) using a generic JTAG/SWD dongle e.g. using OpenOCD (which supports them)?

[ataradov]

I don't have first hand experience with Atmel ARM chips but their AVRs and XMegas have the debug protocols closed/undocumented. And if you want to program using JTAG (on parts that have it), it is the same story, the information necessary to implement is available only under NDA to partners.

But we are not taking about AVRs and XMegas.

The EDBG chip is meant to handle this and translate the many Atmel-specific protocols (DebugWire, PDI,  Atmel's JTAG/SWD) into CMSIS-DAP over a virtual serial port.

It is not working over virtual serial port, it is working over vendor-specific commands of the CMSIS-DAP protocol.

Can you actually program a SAM21 (or similar) using a generic JTAG/SWD dongle e.g. using OpenOCD (which supports them)?

Yes, of course, as long as OpenOCD supports the part.

[janoc]

I don't have first hand experience with Atmel ARM chips but their AVRs and XMegas have the debug protocols closed/undocumented. And if you want to program using JTAG (on parts that have it), it is the same story, the information necessary to implement is available only under NDA to partners.

But we are not taking about AVRs and XMegas.

Yes, correct - I have assumed the Atmel's ARMs are similar in this regard.

Can you actually program a SAM21 (or similar) using a generic JTAG/SWD dongle e.g. using OpenOCD (which supports them)?

Yes, of course, as long as OpenOCD supports the part.

OK, good to know. That may actually make me look at them again in the future.

[matseng]

If you have swd connections, what prevents you from using those clk/dat pins as tx/rx for a bootloader? I don't know the samd20 pin/peripheral multiplexing scheme, but it wouldn't surprise me if you could get a serial port to work on those pins. A bootloader solution may end up being more work than an swd solution, but I don't think the bootloader option goes away just because you have some connector labeled as swd.

Now I feel extra stupid... ;-(  I knew that the two SWD pins could be used as GPIO, but I didn't bother to check if they could be muxxed to something else, I just assumed that they basically were more or less dedicated for SWD.  But it turns out that I can mux in SERCOM1:2 and :3 to the pins. Luckily TX supports :0 and :2 and RX can use any of :0/1/2/3 so it seems to be good to go for a bootloader then.

But reading about the discussion about the CMSIS-DAP, EDBG and OpenOCD it seems that I've got a lot to learn about the lower level ARM stuff.

Thanks for all your input in this issue....

[thm_w]

I wonder if those ST-Link clones can be flashed J-Link OB firmware... I know that is running against their EULA really.

Yes, but its not worth the risk (to send it out) when blackmagic probe software is capable of programming them as well.
https://madnessinthedarkness.transsys.com/blog:2017:0122_black_magic_probe_bmp_on_st-link_v2_clones

[SiliconWizard]

OpenOCD has support config for SAMD chips, and works with many jtag probes, such as the FTDI-based ones which are cheap.