• State Verified Answer
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 12953 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 100016
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How can I debug a softdevice application?

Guest

When I'm running a BLE application with the debugger, and the CPU halts on a breakpoint, it seems to end up in the assert handler when I start it again. How can I avoid that?

Parents
  • 0

    You are right that when you start the CPU after having been halted on a breakpoint, you'll most likely either see an assert or hang in an infinite loop.

    The reason is simply that the nRF51822 only have a single processor, so both the application and the softdevice's BLE stack will be halted when the device halts on a breakpoint. It is therefore not possible for the softdevice to receive or transmit BLE packages while halted, and this means that BLE link will be considered lost after the connection supervision timeout. Also, all stack events and hardware interrupts occurring will not be received properly while halted, so if you start running again, the internal sanity checks in the softdevice will therefore most likely fail, causing an assert.

    You therefore have to do debugging by other means when using the softdevice, for example by doing UART printouts, toggling GPIO or similar. Please also note that it's perfectly possible to halt the CPU on a certain condition and look at the current state of variables and similar, it's only if you try to start again that you will see problems.

Reply
  • 0

    You are right that when you start the CPU after having been halted on a breakpoint, you'll most likely either see an assert or hang in an infinite loop.

    The reason is simply that the nRF51822 only have a single processor, so both the application and the softdevice's BLE stack will be halted when the device halts on a breakpoint. It is therefore not possible for the softdevice to receive or transmit BLE packages while halted, and this means that BLE link will be considered lost after the connection supervision timeout. Also, all stack events and hardware interrupts occurring will not be received properly while halted, so if you start running again, the internal sanity checks in the softdevice will therefore most likely fail, causing an assert.

    You therefore have to do debugging by other means when using the softdevice, for example by doing UART printouts, toggling GPIO or similar. Please also note that it's perfectly possible to halt the CPU on a certain condition and look at the current state of variables and similar, it's only if you try to start again that you will see problems.

Children
Related