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

application debug with softdevice

Hello,

After searching in forum, I understood that we cannot debug application with softdevice unless PRIMASK bit is set.

But in my application there is a requirement that to transmit data received from uart to connected devices using RADIO. If I set PRIMASK bit I will not get BLE interrupts. How can I debug my complete application ?

Does anyone have tried to debug application with softdevice?

Regards, Sowmya

Parents
  • You are right, when the softdevice is enabled and there is BLE activity then it gets difficult to debug your application. This is because softdevice interrupts are highest priority and when your application somehow masks servicing softdevice interrupt immediately, then when softdevice ISR gets to be serviced (when you unhalt the CPU), softdevice realizes that its real-time requirements have been broken by the breakpoint you set in your application, it will assert immediately and this is unrecoverable fault unless you reset chip.

    I am not sure if there is a better way to do it but this is how i debug code with softdevice. I put a breakpoint in the application and run the debugger until the breakpoint is hit. It is important that you set the PRIMASK to 1 quickly here. Once that is done, you can step debug your application code until you hit a softdevice function (say sd_softdevice_disable). From here debugger wont help you to step. Then you have remove your old breakpoint and set a new breakpoint to the line next to sd_softdevice_disable. and restart the whole procedure again.

    All this pain is not to let the softdevice know that we have halted the CPU. Hope this helps.

    update

    For nRF52, it gets better when you can use the onboard ETM. Read the post here

  • Yes you can debug your BLE application, but not like a normal one. It will be tedious. Imagine your BLE application is something like this which you want to debug

    1) err_code = my_func1();
    2) err_code = my_func2();
    3) err_code = sd_xxx
    4) err_code = some_other_function();
    
    void some_other_function()
    {
       some logic here;
       some other logic here;
       sd_xxx_call();
    }
    

    now you can set your breakpoint at 1) and start the debugger. Once your breakpoint is hit and you set the PRIMASK register, you can step you code from 1) to 2) and then from 2) to 3) but you cannot go any further. At this point you should remove the breakpoint from 1) and put it at 4)

    Then when you restart the debugging session again, then your break point will hit allowing the softdevice to complete its action for 3)

    after you hit the breakpoint 4) you can even step inside the function some_other_function() until you hit the sd_xxx_call.

    if you are waiting for any events and want to debug the BLE events, then put the breakpoints where you receive the events. It is possible to debug your application, but the process is cumbersome and tedious. It will get impossible to write complex applications if we cant debug BLE application at all.

Reply
  • Yes you can debug your BLE application, but not like a normal one. It will be tedious. Imagine your BLE application is something like this which you want to debug

    1) err_code = my_func1();
    2) err_code = my_func2();
    3) err_code = sd_xxx
    4) err_code = some_other_function();
    
    void some_other_function()
    {
       some logic here;
       some other logic here;
       sd_xxx_call();
    }
    

    now you can set your breakpoint at 1) and start the debugger. Once your breakpoint is hit and you set the PRIMASK register, you can step you code from 1) to 2) and then from 2) to 3) but you cannot go any further. At this point you should remove the breakpoint from 1) and put it at 4)

    Then when you restart the debugging session again, then your break point will hit allowing the softdevice to complete its action for 3)

    after you hit the breakpoint 4) you can even step inside the function some_other_function() until you hit the sd_xxx_call.

    if you are waiting for any events and want to debug the BLE events, then put the breakpoints where you receive the events. It is possible to debug your application, but the process is cumbersome and tedious. It will get impossible to write complex applications if we cant debug BLE application at all.

Children
No Data
Related