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.

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

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

Children
No Data
Related