Enhancement: Support for Black Magic Probe debugging?

[rpavlik]

I know I saw this once before on the old SF site, but I wanted to bring this up here.

The Black Magic Probe - is both a piece of hardware, and a somewhat-portable firmware (can flash it to ST-Link and some other devices) that implements an SWD and JTAG probe for Cortex-M (and some Cortex-A), and internally implements the GDB server, so that the serial port it exposes to the system can be directly connected to with target extended-remote \\.\com31 or your platform's variant - see https://github.com/blacksphere/blackmagic/wiki/Useful-GDB-commands for high performance and simple usage. It also supports SWO.

A plugin would be useful for a few reasons. One would be auto-selection of serial ports: the CDC-ACM device exposed, since it can be determined from the USB interface number. Another, naturally, would be the same sort of easy configuration of the stuff that usually goes in a GDB init script. The other, would just be getting it to work in modern Eclipse...

I've tried the built-in "GDB Hardware Debugging" plugin (in the latest gnu-mcu-eclipse download - a Neon.3 build) but I'm getting MI errors that suggest it's trying to connect with just the equivalent of remote instead of extended remote. From what I've been able to search, it seems like recent versions of eclipse updated debugging frameworks to DSF and since there is no "standard" alternate plugin left around, there's apparently no way to configure it from the Eclipse GUI; even though, e.g., Visual Studio Code GDB plugin works just as well with it as with the J-Link, with just a different init script. At this point, I'm out of my league in Eclipse, so I'm filing a bug/request as a way of throwing my hands up - the BMP works great if I'm willing to do it all in the terminal, otherwise I basically have to use a nucleo-jlink.

[ilg-ul]

BMP seems a nice toy, but I don't know how much traction it has; developing a new debugging plug-in is not a trivial task, and currently I do not have the resources to do it.

[jesperkp]

I have no problems running the Black Magic Probe with Eclipse and the STM32. It does take a little "tweeking" of the configuration. Here is how I made it work: In the Eclipse Debug Configuration I added a GDB Hardware Debugging entry. I configured it like this: Main: is standard (ie. project and which file gdb should use)

Debugger: GDB Setup: (Notice that I added the remote handling here that would normally be in the "Startup" section which I could not get to work) /usr/bin/arm-none-eabi-gdb -ex 'target extended-remote /dev/ttyACM0' -ex 'monitor swdp_scan' -ex 'att 1' Remote Target: Untick this option

Then you should be able to debug your STM32 using BMP from within Eclipse

[ilg-ul]

Yes, GDB Hardware Debugging is the basic tool, with some care it should work for all JTAG probes.

The GNU MCU Eclipse debugging plug-ins extend it with easier configuration and automatic start of the server.

[rpavlik]

Ah, so that's how to dodge the mi/extended-remote mismatch, preconfigure it in the command line part. Will try that next time i have to debug.

[maave0]

@jesperkp commented on Nov 17, 2017, 8:51 PM EST:

(Notice that I added the remote handling here that would normally be in the "Startup" section which I could not get to work)
/usr/bin/arm-none-eabi-gdb -ex 'target extended-remote /dev/ttyACM0' -ex 'monitor swdp_scan' -ex 'att 1'

Thanks! The startup tab worked for me so I placed my commands in there

My gdb command is simply "arm-none-eabi-gdb" without the -ex options.

under Startup tab: uncheck "Reset and Delay" and "Halt" place any commands in the text field below. i.e.:

target extended-remote COM8
monitor connect_srst enable
monitor swdp_scan
attach 1

then you can play around with the other options and write more commands under the Run Commands text field. I took notes from the BMP wiki.

[ilg-ul]

thank you. this seems advanced usage, not very well supported by the plug-ins.

[JojoS62]

@maave0 with your setting I can use the BMP also for debugging. Only thing I could not manage: after connecting to the target, it is only halted and stops anywhere. With OOCD, the debug session starts with running from reset vector until main. With BMP, I have to press the 'restart' button first to get the clean start. What can I set to do this automatically after starting the debugger?

[maave0]

@JojoS62 commented on Feb 14, 2018, 2:38 PM EST:

@maave0 with your setting I can use the BMP also for debugging. Only thing I could not manage: after connecting to the target, it is only halted and stops anywhere. With OOCD, the debug session starts with running from reset vector until main. With BMP, I have to press the 'restart' button first to get the clean start. What can I set to do this automatically after starting the debugger?

I had to shelve my project for now so I haven't gotten farther than that.

[JojoS62]

