1
\$\begingroup\$

 
Why this is not a duplicate
Some people seem to think this question is a duplicate, but there is an important difference:

  • The How to update the SWDAP firmware? question is all about how to update the firmware to the SWDAP probe. In the end we got a solution. The purpose of that question is therefore fulfilled. (I've edited the conclusion-section of that question to clarify this).

  • The question on this page is all about what firmware is being put on the probe - and more in particular - what is wrong with that firmware such that it malfunctions with OpenOCD.

Please take your time to read both questions completely (not just the titles) if you think this question is a duplicate.

 

1. Intro

1.1 SWDAP probe
I'm experimenting with the SWDAP probe from ARM (see https://www.l-tek.com/web-shop/l-tek-swdap-interface/). This flash/debug probe supports all Cortex-M microcontrollers. It uses the SWD protocol instead of JTAG.

enter image description here

At first I had some trouble updating the probe's firmware, but that has been solved in my previous question (see How to update the SWDAP firmware?). The firmware on the probe itself is named "DAPLink" (see https://github.com/ARMmbed/DAPLink).

1.2 My system
My computer has following software:

  • Windows 10, 64-bit
  • OpenOCD 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)

 

2. Test with original firmware

The probe arrived to me with some firmware on it. I've plugged the probe into my computer while holding down the reset button. This way, I could access firmware.bin and save a copy of it as a backup.

On the original firmware, the probe works perfectly with OpenOCD. This is my OpenOCD startup command:

openocd -f probe_swdap.cfg  -f chip_stm32f767zi.cfg
        -s "C:/.../scripts" -c "init; reset halt"

Note 1: I've splitted the command over two lines for readability.
Note 2: C:/.../scripts represents the path to the scripts subfolder in my OpenOCD installation folder.

This is my probe_swdap.cfg file:

# OpenOCD probe config file for SWDAP
source [find interface/cmsis-dap.cfg]
transport select swd

And here is my chip_stm32f767zi.cfg file:

# OpenOCD config file for STM32F767ZI
source [find target/stm32f7x.cfg]
reset_config srst_only

After running the OpenOCD startup command (see above), I get the following output in my console:

Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x5ba02477
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : stm32f7x.cpu: external reset detected
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001848 msp: 0x20080000
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

This works perfectly. OpenOCD listens on port 3333 for GDB connections. So next thing I do is starting a GDB client and connect to OpenOCD. Then I can start flashing/debugging my target STM32F767ZI chip. All is well.

 

3. Test with newest v0254 firmware

I'll first say a word about the firmware name convention. You can download the latest firmware from the DAPLink GitHub page. The names have a specific meaning:

[Version] _ [Probe Chip] _ [Target Chip] _ [Offset].bin
more info see How to update the SWDAP firmware?

The Probe Chip must match the chip on the probe itself. For me, that's the LPC11U35. The Target Chip must only match the target chip if you're planning to use the drag-and-drop flashing feature. I'm just using OpenOCD, so this Target Chip field doesn't matter to me.

The v0254 version has a "general" 0254_lpc11u35__0x0000.bin firmware, being "target-agnostic". As I'm not using the drag-and-drop flashing, this choice makes most sense to me. So I update the SWDAP probe with this firmware.

Unfortunately, OpenOCD crashes immediately:

Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Error: CMSIS-DAP command CMD_INFO failed.

I've used exactly the same OpenOCD startup command as before, with exactly the same config files. Something is wrong with the 0254_lpc11u35__0x0000.bin firmware.

 

4. Test with v0253 firmware

There is no "general" 0253_lpc11u35__0x0000.bin firmware. All are target-specific. But that doesn't matter because I'm not going to use the drag-and-drop feature anyway.

I chose 0253_lpc11u35_6lowpan_borderrouterethernet_0x0000.bin and flashed it to my probe. I plug out the probe and plug it back in. Now I start OpenOCD with the same commands as before. I get the following output:

Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 2000 kHz

In fact the output looks good. It's the exact same output I get with the original firmware up to the Info : clock speed 2000 kHz line. But after that line, OpenOCD stops. It doesn't hang, it just terminates (this is clear because I get a new prompt in my console).

