• State Not Answered
  • Replies 2 replies
  • Subscribers 74 subscribers
  • Views 615 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 241010
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

User breakpoints management

Gianluca

Hi, i'm new to Nordic devices and i hope this topic hasn't already been treated. I'm triyng to debug an example application; after the first breakpoint, i loose the control of the device. I read that this is due to the loose of syncronization of the softdevice Bluetooth library. I'm asking if there is a way to solve that because working with one shot breakpoint is not a good position. Our toolset is as follow:

development board: nRF52840-DK

Bluetooth sdk: nRF5 SDK 16.0.0

BLE Mesh SDK: nrf5_SDK for Mesh v4.0.0

Application example: mesh light switch server

Error condition from debug terminal: 82190>, app_error_weak.c,   96, Softdevice assert: 96294:0

I experienced the same issues using a device peripheral example (uart) in which i found the NRF_BREAKPOINT_COND assertion in the app_error_fault_handler routine.

I simply ask if it is not possible to use breakpoints and how to manage the interactions with the peripheral interrupts.

Thanks a lot for the answers.

Parents
  • 0

    Hello,

    The reason why the softdevice asserts is, as you say, because the softdevice is loosing time sensitive time slots. Unfortunately, there is not much we can do about this. 

    There is something called Monitor Mode debugging, where it doesn't actually stop the CPU while you step, but in my opinion, this is more work than just using logging to see what's happening instead of debugging when you are developing. 

    I assume you are using the Mesh SDK there are two error handlers. One designed for the Mesh SDK, and one designed for the "normal" SDK. 

    I suggest that you add the define "DEBUG" to your preprocessor defines. Go to project settings by right clicking the project name, and follow the instructions here:

    What does the log say then?

    NB don't set a breakpoint. Look at what the error handler prints in the log.

    You can set a breakpoint if you want to know what happens at one point in time, and you can step a few time until the application realize that the softdevice has missed some events. Then you need to restart the application and set a new breakpoint.

    Best regards,

    Edvin

Reply
  • 0

    Hello,

    The reason why the softdevice asserts is, as you say, because the softdevice is loosing time sensitive time slots. Unfortunately, there is not much we can do about this. 

    There is something called Monitor Mode debugging, where it doesn't actually stop the CPU while you step, but in my opinion, this is more work than just using logging to see what's happening instead of debugging when you are developing. 

    I assume you are using the Mesh SDK there are two error handlers. One designed for the Mesh SDK, and one designed for the "normal" SDK. 

    I suggest that you add the define "DEBUG" to your preprocessor defines. Go to project settings by right clicking the project name, and follow the instructions here:

    What does the log say then?

    NB don't set a breakpoint. Look at what the error handler prints in the log.

    You can set a breakpoint if you want to know what happens at one point in time, and you can step a few time until the application realize that the softdevice has missed some events. Then you need to restart the application and set a new breakpoint.

    Best regards,

    Edvin

Children
Related
Terms of service