Eclipse for native code debugging

[espruino-discuss3]

Posted at 2016-09-07 by ddm

When experimenting with extending Espruino using libs it is useful to have a proper debugging workflow for native code.

I don't have experience with high-end commercial IDEs but I found that Eclipse with GNU ARM Eclipse was usually good enough for ARM Cortex MCUs.

Does anyone use this kind of setup? If so, what advice can you share?

[espruino-discuss3]

Posted at 2016-09-07 by @gfwilliams

When debugging the Pico I connect to an STM32Discovery board and use that as a cheap/easy ST-Link. Connecting to the debug pads on the Pico is a bit fiddly though: http://www.espruino.com/AdvancedDebug

Getting that integrated into the IDE is something I found irritating and not really worth it (but that may have changed). If you just use the command-line GDB I've made a few macros (see .gdbinit) that make your life easier when debugging the interpreter.

---

Posted at 2016-09-07 by ddm

I noticed that there are eclipse configuration files under targets/efm32/. They seem to do the job well and, when used with DEBUG=1, produce executables with proper debug info.

I am currently trying to replicate the setup for nRF chips since that is what I am using. My current attempts are falling short since I can't properly link source files to the executables and have to fall back to the eclipse disassembler.

Ideally, I would like to get to a point where I can hit a breakpoint anywhere in the Espruino C code (including generated files).

---

Posted at 2016-09-07 by @gfwilliams

Ahh, you may be disappointed then. You can't debug nRF chips while bluetooth is enabled, because that enables a hardware watchdog which reboots the chip the second you hit the breakpoint.

There may be some solutions to that, but it'll definitely make your life a bit harder :)

---

Posted at 2016-09-07 by ddm

Thank you for clarifying that: I bumped into that exact behaviour today. That said, stepping into the init routines seems to work fine. No luck debugging BLE advertising and services of course...

I am still trying to figure out how to get around the limitation because it would make adding new Bluetooth and NRF-related JS functions easier.
Eclipse is a heavy and complex beast but it is free and the ARM support keeps getting better. With a properly configured "debug perspective" you can get a lot done.