Something else that I noticed is the DAPLINK drive showing up in my Windows file explorer:

enter image description here

That didn't happen with the original firmware, nor with v0254.

 

5. Test with v0252 firmware

For this test, I put the 0252_lpc11u35_tiny_0x0000.bin firmware on my probe. I get the exact same output as with the v0253 firmware:

Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
swd
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 2000 kHz

OpenOCD terminates after the Info : clock speed 2000 kHz line (again).

Also this time, I notice the DAPLINK drive in my Windows file explorer as soon as I plug in the probe.

 

6. Conclusions

I conclude that:

  • Original firmware works just fine with OpenOCD.
  • Firmware 0254_lpc11u35 ... .bin is plain dead. OpenOCD crashes immediately.
  • Firmware 0253_lpc11u35 ... .bin is half-dead. OpenOCD terminates after outputting a few good lines. Also a DAPLINK drive appears in Windows.
  • Firmware 0252_lpc11u35 ... .bin reacts just like v0253.

I think firmware v0254 is defunct. But I don't want to jump into conclusions about firmware v0253 and v0252. Perhaps I need to issue a different startup command in OpenOCD to get them working? Or maybe I need to change something in my probe's config file?

\$\endgroup\$
5
  • \$\begingroup\$ You have done a great job of documenting your problem, but wouldn't it be best to contact L-Tek about their probe? It sounds like your problem is very specific to that device and its firmware. Also, I would try using a different computer to see if your drivers or OpenOCD have somehow gotten corrupted. \$\endgroup\$
    – Elliot Alderson
    Commented Nov 3, 2019 at 12:56
  • 1
    \$\begingroup\$ Possible duplicate of How to update the SWDAP firmware? \$\endgroup\$
    – Elliot Alderson
    Commented Nov 3, 2019 at 13:05
  • \$\begingroup\$ Hi @ElliotAlderson, I understand you point about the duplicate. I've edited the other question to differentiate it better from this one. I've also added the section 7. Why this is not a duplicate in this question to explain the difference better. Thank you for your suggestions. \$\endgroup\$
    – K.Mulier
    Commented Nov 3, 2019 at 15:22
  • \$\begingroup\$ Hi @ElliotAlderson, I've already tried to contact L-Tek, but they did not yet respond. However, the probe L-Tek made is completely based on the open-sourced hardware project from ARM: the SWDAP project (see github.com/ARMmbed/mbed-HDK/tree/master/…). Along with this open-source hardware, ARM also provides the open-source firmware DAPLink (github.com/ARMmbed/DAPLink) to run on that hardware. Both should operate seamlessly together. \$\endgroup\$
    – K.Mulier
    Commented Nov 3, 2019 at 15:24
  • \$\begingroup\$ Hi @ElliotAlderson, my drivers of OpenOCD are fine. Everything works with the original firmware on the SWDAP probe. And other probes (Black Magic Probe, STLink, ...) all work perfect with OpenOCD too. So it has to be the new DAPLink firmware. \$\endgroup\$
    – K.Mulier
    Commented Nov 3, 2019 at 15:27

2 Answers 2

Reset to default
2
+50
\$\begingroup\$

Have you tried pyOCD? It works flawlessly with DAPLink, has great support and community directly on GitHub, it is written in Python, works on any platform, can utilize modular approach of CMSIS Pack Manager to support hundreds of targets just by downloading their specifications, can Debug MultiCore, can Flash rapidly using FlashAlgo skipping pages that does not need rewrite, and it is optimized to work with DAPLink. It works out of the box on anything that has Python Virtualenv no compilation required (or is done in the background by pip). Why do you even bother with OpenOCD and something that was not really meant there? Do you still script with TCL in a binary C based application? Can you understand how much power you get when all application is written in Python and you can reuse anything as module in your own application? I have used OpenOCD along with UrJTAG and even developed LibSWD around 2009..2013 but DAPLink+pyOCD feels like next generation tool we even did not dream about back then. You may also try the ARM MBED-OS :-)

