OpenOCD and hardware debugger support

[dat98pli]

Previous posts in this forum talks about OpenOCD support out-of-the-box. What is the current status of this implementation? Will this be delivered as part of the first SDK release (available soon)?

For rapid serious software development a good hardware debugger setup is in most cases crucial. What tools are you using in-house when developing/debugging the SDK? At least for a start it would be nice to replicate such a setup to allow less trouble in early stages…
A reference manual with peripheral register descriptions together with an IDE that will show the register value is something I hope will be available in near future. Is this something you will bring to Eclipse?

It would also be very beneficial to have support for real-time recording for and visualization to catch true runtime behavior of an application and SDK. I would argue that support for such a tool will be even more important in the ESP32 case when running FreeRTOS on a dual-core. Segger provides a tool called SystemView and there should also be a profiling tool in the Xtensa Xplorer IDE. Are you using any similar tool? Any recommendations to avoid any hassle before everything has matured?

Answer to the questions above would allow us to get tools prepared while waiting on the hardware.

Thanks! Keep up the good work!

[ESP_Sprite]

Yes, OpenOCD is being worked on very hard, I just finished re-basing the tree on the latest upstream version. At the moment, it supports standard gdb debugging, and I just got FreeRTOS support working again as well, so you can basically switch between individual threads in gdb. Multicore support does exist, but because OpenOCD is slightly derpy in that respect, for now you do it by connecting gdb to a different openocd tcp port. Work on that is somewhere on my list.

We used to use the Xtensa tools in-house, but we moved away from that more and more, I think most if not all our devs that are using JTAG are using OpenOCD for their debugging. We use a certain FT2232-based board; those ones are very well supported by OpenOCD, but I see no reason why other OpenOCD-supported JTAG adapters shouldn't work.

A reference manual is being worked on, the initial version (which is missing a bunch of chapters... documentation is no small job, unfortunately) will be released soon (if it hasn't been already by now). We are working on IDE support for ESP-IDF itself, but I'm not sure if that goes up to debugging and hardware registers; I'm sure that is something we can eventually work in.

We have some real-time capture behaviour: the ESP32 is going to be able to set aside some memory (32K in total, if memory serves, no pun intended) as a trace buffer. OpenOCD has support for setting tracebuffer trigger events and dumping the tracebuffer. We also have a small command-line program that can correlate the tracebuffer contents to assembly and source code lines.

You should see our OpenOCD port show up on Github this or the next week by the way, if everything works out. I'll also try to clean up and upload the trace tool by then.

Hope that answers your question

[dat98pli]

Thanks for you detailed and clear answer.

Does ESP32 (Tensilica LX6) support for memory background read/write while the cores are running?
This is a cool feature available on at least ARM Cortex-M0/M0+/M1/M3/M4/M7 and Renesas RX100/200/600.
This will allow for output information from the target microcontroller as well as sending input to the application at a very high speed without affecting the target's real time behavior. This is something that for instance Segger is taking advantage of in their RTT technology. Segger SystemView for real time tracing is built upon RTT.

[ESP_Sprite]

Unfortunately, I have not seen that functionality in the Xtensa core we use. The default way to do things on our core is to halt the processor and then feed instructions into the core instruction pipeline, which obviously means the CPU can't run at the same time.

[dat98pli]

Too bad... but you can't have it all

[rudi ;-)]

@ESP_Sprite
thanks from me too, for the detailed answere.
it looks like a very very interesting can do.
because esp32 has 2 cores. in debug mode we can controll the wifi/bt core too? can switch between the core's?
or in debug mode we can switch on/off wifi/bt core?
you know, can we use a pipe over wifi/bt for debug?
would be interesting thing.
sorry for many questions in this. no hurry! its sheer curiosity


@dat98pli
only a re question, because english is not my main language and without that I want to contradict ESP_Sprite
what you want is sound to me like this "done in esp8266" : YouTube example
simple example shows,
there is a breakpoint, but the core runs in background in this example a special ( and really simple ) task and wait for user instruction over the debug channel.
is possible to injection vars, patch params in func , jump to a specific addr pointer and so on.
but there is a runing "while(1) debug task" in background, it eats a small ram.
in this example only show, hold on each breakpoint, point to the c src code in project, with debug button go into this
if next breakpoint is, then stop again here, show the debug line in code .. and so on..

in next steps this task becomes system infos for display status and changes nonstop.
next steps this is on a DebugPin for only outputs, but for communication with the task, there are two pins need.
not sure is this what you ask and need .

best wishes
rudi

[ESP_Sprite]

Rudi: That's in software and uses 2 extra pins the J-link idea is that everything can happen over JTAG.

By the way, parts of the register level documentation ('parts of' because we're still working on it) have been released by now, see http://esp32.com/viewtopic.php?f=5&t=188

[a2retro]

@ESP_Sprite, I was trying to compile openocd-esp32 with MSYS2 environment but it will not configure due to missing libusb-1.0. I did searches and tried several things but I could not get past this.

Is this possible with some work or it just not do able?

Glenn

[ESP_Angus]

@ESP_Sprite, I was trying to compile openocd-esp32 with MSYS2 environment but it will not configure due to missing libusb-1.0. I did searches and tried several things but I could not get past this.

Hi Glenn,

We plan to provide a precompiled openocd for Windows, but there isn't one yet. It is possible to compile it from scratch, it's just fiddly.

These commands should work inside the MSYS2 environment:

Code: Select all

pacman -Syu
pacman -S libtool autoconf automake pkg-config mingw-w64-i686-libusb
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/mingw32/lib/pkgconfig
./bootstrap
./configure
make
make install

The first command, "pacman -Syu", may prompt you to close and reopen the MSYS2 shell after it updates msys itself. If this happens you should rerun "pacman -Syu" to receive remaining updates.

You may also need to run ./bootstrap twice if configure fails the first time (I had to, but I think I was missing a dependency the first time I ran it!)

Use Zadig or a similar tool to install libusbK drivers for the hardware.

This process builds a 32-bit openocd (to go with the 32-bit MSYS2 environment.) It works on 64-bit Windows also. It is probably possible to build a fully native 64-bit version, if you put a 32-bit MINGW toolchain into the MSYS2 environment.

Please let us know how you go.

EDIT: Made some updates regarding 64-bit support.

[a2retro]

Hi Angus, I have made a successful build. Thanks!! very much. Now to test it.

I noticed a few odd things when following your instructions but nothing that prevented the build.

1) During the second pacman -Syu there was a conflict for two files. I googled and found out the fix was to rename them and try again.
2) During the third attempt (successful) there were a lot of errors relating to Python 2.7 (warning: could not get file information for mingw32/xxx). They appeared to be missing files?, I can provide some additional details if you interested.
3) error: target not found: makeinf (typo in package name?)
4) + automake --gnu --add-missing --copy
Makefile.am:23: warning: wildcard $(srcdir: non-POSIX variable name
Makefile.am:23: (probably a GNU make extension)

Glenn