3

I compiled openocd from git (latest commit: March 7, 2021) with --enable-cmsis-dap.

openocd cannot open my CMSIS-DAP device:

openocd -f interface/cmsis-dap.cfg -f target/max32660.cfg
Open On-Chip Debugger 0.11.0+dev-00056-g6448f70-dirty (2021-03-20-23:58)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: unable to find a matching CMSIS-DAP device

Warn : Flash driver of max32xxx.flash does not support free_driver_priv()

USB setup is fine. See, pyocd finds the CMSIS-DAP just fine:

pyocd cmd --target MAX32660
Connected to MAX32660 [Running]: 044400006fed0cc900000000000000000000000097969904
>>>

So how can openocd not find it?

Also, openocd used to be able to find it. How can it change its mind?

Here is more debug output around openocd's interaction with the CMSIS-DAP device:

Debug: 108 14 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x10c4:0xea60
Debug: 109 15 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0d28:0x0204 'DAPLink CMSIS-DAP'
Debug: 110 15 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0d28:0x0204
Debug: 111 15 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 0, endpoint[0] is not bulk out
Debug: 112 16 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 3 string 'CMSIS-DAP'
Debug: 113 16 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 3, endpoint[0] is not bulk out
Debug: 114 16 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 1, has only 1 endpoints
Debug: 115 16 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 2, class 10 subclass 0 protocol 0

Looks to me like it "found" the device? So what is the problem then?

Update: If I unplug and replug the CMSIS-DAP, then it works. But it seems that after running a few commands in pyocd (which generally works better than openocd) then openocd has this problem again. So, kind of a workaround, but painful.

personal_cloud
  • 317
  • 4
  • 11
  • 1
    I've had bad problems like this that were cured by swapping to a different USB cable... maybe some kind of wear issue... The fact that it had been working previously, suggests that something in the setup changed; if it never had worked then that would suggest wrong configuration. But if yesterday it worked and today it does not, and yet nothing obvious was changed, then maybe something wore out or there is an intermittent connection like a "cold solder" connection. – MarkU Mar 21 '21 at 09:57
  • @MarkU That makes sense. USB is a very flaky technology, so I can see how it could start to develop an issue that affects one piece of software but not another. There's a reason you have to pay $400 to go over 16 feet... the $100 extenders work for most software and devices, but cause various glitches that appear to affect specific devices and software more than others. Makes sense. USB was designed only for mass-market products made by companies that have hundreds of engineers to get everything within tight specs. Very different from, say, RS-232 or even Ethernet. – personal_cloud Mar 22 '21 at 17:20
  • Scripts for Maxim Microcontrollers in mainline openocd are buggy. Download Maxim Micros SDK from Maxim website and use Openocd compiled by Maxim with their scripts. For MAX32660 and Linux: https://www.analog.com/en/design-center/evaluation-hardware-and-software/software/software-download?swpart=SFW0018720A – Misaz Jan 08 '23 at 10:49

1 Answers1

1

Replugging the USB cable works. However, as flaky as USB generally is, this particular problem is not a USB issue. It is a bug in openocd that is addressed by a helpful utility in pyocd (if you knew to look for it there). From the pyocd command reference:

Usage: exit

Terminate running gdbservers in this session. For the pyocd gdbserver subcommand, terminating gdbservers will cause the process to exit. The effect when the gdbserver(s) are running in a different environment depends on that program. Note that gdb will still believe the connection to be valid after this command completes, so executing the ‘disconnect’ command is a necessity.

Note: you have to actually type exit; control-D does not actually do the same thing! I would guess that "that program" is referring specifically to openocd, which has trouble initializing the USB device if it wasn't previously in a perfect state.

Just write a shell script that does the following before starting openocd:

echo exit | pyocd cmd --target max32660
sleep 0.5
personal_cloud
  • 317
  • 4
  • 11