CMSIS-DAP device showing up multiple times and debug fails

[eamonn.walsh]

Hi,
I’m trying to debug code on our new Analog Devices SDP-K1 board https://www.analog.com/sdpk1. This board is based on an STM32F469, is Mbed supported and has a CMSIS-DAP debug interface (I’ve successfully used IAR for instance to debug code running on the F469 using the CMSIS-DAP debug interface). When I create a new Mbed project and get to the stage of selecting the “Debug Method”, if I select “Show: USB Devices” I see 5 instances of the CMSIS-DAP device (See “1. Multiple CMSIS-DAP instances.png” attachment). If I select any of them and hit the “Test” button I get a “System.Exception: unable to find CMSIS-DAP device”. My second attachment (“2. CMSIS-DAP debug fail.PNG”) shows the settings used.

I can get the debug test to pass if I instead select “Show: Debug Methods” then configure as shown in my third attachment (“3. Settings that work.png”. Advanced settings are expanded for reference but unchanged from the default).

This board will be used by a wide variety of Analog Device’s customers. If they use VisualGDB for code development is there a way to get it to only show one CMSIS-DAP instance per attached board and resolve the “unable to find CMSIS-DAP device” exception?

Thanks,
Eamonn
Analog Devices

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for reaching out to us. Most likely, the debug probe internally exposes several USB interfaces (that technically count as separate USB devices) without reporting a unique serial number and that confuses the VisualGDB logic.

Please try locating the device in the Windows Device Manager (the debugger endpoint, not the virtual COM port and check its full hardware ID with VID, PID and MI strings). Then try editing the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file to specify the UsbIdentity\Interface element that matches the MI value from the hardware ID.

Then please restart Visual Studio and see if the problem is resolved. If yes, please let us know the changes you made to interfaces.xml and we will update the version shipped with VisualGDB.

On a side note, using the CMSIS-DAP interface for debugging usually results in incredibly slow debugging performance (every single step can take about 5 seconds) due to the USB latency arising from the use of the USB HID class. If you have a feedback channel to the engineering team behind this Analog board, please consider suggesting that they update the firmware to expose an additional USB BULK interface and submit an OpenOCD patch to recognize it. It would require installing the WinUSB driver (as with many other debug probes), but would make debugging more than 10x faster.

[eamonn.walsh]

Hi,
Thanks for getting back to me so quick! I had a look in Device Manager. I see the HID interface used for debug at VID 0x0D28, PID 0x0204 and  MI 03. Then when I look in interfaces.xml this VID and PID is already in there under the “cmsis-dap” programming interface without any interface specified. Just for an experiment I added <Interface>03</Interface> and closed and re-opened Visual Studio but it made no difference. 0x0D28 and 0x0204 are the VID and PID used for Freescale based CMSIS-DAP implementations so I wasn’t too surprised to see it already there. I should say that when I view the device in the Microsoft Usbview tool I do see 5 interfaces (the mass storage, virtual comm port etc.) in the composite device so perhaps this is why VisualGDB shows 5 instances? Is there anything else that you think might help?

And thanks for the tip on using a bulk end point for debug! I’ll have to look into it.

Thanks

[support]

Hi,

Sorry for the delay. We have received a few reports of broken compatibility with recent tool updates and wanted to resolve them first.

We have added a special diagnostic mode that shows USB instance IDs for USB-based debuggers to the following build: VisualGDB-5.5.1.3284.msi

Please try enabling USB device diagnostics as shown below:

Then VisualGDB will show the instance IDs each time you are selecting a device:

 

Please share a screenshot of the VisualGDB’s device list showing the IDs and also the full instance ID of the “debug” device in the Windows Device Manager (Properties -> Details -> Device Instance Path) and we should be able to adjust VisualGDB to filter it correctly. If you cannot locate the correct device in Device Manager, please locate any of the virtual devices provided by the debug probe (e.g. the virtual COM port), switch to “Devices by connection” and look for nearby devices.

Attachments:

You must be logged in to view attached files.

[eamonn.walsh]

Hi,

Thanks for working with me on this. I downloaded and installed v5.5.1.3284 of VisualGDB. The new show USB instance IDs feature works pretty good! I found the HID device in Device Manager. It has an interface number of 03 (full device instance path is HID\VID_0D28&PID_0204&MI_03\8&20984F72&0&0000). But when I select the device with this interface number in VisualGDB the debug test still fails. See attached pics 1, 2 and 3.

