Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Nguyen Hoan Hoang — Thu, 09 Oct 2014 08:51:33 GMT

Luna does not work well. see this post embeddedsoftdev.blogspot.ca/.../eclipse.html

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

zeusminos — Thu, 09 Oct 2014 06:13:50 GMT

hi, What eclipse/gcc toolchain version are you using? What Segger jlink module/firmware version are you using? What Segger jlink software version are you using?

I have some very strange behavior using eclipse luna (latest version) and I am in the process to downgrade and use eclipse Kepler 4.3 SR2. According to GNU ARM Eclipse is the most stable option. They recommend to use gcc-arm-none-eabi-4_8-2014q2 (I am using this ver already). I am using the latest Segger version.

My next step is use Kepler and if I do not see any change I will use the toolchain/jlink recommended/included in the SDK.

Feel free to post your combinations and we may narrow down this issue.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Nguyen Hoan Hoang — Fri, 28 Mar 2014 01:35:17 GMT

Hi Ellot,

 I am using the same Eclipse plugins from livius as you.  I don't use the makefile.  I created the Eclipse project using the Wizard for generic ARM.  Then go to project properties and change the processor to Cortex-M0 and set all the include paths.  Add links to SDK sources as require.  Debug using the default settings.  I have no problem debugging blank app.  When using s110, it just doesn't break.  To be able to debug with s110, the trick I found is to first upload the code using nRFGo via DFU upload via serial.  I have the DFU project in Eclipse working.  After DFU flash the App, go back to Eclipse and start debuting, it should stop at system startup.  One other thing, there is a limit of 4 break points.  Debug won't start properly if you set more than 4 break points.  I hope this helps.  Good luck.

Hoan

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Eliot Stock — Fri, 31 Jan 2014 19:35:41 GMT

I finally managed to get this to work using a combination of the unofficial pure gcc Makefiles here:

github.com/.../nrf51-pure-gcc-setup

and the GNU ARM Eclipse plugin here:

gnuarmeclipse.livius.net/.../

I'm using the pure-gcc Makefiles to build the project and start the Segger GDB server, but then the GDB client is all within Eclipse. Will attach screenshots of my configuration for the Eclipse GDB stuff in case it helps anyone else. Using the terminal version of the GDB client was useful in figuring out how it all works, but in the end I've switched back to the Eclipse GDB client for now.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Ole Morten — Tue, 07 Jan 2014 13:48:24 GMT

As for the first part, you haven't included the first line in my suggestion, the file line. When you haven't, GDB will for sure be confused.

Also, if you hardcode the reset handler, you must be certain that it is correct for your softdevice version. It seems to me that the reset handler for 6.0.0 is on 0x12B99, so if you then try to use 0x114CD, nothing will work correctly.

If you struggle with Eclipse, you may be better off starting out with command line GDB, get that working, and only then move to Eclipse.

Finally, you can ignore all the other monitor commands in the application note, as they are not strictly required.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Eliot Stock — Sat, 04 Jan 2014 00:23:04 GMT

I still can't get this to work.

Following your suggestion here...

devzone.nordicsemi.com/.../strange-behaviour-with-nrf51822-and-s110

... gdb gets very confused:

monitor speed 30
monitor flash device = nRF51822
load
Loading section .text, size 0xab90 lma 0x14000
Loading section .ARM.exidx, size 0x8 lma 0x1eb90
Loading section .data, size 0x94 lma 0x1eb98
Start address 0x1e6e1, load size 44076
Transfer rate: 21521 KB/sec, 8815 bytes/write.
mon reset
monitor flash download = 1
The target endianness is set automatically (currently little endian)
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.

monitor halt
continue
Continuing.

Temporary breakpoint 1, 0x000157bc in main ()
No breakpoint number 5.

If I instead use "Load image" and "Load symbols" and point to the .elf file (I'm now using the GNU ARM Eclipse plugin, which seems to produce both an .elf file and a .hex file), then reduce my gdb startup commands to simply "mon reset", I get the same errors.

If I then add the following back in for startup commands...

mon speed 10000
mon endian little
mon flash download = 1
mon flash device = NRF51822
mon reset 0

... I do get the same errors on the gdb console, but at least some code executes on the device. The debugger doesn't show me the breakpoint in the code, it creates a "Source not found" window at an address in my main() (0x157bc).

I've also followed your advice here...

devzone.nordicsemi.com/.../uart-application-problem

...and put address 114CD in for "Set program counter at".

And I've removed the default NVIC_SystemReset() call in the app_error_handler() and instead called ble_debug_assert_handler(), as you suggested somewhere.

Am out of ideas.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Ole Morten — Thu, 28 Nov 2013 16:33:04 GMT

Sorry if I was unclear, but I meant to ask you to remove this reset, and instead use an infinite loop (or ble_debug_assert_handler, since that contains such loop).

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Eliot Stock — Thu, 28 Nov 2013 16:30:16 GMT

Yes, still having trouble. Nope, haven't touched the code from the BLE proximity profile sample app, so the app_error_handler is just as it was.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Ole Morten — Thu, 28 Nov 2013 16:21:12 GMT

Does that mean that you still have trouble?

Did you also remove the reset from app_error_handler, and instead use some kind of infinite loop? I've sometimes seen Eclipse/GDB be confused from this.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Eliot Stock — Thu, 28 Nov 2013 15:48:51 GMT

That worked for a second and got me as far as the main loop, but seconds later I was stuck again with the debugger looking at 0x0.

RE: Eclipse CDT, GDB debugging with nRF51822: breaks on every line.

Ole Morten — Tue, 26 Nov 2013 11:02:09 GMT

I suspect what you're seeing is a consequence of Eclipse not behaving correctly with regard to reseting. Have you had a look at this and this question? I'd recommend trying to modify your startup settings, deselecting the "Load" options and do it manually instead.