[eamonn.walsh]

Thanks

[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 4 years, 5 months ago by eamonn.walsh.

[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…”?

[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

[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.

[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*.

[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

[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

[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.

[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.

[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]

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.

[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

[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.

[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.

[Author]

Posts