Well, if you read the issue on github and this thread it seems rather clear to me that the problem is with platformio.
If by any chance you find a quick fix I can apply to get debugging working I’d be incredibly thankful! Uploading works now, which was not a big issue because I could always upload via serial. Spent all day tracking this down to get debugging working. I am glad it’s not a hardware issue with my prototypes though!
We’ve just updated openOCD to the latest version but you will need the latest PlatformIO Core Dev and special branch of ESP32 dev-platform. If this works for you, we merge it into develop branch when release PlatformIO Core 5.0.2.
How to try?
Please open PlatformIO Core CLI in VSCode (terminal icon on the blue bottom bar) and type:
@ivankravets Before the update, it worked – both uploading and debugging with an old ESP32 chip. After the update it didn’t work anymore. As it turns out, program_esp32 needs to be changed to program_esp in builder/main.py. With the modification, both uploading and debugging worked again. So there is still a modification needed. I can’t tell anything about the newer chips. I will have to go through by collection of ESP32 boards.
@lienbacher On reading your post the second time, I’ve seen what you have changed. Thanks.
@ivankravets indeed the change in the post I linked above and that manuelbl highlighted is not in this update. seems it only updates the version of openocd, which in turn has some breaking changes explained by the openocd devs in the issue in github I linked above.
Changing main.py fixes uploading, but there’s still a fix necessary for the call of the debugger. Supposedly it is the same fix, but I was unable to find where the debugger is acutally called from.
@ivankravets thank you! Uploading works and the debugger at least starts and does not fail right away anymore.
I am only having the problem that the debugger does not stop on any breakpoints, which is a bit odd. In my experience it should stop right away in app_main() and needs to be manually resumed. however it does neither stop there, and it also does not stop on any breakpoints
esp32: Debug controller 1 was reset.
esp32: Core 1 was reset.
Info : Target halted. CPU0: PC=0x40000400 (active)
Info : Target halted. CPU1: PC=0x40000400
Target halted. CPU0: PC=0x40000400 (active)
Target halted. CPU1: PC=0x40000400
Hardware assisted breakpoint 1 at 0x40117598: file /Users/wolfgang/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp, line 24.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = thb app_main`
PlatformIO: More configuration options -> http://bit.ly/pio-debug
Note: automatically using hardware breakpoints for read-only addresses.
Warn : cpu0: No free slots to add HW breakpoint!
Info : cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : cpu0: Detected debug stubs @ 3ffd9834
cpu0: Detected debug stubs @ 3ffd9834
The ESP32 has only two breakpoints. That’s quite limiting. If you set more breakpoints, it becomes quite unpredictable which ones are honoured and which ones aren’t. Single stepping also needs a breakpoint.
debug_init_break = thb app_main sets a temporary breakpoint on app_main. But the log also contains a warning:
Likely, it was already out of breakpoints… Try it again without setting any breakpoint before your start the debugger.
Turns out, it seems to be only stopping in tasks on core1, i could get it to stop in loop after a good night of sleep. It does however not stop in either of the two possible breakpoints set with debug_init_break`
yes, one change from yesterday: I had debug_init_break = tbh app_maininstead of tbreak for unkown reasons.
yes with all breakpoints disabled I can click pause and resume. If I try step-by-step debugging I get an error in the bottom right: Could not step over: TypeError: Cannot read property 'name' of null. If I get it to stop in the loop and try a step it stops in a very different place of code that is rather far from the next line to be executed and then wont step further.
Guess I will try lower clock speed to see if it changes the behavior. By the way, I can’t seem to find the setting anymore, did the configuration change with the openocd update?
I am also getting a waring on upload, maybe related? WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
I have not specifically selected this file anywhere …