Program cacthes breakpoint and then freezes

RE: Program cacthes breakpoint and then freezes

RK — Wed, 01 Apr 2015 00:51:56 GMT

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

RE: Program cacthes breakpoint and then freezes

RK — Thu, 26 Mar 2015 12:39:01 GMT

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.

RE: Program cacthes breakpoint and then freezes

Bill Siever — Thu, 26 Mar 2015 12:37:00 GMT

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

RE: Program cacthes breakpoint and then freezes

RK — Wed, 25 Mar 2015 23:53:04 GMT

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.

RE: Program cacthes breakpoint and then freezes

Bill Siever — Wed, 25 Mar 2015 23:45:42 GMT

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.

RE: Program cacthes breakpoint and then freezes

RK — Wed, 25 Mar 2015 23:33:58 GMT

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.

RE: Program cacthes breakpoint and then freezes

Bill Siever — Wed, 25 Mar 2015 23:26:41 GMT

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)

RE: Program cacthes breakpoint and then freezes

Vebjørn — Wed, 25 Mar 2015 15:10:25 GMT

I am currently writing a short tutorial on how to use RTT to debug timing-sensitive applications, it will be available soon. In the meantime, you can read more about here: www.segger.com/jlink-real-time-terminal.html

RE: Program cacthes breakpoint and then freezes

jkwintal — Wed, 25 Mar 2015 14:16:50 GMT

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... ;)

RE: Program cacthes breakpoint and then freezes

RK — Wed, 25 Mar 2015 14:13:54 GMT

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.