Can't get J-Link to work with Olimex ESP8266-EVB

Sysprogs forums Forums VisualGDB Can't get J-Link to work with Olimex ESP8266-EVB

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #11128
    markb
    Participant

    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

    #11132
    support
    Keymaster

    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.

    #11133
    markb
    Participant

    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
    #11135
    support
    Keymaster

    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.

    #11140
    markb
    Participant

    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.

    #11141
    markb
    Participant

    A couple of related questions:

    1. 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?
    2. What does the “all zeros” error mean, anyway?

    Thanks.

    #11142
    markb
    Participant

    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?

    #11144
    gojimmypi
    Participant

    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.

    #11145
    markb
    Participant

    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.

    #11147
    support
    Keymaster

    Hi,

    This could mean a missing configuration block. Please try flashing the esp_init_data_default.bin file using the serial bootloader as described here.

    #11149
    markb
    Participant

    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.

    #11155
    support
    Keymaster

    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.

    #11156
    markb
    Participant

    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.)

    #11159
    support
    Keymaster

    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).

    #11275
    markb
    Participant

    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.

    • This reply was modified 7 years, 4 months ago by markb.
Viewing 15 posts - 1 through 15 (of 16 total)
  • You must be logged in to reply to this topic.