Problem debugging ESP32-WROOM-32 with esp-prog

I have an AZ-Delivery - ESP32 Dev KitC V2 - ESP32-WROOM-32 and an ESP-PROG bebug board and the objective is to step-through debug.

I’ve wired the boards up as follows:

ESP-Prog wiring DevKit
TMS GPIO 14
TCK GPIO 13
TDO GPIO 15
TDI GPIO 12

I’m using Visual Studio Code / PlatformIO. The application is:

void setup()
{
    Serial.begin(115200);
}

void loop()
{
    Serial.println("Hello World");
    delay(1000);
}

The platformio.ini configuration is:

[env]
lib_deps = arduino-libraries/Arduino_JSON@^0.1.0

[env:esp-prog]
platform = espressif32
board = esp32dev
framework = arduino

monitor_speed = 115200
monitor_port = /dev/cu.usbserial-14200
monitor_filters = esp32_exception_decoder

upload_speed = 115200
upload_port = /dev/cu.usbserial-14200
upload_protocol = esp-prog

build_type = debug 
build_flags = -DUSBPORT=/dev/cu.usbserial-14200

platform_packages =
    tool-openocd
    tool-esptoolpy@1.30300.0
    framework-arduinoespressif32@https://github.com/espressif/arduino-esp32.git

debug_tool = esp-prog
debug_port = /dev/cu.usbserial-14200
debug_speed = 100
debug_init_break = tbreak setup
debug_build_flags = -O0 -g -ggdb
debug_init_cmds = target extended-remote /dev/cu.usbserial-14200
debug_server =
    /Users/[USER]/.platformio/packages/tool-openocd-esp32/bin/openocd
    -s
    /Users/[USER]/.platformio/packages/tool-openocd-esp32/share/openocd/scripts
    -f
    /Users/[USER]/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/interface/ftdi/esp32_devkitj_v1.cfg
    -f
    /Users/[USER]/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/board/esp-wroom-32.cfg

Build is successful
Upload is successful
Debugging doesn’t work. I have a breakpoint on the setup method but when I select Run → Start Debugging, the breakpoint is not hit and the debug control panel displays:

DubugPanel

Please, can anyone advise on what I’m doing wrong?

That’s not even used for esp32, it’s using the tool-openocd-esp32 pacakge

This seams rather complicated, and you’re overwriting the init_cmds where the init_break would have been set – not good.

With just

[env]
lib_deps = arduino-libraries/Arduino_JSON@^0.1.0

[env:esp-prog]
platform = espressif32
board = esp32dev
framework = arduino

monitor_speed = 115200
monitor_port = /dev/cu.usbserial-14200
monitor_filters = esp32_exception_decoder

upload_speed = 115200
upload_port = /dev/cu.usbserial-14200
upload_protocol = esp-prog

build_type = debug 
build_flags = -DUSBPORT=/dev/cu.usbserial-14200

platform_packages =
    tool-esptoolpy@1.30300.0
    framework-arduinoespressif32@https://github.com/espressif/arduino-esp32.git

debug_tool = esp-prog
debug_port = /dev/cu.usbserial-14200
debug_speed = 100
debug_init_break = tbreak setup
debug_build_flags = -O0 -g -ggdb

what happens there?

Thanks for your response, Max, and simplification of my platformio.ini but unfortunately the result is the similar.
Build and upload are successful but Run → Start Debugging results in:

Again, the debug panel shows the same; I can restart and stop but nothing else.
No breakpoints are hit.
I realise from the result screenshot that there is an issue with ‘Obsolete PIO Core v6.0.2’ but this doesn’t appear to be critical.

I’m new to the esp32 environment and debugging sounded to be a simple process. I’m really confused.
Have you any other suggestions?

VSCode has a bottom “Debug Console” tab (next to the “Output” tab), what does it say in there?

Does pressing pause halt the microcontroller?

Do you mean ‘pause’ on the debug panel? If so, it’s not enabled to push.
DubugPanel

The complete Debug Console displays:

