Internals: Do we have a debug strategy or technique?

[espruino-discuss]

Posted at 2015-09-29 by Kolban

When working on the source code of Espruino (C) and making changes, I find myself injecting logging statements to see what is going on. This is the case for my tinkering with ESP8266 port. I am wondering if on other boards or in general there is a better debugging strategy?

Is there any kind of source level debugger being used?

Should we consider the ability to include debug statement in the C source code that would be compiled out for release but present for debug builds? At present I am putting in debug statements, testing and then removing the debug statements but I would rather be able to leave them in and simply switch them off.

[espruino-discuss]

Posted at 2015-09-29 by asez73

Hi @Kolban,
Actually, it depends on what possibilities the hardware has.
If you are left with pure software, you'r doing it the sole way possible.
On Arduino platforms there is a plugin in Visual Studio to inject those 'breakpoint' and 'watches' done from the IDE at compile time. This video will show you how pratical it is. It's not free but there is an evaluation version and the prices seem 'fairly reasonnable'.
There is also a possibility to use it on ESP8266 but through the Arduino sketches. I don't think Espruino would be debuggable this way.
All other approaches are hardware specific: up to the number of hardware breakpoints versus software breakpoints.
For the ESP8266 there is this threat or this one which basically explains how to install openocd. This links, no warranty, to the specific xtensa openocd.
With other environments you could get lot's more (Keil and others professionnals), but that's expensive.
For CC3200, TI has it's own CCSv6 (eclipse+gdb+openocd+specific hardware on dev board) approach which allows to import energia sketches or use ti-rtos or even bare metal c and do step by step debugging.
For the STM32, you could see Emblocks which would handle Nucleo's out of the box: However that's windows only.
For Linux, that's the luxious situation, you have everything GDB and lot's of others.

---

Posted at 2015-09-29 by asez73

An other approach is Qemu described here .
You'll be able to use gdb but the hardware wont't be real, just emulated...

---

Posted at 2015-09-29 by Kolban

@asez73 Oh Wow!!! This looks GREAT .... MANY thanks for the link ... looks like I have lots of new study to do now.

---

Posted at 2015-09-29 by asez73

The time you'll spend installing will be well paid, I think😉http://www.esp8266.com/viewtopic.php?f=9&t=3751
Now, considering the linux based process to build Espruino, I would suggest using the gdbstub above and use a gdb/eclipse.
This way you would keep all of the conveniencies of eclipse environment, python and so on for Espruino building itself and little more space used inside the Esp.

---

Posted at 2015-09-29 by asez73

And finally, read this ...
Just noted that this ends up on smartJS project, yet worth reading!

---

Posted at 2015-09-29 by Kolban

@asez73 After studying some of these articles, what I think I am sensing is that this is still a bleeding edge area. There seems to be quite a few different stories ... but at this stage, none of them appear to be overly polished. There doesn't seem to be a recipe (that I have seen yet) that one would just follow to achieve source level debugging that doesn't seem to include "... and start by downloading this GitHub project to a Linux environment and compile it .... ". This is not to short change the efforts that are going on to make all this happen ... it just doesn't appear to be as consumable as I might personally like.

I personally enjoy writing up "how-to" guides ... and would be delighted to write up a recipe in depth ... but that pre-supposes I can learn a recipe to write about :-)

Currently, I seem to have two tracks ... one is QEMU and the other is deeper study of something called Crosstool-NG. Neither of which I know much about yet.

---

Posted at 2015-09-30 by asez73

That's it, and now you know why I did not carried on this way...
Anyway, as I wrote, you have little or none real solution but what you are already doing for the ESP8266.
On the STM32, there are much more interesting solutions with openocd and Nucleo's boards.

Now, for the ESP8266, until this summer you could not do any debugging within it, but by inserting prints. Now, with Arduino IDE compatibility and Visualmicro plugin, you could some step by step debugging. The trouble is the requirement to be able to actually build Espruino under Windows.

---

Posted at 2015-09-30 by @gfwilliams

On the STM32 I use a discovery board as an 'ST-Link', and then debug with GDB - docs here: http://www.espruino.com/AdvancedDebug

However I only do that rarely. An awful lot of Espruino can be compiled natively on Linux and debugged very easily from there - sometimes you can fudge embedded code to run straight from Linux itself. You can also get away with quite a lot by looking at the lst file to find out the addresses of symbols and then using peek32 from Espruino itself to check out how those variables are changing over time.

But on ESP8266 I'm not sure what's available - you'd probably need some kind of JTAG connection to it to debug properly... But my experience has been that even on relatively mature platforms, debugging tools really suck.

It might be easier for you to hack up some kind of simple 'ESP8266 test harness code' that runs on Linux and emulates the calls the ESP8266 SDK has - after all, sounds like most issues aren't XTENSA related - it's just how you interface to the API.

Nice side effect of running under Linux is that when you 'exit', Espruino can run a memory leak check that can be really handy.

---

Posted at 2015-10-15 by asez73

@Kolban, you should have a look here .

It says

For internal use, we at Espressif desired a GDB stub that works with FreeRTOS and is a bit more capable, so we designed our own implementation of it. This stub works both under FreeRTOS as well as the OS-less SDK and is able to catch exceptions and do backtraces on them, read and write memory, forward [os_]printf statements to gdb, single-step instructions and set hardware break- and watchpoints. It connects to the host machine (which runs gdb) using the standard serial connection that's also used for programming.

Really interesting, isn't it?

---

Posted at 2015-10-15 by Kolban

Very ... I can't wait to give it a whirll!! It looks VERY exciting.