\$\endgroup\$
15
  • 1
    \$\begingroup\$ This is a giant tangential comment rather than an answer to the question asked. Do you have any actual evidence or reason to believe pyOCD would yield a different result? Remember, the asker's probe worked just fine with OpenOCD using the original firmware, the issue only arose when they foolishly insisted on reflashing it with something else having less than clearly documented functionality and promising no apparent benefit whatsoever. \$\endgroup\$
    – Chris Stratton
    Commented Nov 5, 2019 at 2:16
  • 2
    \$\begingroup\$ Negative. There is a lot of confusion in this thread. First of all the DAPLink is "the original" firmware and the problem may indicate a regression in recent release. Second of all, no question is asked if DAPLink works with OpenOCD, just a statement that it does not, which may imply false assumption that it does not work at all, which is then negated with an incomplete statement that it "may" work with an older release, which is neither a statement nor question, more like a comment with unclear goal. I would suggest if it does not work fix it and send the patches over GitHub :-) \$\endgroup\$
    – CeDeROM
    Commented Nov 5, 2019 at 2:47
  • 1
    \$\begingroup\$ Third of all, DAPLink is actively developed by ARM MBED team that also develops DAPLink and MBED-OS, so this is part of the same ecosystem used by thousands of people around the world as well as amazingly complex CI infrastructure to test every single firmware change on a hundreds of a real world hardware, so yes this is actual evidence that DAPLink+pyOCD works flawlessly. You are provided with references to try out yourself all is Free-and-Open-Source-Software :-) \$\endgroup\$
    – CeDeROM
    Commented Nov 5, 2019 at 2:48
  • 1
    \$\begingroup\$ "Because it is optimized for pyOCD and tested for pyOCD". I have developed both OpenOCD and DAPLink/pyOCD. If you have time, sure you can play. But there is far better tool right next to you that you can simply use in order to create something new, more advanced, and learn a lot more. I have provided a solution to a problem, up to you what you make out of it. Take care :-) \$\endgroup\$
    – CeDeROM
    Commented Nov 5, 2019 at 3:06
  • 3
    \$\begingroup\$ Hi @ChrisStratton and CeDeROM, please stop fighting. Both of you have a point. (1) Technically speaking, this answer doesn't solve the problem. I will still look out for a solution with OpenOCD. (2) Nevertheless, this answer is very useful to me. We will at some point add PyOCD to our new IDE, and I am grateful for CeDeROM his efforts to list all the PyOCD resources and the clear overview of OpenOCD vs PyOCD. A big thank you to Mr. CeDeROM and a big fat +1 on your answer! \$\endgroup\$
    – K.Mulier
    Commented Nov 5, 2019 at 7:38
1
\$\begingroup\$

I got the following reply from Antonio Borneo per mail:

Hi Kristof,

I have seen the messages about the daplink issue, but without the adapter I though I cannot do that much, so I dropped it.

I have read again all the threads (very quickly, I have to admit) and also downloaded the daplink code from https://github.com/armmbed/DAPLink It is a special implementation of CMSIS-DAP for mbed.

The original FW you had in your board was a v0244 or older, because OpenOD recognizes it as Info : CMSIS-DAP: FW Version = 1.0 This string has been changed in DAPLink FW file source/daplink/cmsis-dap/DAP.c with commit https://github.com/ARMmbed/DAPLink/commit/48417e9f8541f51bf2ca2e26a7ee69c5fcb34b80
so the newer FW you have tested v0252 and v0253 report Info : CMSIS-DAP: FW Version = 1.10 and both do not work with OpenOCD. I don't have a cmsis-dap v1.10 to verify if there is already something wrong in OpenOCD.

The DAPLink FW v0254 adds many changes. Between them it stops reporting the CMSIS-DAP version "1.10", reporting instead the DAPLink version "0254".

Checking the code of DAPLink, looks like it is possible to recompile it for STM32F103 (ST-Link)! Maybe I will have a look at it using an old Nucleo board, but it will depends on my spare time.

Or maybe some other OpenOCD developer could take this reply as a hint. Antonio

It doesn't completely solve the problem yet, but it gives valuable hints. Thank you @Antonio.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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