ESP32 Forum

Hi,

Thanks for the reply.

The info about ctrl-T ctrl-R is very useful thanks for that, looking into it ctrl-T ctrl-F flash the target as well. So now I can just leave the monitor running and flash and reset from it. This is very good as I have issues with the EN button not resetting on mine.

I also have openocd working from Eclipse now which seems to be working pretty well. If anyone else is interested there is a very useful blog about setting it up here: https://www.matthias-jentsch.de/2017/02 ... d-openocd/

So my issues seem to have even caused by the default esp32.cfg file needing to be changed to 3.3V and the fact that my EN button was not resetting the board in order to try to get the thing to halt.

Is there a reason that "mon reset halt" is not working the way gdb would like it to?

Essentially, 'mon reset halt' is broken in two ways. First of all, it does not reset the SOC, but only the cores (and maybe even only the active core, I don't remember that detail). That can leave WiFi, BT or other hardware peripherals in a state where the SOC doesn't boot up correctly. Secondly, 'mon reset halt' halts before FreeRTOS starts up. The OpenOCD implementation of FreeRTOS compatibility always looks for FreeRTOS structures in the location the binary you're debugging indicates; when FreeRTOS hasn't started yet, these locations can contain garbage, leading to all kinds of interesting issues with weird GDB messages about threads.

Thanks very much for the info.

Will these be "fixed" or is that not possible?

The first part is fixable: we can eg tickle the RTC WDT to do a SOC reset. The second one isn't directly solvable in a way that other chips work, but letting 'mon reset halt' run to the first point after FreeRTOS startup will give an experience that should conform to how many people use OpenOCD/GDB on the ESP32.

HI,

Super, thanks for the info.

Andy

I wanted to thank @AndyCap for his post:

AndyCap » Thu Apr 13, 2017 5:13 am

I had exactly the same issue and problems as your described and I too was trying to debug SPI. The time you took to post a follow on and describe that as an issue saved me much time. Thank you kind sir.

Also, while you're kicking this topic, a few things I said aren't applicable in the current openocd-esp32 version anymore; for instance, 'mon reset halt' should work now.

I'm running into a similar issue. I have an esp-Wrover-Kit. I installed Msys32 and esp-idf using the versions in the espressif instructions.
I start bash and enter :
bin/openocd.exe -f share/openocd/scripts/interface/ftdi/esp32_devkitj_v1.cfg -f share/openocd/scripts/board/esp32-wrover.cfg

I get the following error:

$ bin/openocd.exe -f share/openocd/scripts/interface/ftdi/esp32_devkitj_v1.cfg -f share/openocd/scripts/board/esp32-wrover.cfg
Open On-Chip Debugger 0.10.0-dev-ga859564 (2017-07-24-16:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 20000 kHz
force hard breakpoints
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : esp32: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
Info : esp32: Core was reset (pwrstat=0xFF, after clear 0xFF).
Error: cpu0: esp32_fetch_all_regs (line 163): DSR (FFFFFFFF) indicates target still busy!
Error: cpu0: esp32_fetch_all_regs (line 163): DSR (FFFFFFFF) indicates DIR instruction generated an exception!
Error: cpu0: esp32_fetch_all_regs (line 163): DSR (FFFFFFFF) indicates DIR instruction generated an overrun!
Error: cpu0: esp32_fetch_all_regs (line 190): DSR (FFFFFFFF) indicates target still busy!
Error: cpu0: esp32_fetch_all_regs (line 190): DSR (FFFFFFFF) indicates DIR instruction generated an exception!
Error: cpu0: esp32_fetch_all_regs (line 190): DSR (FFFFFFFF) indicates DIR instruction generated an overrun!
Error: Exception reading pc!

Info : Target halted. PRO_CPU: PC=0x00000000 APP_CPU: PC=0x00000000 (active)
Error: cpu0: xtensa_write_memory (line 696): DSR (FFFFFFFF) indicates target still busy!
Error: cpu0: xtensa_write_memory (line 696): DSR (FFFFFFFF) indicates DIR instruction generated an exception!
Error: cpu0: xtensa_write_memory (line 696): DSR (FFFFFFFF) indicates DIR instruction generated an overrun!
Warn : esp32: Failed writing 4 bytes at address 0x3FF5F064, data - a1, 3a, d8, 50, a1, 3a, d8, 50
embedded:startup.tcl:21: Error:
in procedure 'init'
in procedure 'ocd_bouncer'
in procedure 'flash'
in procedure 'ocd_bouncer'
in procedure 'esp_core_halt'
in procedure 'esp32' called at file "share/openocd/scripts/target/esp32.cfg", line 44
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 21

I have all jumpers placed on the board exactly as pictured in the espressif instructions for the Wrover board, and nothing else connected to the board.

Any Ideas?

Thanks

Do you perhaps have code running on the ESP32 that reconfigures the GPIOs used for JTAG to something else?

Hi all,
Excuse me but it is the first time I participate in the forum, and I do not really know if this is the best way to proceed.
My case is the same as dkunzig. I also have the ESP32-WROVER-KIT on its factory configuration (an RGB is blinking on red, blue and green colour constantly). I am following the espressif instructions and all is fine until I start bash and enter:
bin/openocd.exe -f share/openocd/scripts/interface/ftdi/esp32_devkitj_v1.cfg -f share/openocd/scripts/board/esp32-wrover.cfg

After that, I have the same error as dzunkig:

none separate
adapter speed: 20000 kHz
force hard breakpoints
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
....

I bought the ESP32-WROVER-KIT because I want to work with the debug functionality. I am spending so many time on this and I am pretty sure that this is a very simple error, that probably most of you have solved in an easy way.

Could you suggest me anything to solve this problem?

Thanks in advance.