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 ?
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 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).…
Add the following line in you code just before breakpoint:
__ASM volatile ("MSR primask, %0" : : "r" (0x1) : "memory");
This will set PRIMASK register. You will be able…
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.
I hope this helps.
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.
I have got it. I have other questions are going to ask. hope you helps .
Ø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:
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:
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.