Last release v0254 crashes with OpenOCD

[kristofmulier]

1. Problem with v0254 release

I just flashed the latest firmware 0254_lpc11u35_0x0000.bin to my SWDAP probe, which I have downloaded from the latest release. Windows properly recognizes the probe as a CMSIS-DAP device (Control Panel > Hardware and Sound > Devices and Printers). But the probe malfunctions with OpenOCD. After restoring the original firmware, the probe works again with OpenOCD.

Some details:

• OpenOCD version: 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
• Operating System: Windows 10, 64-bit
• SWDAP probe: The official one, bought from L-Tek (https://www.l-tek.com/web-shop/l-tek-swdap-interface/)

The OpenOCD error is:

Error: CMSIS-DAP command CMD_INFO failed.

For more info, please read my StackOverflow posts here:     - How to update the SWDAP firmware? [solved]
    - DAPLink firmware doesn't operate with OpenOCD [not yet solved]

2. Problem with older releases

I just downloaded the .zip file from the v0253 and v0252 releases. Unfortunately, there is no generic xxxx_lpc11u35_0x0000.bin binary. They are all target-specific. I want to flash a generic binary to my probe, such that it can work with any target chip.

[flit]

0254 bug

Thanks for the report! I'll try to reproduce as soon as I get a chance, probably this weekend.

What target MCU are you using? It shouldn't matter but might as well clarify.

Older releases

Any DAPLink release will work with any target when driven by the host via CMSIS-DAP. The target-specific part of a firmware binary applies only to USB mass storage flash programming. So you can pick an arbitrary firmware for the LPC11U35 HIC (Hardware Interface Circuit, the probe circuit) and it will work fine. Just don't try using mass storage flash programming if the target doesn't match the one you're connected to.

We only started providing "no-target" or standalone builds in 0254.

Docs

And apologies that you had such trouble figuring out the terminology… I'll try to write an overview doc that answers all the questions you raised on StackOverflow. This will appear in the DAPLink docs directory.

Plug

(Shameless plug) Have you tried pyOCD instead of OpenOCD? It's generally much easier to use than OpenOCD, and supports nearly all Cortex-M devices through CMSIS-Packs (notwithstanding occasional bugs or device weirdness).

[kristofmulier]

Hi @flit , Thank you very much for your quick reply!

1. Target chip

The target chip I'm using is the STM32F767ZI from STMicroelectronics. I've soldered it myself on a self-designed board. That board has a 10-pin Cortex debug connector for the SWD connection.

2. Older releases

Thank you very much for your clarifications. It's a good idea to provide a "no-target" binary, because some people (like me) want to use the SWDAP probe for all sorts of targets. If we have to pick a binary with a specific target chip in the name, we get confused ;-)

3. Docs

Thumbs up for your plans to write an overview doc! That is very much appreciated ^_^

4. Plug

I haven't tried pyOCD yet. It's on my TODO list. Currently, we use plain OpenOCD for our startup Embeetle IDE (https://embeetle.com). Adding pyOCD would certainly be a big plus. 
 

Note: I've added a page about the SWDAP probe on our Embeetle IDE website: https://embeetle.com/#hardware/probes/swdap
Thank you very much for your quick reply. I am very grateful for your help! Please feel free to use my screenshots from the StackOverflow question in your docs, if that would be helpful ;-)

[flit]

Thanks for the info. 😄 I'll try to test out OpenOCD with DAPLink over the next couple days.

[RadioOperator]

@kristofmulier Hi, your system worked ok before you update v0254?

[kristofmulier]

Hi @RadioOperator , Yes, the SWDAP could flash to my target STM32F767ZI chip with OpenOCD. When I updated the SWDAP firmware to v0254, it malfunctioned (OpenOCD showed an error). Then I flashed again the original firmware to the SWDAP, and it works again.

You can read more details on my StackOverflow questions:     - How to update the SWDAP firmware? [solved]
    - DAPLink firmware doesn't operate with OpenOCD [not yet solved]

[kristofmulier]

Hi @flit , I've tested not only firmware v0254 but also v0253 and v0252. They all fail with OpenOCD, but their failures are different. I've explained everything in great detail on StackOverflow:

    - How to update the SWDAP firmware? [solved]
    - DAPLink firmware doesn't operate with OpenOCD [not yet solved]

Thank you very much. Kind regards, Kristof

[0xc0170]

I wonder if this bug is on our side or openOCD, will see. I looked at the openOCD sources, can see this was the change for the info phase (http://openocd.zylin.com/gitweb?p=openocd.git;a=commitdiff;h=6cae70ccef707ff6e1023893334204d4ee38ca43). I wonder if it would be worth trying older openOCD, just to be sure.

You don't have sources for the old firmware that works? what version of daplink was it

What is the retval here : https://github.com/ntfreak/openocd/blob/0cba5b4ea30a436e1ab381b374ea89743a23e09c/src/jtag/drivers/cmsis_dap_usb.c#L500 ? I can see there many log_errors you should be getting, what is actually failing in this info phase?

[kristofmulier]

Hi @0xc0170 , I've documented everything I know in my StackOverflow question: DAPLink firmware doesn't operate with OpenOCD

For the firmware v0254 version, I get the following OpenOCD error:

Error: CMSIS-DAP command CMD_INFO failed.

But I have no idea what is happening in the background causing this failure.

For the firmware v0253 and 0252, I get the following OpenOCD 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

For some uknown reason, OpenOCD terminates after the last line Info : clock speed 2000 kHz without showing any error. Normally OpenOCD should start a Telnet and GDB server, but that doesn't happen.

For more info on the OpenOCD startup commands and the config files I'm using, please visit my StackOverflow question DAPLink firmware doesn't operate with OpenOCD.

[cederom]

Hey @kristofmulier have you tried https://github.com/mbedmicro/pyOCD ? DAPLink works amazingly well with pyOCD. pyOCD has lots of advantages over OpenOCD which I was using a lot back then around 2009..2013. Why do you still stick to the OpenOCD when there are better solutions? :-)

[cederom]

My response on StackExchange, as above. I hope to convince you to the dark side, so you start working with pyOCD :-)

https://electronics.stackexchange.com/questions/465577/daplink-firmware-doesnt-operate-with-openocd/465821#465821

[kristofmulier]

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.

[djix123]

In case people are still having trouble with this, adding the following lines to 'cmsis-dap.cfg' allowed the latest openocd to work for me:

cmsis_dap_vid_pid 0xc251 0xf001 cmsis_dap_backend hid

this forces openocd to use the adaptor on the vid/pid specified and not attempt to find one using text identification, bypassing the reported issue.

[mbrossard]

@djix123: we have other report that upgrading to openocd 0.11.0 solved many issues with 0254, because it supports the CMS-DAPv2 through the bulk endpoint.

[djix123]

@mbrossard: thanks - yes, I was hoping that was the case, but openocd 0.11.0 alone didn't fix the issue for me.

I bought one of these from eBay:

https://www.ebay.com/itm/184832012014

Its a Muse Labs clone. Looks like they sell two versions. One with the HID API only and one with HID API + bulk endpoint. I bought the HID API only (cheaper!). The version reported by the device fails to be recognized by openocd 0.11.0 so based on this thread and then reading the openocd cmsis-dap enumeration code realized I could force its recognition with the two additions above to the cmsis-dap.cfg file.

[flit]

There might be two problems here?

For DAPLink 0254, it seems the change where it reports the DAPLink version for DAP_Info value 0x04 instead of the CMSIS-DAP protocol version may be causing issues with OpenOCD. This change was motivated by unclear DAP_Info documentation that is now corrected. Recent builds of DAPLink, and the upcoming 0256 release, fix this (and return the DAPLink version in the new value 0x09 dedicated for this purpose). Although, if OpenOCD is looking for CMSIS-DAP protocol versions, it may still fail because DAPLink is now returning version "2.1" for that.

For the issue reported by @djix123, I'm not sure if that's DAPLink. The USB VID/PID 0xc251/0xf001 is not the VID/PID used by DAPLink, although someone could have changed it. There is quite a lot of confusion on the web mixing up the terms "CMSIS-DAP" and "DAPLink": CMSIS-DAP is a protocol specification, DAPLink is debug probe firmware that includes support for the CMSIS-DAP protocol; there are many implementations of CMSIS-DAP that are not in any way related to DAPLink, yet often people still call these "DAPLink".

Since we don't have one of these probes to test, it's not clear what firmware it's running. You should be able to tell by looking at a "DETAILS.TXT" file on the probe's USB mass storage volume. If it doesn't have an MSD volume, it may or may not be DAPLink—"no-target" builds of DAPLink starting with v0254 disable MSD support. If there is an MSD volume but no "DETAILS.TXT" file, it's definitely not DAPLink.

[kristofmulier]

Hi @flit , I can send you the official SWDAP probe: https://www.l-tek.com/web-shop/l-tek-swdap-interface/

This probe is ARM's reference design of the CMSIS-DAP standard. Therefore, it's the ideal hardware to test the DAPLink firmware on.

You can contact me here: https://new.embeetle.com/#contact

My name is Kristof Mulier. My mail address is shown there.