debugger - live breakpoints and memory access

[samsonc]

Hi, For some time, I've been developing code on the nRF51 with a U-lInk based debuggers and Keil. Things have worked well with that setup. One particularly nice feature (which I had not realized was a feature) is that the U-link can read and write certain things without halting the MCU. For example, the watch window generally updates without halting the CPU, and breakpoints can be set without halting the CPU. This has been particularly useful for early and quick debugging, especially when the BLE stack is running - as I can observe what's going on without crashing the stack.

Since switching to the nRF52, I've decided to switch over to a GCC/Eclipse for my development, in part to make things a bit more compatible with other MCUs I work with. I suddenly noticed that live viewing/breakpoints are no longer the case with the built-in Segger debugger on the nRF52 board - just the act of setting a breakpoint will cause an exception on the stack. I believe the feature is called background memory access - is it no longer available on the nRF52 chip, is this a limitation of the built-in on-board Segger debug chipset, or is it some sort of GDB limitation? I've followed to the tutorial to set up this toolchain.

Thanks! Samson

UPDATE

I'm inclined to believe that the limitation is in Eclipse/J-Link GDB server area. I'm interested in:

• Any plugins that would allow live trace to work properly in "vanilla" eclipse CDT (Looking back, I realize that I have seen other MCU-specific platforms which have been modified to have this work) or
• Any other development environments with better debug capabilities which work together with a makefile/GCC back-end (I'm pretty sure Keil or IAR can't without more hassle on the compile-end, but correct me if I'm wrong)

[samsonc]

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?

[RK]

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.

[samsonc]

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.

[RK]

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.