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.

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.

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.