Program cacthes breakpoint and then freezes

[jkwintal]

I have just started with nRF51 DK using Keil uVision and encountered a strange problem. I compiled and loaded a ble_app_hrs example, I can see it working fine (the LED flashes every 2 seconds or so). I want to debug the example to see the flow of the program. And here I have a strange problem - after the program catches the breakpoint it's usually no longer running after I press Run. Sometimes after the breakpoint catches I am able to do 2 or 5 or even 20 steps, but then it does not respond again. I set the breakpoint in the periodic function heart_rate_meas_timeout_handler. It stops immediately after running the debug session, and when I click Run it never cacthes again. As I said, I am only able to do a couple of steps more after the breakpoint and at some point the program won't stop again. Any ideas what is causing the problem?

[Bill Siever]

I've just used RTT to get a better sense of the sequence of events when doing BLE transactions and to identify some tricky errors. It has generally worked well for me when logging a few small messages (while using the softdevice). I use Segger's log viewer to see the message.

I've wondered if there might be some throughput problems when doing more exhaustive logging. I've also wondered if it's sensitive to the buffer size.

[RK]

Yeah I'll try their log view - have to work out how to do that on OSX, don't think they provide a GUI app, just a socket you can connect to. Although again I wonder how that will play with having another client - i.e. Crossworks, already trying to get the messages. Certainly I stop seeing messages when the softdevice is active, but I'll write a simple project and try to break it down a bit.

Throughput can be an issue, I've swamped the buffer (in non=softdevice mode), it's a ring buffer and eventually you overwrite yourself.

UPDATE

Ok I debugged my way through the code to find my problem using RTT with the softdevice was entirely of my own making, it just so happened the RTT buffer was in-memory next to a buffer of my own and I was overwriting it by one byte, breaking the structure.

So RTT now seems to be working ok with the softdevice.

[Bill Siever]

Thanks for the update. I hope to transition to Crossworks and I'm happy to hear that it will play well with RTT.

[RK]

When you do - send me a private message - I wrote a plugin for crossworks which sets up projects with all the right flags for softdevice / no softdevice / different boards etc. I've found it rather useful and can send it to you.

[RK]

Note for anyone searching for RTT information. The latest Crossworks (3.4) needs you to set "Startup Completion Point" to 'main' in order for the RTT system to be properly started and get trace information. I'm told there was a race condition in the previous code which could cause RTT to try and initialize in the debugger before the code actually got to the point of setting up the buffer, so RTT initialization was deferred to this fixed 'Startup Completion Point'.