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.
I donāt have any newer ESP32 boards that I could test. (I found an ESP32-SOLO-1 that doesnāt have all required debug pins, and I found an ESP32-S2, which is not supported yet.)
Great! I think the main goal was to switch to the latest openOCD. We had a blocker issue on the PlatformIO Core side where ESP32 was historically hardcoded.
@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.
Have you tried putting debug_init_break = tbreak app_main, or, if you are debugging an Arduino project debug_init_break = tbreak setup in the platformio.ini?
What happens when you disable all breakpoints, start debugging, then click on the Pause button? Does the chip halt? Can you do further step-by-step debugging and halt on subsequently set breakpoints?
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 ā¦
Well youāre working with arduino so you might want setup as breakpoint, but still app_main should work since itās also defined in the Arduino core, it should stop there then
In my experience thatās an issue that can be ignored because it somehow tries to read some variebles (or the thing you mouse hover over) and if it canāt resolve that, it gives that āerrorā
The OpenOCD board target is implicitly selected for you by having chosen the board = esp32dev, which declares
to change that, set board_debug.openocd_board in the platformio.ini to some other script file name that is in the `scripts/board/ file of the openocd installation. For now it should be okay though.
Hmm, something I overlooked (or consequently ignored), Iām getting an error right after I start the command: zsh: /Users/wolfgang/Library/Python/2.7/bin/pio: bad interpreter: /usr/local/opt/python@2/bin/python2.7: no such file or directory
I guess I ignored it since I know pio comes with itās own python 3, but itās still odd it pops up in the firstplace and might be related.
Nevertheless It crashes with a curious error, hereās the log after compiling:
Tool Manager: Installing platformio/contrib-pysite @ ~2.37.0
Unpacking [####################################] 100%
Tool Manager: contrib-pysite @ 2.37.191020 has been installed!
Tool Manager: Removing contrib-pysite @ 2.38.201019
Tool Manager: contrib-pysite @ 2.38.201019 has been removed!
Reading symbols from /Users/wolfgang/Documents/PlatformIO/Projects/AltimeterLVGL2/.pio/build/esp32dev/firmware.elf...done.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = esp-prog
PlatformIO: Initializing remote target...
Open On-Chip Debugger v0.10.0-esp32-20200709 (2020-07-09-08:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 20000 kHz
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : Configured 2 cores
adapter speed: 20000 kHz
Info : tcl server disabled
Info : telnet server disabled
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : cpu0: Detected debug stubs @ 3ffd9834
Info : accepting 'gdb' connection from pipe
Error: No symbols for FreeRTOS
Info : Target halted. CPU0: PC=0x4009177C (active)
Info : Target halted. CPU1: PC=0x400F01CE
Info : cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3f400020, 721 KB
Info : Flash mapping 1: 0xd0018 -> 0x400d0018, 966 KB
Info : cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Auto-detected flash bank 'esp32.flash' size 4096 KB
Info : Using flash bank 'esp32.flash' size 4096 KB
Info : cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3f400020, 721 KB
Info : Flash mapping 1: 0xd0018 -> 0x400d0018, 966 KB
Info : Using flash bank 'esp32.irom' size 968 KB
Info : cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3f400020, 721 KB
Info : Flash mapping 1: 0xd0018 -> 0x400d0018, 966 KB
Info : Using flash bank 'esp32.drom' size 724 KB
0x4009177c in vTaskEnterCritical (mux=<optimized out>)
at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c:4206
4206 /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c: No such file or directory.
Loading section .flash.rodata, size 0xb63b8 lma 0x3f400020
(gdb) .pioinit:12: Error in sourced command file:
Load failed
So i canāt even type the second commands you asked
Hm, there might be a conflicting global PlatformIO installation that was installed using the outdated Python 2.7ā¦ You may still be able to access the Python3-CLI interface from the Toolbar ā PlatformIO Terminal? And execute python --version or pio system info to make sure itās running Python3, too. Then try the PIO commands again.
Please remove ALL duplicated PlatformIO Cores Redirecting...
Ensure that you have enabled āUse built-in PlatformIO Coreā and ābuilt-in Pythonā settings within PlatformIO IDE for VSCode. Restart VSCode.
P.S: When you start PlatformIO Core CLI within VSCode, you should see Python 3.8 when type python --version. Itās our pre-compiled portable Python for macOS. We plan to drop support for Python 2 soon.