Processing esp-prog (platform: espressif32; board: esp32dev; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (4.4.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (cmsis-dap, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 @ 2.0.4+sha.cf01523
 - tool-esptoolpy @ 1.30300.0 (3.3.0)
 - tool-openocd-esp32 @ 2.1100.20220411 (11.0)
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 33 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Arduino_JSON @ 0.1.0
Building in debug mode
Retrieving maximum program size .pio/build/esp-prog/firmware.elf
Checking size .pio/build/esp-prog/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   5.0% (used 16396 bytes from 327680 bytes)
Flash: [==        ]  18.7% (used 244861 bytes from 1310720 bytes)
========================= [SUCCESS] Took 1.95 seconds =========================
undefinedOpen On-Chip Debugger  v0.11.0-esp32-20220411 (2022-04-11-08:47)
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.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 100 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 100 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 : starting gdb server for esp32.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Reading symbols from /Users/[USER]/SOURCECODE/Defineline/ProofOfConcept02/Debug/.pio/build/esp-prog/firmware.elf...
PlatformIO Unified Debugger -> https://bit.ly/pio-debug
PlatformIO: debug_tool = esp-prog
PlatformIO: Initializing remote target...
.pioinit:11: Error in sourced command file:
/dev/cu.usbserial-14100: Resource busy.

Can you remove the debug_port = .. line from the platformio.ini and retry?

I’ve removed debug_port = /dev/cu.usbserial-14100 from platformio.ini

The build is successful.
The upload responds in various ways. I’ve listed below the differences but in all ‘successful’ uploads the debug panel is the same as always
DubugPanel
and no breakpoints are hit.

UPLOAD 1…

** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Warn : Unsupported syscall 3f4014c8!
Warn : Unsupported syscall ffffffff!
shutdown command invoked
============================================ [SUCCESS] Took 144.14 seconds ============================================

UPLOAD 2…

Warn : JTAG tap: esp32.cpu1       UNEXPECTED: 0x1a7285fd (mfg: 0x2fe (W5 Networks), part: 0xa728, ver: 0x1)
Error: JTAG tap: esp32.cpu1  expected 1 of 1: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Error: auto0.tap: IR capture error; saw 0x0003 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Warn : target esp32.cpu0 examination failed
Warn : target esp32.cpu1 examination failed
Error: auto0.tap: IR capture error; saw 0x0003 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Error: Couldn't halt target before SoC reset
embedded:startup.tcl:1162: Error: ** Unable to reset target **
in procedure 'program_esp'
in procedure 'program_error' called at file "/Users/[USER]/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 93
at file "embedded:startup.tcl", line 1162
*** [upload] Error 1
============================================= [FAILED] Took 2.56 seconds =============================================

UPLOAD 3…

** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Warn : Unsupported syscall 3f4014c8!
Warn : xtensa_write_memory: esp32.cpu1: target not halted
Error: Failed to write ESP32_TIMG0WDT_PROTECT (-304)!
Warn : Unsupported syscall ffffffff!
Warn : Unsupported syscall ffffffff!
shutdown command invoked
============================================ [SUCCESS] Took 146.19 seconds ============================================

UPLOAD 4…

Warn : Unsupported syscall ffffffff!
...
... [repeated 19 times]
...
Warn : Unsupported syscall ffffffff!
Error: timed out while waiting for target halted
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Warn : Unsupported syscall 3f4014c8!
Warn : Unsupported syscall ffffffff!
shutdown command invoked
============================================ [SUCCESS] Took 158.35 seconds ============================================

The connection seems to be quite unstable if it detects these wrong things… there are multiple biterrors there. However, you already set the connection speed down to 100khz…

Are you plugging the ESP-Prog directly into the dev board via female-to-female cables, without a breadboard? Have you tried other cables?

The cabling has been messy. Initially, I did use female-to-female cables between the esp-prog and the dev board. I’m currently using breadboards to mount the dev board with female-to-male and does appear to be more stable.
I’m also using 2 USB cables to power each board. I have occasionally used just 1 USB to the esp-prog and used the power supply from it to the dev board but opted to use 2 USB’s to at least be sure of the power supply. Which approach is better?

The upload now shows a consistent response which is:

Error: Failed to get flash maps (4294967295)!
Warn : Failed to get flash mappings (-4)!
Error: Failed to get flash maps (4294967295)!
Warn : Failed to get flash mappings (-4)!
** Programming Started **
** Programming Finished **
** Verify Started **
Error: **** Verification failure! ****
Error: target_hash f12b21...20e145
Error: file_hash: eee764...6ea591
embedded:startup.tcl:1162: Error: ** Verify Failed **
in procedure 'program_esp' 
in procedure 'program_error' called at file "/Users/[USER]/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 135
at file "embedded:startup.tcl", line 1162
*** [upload] Error 1
============================================= [FAILED] Took 89.18 seconds =============================================

Hopefully this is narrowing the problem down but I’m still lost and your help is really, REALLY appreciated! Thank you!!

A common cause for this is to use the JTAG pins for something else, e.g. by wiring up LEDs, buttons or other peripherals or by configuring them in software as GPIO, I2C etc.

I recommend to upload the simplest firmware/sketch possible, like a Blink sketch using an LED pin that certainly does not conflict with JTAG.

1 Like

The code being used is:

#include <Arduino.h>

void setup()
{
    Serial.begin(115200);
}

void loop()
{
    Serial.println("Hello World");
    delay(1000);
}

I’m not using any other peripherals.
I’ve switched between 3 different dev boards but the results are the same.
I used a fresh set of wires and have checked my wiring matches this:

ESP-Prog  -> Dev board
TMS      -> GPIO 14
TCK      -> GPIO 13
TDO      -> GPIO 15
TDI      -> GPIO 12
GND      -> GND
VDD      -> 5v 

Is this right?

I only use VDD when using 1 USB to esp-prog.
Any other suggestions are welcome and appreciated!

Looks ok except for VDD -> 5V. The ESP-Prog does not provide sufficient power to also feed the ESP32. It will become unreliable as it crashes when it gets insufficient power during spikes of power consumption.

Can you try a minimalistic platformio.ini:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
upload_protocol = esp-prog
debug_tool = esp-prog
debug_init_break = tbreak setup

You won’t see any serial output. And do not use the serial monitor. It’s just for isolating the problem.

This worked! I can now step-through debug the ‘Hello World’ app, which is exactly what I wanted.
The debug console displays:

What do I do to enable the serial monitor?

You can now addd these lines again:

monitor_speed = 115200
monitor_port = /dev/cu.usbserial-14200
monitor_filters = esp32_exception_decoder

But make sure the monitoring port is the serial port of the ESP32 board and not a serial port of the ESP-Prog.

Then click “Serial Monitor” in the status bar.

Absolutely perfect!!! Thanks to maxgerhardt and manuelbl for patiently guiding me to a solution.

For the benefit of others - I’m a newbie with esp32 programming and my objective was to use an eps32 board with an esp-prog board to step-through debug a ‘Hello world’ app.

I believe the fundamental problem that I didn’t even realise I was experiencing was bad wiring, which maxgerhardt raised. I had been using wires between the boards but then mounting the dev board on a breadboard and using a new set of wires has certainly stabilised things. However, the wiring is still not perfect and I’m still getting an occasional error but now I know it means the cables need checking!

I also think that I caused problems for myself by finding ‘potential’ fixes to the various errors (misinterpreted by me) and over complicating platformio.ini, plus me adding things that ‘appeared’ to be a good idea. maxgerhardt advised substantially reducing platformio.ini and this eliminated conflicts I didn’t realise I’d invoked. This narrowed down and revealed a single error. Subsequently, manuelbl suggested to go right back to the bare minimum and this solved my self-inflicted problem.

Another crucial mistake I’d made was noticed when manuelbl explained adding the monitor_* parameters. I’d not realised the monitor_port should be for the dev board and not the esp-prog board.

1 Like