- This topic has 3 replies, 2 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
Hello,
I’m struggling to make the JTAG work on ESP8266. I tried my own board with the Segger J-link, the same I’m using with success with the ESP32, but I always get the “Error: JTAG scan chain interrogation failed: all zeroes”.
Then I tried to use a NodeMCU board and an Olimex Debugger, like your example https://visualgdb.com/tutorials/esp8266/nodemcu/jtag/, however I get the same error. This is the debug log when I try to connect to the NodeMCU:
C:\Users\Mattia\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp8266.core\bin\openocd.exe -c “gdb_port 49839” -c “telnet_port 49840” -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -c “adapter_khz 3000” -f target/esp8266.cfg -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.9.0 (2015-11-04-20:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 3000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter speed: 1000 kHz
stop_wdt
VisualGDB_OpenOCD_Ready
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Error: esp8266.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Warning: Target not halted, breakpoint/watchpoint state may be unpredictable.
Info : accepting ‘gdb’ connection on tcp/49839
Info : dropped ‘gdb’ connectionI tried to see with the oscilloscope, and the reset pin never goes down. A part from this, the clock and TDI is putting data into the target, but TDO never outputs anything.
Do you have an idea of why I can’t connect?
Thank you,
Mattia
Usually, this type of error is caused by power (i.e. power not stable enough and the board keeps resetting), wiring (e.g. incomplete soldering or short-circuited pins) or the existing firmware disabling the JTAG pins (erasing the FLASH memory via esptool.py should take care of that).
If the reset is never issued, please try using both pins 3 and 15 (different debug probes use different reset pin by default). Also make sure the esp8266.cfg file has not been modified and still sets reset_config to trst_and_srst). If you are not sure, you can also delete and reload the ESP8266 OpenOCD package via VisualGDB Package Manager.
Hello,
the Power supply seems to be very stable, and I recontrolled the wiring to be sure not to make any error. I replaced the firmware with the one from the “Hello World” example, putting the bootloader in 0x0000, partition table at 0x8000 and the firmware at 0x10000.
I also checked the esp8266.cfg in the target file, which, in my case, is “c:\Users\Mattia\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp8266.core\share\openocd\scripts\target\”, and it has the following instruction:
set _CHIPNAME esp8266
transport select jtag
reset_config trst_and_srst
adapter_khz 1000
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME xtensa -endian little -chain-position $_TARGETNAME# esp8266 seems to have a quirk where the JTAG hardware doesn’t work
# at all for ~20ms after RST is released. We do a custom reset to
# avoid JTAG layer errors
proc init_reset {mode} {
# assert both resets (SRST/TRST not a clear division on esp8266 anyhow)
jtag_reset 1 1
sleep 30
jtag_reset 0 0# wait for debug port to wake up
sleep 30# validate scanchain
jtag arp_init
}# Disable system watchdog when halted to avoid unexpected resets
$_TARGETNAME configure -event halted {
stop_wdt
}proc stop_wdt { } {
mww 0x60000900 0
}But I still can’t go in JTAG mode.
In any case I can see the reset pin going down, neither in pin 3 nor in pin 15. Is there any other way to reset the chip, even manually, to enter in JTAG debug?
Thank you,
Mattia Berton
- You must be logged in to reply to this topic.