ESP8266 (ESP-12) JTAG Programming with Segger J-Link, but code does not execute

[gojimmypi]

I’m trying to program an ESP-12, a simplified version of the NodeMCU, via Segger J-Link. All appears to go well, however the code is not actually getting executed (prior code clearly still there).

I’m following the sysprogs tutorial:

https://visualgdb.com/tutorials/esp8266/openocd/

All appears to go well. Upon completion, there’s a dialog box that says “The device has been programmed successfully”. I’ve even been able to put a breakpoint in the blink section (although not able to single step from there). The output looks like this:

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 Jan  9 2017 17:48:51
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 101000
Info : J-Link hw type J-Link
Info : J-Link max mem block 22664
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.306 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: 0x40101113
Info : debug cause: 0x20
Info : halted: PC: 0x4010078c
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
invalid command name “detach”
Info : dropped ‘gdb’ connection

However, the code did *not* end up on the chip (or at least, not in a place to be executed). I have a serial monitor on the Tx/Rx lines, and previous code from my GDB Serial experiment is still there (the RTOS WiFi demo):

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x3ffe8000, len 928, room 16
tail 0
chksum 0x1a
load 0x3ffe83a0, len 760, room 8
tail 0
chksum 0x4f
load 0x40100000, len 29984, room 8
tail 8
chksum 0x8d
csum 0x8d
OS SDK ver: 1.5.0-dev(950076a) compiled @ Nov  4 2016 19:29:32
phy ver: 1055, pp ver: 10.7

rf cal sector: 251
tcpip_task_hdl : 3fff03d8, prio:10,stack:512
idle_task_hdl : 3fff0478,prio:0, stack:384
tim_task_hdl : 3fff2a30, prio:2,stack:512
Hello world!mode : softAP(5e:cf:7f:xx:xx:xx)
dhcp server start:(ip:192.168.123.1,mask:255.255.255.0,gw:192.168.123.1)
add if1
bcn 100

I’m using Visual Studio 2015 with VisualGDB Version 5.2 Build 1389 (that special download from the tmp directory that has a fix for the “Program and Start without Debugging” problem.

This may also explain the NodeMCU problems regarding the repeated exception errors: the code is not actually getting writing as VisualGDB thinks it is.

Any suggestions would be greatly appreciated. Thanks.

 

[support]

Hi,

We have experienced this on one of our boards – despite not returning any error codes, the FLASH programming functions did not overwrite anything. Again, as many things on ESP8266, it’s hard to say where the problem is as the FLASH programming code in ESP8266 is not open-source.

Please try first loading your program via the bootloader mode (or erasing the FLASH completely). This may reset the state of the FLASH and make it programmable via JTAG.

[gojimmypi]

Yes, I’ve tried using the bootloader mode when attempting to program via JTAG, even though there was no prompt as with the GDB stub method. I’ve still not yet been successful. Given the nature of JTAG, I wasn’t really sure if this was needed or not.

fwiw – I recently tried VisualGDB with an STM32 device (specifically the STM32F103c8 found in the Smart V2):

http://wiki.stm32duino.com/index.php?title=STM32_Smart_V2.0

my setup / result pics here:

https://twitter.com/gojimmypi/status/835449862497849344

wow! It was amazingly simple to setup and debug! I’ve spent a huge amount of time trying to get this to work with the ESP8266… and just minutes with the STM32, following this OpenOCD tutorial (but with Segger J-Link, instead):

https://visualgdb.com/tutorials/arm/st-link/

I really hope you folks can get the ESP8266 (and ESP32) information you need from Espressif folks to make ESP8266 debugging as easy and robust as you’ve done with STM32.  (hard to beat a full SOC IoT device with WiFi for as little as 3 bucks).

So between this success, and the really impressive remote debugging that I was able to get working from Visual Studio to Raspberry Pi… well, VisualGDB is awesome!  🙂

[support]

Hi,

Thanks for the kind words. VisualGDB works with STM32 out-of-the-box because the underlying debug mechanisms are reliable and stable, so VisualGDB can build on top of them and extend them with usability features. ESP8266/ESP32 is much cheaper, but unfortunately it’s a very shaky foundation. Many basic things don’t work (e.g. see this list) and many other things keep changing between the SDK releases and devices. So until we see some stability in terms of basic functionality, our ESP8266/ESP32 support will be very very basic.

We will consider making a crowdfinding campaign to fix the common annoyances of the open-source ESP8266 debug tools (gdb/OpenOCD), but it’s hard to say if the hobbyist community (that are practically the only users of ESP8266/ESP32) will find it worth the price.

[gojimmypi]

We will consider making a crowdfunding campaign to fix the common annoyances of the open-source ESP8266 debug tools (gdb/OpenOCD)

Sign me up!!! 🙂

https://twitter.com/gojimmypi/status/836022626665422848

 

[Author]

Posts