# How to update the SWDAP firmware?

## 1. About the SWDAP probe

I bought an SWDAP probe some time ago from L-Tek (see https://www.l-tek.com/web-shop/l-tek-swdap-interface/). It took me some time to figure out the terminology, but I learned that:

• CMSIS-DAP is a standard defined by ARM. All probes that comply with this standard can flash and debug ARM target chips.

• SWDAP is an open-source probe, built by ARM. In fact, it's a reference hardware-implementation of the above mentioned standard. The SWDAP is sold by L-Tek and is based on a NXP LPC11U35 chip. (See https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/tree/master/DAPLink/Probes/SWDAP).

• DAPLink is an open-source firmware (written by ARM) that runs on the SWDAP probe. It is the reference software-implementation of the above mentioned standard. (See https://github.com/ARMmbed/DAPLink).

## 2. Firmware update

I would like to update the firmware on my SWDAP probe. In other words, I want to flash the latest DAPLink firmware to my SWDAP probe.

I don't see a proper explanation how to do this.

2.1 First try
-----------------
I found the following webpage:
But this webpage is a two year old blogpost. The binaries it links to are certainly deprecated.

2.2 Second try
----------------------
Thank you @RonBeyer for your answer. I clicked on your link (https://os.mbed.com/platforms/SWDAP-LPC11U35/) and noticed there are indeed some Prebuilt Images (binaries), but only for:

• NXP K64F
• NXP LPC1768
• Nordic nRF51822
• Multitech xDOT

Unfortunately, the NXP LPC11U35 is not in that list. Anyhow, I downloaded all of the binaries, and guess what their names are:

• NXP K64F => lpc11u35_swdap_k64f_if_crc.bin
• NXP LPC1768 => lpc11u35_swdap_lpc1768_if_crc.bin
• Nordic nRF51822 => lpc11u35_swdap_nrf51822_if_crc.bin
• Multitech xDOT => lpc11u35_xdot_l151_if_crc.bin

So this confuses me even more. I have no idea which binary I should flash to the probe.

2.3 Third try
------------------
Thank you @RonBeyer for clarifying the naming convention of these binaries:

[Version] _ [Probe Chip] _ [Target Chip]_ [Offset].bin

Also many thanks for pointing out the webpage where to find the latest binaries for the SWDAP probe:

From the releases page, just scroll down a little bit until you see ">Assets" right under the "notes" part and expand that. You will see a download link for the release.

It seems natural to have a different binary per Probe Chip. But it is striking to have different binaries for the Target Chips, especially because the SWDAP probe aims to work for all ARM targets (all targets that follow the CMSIS-DAP standard). Therefore, I developed my own theory about this thing:

• If you want a general SWDAP probe, take the binary without [Target Chip] in the name. So for my probe that would be 0254_lpc11u35_0x0000.bin with 0254 being the version nr, lpc11u35 the probe chip and 0x0000 the standard offset. The drag-and-drop feature* from this general SWDAP probe doesn't work. But if you use OpenOCD to flash the target, then it will always work.

• If you want to use the drag-and-drop feature*, then choose the binary that corresponds to your specific target chip.

* The drag-and-drop feature makes the SWDAP probe appear as a MSD (Mass Storage Device) when you plug it into your computer. To flash the target chip, you simply have to drag-and-drop the binary file to that MSD.

This is just a theory of mine. Please help if you got more insight into the matter.
EDIT: Apparently, this theory is correct. Thank you @ChrisReed to clarify that ^_^

So... Now that I finally got the right binary file 0254_lpc11u35_0x0000.bin I am totally ready to flash it to the probe.

STEP 1
I plug in the probe while holding the reset button down. As soon as it is plugged in, Dropbox pops up and asks me to import stuff. I click No, but it makes me hopeful that some kind of storage device is recognized. I open the Windows File Explorer, and I see the "CRP Disabled" device:

STEP 2
Only now that I see the "CRP Disabled" device, I dare to release the reset button on the SWDAP probe. I click on the "CRP Disabled" device to see its contents:

STEP 3
I delete the firmware.bin file from the probe (but I first save a backup of it somewhere on my computer). And yes, I am sure:

STEP 4
I copy-paste the new firmware 0254_lpc11u35_0x0000.bin to the probe:

STEP 5
I plug out the probe, and plug it back in (this time not touching the reset button). The first time I did this, I got a little Windows announcement in the right down corner that CMSIS-DAP was being installed. But from the second time onward, that announcement no longer appears. However, I can see the device in:
Control Panel > Hardware and Sound > Devices and Printers

STEP 6
I connect the SWDAP probe to my target board (a small board with a STM32F767ZI microcontroller). Now I run OpenOCD to flash a binary to the target chip. It doesn't work!
I use the exact same OpenOCD commands that I used before updating the SWDAP firmware. It used to work before that update. But now it fails over and over again. I get the following error from OpenOCD:

Error: CMSIS-DAP command CMD_INFO failed.

2.4 Restore original firmware
------------------------------------------
Luckily I had taken a backup from the original firmware.bin on the probe. I now follow the steps described above again, this time to restore the original firmware.

To my great relief, I can again flash my target board using OpenOCD.

## 3. Conclusion

With the help from @RonBeyer and @ChrisStratton, I managed to flash the SWDAP probe with the latest DAPLink firmware 0254_lpc11u35_0x0000.bin. Unfortunately, this causes the probe to malfunction with OpenOCD. Luckily I had kept a backup from the original firmware on the probe. Restoring that backup brings the probe back to live.

The purpose of this question is fulfilled: I can flash new firmware to the probe. The new problem that arised is about the firmware itself. I've opened a separate question for that problem: DAPLink firmware doesn't operate with OpenOCD

## 4. Notes

🖒 Thumbs up for ARM, and for @ChrisReed who replied very quickly on my GitHub issue that I raised on DAPLink! He clarified to me that all binaries with a specific "target chip" in the name should actually work for all target chips, provided that you don't use the drag-and-drop functionality.

• As the documentation isn't making any sense, you probably need to either ask the vendor or figure it out yourself from the linked github sources. Oct 31 '19 at 15:50
• Why specifically do you need to update the firmware? Does it already work? If not, what change are you hoping for? How does the board currently identify itself when connected to a PC? Oct 31 '19 at 15:57
• Hi @ChrisStratton, right now the probe works just fine. But I want to know how to update this probe. In the future, the DAPLink firmware will certainly support new target microcontrollers, and I want to be prepared :-) Oct 31 '19 at 15:59
• You seem to be coming at this from a mistaken perspective - DAP doesn't support new target microcontrollers, the host PC software does (that's the whole point - it is a "low level" adapter that keeps all the target knowledge on the PC). Anyway, you ignored the question about how it currently identifies - figuring that out might be a clue. Oct 31 '19 at 15:59
• Hi @ChrisStratton, thank you for this clarification (I'm pretty new to DAP and DAPLink). Nevertheless, I just want to know how to do the firmware upgrade. It just doesn't feel right I cannot do that. Oct 31 '19 at 16:01

From the mbed page for the product:

## Reprogramming SWDAP

When a new SWDAP is plugged in to your machine, it will not contain valid any firmware, and so will appear as a disk drive called "CRP Disabled" as.

To program the SWDAP, follow these steps:

• Open the drive, and delete the file called "firmware.bin"
• Copy the .bin file onto the "CRP Disabled" drive.
• On Windows, replace firmware.bin with the above firmware
• On Linux/Mac, use command: dd if={new_firmware.bin} of={firmware.bin} conv=notrunc
• Unplug your SWDAP, and plug it back in
• It should now appear as a disk drive called DAPLink

You can re-program your SWDAP at any time by plugging it in with the button held down. This will cause it to appear as the "CRP Disabled" drive, at which point you can follow the steps above.

It would seem that you want to start at the highlighted step (my emphasis) and then begin the procedure at the top. The link to download the firmware is on the page linked at the top of this answer.

When you download the release*, you will see quite a few files:

The file naming format is:

[Version]_[Board Name]_[Target Name]_[Offset].bin

So you would pick the appropriate firmware file for both the board (LPC11U35) and the target that you are programming. For example if your target board is the LPC812-LPCXpresso Board you would select the 0254_lpc11u35_lpc812xpresso_0x0000.bin file.

*Releases page: https://github.com/ARMmbed/DAPLink/releases . From the releases page, just scroll down a little bit until you see "> Assets" (right under the "notes" part) and expand that. You will see a download link for the release.

• Hi @RonBeyer, Thank you for your answer. Unfortunately it is still unclear to me which prebuilt binary I should flash (see EDIT in my answer). Please enlighten me. Oct 31 '19 at 15:52
• @RonBeyer - just because it's firmware for the chip on the board, doesn't mean it's firmware for the board in question. Which specific download on your linked page are you arguing is appropriate for the asker's board? Oct 31 '19 at 15:54
• "LPC11U35" is a chip. Not a board. Again, which of the listed images is appropriate to the asker's board? You don't know, because that information is not available on the page you linked to. It's quite possibly any of them will work, but there's no information there to indicate that, or to indicate that they will not brick the board (though hopefully that is unlikely). Oct 31 '19 at 16:08
• The board requires different firmware depending on the target that it is programming. Any of the LPC11U35 firmwares will work, however the appropriate depends on what it is programming. I can't say specifically because the OP did not provide that information. So the appropriate firmware depends on both the DAPLink board (this one is LPC11U35 based) and the target board. Oct 31 '19 at 16:13
• "The board requires different firmware depending on the target that it is programming" the whole point of the DAP idea is that it should not. It's possibly that mbed is doing something silly and making its USB identification target specific. But the legitimate reason for a different firmware would be if the LPC11U35 is wired up in different ways when "captive" on eval boards with various targets. Oct 31 '19 at 16:30