Should custom uploader be invoked by debugger?

1

I have a custom uploader defined that launches a local emulator. This is set as a pre-hook extra script and works great if I just use “upload”. However, if I attempt to launch debug using “PIO Debug” I was assuming the upload should occur. I’ve found references on the internet that make me think this should work, but it is currently not. When clicking “PIO Debug” in VS Code, the project builds, but fails to execute my custom upload and launching the emulator. Is this expected behavior? If not, what would be the best way to debug the debugger launch in this case?

Thanks,
Craig

2

FWIW… the test project I’ve been using for testing all of this out can be found in my Github account here: GitHub - csetera/esp32_qemu_testing: Project for use in testing the ESP32 QEMU emulator

I would LOVE any kind of feedback to improve things.

Thanks,
Craig

3

This will only be done if debug_load_cmds (docs) is set to preload.

PlatformIO’s default configuration is to start up the debug server (e.g., “openocd”), which gdb will establish a connection to, and then use the gdb load <path to elf> command to upload the firmware.

With the above config value set to preload, it will however first try to “upload” the firmware (until the upload process exits, by the way), then start the debug sever and connect to it via gdb.

Sure:

  1. Adding support for essentially debug_tool = xtensa-qemu should be done by modifying the platform code (espressif32 in this case) rather an extra script in a project. (This is of course fine for just a proof of concept). This use case is extremely close to other “emulator” / simulator already being used by PlatformIO, e.g., debug_tool = simavr to emulate AVR firmwares using SimAVR. See the relevant Python code for that here. Same goes for debug_tool = renode in e.g. the ststm32 platform. I would suggest forking pioarduino as a base for your modified platform (see below).
  2. Re “The GDB version that is installed for Platformio has a dependency on an older version of Python and does not play nice on newer operating system versions” in the repo: This may be true for the official platformio/platform-espressif32/ platform, but very likely not for pioarduino/platform-espressif32, which is essentially the “up-to-date” continuation of the official platform that supports Arduino-ESP32 3.x, newer boards and newer toolchains. You should check whether these versions still have the problem of the Python2 dependency. That would eliminate your qemu_gdb_override.py hack.
  3. The PoC assumes qemu-system-xtensa to be installed globally on the machine. That’s not how PlatformIO manages tool dependencies normally: You should compile the XTensa Qemu for the common operating systems (Windows x64, Linux x64, MacOS ARM64) and package them as a PlatformIO package (package.json) that can then be uploaded to the PlatformIO registry. That way, a modified espressif32 platform can easily take advantage of the new package, plus it automatically picks the one matching the host architecture. See here for an introduction to the platform internals.
  4. This line assumes the tool-esptoolpy tool used for the project is always at this path. Technically that is not always true, it could also e.g. be tool-esptoolpy@xx.yy.zz. You should be querying the platform for the path to the currently used tool-esptoolpy package. See here.
4

Thanks @maxgerhardt for your detailed response. I will do some poking around and see if I can make some improvement. I’m not sure, however, if I’m interested to get into managing the emulator package repository. None of these languages are even close to my primary programming language, so as you mentioned… I’m hacking together a lot of the pieces :slight_smile:

Craig

5

@maxgerhardt - Thanks again for the pointers.

I was able to switch to pioarduino and as you suggested, that left me with a working GDB implementation. Whether it was that switch or something else, I was finally able to set breakpoints in PIO/VSCode and have them work properly so that is a huge win. I had looked once before at pioarduino, but wasn’t sure what the exact situation was. When I tried it, I was getting errors. It turned out that I had to remove my .pio folder completely before making the switch or I was getting weird errors.

I also made the suggested changed in #4 that you mentioned. One of the many things I was unaware of as I hacked and slashed things together.

I’m not sure I understand how to improve the situation with the emulator launch. Are there any docs about how the various launch pieces come together? Looking at the SimAVR references you provided didn’t really help me get a vision of how things are supposed to fit together. As an embedded hobbyist, I probably don’t have enough experience with different hardware platforms to fully understand how things are put together.

In the end, I have a reasonable set of tools working now that I can use to start going back to the primary project, but I’m willing to keep poking at some of this if there is overall value to others as well as myself.

Thanks again!
Craig