CMSIS-DAP device showing up multiple times and debug fails

[support]

Hi,

The “debugging exited without any breakpoint hits” error was caused by incorrect propagation of CMAKE_C_FLAGS that might got cached on your side. Please try deleting the entire VisualGDB\Debug directory and rebuilding the project.

If the breakpoint still doesn’t work please try hardcoding asm(“int3”) in the main() function to trigger an unconditional breakpoint. If the breakpoint triggers, but the source code is not shown, please double-check that the build.ninja file contains the -g”, tine FLAGS statement for the main file, e.g.:

build src/CMakeFiles/openocd.dir/main.c.obj: C_COMPILER__openocd ../../src/main.c || cmake_object_order_depends_target_openocd
    FLAGS = -std=gnu99 -Werror=incompatible-pointer-types -g -DPKGBLDDATE=\"2019-10-08\" -DRELSTR=\"\" -DGITVERSION=\"\"

[eamonn.walsh]

Hi,
I tried deleting the VisualGDB\Debug directory and rebuilding but that didn’t help.

I inserted an “asm(“int3″);” statement directly before the “return openocd_main(argc, argv);” statement and yes, it caused a break so technically resolves the “debugging exited without any breakpoint hits” issue but it doesn’t solve the core issue. The openocd_thread() function calls parse_cmdline_args() but parse_cmdline_args always fails due to the “if (optind < argc)” statement always being true. This means the server_loop() function is never entered and the main function just exits.

Thanks,
Eamonn

[support]

Thanks for the update. This could be caused by another issue – one of the recent GDB updates changed the way the command-line arguments must be escaped and it looks like our OpenOCD toolchain did not specify it correctly. It may cause issues when trying to pass command-line arguments with spaces (such as -c “xxx yyy zzz”).

We have updated our OpenOCD toolchain package one again resolving the issue. Please feel free to reinstall it, or to simply add the ArgumentEscapingMode line to toolchain.xml as shown below:

<?xml version="1.0"?>
<Toolchain xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <...>
    <ArgumentEscapingMode>Advanced</ArgumentEscapingMode>
</Toolchain>

Please also ensure you are using the latest VisualGDB build: VisualGDB-5.5.1.3311.msi

You can verify the arguments seen by OpenOCD by setting a breakpoint in main and evaluating “*argv@argc” in the Watch window (it will expand *argv to a fixed-size array of size argc). If the arguments still don’t match what is specified in VisualGDB Project Properties, please let us know.

If the arguments are correct, but OpenOCD still does not work, please let us know if you are able to step into openocd_main(), i.e. if the source line mapping and variable evaluation are working.

[eamonn.walsh]

Hi,
I downloaded and installed the new VisualGDB installer then tried, but failed, to locate toolchain.xml (if Windows search is to be believed it does not exist on my system). If I instead want to re-install OpenOCD then how do I do that? I downloaded the newest version from https://gnutoolchains.com/arm-eabi/openocd/ and copied the contents into my \AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd directory. Is this sufficient? Not my preferred route for installing anything but there does not seem to be an associated installer.

Re-tested VisualGDB but still can’t debug a board when 2 are connected. Also pulled down all updates to the openOcd repo but it still fails complaining about “Unexpected command line argument: 0604000040214E4500581018C89200169E11000097969900ö”.

Thanks,
Eamonn

[support]

The Toolchain.xml file should be in the location where you have extracted the toolchain during step 1 of this tutorial. If you believe the file is not there, please try downloading/extracting it again and if it’s still missing, please send us a screenshot of the directory with the unpacked toolchain archive.

The OpenOCD installed into %LOCALAPPDATA% is automatically managed by VisualGDB. You can use the Tools->VisualGDB->Manage VisualGDB Packages to automatically update it (VisualGDB normally checks for updates every week). That said, updating OpenOCD would indeed not solve the original problem, as we have not had a chance to reproduce it. If you could step through the OpenOCD source code as it tries to start a debug session with the explicit serial number specified via command line and let us know why it is not handling the serial number argument as expected, we should be able to integrate the fix for it in our OpenOCD fork.

 

[eamonn.walsh]

Hi,
So, I was finally able to get things working and find out what’s up. “Toolchain.xml” does not exist in c:\MinGW but “CustomToolchain.xml” does… I added <ArgumentEscapingMode>Advanced</ArgumentEscapingMode> to that and it’s definitely needed.
But another problem is that the “wcscmp(cmsis_dap_serial, cur_dev->serial_number)” string comparison on line 275 of cmsis_dap_usb.c is case sensitive. The serial number string “cmsis_dap_serial” that VisualGDB produces contains upper case letters while the “cur_dev->serial_number” string that openocd finds for connected USB HID devices contains lower case letters. Therefore the wcscmp compare always fails. I modified the serial number string in my input argument to use lower case letters and the openocd solution can connect to both test boards when I specify their respective serial numbers. Can the string comparison be made case invariant? I think everything would just work then *fingers crossed*.

[support]

OK, we have updated our OpenOCD fork to do case-insensitive comparison for CMSIS-DAP serial numbers.

Please feel free to update your copy via Tools->VisualGDB->Manage VisualGDB Packages->Updates and let us know if it resolves the problem.

[eamonn.walsh]

Hi,
So it turns out there was one more case sensitive wcscmp() serial number comparison in hid.c (.\external\hidapi\source\windows\hid.c) on line 531. I was getting an “Error: unable to open CMSIS-DAP device 0xd28:0x204” but having changed to using wcsicmp() OpenOCD can now connect to both devices. To confirm I copied my built OpenOCD to my “AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin” and was able to successfully run the debug test with both connected boards and run/debug code on them.

[support]

Thanks for finding this out. We would normally want to avoid modifying the hidapi source code (as it would involve forking it just for that change), so we have instead updated our OpenOCD to replace the serial number received from the command line with a correctly-cased version once a case-insensitive match is found. Please try this build and let us know if it works: https://sysprogs.com/files/tmp/openocd.exe

[eamonn.walsh]

Sorry, was out of the office yesterday. Yes, it works perfectly! If you push out an updated OpenOCD package then I’ll pull down the update and reconfirm, and then let our other VisualGDB developers know. Thanks

[support]

No problem. We have updated our OpenOCD package to include the latest fix.

[eamonn.walsh]

Updated my OpenOCD package and works perfectly as expected. Thanks.

Is it safe to assume that the latest beta version (https://visualgdb.com/download/ -> http://sysprogs.com/getfile/668/VisualGDB-5.5.1.3327.msi) includes the required fixes? If so, I’ll push this out to a few developers. Should installing the beta also automatically install the latest version of OpenOCD or do I need to tell developers to go to “Manage VisualGDB Packages…”?

[support]

Good to know it works. The latest OpenOCD package is compatible with both VisualGDB 5.4 and 5.5 Preview, so as long as the developers can the Tools->VisualGDB->Manage VisualGDB Packages->Updates command to install it, they should be good to go.

[eamonn.walsh]

But I think I’m right in saying that there were some fixes made to VisualGDB 5.5 to resolve issues outside of OpenOCD. The latest 5.5 Preview version includes those fixes?

• This reply was modified 5 years, 2 months ago by eamonn.walsh.

[support]

Yes, VisualGDB 5.5 includes numerous fixes, but also introduces new functionality like the new Advanced Build Log View that might still have some sharp edges due to the preview/beta status. We offer both versions for download so that our customers can make a choice between a more functional and more stable version depending on their constraints.

[Author]

Posts