This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Program cacthes breakpoint and then freezes

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?

Parents
  • 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.

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

Reply
  • 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.

Children
No Data
Related