Forum Replies Created
-
Posts
-
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.
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.)
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.
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.
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?
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.
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.
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
