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.