Now, I just noticed that the instance ID displayed in VisualGDB doesn’t fully match the ID shown in Device Manager. The VID, PID and interface number are correct but the string preceding the VID is different (“HID” versus “USB”) and the number after the interface is different. Looking further in Device Manger I see that in the “Human Interface Devices” section there is another device that matches what VisualGDB is showing. See attached pic 4. The device instance path for this device fully matches the device with interface 03 in VisualGDB. Is this a hint for why debug doesn’t work? i.e. VisualGDB for some reason is not finding the actual HID interface implementing CMSIS-DAP. (don’t know why the same interface is showing up twice as apparently different devices (different devices but both shown in the HID section of Device Manager while one appears to be a HID device but the other is not))

Attachments:

You must be logged in to view attached files.

[eamonn.walsh]

FYI. I viewed devices by connection in Device Managers (didn’t realise you could do that. pretty handy view for composite USB devices). See attached image. The “USB Composite Device” is the SDP-K1 DAPLink. As you can see I copied out the device instance path for each interface and pasted it into a notepad doc.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The different device IDs happen due to the specifics of Windows driver matching (the HID\<..> is a high-level device node created on top of the USB\<…> device node, letting the USB controller, USB HID and HID class-specific drivers work together in a layered fashion). It should not affect any functionality on the VisualGDB level.

Either way, we have updated VisualGDB to automatically eliminate redundant USB device entries that correspond to the same physical device. It should completely resolve the problem.

Please try this build: VisualGDB-5.5.1.3285.msi

If it still doesn’t work, please share an updated screenshot of the VisualGDB device list with the instance ID display turned on.

[eamonn.walsh]

Hi,

So mixed news. First the good news, the fix works great! I only see one device now and the debug works perfectly. However, I thought to myself, “what does this look like if I plug in 2 boards?” so I plugged a 2nd board in but VisualGDB never finds it. I may have inadvertently misled you into thinking that all SDP-K1 boards have exactly the same device instance path when in actual fact the long string of characters after the PID (starting with 0604) is a serial number that changes from board to board. The 2nd board has a different serial number and therefore a different path. Presumably this is why it isn’t found?

Also, I should point out, in case you’re not aware that a lot of Mbed enabled boards use the same VID and PID (0x0D28 and 0x0204). I don’t know if you’re using the interface number in this updated scheme but it’s possible that the HID interface may not be 03 with other Mbed boards. If this is potentially an issue then perhaps the new selection scheme can only be enabled when the “SDP_K1” is selected as the Mbed target in the Toolchain window during the project creation.

Thanks and sorry if I misled you. Eamonn

[support]

No worries. The logic we added for elimination of the duplicate entries does compare the serial numbers, so normally having 2 different physical devices should show them correctly.

Please try this build: VisualGDB-5.5.1.3287.msi

Please try enabling View->Other Windows->VisualGDB Diagnostics Console, then open the device list, confirm that there is just 1 device instance, while 2 physical devices are plugged in  and click on the “copy to clipboard” link on the device entry. This will produce a detailed log of enumerating the USB devices and eliminating the duplicates to the VisualGDB Diagnostics Console. Please share the output from that window and we should be able to understand what is going on and fix it further.

[eamonn.walsh]

Progress… First, I made a boo boo. The 2nd board I was testing with was a valid CMSIS-DAP device but it had an older version of our firmware on it which meant it had a different USB VID/PID and so wasn’t been picked up by VisualGDB. Fixed that and now see 2 devices as expected when in show USB devices mode. The serial numbers for both boards are what I’d expect them to be but…

If I just plug one board in at a time and run the debug test it passes (true for either of the 2 boards I’m testing with). However if I plug both boards in at the same time and try to run the debug test on either of them it reports an “unable to find CMSIS-DAP device” exception.

[support]

Good to know the USB device display works. The “unable to find CMSIS-DAP device” issue is a bit trickier. Generally, when VisualGDB detects multiple instances of the same debugging interface, it issues a special command to OpenOCD (cmsis_dap_serial for CMSIS-DAP devices) in order to pick a specific one.

If this doesn’t work, either VisualGDB determined the serial number incorrectly, or OpenOCD fails to handle it.

