CMSIS-DAP device not found using v0.10.0-20170124

[renaudcerrato]

Just received my ATMEL SAMC21 XPLAINED PRO, and I immediately tried to play with it: the first thing I noticed is that the OpenOCD version which came with my distribution (Ubuntu 16.04) didn't included the required board script. I lazily ripped it, and tried to flash a blinky demo:

$ openocd -f board/atmel_samc21_xplained_pro.cfg -c "program demo.elf reset exit"
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
...
Info : only one transport option; autoselect 'swd'
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 02.09.0169
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD IDCODE 0x0bc11477
Info : at91samc21j18.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000120 msp: 0x20002448
** Programming Started **
auto erase enabled
Error: Couldn't find part correspoding to DID 11010100
Error: auto_probe failed
** Programming Failed **
shutdown command invoked

Ok, fair enough, SAMC21 support have been added lately: I needed to upgrade OpenOCD to the latest version available.

$ /opt/gnuarmeclipse/openocd/0.10.0-201701241841/bin/openocd -f board/atmel_samc21_xplained_pro.cfg -c "program demo.elf reset exit"
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-19:18)
...
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device
Error: No Valid JTAG Interface Configured.

OpenOCD 0.9.0 is able to detect the CMSIS-DAP interface, but not the latest version? Running the above command using sudo didn't fixed it and confirmed that this is not a permission issue along with the following commands:

$ lsusb
...
Bus 003 Device 053: ID 03eb:2111 Atmel Corp. 
...
$ ls -l /dev/bus/usb/003/053
crw-rw----+ 1 root plugdev 189, 308 Apr 17 15:59 /dev/bus/usb/003/053
$ id
uid=1000(renaud) gid=1000(renaud) groups=1000(renaud),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),127(sambashare)

I'm stuck. I'm willing to help, but I've no idea how.

[renaudcerrato]

BTW, I tried adding cmsis_dap_vid_pid 0x03eb 0x2111 to the board script with no change.

[ilg-ul]

OpenOCD 0.9.0 is able to detect the CMSIS-DAP interface, but not the latest version?

unfortunately, personally I'm not using openocd at all, and I have no idea when interfaces are added/removed, and how to use them.

the script to build the openocd binaries is available at https://github.com/gnuarmeclipse/build-scripts/blob/master/scripts/build-openocd.sh, and I see that --enable-cmsis-dap is present.

if you think that other options are required, please let me know, and I can consider a new release.

[renaudcerrato]

Thanks for the feedback. I digged into the code, and even looked at the diff between both versions and I can't see what could be going wrong.

Using the debug option, I can clearly see that we're failing at cmsis_dap_usb_open()#L283 - but since the auto-detection loop above hasn't been really modified since 0.9.0 - it should have detected the "CMSIS-DAP" substring into the product string. It looks like more a libusb issue.

I'll try to build it.

[renaudcerrato]

As I suspected @ilg-ul, the problem lies inside the USB layer: by switching the hidapi backend from hidapi-libusb to hidapi-hidraw, the adapter is properly detected. When running on the libusb backend hid_enumerate() doesn't returns all HID devices.

In fact, the version shipped with Ubuntu 16.04 is using the hidraw backend:

$ ldd /usr/bin/openocd
...
        libhidapi-hidraw.so.0 => /usr/lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007f694ce8e000)
...

Shall we switch to the hidraw backend?

[ilg-ul]

can you be more specific what changes need to be considered for the build script? remember, we need a portable solution, that works for all platforms.

[renaudcerrato]

According to the hidapi documentation:

HIDAPI has four back-ends:
    * Windows (using hid.dll)
    * Linux/hidraw (using the Kernel's hidraw driver)
    * Linux/libusb (using libusb-1.0)
    * FreeBSD (using libusb-1.0)
    * Mac (using IOHidManager)

The hidraw backend is not available for FreeBSD, but your script doesn't support it anyway. You'll find below, the diff of my build-openocd.sh script:

diff --git a/scripts/build-openocd.sh b/scripts/build-openocd.sh
old mode 100644
new mode 100755
index 6069b71..dae5612
--- a/scripts/build-openocd.sh
+++ b/scripts/build-openocd.sh
@@ -1085,7 +1085,7 @@ then
 elif [ "${target_name}" == "debian" ]
 then
   HIDAPI_TARGET="linux"
-  HIDAPI_OBJECT="hid-libusb.o"
+  HIDAPI_OBJECT="hid.o"
 fi

 if [ ! -f "${install_folder}/lib/libhid.a" ]
@@ -1124,7 +1124,7 @@ then
     \
     PKG_CONFIG_LIBDIR="${install_folder}/lib/pkgconfig":"${install_folder}/lib64/pkgconfig" \
     \
-    make clean "${HIDAPI_OBJECT}"
+    make clean "${HIDAPI_OBJECT}" COBJS=${HIDAPI_OBJECT}

     # Make just compiles the file. Create the archive.
     # No dynamic/shared libs involved.

Not sure why hid_enumerate() doesn't returns that adapter using the libusb backend. This doesn't sounds like a libusb issue since I played with LD_LIBRARY_PATH to enforce the use of my system libraries (instead of the local ones), but I can be wrong.

I asked the openocd-devel mailing list if there's any reasons to prefer the hidraw backend over the libusb one as Ubuntu is doing.

[renaudcerrato]

As noted above, I've been discussing on the openocd-devel mailing list and following their suggestions I compiled against hidapi 0.8.0-rc1 and it worked using both backends! A few commits might make all the difference:

https://github.com/signal11/hidapi/commit/a991328721b3b39cbc90f562b87df0bb1eeaf5c4 https://github.com/signal11/hidapi/commit/ec24f931007d75e061d26d6f9705790913f72fa0

I'm not able to spend more time trying to fix the build script, hopefully you'll consider the move and do a new release.

[ilg-ul]

yes, I'll consider this for the next release, although it is a bit strange to use a version marked -rc1 that is several years old...

[renaudcerrato]

For sure. I should have noticed that Ubuntu 16.04 is shipping with libhidapi 0.8.0~rc1 (git20140201.3a66d4e+dfsg).

Thanks!

[ilg-ul]

I'm not able to spend more time trying to fix the build script

you were right, fixing the script for 0.8.0-rc1 was tricky.

please try the new build script and let me know if the resulting binaries are functional.

[ilg-ul]

I prepared a pre-release: https://github.com/gnuarmeclipse/openocd/releases/tag/gae-0.10.0-20170418

please confirm that the new version is functional in your environment. if possible, test both the 32-bits and 64-bits binaries.

[renaudcerrato]

Thanks! Indeed, both 32 and 64 bits pre-release versions are working! Congratulations!

[ilg-ul]

thank you, in this case I'll complete the release.

and the merit for identifying the problem and suggesting a fix is mainly yours.