Can I debug BLE program?

[shali lv]

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

[Michael Ambrus]

Ø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.

[Øyvind]

Setting PRIMASK to 1 will not stop any interrupt source from generating interrupt request signals. It only prevents the CPU from entering any exception (with configurable priority, i.e. all interrupts except RESET, NMI and HardFault) as long as PRIMASK is 1. That is also the reason why the sd_* calls won't work while PRIMASK is 1 as they are implemented as SVCalls, which triggers an interrupt which executes the SD functions.