VSCODE ESP32 OLIMEX testing the 'board_debug.adapter_speed' on the new bleeding edge release

Development Platforms
1

I have just tested the fixed bug related to the ‘board_debug.adapter_speed’ configuration option.

platform.ini

[platformio]
default_envs = nodemcu-32s

[env:nodemcu-32s]
;platform = espressif32
platform = GitHub - platformio/platform-espressif32: Espressif 32: development platform for PlatformIO
board = nodemcu-32s
board_debug.adapter_speed = 500
;board_upload.flash_size = 8MB
;board_upload.maximum_size = 8388608
board_upload.flash_size = 4MB
board_upload.maximum_size = 4194304
framework = espidf
monitor_speed = 115200
debug_tool = olimex-arm-usb-ocd-h
upload_protocol = olimex-arm-usb-ocd-h
;board_build.partitions = ESP32_OTA_8M.csv
board_build.partitions = ESP32_OTA_4M.csv

It is still not possible to change the default adapter speed (5000) according to the configuration in the platform.ini file.

PlatformIO: Initializing remote target…
Open On-Chip Debugger v0.10.0-esp32-20201202 (2020-12-02-17:38)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
2
Info : FreeRTOS creation
adapter speed: 5000 kHz

Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 5000 kHz
.
.
.

It of cause helped that the default value has changed from 20000 to 5000 so that the Olimex debugger is able to start.

One peculiar thing I noticed was that in order to start the debug session the first time after upgrading to the new bleeding edge release, I needed to erase the flash (platform/Erase Flash) otherwise I would repeatedly get the error:
“error: JTAG scan chain interrogation failed: all ones”??

The debug session also seem a bit unstable, when setting the first breakpoint (after the app_main() breakpoint) and pressing ‘Continue’ I get the below messages and the breakpoint is never reached.

Thread 1 hit Temporary breakpoint 1, app_main () at src/main.c:132
132 int app_main(void) {
Note: automatically using hardware breakpoints for read-only addresses.
Info : esp32.cpu0: Debug controller was reset.
Info : esp32.cpu0: Core was reset.
esp32.cpu0: Debug controller was reset.
esp32.cpu0: Core was reset.
Info : esp32.cpu1: Debug controller was reset.
Info : esp32.cpu1: Core was reset.
esp32.cpu1: Debug controller was reset.
esp32.cpu1: Core was reset.

2

Looking at the commit that changed it and its commit name ‘Allow overriding debug adapter speed using “debug_speed” option’ I have however tried this

[env:nodemcu-32s]
platform = espressif32
board = nodemcu-32s
debug_speed = 100
framework = arduino
monitor_speed = 115200
debug_tool = olimex-arm-usb-ocd-h
upload_protocol = olimex-arm-usb-ocd-h

(note that per this the new platform 3.0.0 was released yesterday so we can use the normal platform and a pio platform update espressif32).

And a build + Verbose Upload gives

openocd -d2 -s C:/Users/Max/.platformio/packages/tool-openocd-esp32/share/openocd/scripts -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f board/esp-wroom-32.cfg -c “adapter_khz 100” -c “program_esp …”

So it successfully set 100kHz.

They implemented it with just a different name than I thought. I’ll correct my original post.

3

Wow, things happens fast here!

So, what would be the preferred procedure for cleaning up (removing) the “old” installation and making a new clean one base on the stable release (3.0.0)?

4

I’d jsut recommend to update the project from the bleeding edge platform to platform = espressif32 and update as previously said. If one wants to be sure that 3.0.0 is used, one can also write platform = espressif32@3.0.0 to fixate it (until the developer tests the next platform version before updating).

The old C:\Users\<user>\.platformio\platform\espressif32@src-* folder can be kept or deleted, since they’re not used anymore if stable / tagged platform versions are used.

5

Thanks maxgerhardt - I can confirm that the new

debug_speed

option in platform.ini works as expected.

Although I am now experiencing a new error in the ‘debug console’:

Warn : address 0x400d4214 not writable
Error: esp32.cpu0: Failed to write breakpoint instruction (-4)!
Error: esp32.cpu0: Failed to add SW breakpoint!
Error: can’t add breakpoint: unknown reason
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x400d4214

Command aborted.

:face_with_symbols_over_mouth:

6

Hm from the address it is in the external flash memory, which starts at 0x400C_2000 and ends at 0x40BF_FFFF (+74260 bytes from start). But, that memory is read-only (if you don’t want to trigger a flash erase).

Per docs there are a lot of quirks. Seeing

might indicate that you have too many breakpoints active. Clear them all and retry.

Currently GDB can not set software breakpoints in flash. So until this limitation is removed those breakpoints have to be emulated by OpenOCD as hardware ones (see below for details).
…ESP32 debugger supports 2 hardware implemented breakpoints …

If it still does not work, retry on a clean ESP-IDF blinky project.

7

Hmm, aside from the automatic one at ‘app_main ()’ there was only one assigned when I hit the ‘Continue’, which then led to the error.

My segment table:
Partition table

Looking at the docs you linked to it seems I need to put something like this
“esp appimage_offset 0x10000” somewhere in the OpenOCD configuration?

8

I tried the esp-idf blink example (made sure I only added one breakpoint) with the exact same result?

Platform.ini:

[env:esp32dev]
platform = espressif32
framework = espidf
board = nodemcu-32s
monitor_speed = 115200
debug_tool = olimex-arm-usb-ocd-h
upload_protocol = olimex-arm-usb-ocd-h
build_flags =
; https://docs.espressif.com/projects/esp-idf/en/latest/get-started/get-started-wrover-kit.html#rgb-led
-D CONFIG_BLINK_GPIO=2

Debug console:

Thread 1 hit Temporary breakpoint 1, app_main () at src/blink.c:28
28 gpio_pad_select_gpio(BLINK_GPIO);
Warn : address 0x400d09b8 not writable
Error: esp32.cpu0: Failed to write breakpoint instruction (-4)!
Error: esp32.cpu0: Failed to add SW breakpoint!
Error: can’t add breakpoint: unknown reason
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x400d09b8

Command aborted.

Not sure if it was expected but I also needed to erase the flash to get around the “error: jtag scan chain interrogation failed all zeroes”.