Electronic – How to update the SWDAP firmware

armdebugginglpcmicrocontrollerprobe

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:
https://os.mbed.com/blog/entry/DAPLink-bootloader-update/
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:

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

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.

Best Answer

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"

Download the required image from the table above (or build your own using DAPLink project)

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

Related Solutions

Cortex M3 debugging: Intermittent partial load of binary with pyOCD, then timeout

I have a (band-aid) fix for the issue and two guesses for what might be the underlying cause. I'll give my fix first.

(Disclaimer: I'm not very knowledgeable about pyOCD or pyusb and my fix here was purely heuristically derived. This fix may very well screw up some other functionality of pyOCD or pyusb.)

Increase the pyusb serial write timeout. I'm not sure what the default timeout is, but I got roughly the same failure frequency when I set the write timeout to 1000ms. 2000ms seemed long enough to consistently succeed.

Here's where to change the timeout. Note that I installed pyusb and pyOCD with pip in the default locations on Ubuntu 14.04, which put the file at /usr/local/lib/python2.7/dist-packages/usb/core.py.

Function self.device.write(), at core.py:349 (part of pyusb 1.0.0rcl).

Before (full function for context):

def write(self, data, timeout = None):
    r"""Write data to the endpoint.

    The parameter data contains the data to be sent to the endpoint and
    timeout is the time limit of the operation. The transfer type and
    endpoint address are automatically inferred.

    The method returns the number of bytes written.

    For details, see the Device.write() method.
    """
    return self.device.write(self, data, timeout)

After (only change is default timeout value):

def write(self, data, timeout = 2000):
    r"""Write data to the endpoint.
    [ ... ]
    """
    return self.device.write(self, data, timeout)

Now for my guesses about the underlying issue.

I'm running Ubuntu 14.04 as a guest VM via VirtualBox 5.0.0, so it may be that there's some extra latency to the USB endpoint since the USB device has to be mounted through the VM framework.
Some bug with pyusb, pyOCD, or the target firmware.

I suspect #1 more than #2. Testing a similar setup natively on Windows (pyocd_win), I don't have any loading timeout issues.

Electronic – How to start with STM32F103C8T6 board

As it comes to datasheets they are indeed divided. "Reference manual" is complex descriptions of how to do things, configuration and detailed considerations about the whole MCU. "Datasheet" is on the other hand only a brief description of MCU features, pinouts, packages etc. There is also very helpful document for every STM32 line (F1,2...7) "Getting started with STM32F7xxxx MCU hardware development" which provides you with many informations if case you would like to design a custom board. In comparison to AVRs, registers descriptions are sometimes put a bit aside from main description of particular chapter.
STM32CubeMX is not a library, just a useful program from ST, which enables you to set pinouts, its configurations, set systems clocks etc and then, at the end, generate a code and the whole project. The project can be generated specially for Eclipse (System Workbench for STM32) in which you just import this project and you're ready to go. The new library is HAL ("hardware abstraction layer") and try to use it. That's the new thing and sometimes it's hard to find examples on the Internet but don't teach your students outdated technologies. HAL is convenient to use and has documentation, so I think it's better choice.
Which library? Anyway it shouldn't be a problem to google them, I think.
Even if you would like to use only one OS (like Windows), Eclipse (AC6 = System workbench for STM32) is - I think - the best option. There is for example Keil's uVision 5 - but that's really terrible IDE - it lacks most of features IDE should offer (refractoring, click-and-search, proper error checking, finding references and many, many more). So, all in all, the Eclipse is pretty much the only reasonable choice for IDE for STM32.