Timeout with CMSIS-DAP on ESP32 (OCD-771)

[gudvinr]

Development Kit

None

Module or chip used

ESP-WROOM-32 (Wemos D1-mini32, ESP32-D0WDQ6 (revision v1.0))

Debug Adapter

DAPLink (WCH CH32F103)

OpenOCD version

v0.12.0-esp32-20230419

Operating System

Arch Linux

Using an IDE ?

VSCode (PlatformIO)

OpenOCD command line

/path/to/openocd/bin/openocd -d3 \
-c "gdb_port pipe; tcl_port disabled; telnet_port disabled" \
-s /path/to/openocd/share/openocd/scripts \
-f "interface/cmsis-dap.cfg" \
-c "cmsis_dap_vid_pid 0xc251 0xf001; cmsis_dap_backend hid" \
-c "set ESP32_FLASH_VOLTAGE 3.3" \
-f "target/esp32.cfg"

JTAG Clock Speed

500 (and 5000 too)

ESP-IDF version

v4.4.4 (arduino-esp32 v2.0.9)

Problem Description

1. Attach daplink adapter and the board to PC
2. Run openocd
3. Wait

I am using platformio with following board config:

platform = espressif32@^6.3.2  ; latest default
platform_packages =
	tool-openocd-esp32@^2.1200.20230419 ; default is 2.1100.20220706
debug_tool = custom
debug_server =
  $PLATFORMIO_CORE_DIR/packages/tool-openocd-esp32/bin/openocd
  -d3
  -c "gdb_port pipe; tcl_port disabled; telnet_port disabled"
  -s $PLATFORMIO_CORE_DIR/packages/tool-openocd-esp32/share/openocd/scripts/
  -f "interface/cmsis-dap.cfg"
  -c "cmsis_dap_vid_pid 0xc251 0xf001; cmsis_dap_backend hid"
  -c "set ESP32_FLASH_VOLTAGE 3.3"
  -f "target/esp32.cfg"
debug_speed = 500
upload_protocol = esptool
board = wemos_d1_mini32
board_build.f_cpu = 240000000L

udev rules are set for daplink to work under normal user:

# CMSIS-DAP compatible adapters
ATTRS{product}=="*CMSIS-DAP*", MODE="0666", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_PORT_IGNORE}="1"
ATTRS{product}=="*CMSIS_DAP*", MODE="0666", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_PORT_IGNORE}="1"

cmsis_dap_vid_pid set to c251 f001 according to lsusb:

Bus 001 Device 055: ID c251:f001 Keil Software, Inc. CMSIS_DAP

CMSIS-DAP with cmsis_dap_backend hid seems to be supported since v0.12 as seen in #237 so I can't use default openocd-esp32 that comes with espressif32 platform atm. To work around that I set debug tool in platformio to custom.

I don't use daplink for upload though. It is handled by esptool since I connect to PC via second USB anyway.

Debug Logs

openocd-esp32-verbose-debug.txt

Expected behavior

I kinda expect it to work and jump into debugging.

Screenshots

No response

[erhankur]

@gudvinr Based on the log, it appears that the chip is resetting unexpectedly while running the stub algorithm. Could you please disable flash support and try again? If it succeeds, we can then focus on identifying the specific issue.

/path/to/openocd/bin/openocd -d3 \
-c "gdb_port pipe; tcl_port disabled; telnet_port disabled" \
-s /path/to/openocd/share/openocd/scripts \
-f "interface/cmsis-dap.cfg" \
-c "cmsis_dap_vid_pid 0xc251 0xf001; cmsis_dap_backend hid" \
-c "set ESP32_FLASH_VOLTAGE 3.3" \
-c "set ESP_FLASH_SIZE 0" \
-f "target/esp32.cfg"

[gudvinr]

Could you please disable flash support and try again?

Sure. Now it does not reset but there are still errors:
openocd-log-flash0.txt

Another one with debug_extra_cmds = "set remotetimeout 100000" to avoid timeout errors:
openocd-log-flash0-timeout100.txt

FWIW, esptool reports 4MB flash:

Manufacturer: 20
Device: 4016
Detected flash size: 4MB

[gudvinr]

@erhankur any follow up on this one?

[erhankur]

@gudvinr I couldn't find a time to check your latest logs. I will have a look soon.

[dphzz]

Hello, I am also having the same issue, I was using wuxx nanoDAP firmware on an STM32F103C8T6 and openOCD keeps reporting that the target gets reset continuously.

openocd_esp32_flash0_timeout1000.txt

