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

Can I debug BLE program?

Hi, Can I debug BLE program? for example ble_app_hrs and ble_app_proximity. If not, why and how can I test and evaluate my BLE proram ?

Best Regards

  • You can to a degree. The debugger in Keil uVision runs normally, but if the softdevice is initialized and you hit a breakpoint, then you cannot resume from there (or, you can, but things don't work). Also you cannot step through or anything like that when using softdevice. At least this is my experience.

  • Hi,

    If you stop the execution somewhere in the application code e.g. by using a breakpoint, you can step forward from there if you set the PRIMASK CPU system register to 1 after hitting the breakpoint. You can do this in the "Registers" window in Keil while in debugging mode.

    There are a couple of limitations: You can only step until you hit an sd_* API call or return from an ISR, and you can not set PRIMASK back to 0 and resume execution as stopping the execution breaks the real time properties of the BLE stack. Also, no new interrupts will happen after PRIMASK is set to 1.

    I hope this helps.

  • hi, i use uart port ,to out some debug message. but the ble stack is Time slice so,when you release you have to disable uart to sure function.

  • thanks all I have got it. I have other questions are going to ask. hope you helps .

    sincerely yous

  • Øyvind: Me and my team are struggling with this aspect too. Not being able to debug SD ISR:s with GDB is giving us grief.

    I'm not familiar with primask from before but it seems to be a control register for enabling/disabling interrupts. Or actually, the CPU:s ability to respond to them:

    infocenter.arm.com/.../index.jsp

    We can automate this either in gdb-script or as an inline assembly in code. Would setting this bit stop the soft-device itself or will some HW continue to generate interrupts? Preferably one would like the source of the interrupts to also stop.

    This debugging technique, even if that breaks RT-requirements for SD, being able to step at least until next sd_* or ISR return would make a huge difference.

    == Edit == Here's a gdb-script based solution:

    define hook-stop
        set $primask=1
    end
    
    define hook-run
        set $primask=0
    end 
    
    define hook-continue
        set $primask=0
    end
    

    It will set primask to 1 on each stop, and release the IRQ-block it on each continue or run. Save as file objfile-gdb.gdb for automatic load or load explicitly using gdb's -x option.

Related