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?

[RK]

you can't debug things which use the softdevice and resume again. That throws the BTLE timing, which is very accurate, off, whilst you are stopped in the debugger and the softdevice then fails (usually ends up in the hardfault handler).

You can use other techniques, like logging to a serial port, you can stop ONE time and examine where you are, but if you resume in something using the softdevice you'll crash. The softdevice needs to run uninterrupted.

[jkwintal]

Thanks for the answer. I'm just starting with nRFs and BLE, as you can see. It was probably a silly question to ask, but... ;)

[Bill Siever]

The Segger J-Link tools support a "Real-Time Terminal" (RTT), which is a good tool for logging the flow of the program. It can be used to do all logging via the programmer rather than a UART.

Segger's RTT has been mentioned in some previous forum posts:
devzone.nordicsemi.com/.../ and: devzone.nordicsemi.com/.../ .

I also have a blog post that shows how I configure and use it: http://siever.info/blog/?p=1 (It's pretty easy to install/use as-is, but I created a Keil v5 package that may make it slightly easier. The package is available from my blog if anyone is interested)

[RK]

I've been finding that the RTT works fine before the softdevice is enabled but after that I don't get see any output from it at all. I haven't started investigating much yet but wondered if anyone else had seen anything similar.

I'm using Crossworks, so it might be an issue with their implementation of RTT, it's built right-in to the IDE and messages just appear in the console log, which is useful.

Anyone else seen any issues using this with the softdevice? I suspect I'm just going to have to dig in and see if I can work out what's happening.

[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.