Debugging using black magic probe

[nikhil]

Hello,

I am trying to debug with stm32f4 mcu using black magic probe (https://github.com/gsmcmullin/blackmagic). I am able use eclipse debug perspective and can do step debug operation. I have enabled dbg option in chconf.h However I am able to only access main thread and other threads both static as well as dynamic are not visible. I tried using chibios plugin but it is not working. I also used latest chibistudio but I am not able to run plugin to view and debug other threads.
Am I missing something to get plugin work? Is there any other option to view/debug other threads?

--
nikhil

[Giovanni]

Hi,

So this is an alternative to OpenOCD? interesting, I will keep an eye on the project but I never used it yet.

The chibios plugin requires the standard debug mode in Eclipse, the default for new workspaces is "DSF" mode. Look under the debugger settings.

Giovanni

[nikhil]

Yes this is a nice alternative to openocd and so far performance is good.

I am using standard GDB debug as bmp also demands it. However bmp uses serial com port and not generic tcp/IP. Also I am using swd mode and not jtag.
Can this be the reason of non-functionality?

--
nikhil

[GHF]

I use Black Magic and it's great, but the lack of RTOS-specific support is making me consider going back to ST-Link or an FTDI-based debugger occasionally.

The advantages of the Black Magic are that it runs the GDB stub on the dongle (so you gdb target remote to the /dev/tty.* it creates instead of to a local daemon over TCP/IP) and that it's super fast.

Unfortunately the support for ChibiOS threads is built into OpenOCD, so unless somebody ports the ChibiOS threads/stacks walking to Black Magic, GDB "info threads" will not work and you'll see a single "main" thread, probably running your idle task.

[joewa]

Although I am still new to microcontroller programming it's working fine for me! It is very fast and you can set (conditional) breakpoints at runtime and inspect variables. But I have to admitt since I have not used the Chibios-specific features of OpenOCD I don't know what I am missing...

I would recommend to upgrade your Eclipse with Embsysregview: http://sourceforge.net/projects/embsysregview/
In case it is not showing anything follow this post:
viewtopic.php?f=16&t=2173&start=10#p17721

Jörg

[avrhack]

I've just discovered BMP too having been totally fed up with the unreliability and painful setup of using st-link with OSX. BMP just works, is reliable and is super-fast as other posters here have said.

I have no idea of the complexity or feasibility of adding ChibiOS thread support but as the BMP firmware is open-source and runs on STM32 there's got to be a reasonable chance. Sounds like my next task is to review the OpenOCD code that adds thread support, figure out how that works and see if it can be ported into the BMP firmware. If anyone else has experience of thread support for gdb and has some links or documentation to share that might help me build my knowledge more quickly that would be much appreciated.

[avrhack]

I have no idea of the complexity or feasibility of adding ChibiOS thread support.....

Ah yes. Now I get it. Having done some digging it's clear that the BMP operates at a relatively low level and all the knowledge of symbols and source structure is retained solely within gdb. That should have been obvious to me. So to get the BMP to support threads, the firmware itself needs to start understanding ChibiOS structures and crucially exactly where they are in memory. And since gdb doesn't pass that information to the remote target there's no easy way to do it other than for the firmware to start interpreting the loaded ELF files which would add a pretty major overhead to the BMP firmware.

Looking at how the registry works it seems that it's "just" a case of finding the symbols 'ch_debug' and 'ch' which together give access to some key parameters and the main thread structure, then iterating through those in theory should give the necessary data for the target to pass back to gdb. On second thoughts there is a way to do this without the firmware parsing the ELF and that's to have the parsing done as part of the gdb init scripts, using a new custom monitor command to pass the key data structure addresses into the target firmware whenever an elf is loaded. So the parsing at least doesn't seem to be a massive issue.

Of course it would still mean that a particular version of BMP firmware was tied to a range of ChibiOS versions ie when the core thread structures change, the BMP firmware would need to be re-worked. I'm not sure how often Giovani changes those - my suspicion is that they're pretty stable now?

Not impossible, but certainly not trivial at all. Maybe why no-one appears to have tackled it yet but it's certainly piquing my interest.......

[Giovanni]

Look into the ChibiOS/RT registry, it is what debuggers use to get the list of threads and other information.

Giovanni

[avrhack]

Look into the ChibiOS/RT registry, it is what debuggers use to get the list of threads and other information.
Giovanni

Indeed Giovani. But I will need to hard-code the relevant structures into the BMP firmware, so the question is how often does this change now? I'm assuming that it almost never changes given how mature ChibiOS is?

[Giovanni]

The registry should not change after RT3 hopefully, in RT4 a couple of field will be set to zero because some variables disappeared from thread_t (zero means, not there).

Giovanni