- This topic has 15 replies, 3 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
I’m trying to follow the tutorial here: https://visualgdb.com/tutorials/esp8266/openocd/
I’ve double checked my connections. I have pin 3 from the J-Link (nTRST) connected to CON3-15 of the Olimex board (RSTB).
While VisualGDB appears to complete uploading of the firmware, it never breaks at my breakpoint, and the LED on board the ESP8266 board flashes much faster than the delay in LEDBlink code would seems to dictate.
The openocd log shows the dreaded “all zeros” error.
What am I doing wrong? Thanks.
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
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter speed: 1000 kHz
stop_wdt
Info : J-Link V10 compiled Oct 9 2015 20:36:39
Info : J-Link caps 0xb9fe7bbf
Info : J-Link hw version 101000
Info : J-Link hw type J-Link
Info : J-Link max mem block 26488
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.341 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : TAP esp8266.cpu does not have IDCODE
Warn : Warning: Target not halted, breakpoint/watchpoint state may be unpredictable.
Info : accepting 'gdb' connection on tcp/3333
undefined debug reason 7 - target needs reset
Warn : target not halted
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 : xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same
thing!)
target state: halted
Info : halted: PC: 0x400043e6
Info : debug cause: 0x20
Info : halted: PC: 0x400043e1
Info : debug cause: 0x1
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Interrupt suppression during single-stepping is now enabled
Watchdog feeding during stops is now enabled
Info : halted: PC: 0x40100004
Info : debug cause: 0x2
Hi,
J-Link might handle resetting differently. Please try connecting reset to SRST instead of TRST (normally pin 15). If this does not help, please try disconnecting reset completely and manually resetting the board before programming it.
Still no luck, but I’m not sure if I’m manually resetting the board correctly.
If I connect to pin 15 of the J-Link instead of 3, it hangs on Loading Image, and the log still shows the “all zeros” error.
If I disconnect reset, and power cycle the board with the button held down, it behaves about the same (appears to finish loading the image, does not break), but the green LED stays off, and the “all zeros” error goes away.
Log with pin 15 reset:
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 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter speed: 1000 kHz stop_wdt Info : J-Link V10 compiled Oct 9 2015 20:36:39 Info : J-Link caps 0xb9fe7bbf Info : J-Link hw version 101000 Info : J-Link hw type J-Link Info : J-Link max mem block 26488 Info : J-Link configuration Info : USB-Address: 0x0 Info : Kickstart power on JTAG-pin 19: 0xffffffff Info : Vref = 3.322 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Info : clock speed 1000 kHz Info : TAP esp8266.cpu does not have IDCODE Info : halted: PC: 0x40002eee Info : debug cause: 0x20 Info : accepting 'gdb' connection on tcp/3333 Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors Warn : xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same thing!) Error: timed out while waiting for target halted TARGET: esp8266.cpu - Not halted in procedure 'reset' in procedure 'ocd_bouncer' Warn : WARNING! The target is already running. All changes GDB did to registers will be discarded! Waiting for target to halt. Info : Halt timed out, wake up GDB. Warn : target esp8266.cpu is not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Warn : target not halted Error: Memory write failure! Warn : WARNING! The target is already running. All changes GDB did to registers will be discarded! Waiting for target to halt.
Log with manual reset:
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 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter speed: 1000 kHz stop_wdt Info : J-Link V10 compiled Oct 9 2015 20:36:39 Info : J-Link caps 0xb9fe7bbf Info : J-Link hw version 101000 Info : J-Link hw type J-Link Info : J-Link max mem block 26488 Info : J-Link configuration Info : USB-Address: 0x0 Info : Kickstart power on JTAG-pin 19: 0xffffffff Info : Vref = 3.322 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Info : clock speed 1000 kHz Info : TAP esp8266.cpu does not have IDCODE Warn : Warning: Target not halted, breakpoint/watchpoint state may be unpredictable. Info : accepting 'gdb' connection on tcp/3333 undefined debug reason 7 - target needs reset Warn : target not halted Info : TAP esp8266.cpu does not have IDCODE Warn : xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same thing!) target state: halted Info : halted: PC: 0x40002eee Info : debug cause: 0x20 Info : halted: PC: 0x4000dd38 Info : debug cause: 0x1 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Info : halted: PC: 0x4010013c Info : debug cause: 0x8 Interrupt suppression during single-stepping is now enabled Watchdog feeding during stops is now enabled
Hi,
The log with the manual reset actually looks OK. Does the program fail to start after programming in that case?
Another quick solution would be to try the Olimex ARM-USB-OCD-H programmer. It gives OpenOCD a very low-level control over JTAG and we managed to get relatively reliable debugging experience with it.
The LED stays off, and my breakpoint does not get hit, so I looks to me like the program has not started. But is there another way to tell?
Per @GoJimmyPi, this tutorial does work with the J-Link. (https://gojimmypi.blogspot.com/2017/02/esp8266-jtag-debugging-in-visual-studiosegger.html) It looks like he’s using exactly the same hardware as I am.
A couple of related questions:
- When I use the original reset connection (pin 3), the LED blinks very fast (much faster than the 1000 ms I have in the code or even the 300 ms default). What does that mean?
- What does the “all zeros” error mean, anyway?
Thanks.
Update to the manual reset method: If I reset the device, the LED starts blinking(very quickly) again, and the breakpoint still does not get hit.
If I go back to connecting reset to pin 3, it seems like I can actually break with the pause button (ctrl+alt+break) and step through the assembly. When I do that, the LED stops blinking, and when I continue, the LED starts blinking again. But the blinking is still way too fast. Altering the LEDBlink code to change the delay doesn’t make any difference. The LED blinks just as fast as before. If I alter the code to remove the timer completely, it still does not change the behavior of the device.
So it’s like there is some other code running on the device, which would also explain why my breakpoint isn’t hit. But where is this fast blinking behavior coming from?
fwiw – when I’ve seen the “fast blinking” – it is because the LED shares GPIO with Tx/Rx on some devices and the device is in a reset loop. Try hooking up a serial port at 74880 baud and see if the ESP8266 is spewing reset errors. Errors are typically because of bad code, bad settings such as memory size, etc.
Good tip!
This is what it’s spitting out:
ets Jan 8 2013,rst cause:2, boot mode:(3,6) load 0x3ffe8000, len 880, room 16 tail 0 chksum 0xeb load 0x3ffe8370, len 312, room 8 tail 0 chksum 0x0c load 0x40100000, len 27532, room 8 tail 4 chksum 0x41 csum 0x41 rf_cal[0] !=0x05,is 0xFF
So that would suggest that something got flashed, but not the right thing, or its incomplete. Not sure where to go from here.
Hi,
This could mean a missing configuration block. Please try flashing the
esp_init_data_default.binfile using the serial bootloader as described here.I think I was able to flash esp_init_data_default.bin successfully. Now, upon reset, it spits this out on the serial port:
ets Jan 8 2013,rst cause:2, boot mode:(3,7) ets_main.c
If I then try to start debugging with VisualGDB (pin 3 reset), it still gets the all zeroes error, plus an additional error:
Error: xtensa_step: Timed out waiting for target to finish stepping.
It then breaks at 0x4000dc4b, and puts up a little window over the code that say “Received a SIGTRAP; Trace/breakpoint trap”. If I hit continue, it immediately breaks again at the same place. If I try to single step, it won’t go to the next instruction.
Hi,
Unfortunately this behavior is very common with ESP8266 and ESP32. The execution simply gets stuck inside the ROM or some of the system libraries with no way of telling what is causing this.
Our best advice would be to try different FLASH settings (size/mode/speed) and different reset modes.
Some success! In the debug settings, I changed the flash size to “16m” (which I assume means 16 megabits or 16Mb), because the MOD-WIFI-ESP8266-DEV module that comes with the ESP8266-EVB has 2MB of flash.
It hits my first breakpoint in user_init, but if I try to “step over” from there, it goes to off to some address with no source code. If I “continue”, it does not hit any of my other breakpoints (one in user_init and one in TimerFunction), but the program is actually running, judging by the blinking LED (now blinking at the correct rate).
So definite progress! But it’s not quite there.
The tutorial probably needs an update about setting the flash size correctly, especially since for the hardware shown in the tutorial (same as I am using) the default is not correct. Though, I assume the tutorial has been tested, so it’s mystery why the flash size would matter for J-Link and not for whatever was used to develop the tutorial. (The tutorial doesn’t give any hint as to which JTAG interface to use, but I’m guessing Olimex ARM-USB-OCD-H.)
Hi,
Thanks for pointing out the incorrect FLASH size. We have double-checked the Olimex board we used and it indeed has 16 megabits of FLASH, although the default 32m setting worked for us. We will investigate this further and update the tutorial. Most likely the FLASH size matters for either the ESP8266 bootloader or some part of the system library that might have been slightly different in your case.
Regarding stepping over and breakpoints, ESP8266 as only one hardware breakpoint, so debugging experience is extremely limited. It is recommended to explicitly move all the functions that you want to debug to RAM so that VisualGDB can use unlimited software breakpoints instead. Otherwise you would need to disable all breakpoints in order to do stepping (which may still not work as the xtensa gdb often gets confused with function prologues and incoming interrupts).
It would seem to me that single stepping should still be possible with just one hardware breakpoint. And, in fact, I can single step, it’s just that the first step seems to take me to the wrong address, but then I can continue to single step from there, through the disassembly.
For instance, I set a single breakpoint on the os_timer_setfn call in user_init (LEDBlink.cpp). It seems to break there, as it should. If I look at the disassembly, it looks like this:
One step over (F10) takes me to the .byte directive on the next line, and then the next step takes me off to some other address for which I have no source code:
From, there, I can step through the assembly just fine, but I have no idea where I am.
On a side note, if I set the breakpoint one line earlier in the source, at the gpio_output_set call, the disassembly is different:
I don’t know where the “excw” instructions came from, or what they mean, but the behavior is essentially the same. One step takes me to the same 0x400005ce address.
- You must be logged in to reply to this topic.