thanks. Finally, its working well now. After attaching, the target is not reset and this is intended behaviour. In the 'Run Commands' listbox I added a 'run' or 'start' (for stopping at main()' and now debugging starts as wanted. @ilg-ul +1 for a simple BMP plugIn with enumeration of USB or serial devices to detect one or more BMP. The configuration is much easier than for OOCD. It is very common for all targets because the probe detects the targets and does not need different config files.

[ilg-ul]

although it is not in my short term schedule, when the time comes, I might need a BMP for tests.

[JojoS62]

that will be no problem. I don’t have the original hardware, but a modified STLink clone with the BMP firmware. As this is a open project on github it is no problem, there are already a few hardware alternatives supported. The 5$ China clone or a 2$ bluepill board is of course a interesting hardware for makers. I’m happy when I can send you a ready to use hardware for free, I’ve learned already a lot from your mbed gnuarmeclipse exporter and like your eclipse plug ins.

[ilg-ul]

ok, thank you.

btw, please do not reply by email, use the web interface, quoting the original message is not necessary here.

[JojoS62]

sorry, got it by mail and thought its not in the thread. So, for a hardware request just send me a mail.

[ilg-ul]

I'll consider this. I'm also considering an original BMP21.

[JojoS62]

great, I think the founders of the BMP project will be happy to get more support and make their product more popular, you should contact them. Here is my config as described also by the thread starters. only the 'attach 1' is hidden in the initialzation commands list.

[ACGarland]

I've gotten very close to having GNU MCU Eclipse work with BMP, but have recurring problems where, when single-stepping, Eclipse hangs. I've also been unsuccessful at getting it auto-start (it complains that it can't access memory at an address corresponding to main()). When I just get it to load, but not run, then I can manually type into the gdb console, set a breakpoint at main, and run. It stops at main fine. I can then single-step from the GUI interface--for a while. The single-steps are a LOT slower than they execute in a terminal outside Eclipse. And I can only get 3 or 4 before Eclipse hangs forever waiting for the step to complete.

[ilg-ul]

Activate the GDB trace console (Preferences -> C/C++ -> Debug -> GDB -> Show the GDB traces consoles ...) and you'll be able to see the dialogue between the GDB client and the server.

[ACGarland]

Thanks for the tip! I'm digesting what I'm seeing now. (Sure does use a bunch more interaction than one might imagine behind-the-scenes.)

[ACGarland]

So far, I haven't been able to see anything that looks amiss in the traffic between the gdb server and Eclipse. What seems to happen is, at random, when a single-step completes and Eclipse queries the server for state information, once-in-a-while Eclipse locks up and fails to update. This is using:

• macOS High Sierra 10.13.3
• Eclipse OXYGEN.3 Release (4.7.3), build id: 20180308-1800
• GNU MCU ARM plug-ins (all dated 201801250917)

I thought I'd see if I could replicate the problem in a Windows 7 VM with an older version of Eclipse (MARS.2), but got stuck at another problem before I ever tried to run in Eclipse. Using arm-none-eabi-gdb from terminal, just attempting to connect to the black magic probe (target extended-remote \\.\COM20) issues a "warning: SetCommState failed" and gdb hangs--outside of Eclipse.

Anyway, I've run out of time for a while to look into this further. If and when I find out anything more that may be helpful to others I'll provide an update.

[ilg-ul]

I also suggest you use the original GDB Hardware Debug plug-in, to exclude any possible bugs in my plug-ins.

[ACGarland]

Hmmm... that's how I started earlier--thinking I wouldn't necessarily need GNU MCU Eclipse plug-ins. But I couldn't get anywhere--couldn't even get gdb to run. When I launched a debug configuration it would immediately get "stuck" and seemingly hang. I only started to make some progress after installing your plugin-ins. :-) But that was before I knew how to look at the traffic from client to server so if I do back up and uninstall your plug-ins I could possibly see a bit more about what that didn't seem to work at all.

Thanks for your continued advice.

[ACGarland]

FYI - I've upgraded to Eclipse Oxygen.3a Release (4.7.3a), build id: 20180405-1200 and I'm now able to use the black magic probe (BMP) successfully.

Between the previous failed situation and now, I also set up successful debugging using a Segger J-Link (basic) so there is some chance, I suppose, that configuring that could have changed something under the hood that both configurations use.

Otherwise, I'd have to conclude that there was a GDB-related glitch in Oxygen.3 which was corrected in Oxygen.3A--but that is pure supposition on my part.

[ACGarland]

FWIW - We've seen problems programming FLASH with BMP2.1 (running firmware 1.6.1) using ELF files. After the load completes then a compare indicates the read-only region differs. In our testing we've seen segfaults because vtables had bogus values (leading to crashes when virtual functions are called) as well as other data areas which were not correctly programmed. The work-around seems to be to load from a HEX file (which doesn't manifest this issue) and then switch to the ELF file for obtaining symbols.

[dc42]

FWIW Atmel Studio using an Atmel ICE to upload to ATSAM devices has exactly this problem uploading some .elf files. Converting to .hex or .bin and uploading that instead works. Perhaps the .elf file contains 2 conflicting values for the same memory location?

[tonyg-mg]

One of our developers eventually discovered we had an alignment problem for one of our segments. Once we corrected the alignment, the ELF format worked properly.

[t-szczyrba]

I am trying to get Black Magic clone to work with Mcu Arm Plugin, but without succes. I issue the way of jesperkp - Debug Configuration as GDB Hardware Debugging and modified GDB Command to "arm-eabi-gdb -ex 'target extended-remote /dev/ttyBmpGdb' -ex 'monitor swdp_scan' -ex 'att 1'". Starting debug works fine ( makes reset and halts in _start symbol, but it is minor issue), but any command - resume or step - fails. It means:

• number of displayed threads jumps to 5 ( from 1 when starts )
• it is not possible to issue any comand because there is an error reported: Error: Target not available From another side it is possible to issue commands - breakpoints and steps over 'Debugger Console' without a problem. I have attached gdb trace console log ( output of single step ). console.log

[t-szczyrba]

I forgot write about my configuration:

Eclipse Version: Oxygen.3a Release (4.7.3a) Build id: 20180405-1200

Gnu Mcu of 201901011632

CDT 9.4.3.201802261533