Hello everybody,
Maybe some of you using Eclipse and GCC have encountered the same problems when you try to start a debugging session.
First of all: If you have Bluetooth communication running (either Advertising or a Connection), you cannot debug with GDB server as it will crash the SoftDevice (it cannot perform realtime operation when the debugger hits a breakpoint). Considering this constraint, you can use GDB debugging for other parts of your software if you disable the Bluetooth functionality.
As I have not found any similiar information in this forum yet, I will give a short summary about how to configure Eclipse for GDB debugging.
(1) First, you need the GDB server. You can either start it manually or you can create an entry in "External Tools".
- under "Location", enter
JLinkGDBServerCL.exe(you may want to add the path to this file). - under "Arguments", enter
-select USB -device NRF51822 -if SWD -speed 1000.
(2) Then, you neet to create a debug configuration. Go to "Debug Configurations" and add a new configuration under "GDB Hardware Debugging".
- On the "Main" tab, select your binary (*.elf), set the Project and disable auto build.
- On the "Debugger" tab, under "GDB Setup",
enter arm-none-eabi-gdb(you may want to add the path to this file). Make sure that the default port is used (localhost:2331). - On the "Startup" tab, you may want to add the following "Initialization Commands". There are several comments on the web that say these commands are not needed. But in some cases, I had less problems when I was using them.
.
monitor flash download = 1
monitor flash device = nrf51822
mon speed 1000
mon endian little
mon reset 0
- Finally, at the bottom of the tab, enter the following lines under "Run Commands":
.
monitor reg r13 = (0x00000000)
monitor reg pc = (0x00000004)
The run commands instruct the debugger to load the stack pointer (r13) and the program pointer (pc) from the vector table which is used after a hardware reset.
I experienced a lot of trouble because Eclipse was always loading the program counter manually with the entry point of the generated ELF file. This resulted in ASSERT faults and system resets. I think the reason is that the SoftDevice is not started correctly in this case, as the startup handler from the SoftDevice's vector table is not evaluated. This is exactly what I do with the "Run Commands" mentioned above. With this, the problem seems to be resolved.
If anyone might be interested, I'm also attaching a small .c file which implements a special startup handler for ELF files. The handler simply writes a notification over the Segger RTT and performs a system reset (which initializes the SoftDevice and starts the real application code). To use this startup handler, you have to set the entry point by adding -eELF_Entry_Point to the linker options in your makefile. If you do not use the Segger RTT, you can remove the include command and the function calls.
Have fun!