[erhankur]

@dphzz I did some test here

Reading my notes, you might need to increase reset timeout from the source code. If it helps, I can consider to make it configurable.

[dphzz]

@erhankur Thank you for the quick reply,
Do I have to recompile openOCD from source to adjust that or there is some way to do it from the .cfg file?

[erhankur]

This is not configurable yet. You have to compile it from the source. If you can't, tell me your OS, and I will share the compiled binary.

According to your log, you are a windows user. Can be hard to compile it.

[dphzz]

@erhankur I am running on Windows 10 64bit version (22H2).

[erhankur]

openocd-esp32-win32-0.12.0-esp32-20230419-192-g9ef398ef8.zip

Please replace this package with yours. including script files.

For a reference; I increased this timeout from 100ms to 2000ms now.
https://github.com/espressif/openocd-esp32/blob/master/src/target/espressif/esp32.c#L229

Lets see if it helps.

[dphzz]

@erhankur I run the new openOCD in the terminal, the problem is still the same. It doesn't seem like the timeout was increased at all.
Here is the new log file.
openocd_esp32_flash0_timeout2000.txt

[erhankur]

openocd-esp32-win32-0.12.0-esp32-20230419-193-gd1405eab6.zip

Ok. last try. If it doesn't help, I will re-test with my setup.

[dphzz]

@erhankur The problem still persists.
It worth noting that I was not using the commercial nanoDAP from wuxx like the previously post. I was using an STM32 Bluepill (C8 variant) flashed with wuxx's v2.3 daplink firmware so maybe the problem wasn't from openocd but from the actual firmware itself but I am not sure.

Here is the debug log from the latest attempt.

simple_openocd_esp32_flash0_timeout2000.txt

debug_openocd_esp32_flash0_timeout2000.txt

[erhankur]

At least there is no reset timeout now. I don't know now why your board resetting consistently. Reset reason seems odd. You can try disabling watchdogs. You can make sure, your application works fine without debugger. Or if any chance to connect other debuggers? Sorry, not much familiar with DAP probes.

[dphzz]

@erhankur I did use a jlink to connect to my esp32 running debugger on platformIO and it works fine.
As for the DAP probes, I am running a simple program which print Hello World every second to serial monitor, and when the DAP probe attempt connect to the probe, the serial monitor is garbled into random characters.

[gudvinr]

@erhankur I have FTDI-ish debugger that works with openocd-esp32 and modified config without modifications to source code.

I might test your build with daplink too but I can't really build it myself right now (x86_64 linux).

[erhankur]

@gudvinr you can try
openocd-esp32-linux-amd64-0.12.0-esp32-20230419-193-gd1405ea.tar.gz

[gudvinr]

Now it does not reset indefinitely and I am able to stop at breakpoint but I need some more testing

[arthurfprecht]

Hello! Any follow up on this issue? I have a similar setup from @dphzz - a nanoDAPlink flashed on a STM32F103CB Blue Pill. My ESP32 is a WROOM Dev module. Using the Windows compiled OpenOCD provided here a few posts ago, I don't get the reset timeouts, but the ESP32 keeps being reset, just as @dphzz. On an interesting note, if I put the ESP32 in bootloader mode, the reset messages go away (but the debugging still doesn't work, gdb fails after some time.
OpenOCD log.txt
GDB log.txt

EDIT:
Just as a side note, I tested the OpenOCD provided here with my nanoDAPLink on a different target - a STM32F401 (Black Pill). I used JTAG too, to make sure the problem is not on the debugger. The setup works properly (image attached below). I suspect maybe there is a misconfiguration between the debugger and ESP32, but in any case the debugger is not faulty.

EDIT 2:
I thinkered a little with the nanoDAP debugger, tried to install the latest available firmware (a version that supports bulk driver and some other things). With this, I don't need to reset the ESP32 anymore. Apparently this fixed part of the problem, now the only errors are thrown by gdb (still the same error though). I will put as an attachment the new logs, and also the firmware I used on nanoDAP, so @dphzz can test and see if he gets at least some progress.
log gdb.txt
logOpenOCD.txt
stm32f103xb_stm32f103rb_if_bulk.zip

[erhankur]

@arthurfprecht @gudvinr sorry for the late response. I don't know the latest status of this but to avoid timeout issues, did you try using faster adapter speed like 5000 khz?

[gudvinr]

I switched to different debugger for development but I'll give this daplink one more try.

[erhankur]

@gudvinr I am closing this. Feel free to re-open if you need something from our side.