debugger - live breakpoints and memory access

RE: debugger - live breakpoints and memory access

RK — Sat, 01 Jul 2017 01:44:10 GMT

you can use SES even if you build your code with makefiles. It allows you to load an externally built executable, you can even I think get it to run the make for you. I don't know how good an editing IDE it is when you do that, you can certainly open files and edit them, don't know if you'll get much code completion etc but it'll work a bit.

If you JUST want a debugger, Segger also ships Ozone which is completely free and really very good. That debugs with the JLink directly (no gdb server) and just reads any old ELF you throw at it. That's got no editing IDE at all but does show source code from the debug info in the binary. I like it for quick debugging sessions.

oh and the other thing you can get with SES is monitor mode debugging, that actually lets you debug with the softdevice running.

RE: debugger - live breakpoints and memory access

samsonc — Sat, 01 Jul 2017 01:37:41 GMT

Thanks for the info. Everything you've said is consistent with what I've noticed in the past. I've traced it down to either the Eclipse plug-in or the GDB server. Thanks for the info - I'm going to look at Segger's embedded studio product. The main issue is that I prefer using gdb and makefiles for my toolchain, but the only debug IDE that I knew of that supported it well was Eclipse. Usually most other MCU manufacturers have a custom-modified Eclipse CDT platform that actually supports live view correctly - I suspect it requires some custom plug-ins to make it work.

RE: debugger - live breakpoints and memory access

RK — Sat, 01 Jul 2017 01:31:30 GMT

There's a few parts to this. First off the SWD interface on the ARM chips (all of them now I believe) support memory access while the CPU is running. I'm 99% sure that you can set breakpoints while the CPU is running, 99.9% actually. The only thing you can't do without halting is read the registers.

So if Keil (which I've never used) updates watches etc in realtime I would assume that's because they are at fixed memory addresses and it just reads the data occasionally. Similarly Segger's J-Scope also just instruments the ELF file, finds static variables and reads them (shame that product is still windows-only).

Segger also uses this same technique for their RTT stuff which they're now using for just about everything. RTT is one memory buffer, fixed place, as big as you need, into which you write a stream of data and the JLink just reads it out and gives it to a console, their realtime tracer or anything else. It's their answer to SWO which I prefer myself but is ARM only.

So ARM SWD supports memory access whilst running, the segger JLink adapter supports it too and I'm sure breakpoint setting whilst running is supported.

So now I'll go into guesswork mode. GDB access to the JLink is via Segger's GDB server. This uses the GDB remote protocol, which is super ancient, to do the job. First off I don't know if GDB remote or Segger's implementation of it does a good job of memory reads without halts or breakpoint setting without halts. You could just try running gdb yourself connected to the server and type the monitor commands in, see what happens. If that works, then it's probably the eclipse plugin not doing realtime updates either because it doesn't know how to, or it's not configured for it.

One of the advantages of using something like segger embedded studio is that it doesn't use the terrible GDB server at all, it, like the rest of the Segger tools and good 3rd party apps, reads and writes the JLink directly via the library. This is always going to give you a much better debugging experience, plus access to RTT and all the other good stuff.

RE: debugger - live breakpoints and memory access

samsonc — Sat, 01 Jul 2017 00:43:57 GMT

Follow-up: I tried the Segger J-Scope, which is clearly capable of viewing live variables (even while J-Link is running in Eclipse). So it looks like an Eclipse/GDB configuration issue?