esp-wrover-kit - JTAG help please.

[AndyCap]

Hi Guys,

(Reposting this as it doesn't seem to have worked last time!)

Been banging my head against the wall here for hours and have to give up, any help would be appreciated.

I have built openocd-esp32.

I have the following esp.cfg

Code: Select all

#
# Example configuration file to hook up an ESP32 module or board to a JTAG 
# adapter. Please modify this file to your local setup.
#
#


# Include the configuration for the JTAG adapter. We use the Tian TUMPA here.
# If you have a different interface, please edit this to include the 
# configuration file of yours.
source [find interface/ftdi/esp32_devkitj_v1.cfg]

# The ESP32 only supports JTAG.
transport select jtag

# The speed of the JTAG interface, in KHz. If you get DSR/DIR errors (and they
# do not relate to OpenOCD trying to read from a memory range without physical
# memory being present there), you can try lowering this.
adapter_khz 200

# With no variables set, openocd will configure JTAG for the two cores of the ESP32 and
# will do automatic RTOS detection. This can be be adjusted by uncommenting any of the
# following lines:

# Only configure the PRO CPU
#set ESP32_ONLYCPU 1
# Only configure the APP CPU
#set ESP32_ONLYCPU 2
# Disable RTOS support
#set ESP32_RTOS none
# Force RTOS to be FreeRTOS
#set ESP32_RTOS FreeRTOS

#Source the ESP32 configuration file
source [find target/esp32.cfg]


# The TDI pin of ESP32 is also a bootstrap pin that selects the voltage the SPI flash
# chip runs at. When a hard reset happens (e.g. because someone switches the board off
# and on) the ESP32 will use the current TDI value as the bootstrap value because the
# JTAG adapter overrides the pull-up or pull-down resistor that is supposed to do the
# bootstrapping. These lines basically set the idle value of the TDO line to a 
# specified value, therefore reducing the chance of a bad bootup due to a bad flash
# voltage greatly.

# Enable this for 1.8V SPI flash
esp108 flashbootstrap 1.8
# Enable this for 3.3V SPI flash
#esp108 flashbootstrap 3.3

when I run ./openocd-esp32/src/openocd -s ./openocd-esp32/tcl -f ./openocd-esp32/esp32.cfg

I get:

Code: Select all

Open On-Chip Debugger 0.10.0-dev-g90071eb8 (2017-04-12-14:58)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate
none separate
adapter speed: 200 kHz
force hard breakpoints
Info : clock speed 200 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.cpu0: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
Info : esp32.cpu0: Core was reset (pwrstat=0xFF, after clear 0xFF).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
Info : esp32.cpu1: Core was reset (pwrstat=0xFF, after clear 0xFF).

Anyone any ideas what might be going wrong, do I have the wrong source: source [find interface/ftdi/esp32_devkitj_v1.cfg]

Cheers

Andy

[ESP_Sprite]

Do you have jumpers installed on JP8? All but the top and bottom positions should have a jumper.

[AndyCap]

Hi,

Thanks very much for the reply.

Yep I have all the jumpers installed and have managed to get over the initial problem which seemed to be caused by code using the HSPI running on the ESP32.

I have since entered another world of hurt!

I don't see a way to flash over jtag at the moment is that correct?

On OXS the debugging seems to work most of the time, the only problem is that openocd only seems to be able to connect if I unload the usb serial kext and then I can't flash it or use the 2nd part over usb connection.

So I tried linux and just failed to get it working, only core 0 was being halted on reset (sometimes) core 1 has a life of its own and refuses to halt.

Should the jtag debugging be working or is it still work in progress?

All the best

Andy

[f.h-f.s.]

I have a lot of trouble with debugging too, but that could just be because im using visualgdb(which uses an old esp-idf).
You can flash over JTAG. Visualgdb does this by default.
https://esp32.com/viewtopic.php?f=2&t=854&start=10

[f.h-f.s.]

I have a lot of trouble with debugging too, but that could just be because im using visualgdb(which uses an old esp-idf).
You can flash over JTAG. Visualgdb does this by default.

I posted some info about how VisualGDB does that here:
https://esp32.com/viewtopic.php?f=2&t=854&start=10

[AndyCap]

Thanks for those logs, I'll have a close look and see if i can work the flashing out...

[AndyCap]

I think I am going to have to give up with this board

I only got the esp-wrover-kit as it had jtag debugging and it is hopeless, very temperamental.

Has anyone got a recomendation for a jtag interface that actually woks with the ESP32?

Thanks

Andy

[f.h-f.s.]

I'm using a olimex-arm-usb-ocd with a LoPy. I've given up debugging since it was very temperamental. I debug through print lines, and flash through JTAG now. GDBStub works though, and the backtrace is very usefull. stackoverflow detection and keeping a eye on my heapspace have helped me alot.

[AndyCap]

Hi,

Thanks for the info.

I have managed to make it a little more stable by setting it to 3.3V flash in the esp32.cfg file.

Also I have worked out that my EN/Reset button doesn't seem to work unless I have a serial connection open, very weird. I did read that there was an issue with some of the boards with the EN button, looks like mine is one of them.

With it set up like this I can actually get a halt when I reset the board and gdb will work for a while.

I will try getting the flash working now...

Cheers

Andy

[ESP_Sprite]

To be honest, the OpenOCD implementation still has some rough edges that we need to iron out one of these days, but it should be functional. At the moment, I think you're running into the issue that 'mon reset halt' doesn't do what gdb expects it to do. The workflow that actually works best is to start OpenOCD, reset the board manually or using ctrl-T ctrl-R in 'make monitor', then start gdb. Execution should then have halted before the FreeRTOS schedule has started.