ESP32-Pico-V3 fails to upload/debug using esp-prog

see this post

@ivankravets wow you rock, that was really fast! Trying right away.

@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.

@manuelbl happens to me all the time, no worries :slight_smile:

@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ā€™ve changed program_esp32 to program_esp in two places, about 5 lines apart. Did you do the same?

Sorry, fixed in Use "program_esp" command for new openOCD Ā· platformio/platform-espressif32@7b932d1 Ā· GitHub

Could you re-run pio update to pull the latest changes from the temporary feature/openocd-update branch?

Yes, that works. Thanks.

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.

This commit allows dev-platform to re-configure debugging options. An example:
https://github.com/platformio/platform-espressif32/blob/feature/openocd-update/platform.py#L159

We are going to release PIO Core 5.0.2 this week.

yes thatā€™s what I did too.

@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 :thinking:

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.

no dice, does not stop. If I remove all breakpoints the no free slots error is gone, but it still wont stop anywhere :confused:

[Switching to Thread 1073467744]
_frxt_int_enter () at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/portasm.S:132
132	/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/portasm.S: No such file or directory.
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)
JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : cpu0: Debug controller 0 was reset.
Info : cpu0: Core 0 was reset.
cpu0: Debug controller 0 was reset.
cpu0: Core 0 was reset.
Info : cpu0: Target halted, PC=0x500000CF, debug_reason=00000000
cpu0: Target halted, PC=0x500000CF, debug_reason=00000000
Info : esp32: Core 0 was reset.
esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.
esp32: Debug controller 1 was reset.
esp32: Core 1 was reset.
Info : Target halted. CPU0: PC=0x40000400 (active)
Target halted. CPU0: PC=0x40000400 (active)
Info : Target halted. CPU1: PC=0x40000400 
Target halted. CPU1: PC=0x40000400 
  1. Can you show the full platformio.ini?
  2. 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?
  3. 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`

  1. hereā€™s my platformio.ini:
[platformio]
default_envs = esp32dev

[env:esp32dev]
#platform = espressif32
platform = https://github.com/platformio/platform-espressif32#feature/openocd-update
board = esp32dev
board_build.partitions = huge_app.csv
framework = arduino
monitor_speed = 115200

monitor_port = /dev/cu.usbserial-1414301
debug_tool = esp-prog
upload_protocol = esp-prog
board_debug.openocd_board = esp32-ethernet-kit-3.3v.cfg
debug_init_break = tbreak app_main
; debug_init_break = tbreak setup

board_build.f_flash = 80000000L

lib_deps =
  TFT_eSPI
  Button2
  FastLED

build_flags =
  -D LV_CONF_INCLUDE_SIMPLE
  -I src
  1. yes, one change from yesterday: I had debug_init_break = tbh app_maininstead of tbreak for unkown reasons.

  2. 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 ā€¦

Letā€™s investigate this issue without IDE.

  1. Please open PlatformIO Core CLI (terminal icon on the bottom blue bar) and type:
cd /path/to/platformio/project
pio debug --interface=gdb -x .pioinit

Did it stop at app_main?

  1. Now type tbh setup and type c (continue). Did it stop at setup?

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.

As Ivan said, try from the CLI.

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 :confused:

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.

You will not come to success.

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.

thank you @ivankravets!
Here comes the fun part:
Bildschirmfoto 2020-10-27 um 11.33.36

I have also never installed a second pio core, nevertheless, running pip uninstalled platformio removed version 5.0.2b2 from /user-library/Python/3.7/..., I have zero clue how it got there, nevertheless itā€™s gone. Restarting vscode has pio home launch normally. Running python --version before and after uninstalling returns python 2.7.16 ā€“ I am very sure this returned version 3.8 within as Iā€™ve checked within the past few weeks. Maybe related to the switch to the dev version?

Do you see ~/.platformio/python3 folder?

Hi @lienbacher ! According to your log above, OpenOCD wasnā€™t able to upload all app images to your target. Itā€™s hard to guess why that happened, but itā€™d be great if you try to debug a simple blink project, just to make sure the debugging at least works with default settings.

1 Like