In order to fully track this down, you would need to build OpenOCD from source (see this tutorial), configure it to run the “cmsis_dap_serial” command and step into the logic responsible for handling it and filtering devices by serial numbers. If it turns out VisualGDB is passing the serial number incorrectly, please let us know more details and we should be able to fix it.

If the problem is on the OpenOCD side (e.g. it tries to query the serial number from the HID-level device instead of the USB-level device), feel free to submit a merge request with the fix to our OpenOCD repository and we will include it in the version we ship with VisualGDB.

We can also do all the investigation and OpenOCD fixing for you, however as it involves troubleshooting external tools and hardware, this would be a subject to a customization fee. Please feel free to contact our sales to get a quote if you would like us to handle this for you.

[eamonn.walsh]

Hi,
I’m following the tutorial steps to build OpenOCD but I’m running into an issue at step 9. When I start debug I get a “Debugging exited without any breakpoint hits” message. See attached image and corresponding log file. Any thoughts?

Note that I’d recommend updating step 1 to say that MinGW must be installed in c:\MinGW (it currently says “c:\MinGW or another folder”) and step 2 to say that the OpenOCD repo must be cloned into c:\projects (currently no guidance given). I don’t like creating directories in my root directory so I originally created them elsewhere and when I opened the openocd solution I couldn’t build the project. Repeating the tutorial steps using c:\MinGW and c:\projects resolved all build issues.

Note also that in step 7 the “Working Directory” is shown as empty but when I open the openocd property page it is set to someone’s (“ivan”) “AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts” directory. I set the working directory to my “AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts” directory. Until I did this I could not start debug as it failed due to a “The directory name is invalid” error. The working directory is blank in the image in step 7 in the tutorial. What should the working directory be set to? Regardless of what I set the working directory to (…\scripts or blank) I still get the “Debugging exited without any breakpoint hits” message.

Attachments:

You must be logged in to view attached files.

[eamonn.walsh]

Ok, digging into this further something is going wrong in parse_cmdline_args(). The if (optind < argc) statement is true and so returning an ERROR_FAIL. Think my Command Line Parameters are ok (“-f interface/cmsis-dap.cfg -c “cmsis_dap_serial 0604000040214E4500581018C89200169E11000097969900” -c “transport select swd” -f target/stm32f4x.cfg -c “adapter_khz 3000” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready””). I’ll step through the code and see if I can identify what’s going wrong.

[support]

No problem, it turned out our OpenOCD toolchain was using the old-style definition file that had hardcoded paths. We have updated both the toolchain and the OpenOCD repository so that they don’t have any paths hardcoded and will work out-of-the-box with arbitrary locations.

We have also fixed the “Debugging exited without any breakpoint hits”  error (there was a glitch in one of the CMakeLists files, although it’s hard to say why it didn’t trigger with the old path/toolchain).

Let us know if you find the root cause of the serial number matching problem and we will be happy to update our OpenOCD package.

[eamonn.walsh]

Hi,
Thought I’d replied to this but it would appear I did not… I pulled down the updates to the repo and while the hardcoded path problem is indeed fixed (thanks for that) I’m still getting the “Debugging exited without any breakpoint hits” issue. Still seems to be failing in the same place i.e. the “if (optind < argc)” is true so returning ERROR_FAIL. Note that the message “Unexpected command line argument: 0604000040214E4500581018C89200169E11000097969900” is printed to the command line by a LOG_OUTPUT statement.

Also, and this is possibly an indication of why debug works with one board connected and not with two… When I run the debug test the command line changes depending on if I just have one board connected or two.
1 board connected:  “-f interface/cmsis-dap.cfg -c “transport select swd” -f target/stm32f4x.cfg -c “adapter_khz 3000” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready””
2 boards connected: “-f interface/cmsis-dap.cfg -c “cmsis_dap_serial 0604000040214E4500581018C89200169E11000097969900” -c “transport select swd” -f target/stm32f4x.cfg -c “adapter_khz 3000” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready””

Is OpenOCD not handling the extra “-c “cmsis_dap_serial 0604000040214E4500581018C89200169E11000097969900″” parameter?

Note that I tried running the OpenOCD debug session with the shorter “-f interface/cmsis-dap.cfg -c “transport select swd” -f target/stm32f4x.cfg -c “adapter_khz 3000” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”” command line and this also reported “Debugging exited without any breakpoint hits” due to “if (optind < argc)” being true.

• This reply was modified 4 years, 6 months ago by eamonn.walsh.

[Author]

Posts