JTAG Programming the NodeMCU ESP8266

Sysprogs forums › Forums › VisualGDB › JTAG Programming the NodeMCU ESP8266

Log In Register Lost Password
Viewing 15 posts - 1 through 15 (of 16 total)
1 2
  • Author
    Posts
  • February 13, 2017 at 19:40 #10397
    gojimmypi
    Participant

    Hi.

    Many thanks for prior assistance. I’m almost where I want to be… 🙂

    I’m trying to get my JTAG programmer (either an Olimex ARM-USB-OCD-H or Segger J-Link EDU) to program, and ideally step debug the ESP8266.

    I’ve had success with the Olimex as described in the sysprogs tutorial, targeting the Olimex ESP8266-EVB.

    http://gojimmypi.blogspot.com/2017/02/esp8266-jtag-debugging-in-visual-studio.html

    With that success, I hoped to be able to program the NodeMCU. When testing the settings, all appears well (in this case with the Olimex ARM-USB-OCD-H_:

    C:\SysGCC\esp8266\esp8266-bsp\OpenOCD\bin\openocd.exe -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/esp8266.cfg
    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
    Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
    Info : clock speed 1000 kHz
    Info : TAP esp8266.cpu does not have IDCODE
    Info : halted: PC: 0x400044b4
    Info : debug cause: 0x20
    Info : accepting ‘telnet’ connection on tcp/4444
    shutdown command invoked
    Info : dropped ‘telnet’ connection

    However when actually programming, I get the dreaded “all zeros” JTAG message:

    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
    Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
    Info : clock speed 1000 kHz
    Info : TAP esp8266.cpu does not have IDCODE
    Info : halted: PC: 0x40003b53
    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…
    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: 0x40002ef1
    Info : debug cause: 0x20
    Info : halted: PC: 0x40002ef4
    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
    Info : halted: PC: 0x400044b4
    Info : debug cause: 0x20
    Info : dropped ‘gdb’ connection

    It does however, seem to go through all the motions and after a brief period claims to have successfully programmed the device. Curiously the raw GDB only mentions one binary file:

    restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffc8008 0x20000 0x2f5a4
    &”restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffc8008 0x20000 0x2f5a4\n”
    ~”Restoring binary file C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin into memory (0x3ffe8008 to 0x3fff75ac)\n”

    When running, the program uploaded repeatedly spews reboot because of exception messages:

    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 0x3b
    load 0x40100000, len 27628, room 8
    tail 4
    chksum 0xf2
    csum 0xf2
    syst???param error, use last saved param!
    RD DATA:0X0
    GD25Q32C Config Qio Mode Fail
    rf_cal[0] !=0x05,is 0x6C

    btw – Feature request: please add the default “74880” speed to dropdown. This is the default speed for error messages if not set by target application.

    I’m thinking that despite the message “The device has been programmed successfully”, it has not – particularly given the exception “cause:2”.

    If I had not had success with the Olimex ESP8266-EVB, I may have given up. But I’ve tried two different NodeMCU’s with no success. I’ve even tried powering the NodeMCU separately with 3.3V, ignoring the on-board UART, leaving it powered off: same results.

    I can definitely program the NodeMCU units via VisualMicro / UART with no problems. They work great. It is the JTAG issue I’m struggling with.

    I have a variety of questions, that perhaps would be good to add to a new “ESP8266” section at https://visualgdb.com/support/faq.php (?)  🙂

    1. There are 3 binary files created in the [project]\VisualGDB\Debug directory:
      project.bin
      project-0x00000.bin
      project-0x20000.binI assume the numbers are meant to be firmware addressed, but the two with numbers are relatively small, and the largest file (project.bin) has no number. If manually loading these files via something like the NodeMCI Firmeware Programmer, what’s the load address of the largest file? What is the purpose of each of them? Are they actually all supposed to be loaded into the ESP8266?
    2. In the Debug settings: Is the Sector Size and Erase Block size ever a function of ESP8266 flavor? I’ve use the Arduino / VisualMicro uploaders and have not seen that option. I’ve kept the default of 4096 in all my attempts.
    3. In the Debug Settings: Is “Frequency” the CPU or Flash frequency? For VisualMicro I use 80MHz for CPU and 40MHZ for Flash Frequency. Which value should I used in VisualGDB?
    4. I normally use a Flash Mode of DIO. The default in VisualGDB is QIO. How can I confirm the DIO mode is being used once changed in Debug config? (and does this matter to JTAG?)
    5. There’s a size option in the debug section. Are the units bits or bytes? The default list all have little “m”s – so is that bits? For VisualMicro I have a setting of 4m (1M SPIFFS) when I program via the UART. What value should I use in VisualGDB? I’ve tried them all.
    6. While on the topic of memory settings – what do the -C1 and -C2 suffixes mean?
    7. There are apparently 2 reset options: “ct” and “nodemcu”. I of course have the NodeMCU setting in VisualMicro, but I cannot find a similar setting in VisualGDB. Is there a reset option, or perhaps it does not apply to JTAG programming?

    I ask all these questions, as I believe the problem may be related to these debug memory parameters, and not the electrical, connection or power issues. (particularly since the initial test seems to indicate all is well. I’m certain  both of the units I’ve tested otherwise work properly.

    I realize that there’s been mixed results with the ESP8266 and VisualGDB… but I’ve had a lot of success with the VisualMicro and UART programming with the NodeMCU devices. However I’d like to move on from NonOS to RTOS (particularly since it appears that the ESP32 will not even support the Arduino-style NonOS). For this – I’d really like to get VisualGDB working.

    Sorry for the long post, but I tried to be detailed & I think there will be an increasingly large number of people interested in the ESP8266.

    Thanks very much in advance. 🙂

    <edit: spelling>

    • This topic was modified 7 years, 9 months ago by gojimmypi. Reason: spelling
    • This topic was modified 7 years, 9 months ago by gojimmypi. Reason: spelling
    • This topic was modified 7 years, 9 months ago by gojimmypi. Reason: spelling
    February 13, 2017 at 20:05 #10402
    support
    Keymaster

    Hi,

    As usual with ESP8266, it’s hard to say for sure. Something on the board may be interfering with JTAG or something in the board firmware may be interfering with FLASH programming. As those things are not really documented, unfortunately we can only guess here.

    BTW, you can use VisualGDB with the UART gdb stub as well (see this tutorial). This mode does not involve JTAG and should work if VisualMicro works as well.

    Also feel free to attach the full gdb log so that we could check for common errors.

    Regarding other questions:

    1. The large project.bin file is actually not needed. It’s a default binary file containing ALL the sections from the image. It is useful on other targets like ARM or MSP430, but not on ESP8266 or ESP32. You can disable it via the VS Project Properties (Generate binary files = No). Manually programming the other 2 files should be sufficient (you can also use <SysGCC>\esp8266\esp8266-bsp\ESPImageTool.exe to program an ELF file via a COM port).
    2. We never had to change the default sector/erase block sizes, but as those values are not well documented, we made them editable.
    3. The names for the FLASH modes, frequencies, sizes, C1/C2 come from the esptool.py provided by Espressif and to our best knowledge specify the FLASH parameters that the ESP8266 device will use. On VisualGDB side selecting one of those changes the values in the ESP8266 image header (which is undocumented) similarly to what esptool.py does. Please double-check the exact semantics and meanings of those with Espressif.
    4. The reset options you mentioned do not apply to JTAG programming. In fact, lack for reliable reset (that stops the CPU immediately after resetting before the ROM starts various background processes) is one of the main reasons why JTAG debugging is very unreliable compared to the GDB stub.
    February 13, 2017 at 20:51 #10403
    gojimmypi
    Participant

    Thanks once again for your prompt reply.

    I am unable to use the GDB stub. I’m sure the COM port is working, as not only was I able to previously see the error messages from VisualGDB when trying to JTAG program, but I am also able to go back to VisualMicro and do a “Build-Upload” with that COM port with no problems.

    I reviewed the steps (twice) and confirmed I followed the tutorial. At F5-debug time, I see this error:

    VisualGDB version: 5.2.14.1374
    —————— System.Exception ——————
    System.Exception: Cannot read reply body
    at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk)
    at ESP8266DebugPackage.ESP8266BootloaderClient.Sync()
    at ESP8266DebugPackage.ESP8266StubDebugExtension.StubStartSequence.BuildSequence(String targetPath, Dictionary2 bspDict, Dictionary2 debugMethodConfig, LiveMemoryLineHandler lineHandler)
    at uc.k1(bz a, ICustomStartupSequenceBuilder b)
    at uc.l.c(bz a)
    at ls1.v.p1`1.f(bz a)
    at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.c(Action`1 operation, String caption, he1 exceptionHandler, String[] stages)

    Perhaps you’ll recall that not one, but twice I had problems with Norton thinking that various components were bad – so I disabled Norton, ran a repair from VisualGDB-5.2r8-trial.msi and had different results! It still did not work, saying that GDB was taking too long to respond, so after some time I pressed cancel:

    Your VisualGDB trial expires in 15 days!
    C:\SysGCC\esp8266\bin\xtensa-lx106-elf-gdb.exe –interpreter mi c:\workspace\VGDB\VisualGDB\Debug\VGDB
    -gdb-version
    =thread-group-added,id=”i1″
    GNU gdb (GDB) 7.11
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type “show copying”
    and “show warranty” for details.
    This GDB was configured as “–host=i686-pc-mingw32 –target=xtensa-lx106-elf”.
    Type “show configuration” for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/&gt;.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/&gt;.
    For help, type “help”.
    Type “apropos word” to search for commands related to “word”…
    Reading symbols from c:\workspace\VGDB\VisualGDB\Debug\VGDB…
    done.
    GNU gdb (GDB) 7.11
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type “show copying”
    and “show warranty” for details.
    This GDB was configured as “–host=i686-pc-mingw32 –target=xtensa-lx106-elf”.
    Type “show configuration” for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/&gt;.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/&gt;.
    For help, type “help”.
    Type “apropos word” to search for commands related to “word”.
    OK
    -list-features
    ^done,features=[“frozen-varobjs”,”pending-breakpoints”,”thread-info”,”data-read-memory-bytes”,”breakpoint-notifications”,”ada-task-info”,”language-option”,”info-gdb-mi-command”,”undefined-command-error-code”,”exec-run-start-option”]
    -gdb-set disassembly-flavor intel
    No symbol “disassembly” in current context.
    -gdb-set print demangle off
    OK
    -break-insert -f main
    &”Function \”main\” not defined.\n”
    ^done,bkpt={number=”1″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”<PENDING>”,pending=”main”,times=”0″,original-location=”main”}
    Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.
    -break-delete 1
    OK
    set serial baud 74880
    &”set serial baud 74880\n”
    =cmd-param-changed,param=”serial baud”,value=”74880″
    OK
    target remote \\.\COM12
    &”target remote \\\\.\\COM12\n”
    Remote debugging using \\.\COM12
    Ignoring packet error, continuing…
    &”warning: unrecognized item \”timeout\” in \”qSupported\” response\n”
    Ignoring packet error, continuing…
    Loaded image in 30583 ms
    &”Quit (expect signal SIGINT when the program is resumed)\n”
    Quit (expect signal SIGINT when the program is resumed)
    System.Exception: GDB has exited prematurely
    at VisualGDB.GDBDebugEngine.c(or a, q1 b)

    I tried yet again, but got this message (confirming Norton auto-protect still disabled):

    VisualGDB version: 5.2.14.1374
    —————— System.Exception ——————
    System.Exception: Mismatching reply from ESP8266
    at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk)
    at ESP8266DebugPackage.ESP8266BootloaderClient.Sync()
    at ESP8266DebugPackage.ESP8266StubDebugExtension.StubStartSequence.BuildSequence(String targetPath, Dictionary2 bspDict, Dictionary2 debugMethodConfig, LiveMemoryLineHandler lineHandler)
    at uc.k1(bz a, ICustomStartupSequenceBuilder b)
    at uc.l.c(bz a)
    at ls1.v.p1`1.f(bz a)
    at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.c(Action`1 operation, String caption, he1 exceptionHandler, String[] stages)

    I tried both with power cycle while holding down flash button (I don’t kneed to do this with VisualMicro).. and simply a power cycle: same results.

    fwiw – I have a single breakpoint on line 128 at “wifi_set_opmode”

    I re-confirmed Com12 is the correct port. (it is a CH340-based USB-TTL adapter, that specifically has a jumper for selecting 3.3v)

     

    February 13, 2017 at 20:58 #10404
    gojimmypi
    Participant

    Also feel free to attach the full gdb log so that we could check for common errors.

    here ya go… the whole gdb log:

     

    Your VisualGDB trial expires in 15 days!
    C:\SysGCC\esp8266\bin\xtensa-lx106-elf-gdb.exe –interpreter mi C:\workspace\OMC\VisualGDB\Debug\OMC
    -gdb-version
    =thread-group-added,id=”i1″
    ~”GNU gdb (GDB) 7.11\n”
    ~”Copyright (C) 2016 Free Software Foundation, Inc.\n”
    ~”License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \”show copying\”\nand \”show warranty\” for details.\n”
    ~”This GDB was configured as \”–host=i686-pc-mingw32 –target=xtensa-lx106-elf\”.\nType \”show configuration\” for configuration details.”
    ~”\nFor bug reporting instructions, please see:\n”
    ~”<http://www.gnu.org/software/gdb/bugs/&gt;.\n”
    ~”Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/&gt;.\n”
    ~”For help, type \”help\”.\n”
    ~”Type \”apropos word\” to search for commands related to \”word\”…\n”
    ~”Reading symbols from C:\\workspace\\OMC\\VisualGDB\\Debug\\OMC…”
    ~”done.\n”
    ~”GNU gdb (GDB) 7.11\n”
    ~”Copyright (C) 2016 Free Software Foundation, Inc.\n”
    ~”License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \”show copying\”\nand \”show warranty\” for details.\n”
    ~”This GDB was configured as \”–host=i686-pc-mingw32 –target=xtensa-lx106-elf\”.\nType \”show configuration\” for configuration details.”
    ~”\nFor bug reporting instructions, please see:\n”
    ~”<http://www.gnu.org/software/gdb/bugs/&gt;.\n”
    ~”Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/&gt;.\n”
    ~”For help, type \”help\”.\n”
    ~”Type \”apropos word\” to search for commands related to \”word\”.\n”
    ^done
    -list-features
    ^done,features=[“frozen-varobjs”,”pending-breakpoints”,”thread-info”,”data-read-memory-bytes”,”breakpoint-notifications”,”ada-task-info”,”language-option”,”info-gdb-mi-command”,”undefined-command-error-code”,”exec-run-start-option”]
    -gdb-set disassembly-flavor intel
    ^error,msg=”No symbol \”disassembly\” in current context.”
    -gdb-set print demangle off
    ^done
    -break-insert -f main
    &”Function \”main\” not defined.\n”
    ^done,bkpt={number=”1″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”<PENDING>”,pending=”main”,times=”0″,original-location=”main”}
    Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.
    -break-delete 1
    ^done
    target remote :3333
    &”target remote :3333\n”
    ~”Remote debugging using :3333\n”
    =thread-group-started,id=”i1″,pid=”42000″
    =thread-created,id=”1″,group-id=”i1″
    ~”0x400044b4 in ?? ()\n”
    *stopped,frame={addr=”0x400044b4″,func=”??”,args=[]},thread-id=”1″,stopped-threads=”all”
    ^done
    info shared
    &”info shared\n”
    ~”No shared libraries loaded at this time.\n”
    ^done
    mon reset halt
    &”mon reset halt\n”
    @”JTAG scan chain interrogation failed: all zeroes\n”
    @”Check JTAG interface, timings, target power, etc.\n”
    @”Trying to use configured scan chain anyway…\n”
    @”esp8266.cpu: IR capture error; saw 0x00 not 0x01\n”
    @”Bypassing JTAG setup events due to errors\n”
    @”xtensa_deassert_reset: ‘reset halt’ is not supported for Xtensa. Have halted some time after resetting (not the same thing!)\n”
    @”target state: halted\n”
    @”halted: PC: 0x40003b53\n”
    @”debug cause: 0x20\n”
    ^done
    -exec-next-instruction
    ^running
    *running,thread-id=”all”
    *stopped,reason=”end-stepping-range”,frame={addr=”0x40003b55″,func=”??”,args=[]},thread-id=”1″,stopped-threads=”all”
    set $com_sysprogs_esp8266_wdcfg=0
    &”set $com_sysprogs_esp8266_wdcfg=0\n”
    ^done
    set $vecbase=0x40000000
    &”set $vecbase=0x40000000\n”
    ^done
    set *(0x3fffc200)=0
    &”set *(0x3fffc200)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fffc200″,len=”0x4″
    ^done
    set $ccompare=0
    &”set $ccompare=0\n”
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    print *((int *)0x60000900)
    &”print *((int *)0x60000900)\n”
    ~”$1 = 0″
    ~”\n”
    ^done
    set *((int *)0x60000900)=0
    &”set *((int *)0x60000900)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x60000900″,len=”0x4″
    ^done
    restore C:/SysGCC/esp8266/esp8266-bsp/sysprogs/flashprog/ESP8266FlashProg.bin binary 0x40100000 0 0x1a4
    &”restore C:/SysGCC/esp8266/esp8266-bsp/sysprogs/flashprog/ESP8266FlashProg.bin binary 0x40100000 0 0x1a4\n”
    ~”Restoring binary file C:/SysGCC/esp8266/esp8266-bsp/sysprogs/flashprog/ESP8266FlashProg.bin into memory (0x40100000 to 0x401001a4)\n”
    ^done
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=0
    &”set *((unsigned *)0x3fff8008)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=4096
    &”set *((unsigned *)0x3fff800c)=4096\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=4096
    &”set *((unsigned *)0x3fff8010)=4096\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    &”warning: \nUnrecognised function prologue. Stack trace cannot be resolved. This message will not be repeated in this session.\n”
    &”\n”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=1
    &”set *((unsigned *)0x3fff8008)=1\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=0
    &”set *((unsigned *)0x3fff800c)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=28864
    &”set *((unsigned *)0x3fff8010)=28864\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x00000.bin binary 0x3ffe8008 0x0 0x70c0
    &”restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x00000.bin binary 0x3ffe8008 0x0 0x70c0\n”
    ~”Restoring binary file C:/workspace/OMC/VisualGDB/Debug/OMC-0x00000.bin into memory (0x3ffe8008 to 0x3ffef0c8)\n”
    ^done
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=2
    &”set *((unsigned *)0x3fff8008)=2\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=0
    &”set *((unsigned *)0x3fff800c)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=28864
    &”set *((unsigned *)0x3fff8010)=28864\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=1
    &”set *((unsigned *)0x3fff8008)=1\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=65536
    &”set *((unsigned *)0x3fff800c)=65536\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=193956
    &”set *((unsigned *)0x3fff8010)=193956\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffe8008 0x0 0x10000
    &”restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffe8008 0x0 0x10000\n”
    ~”Restoring binary file C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin into memory (0x3ffe8008 to 0x3fff8008)\n”
    ^done
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=2
    &”set *((unsigned *)0x3fff8008)=2\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=65536
    &”set *((unsigned *)0x3fff800c)=65536\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=65536
    &”set *((unsigned *)0x3fff8010)=65536\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffd8008 0x10000 0x20000
    &”restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffd8008 0x10000 0x20000\n”
    ~”Restoring binary file C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin into memory (0x3ffe8008 to 0x3fff8008)\n”
    ^done
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=2
    &”set *((unsigned *)0x3fff8008)=2\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=131072
    &”set *((unsigned *)0x3fff800c)=131072\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=65536
    &”set *((unsigned *)0x3fff8010)=65536\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffc8008 0x20000 0x2f5a4
    &”restore C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin binary 0x3ffc8008 0x20000 0x2f5a4\n”
    ~”Restoring binary file C:/workspace/OMC/VisualGDB/Debug/OMC-0x10000.bin into memory (0x3ffe8008 to 0x3fff75ac)\n”
    ^done
    flushregs
    &”flushregs\n”
    ~”Register cache flushed.\n”
    ^done
    set $epc2=0x40100074
    &”set $epc2=0x40100074\n”
    ^done
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set *((unsigned *)0x3fff8008)=2
    &”set *((unsigned *)0x3fff8008)=2\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8008″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff800c)=196608
    &”set *((unsigned *)0x3fff800c)=196608\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff800c”,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8010)=62884
    &”set *((unsigned *)0x3fff8010)=62884\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8010″,len=”0x4″
    ^done
    set *((unsigned *)0x3fff8014)=4294967295
    &”set *((unsigned *)0x3fff8014)=4294967295\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fff8014″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    ~”\nProgram”
    ~” received signal SIGTRAP, Trace/breakpoint trap.\n”
    ~”0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n”
    ~”35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n”
    *stopped,reason=”signal-received”,signal-name=”SIGTRAP”,signal-meaning=”Trace/breakpoint trap”,frame={addr=”0x4010013c”,func=”TimerFunction”,args=[{name=”arg”,value=”<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>”}],file=”LEDBlink.cpp”,fullname=”C:\\workspace\\OMC\\OMC\\LEDBlink.cpp”,line=”35″},thread-id=”1″,stopped-threads=”all”
    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
    ^done,value=”0″
    set $ps=0x20
    &”set $ps=0x20\n”
    ^done
    set $epc2=0x40000080
    &”set $epc2=0x40000080\n”
    ^done
    set $sp=0x3fffc000
    &”set $sp=0x3fffc000\n”
    ^done
    set $vecbase=0x40000000
    &”set $vecbase=0x40000000\n”
    ^done
    set *(0x3fffc200)=0
    &”set *(0x3fffc200)=0\n”
    =memory-changed,thread-group=”i1″,addr=”0x3fffc200″,len=”0x4″
    ^done
    set $intclear=-1
    &”set $intclear=-1\n”
    ^done
    set $intenable=0
    &”set $intenable=0\n”
    ^done
    set $eps2=0x20
    &”set $eps2=0x20\n”
    ^done
    set $icountlevel=0
    &”set $icountlevel=0\n”
    ^done
    Loaded image in 12416 ms
    -break-insert -h -f *0x40100004
    ^done,bkpt={number=”2″,type=”hw breakpoint”,disp=”keep”,enabled=”y”,addr=”0x40100004″,at=”<call_user_start>”,thread-groups=[“i1″],times=”0″,original-location=”*0x40100004″}
    mon xtensa_no_interrupts_during_steps on
    &”mon xtensa_no_interrupts_during_steps on\n”
    @”Interrupt suppression during single-stepping is now enabled\n”
    ^done
    mon esp8266_autofeed_watchdog on
    &”mon esp8266_autofeed_watchdog on\n”
    @”Watchdog feeding during stops is now enabled\n”
    ^done
    info target
    &”info target\n”
    ~”Symbols from \”C:\\workspace\\OMC\\VisualGDB\\Debug\\OMC\”.\n”
    ~”Remote serial target in gdb-specific protocol:\n”
    ~”Debugging a target over a serial line.\n”
    ~”\tWhile running this, GDB does not access memory from…\n”
    ~”Local exec file:\n”
    ~”\t`C:\\workspace\\OMC\\VisualGDB\\Debug\\OMC’, file type elf32-xtensa-le.\n”
    ~”\tEntry point: 0x40100004\n”
    ~”\t0x3ffe8000 – 0x3ffe8370 is .data\n”
    ~”\t0x3ffe8370 – 0x3ffe84a8 is .rodata\n”
    ~”\t0x3ffe84a8 – 0x3ffee760 is .bss\n”
    ~”\t0x40210000 – 0x4023f5a4 is .irom0.text\n”
    ~”\t0x40100000 – 0x40106bec is .text\n”
    ^done
    -data-evaluate-expression “&_estack”
    ^error,msg=”No symbol \”_estack\” in current context.”
    -data-evaluate-expression “&__StackLimit”
    ^error,msg=”No symbol \”__StackLimit\” in current context.”
    Cannot resolve the address of _estack. Skipping stack pointer validity check.
    set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg
    &”set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg\n”
    =memory-changed,thread-group=”i1″,addr=”0x60000900″,len=”0x4″
    &”warning: \nUnrecognised function prologue. Stack trace cannot be resolved. This message will not be repeated in this session.\n”
    &”\n”
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”
    =breakpoint-modified,bkpt={number=”2″,type=”hw breakpoint”,disp=”keep”,enabled=”y”,addr=”0x40100004″,at=”<call_user_start>”,thread-groups=[“i1″],times=”1″,original-location=”*0x40100004″}
    ~”\n”
    ~”Breakpoint 2, 0x40100004 in call_user_start ()\n”
    *stopped,reason=”breakpoint-hit”,disp=”keep”,bkptno=”2″,frame={addr=”0x40100004″,func=”call_user_start”,args=[]},thread-id=”1″,stopped-threads=”all”
    -break-delete 2
    ^done
    set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg
    &”set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg\n”
    =memory-changed,thread-group=”i1″,addr=”0x60000900″,len=”0x4″
    ^done
    -exec-continue
    ^running
    *running,thread-id=”all”

    February 15, 2017 at 06:29 #10421
    support
    Keymaster

    Hi,

    OK, thanks for the GDB log. It looks like the FLASH programming code does not report any errors (code 0 below):

    -data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
^done,value=”0″

    so normally the program should work. Are you able to communicate with the board using the esptool.py? If yes, could you try reading the FLASH memory at addresses 0 and 0x10000 and comparing it with the OMC-<address>.bin files?  This should explain if the FLASH gets programmed at all.

    We have also ordered a NodeMCU board and should get it by the end of March. We will check it once it arrives as post a detailed tutorial.

    February 18, 2017 at 13:23 #10452
    gojimmypi
    Participant

    Hi –

    That’s really awesome you ordered a NodeMCU and plan to post a tutorial! I believe many people will be looking forward to that! Thank you so much 🙂

    Yes, my NodeMCU board is otherwise fully functional when programming via UART via VisualMicro. It works great; no complaints.

    Great idea to compare read data to what was expected to be written from VisualGDB.

    First though, I went back to known-good code compiled in VisualMicro and loaded it up like this: (from /C/SysGCC/esp8266/esp8266-bsp)

    python esptool.py –baud 115200 –port “COM19” write_flash –flash_size=8m 0  myfile.bin

    it gave output like this:

    Writing at 0x00000000… (0 %) reply
    Writing at 0x00000400… (0 %) reply
    Writing at 0x00000800… (1 %) reply
    …
    Writing at 0x0003b000… (98 %) reply
    Writing at 0x0003b400… (99 %) reply
    Writing at 0x0003b800… (99 %) reply
    Writing at 0x0003bc00… (100 %) reply

    Written 245760 bytes in 24.08 seconds (81.65 kbit/s)…

    I confirmed the code was operating properly (my code writes a variety of information out Serial UART, so all good there). Note that only one file is written, at 0x0. Not two.

    So I attempted to read it back like this:

    python esptool.py –baud 115200 –port “COM19” read_flash 0 245760

    The files could not be compared, as the source file written was only 244,848 bytes (912 bytes different)

    So then I tried that size:

    python esptool.py –baud 115200 –port “COM19” read_flash 0 244848

    And the files, even though the same size, did not compare… although only 2 differences:

    00000002: 02 00
    00000003: 40 20

    Would that be expected? (again, this is known-good code, confirmed to be working properly)

    I’m also curious as to why 2 bin files need to be loaded at two different addresses when using VisualGDB? Why the code split?

    Just a heads up also, that I then tried erasing my NodeMCU like this:

    python esptool.py –baud 115200 –port “COM19” erase_flash

    That made the GDB stub quite unhappy when then trying to upload:

    VisualGDB version: 5.2.14.1374
    —————— System.Exception ——————
    System.Exception: Unexpected reply from ESP8266
    at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk)
    at ESP8266DebugPackage.ESP8266BootloaderClient.Sync()
    at ESP8266DebugPackage.ESP8266StubDebugExtension.StubStartSequence.BuildSequence(String targetPath, Dictionary2 bspDict, Dictionary2 debugMethodConfig, LiveMemoryLineHandler lineHandler)
    at uc.k1(bz a, ICustomStartupSequenceBuilder b)
    at uc.l.c(bz a)
    at ls1.v.p1`1.f(bz a)
    at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.c(Action`1 operation, String caption, he1 exceptionHandler, String[] stages)

    However after I put back my original code:

    python esptool.py –baud 115200 –port “COM19” write_flash –flash_size=8m 0 mycode.bin

    I was then able to do the GDB upload on top of the non-blank chip. But it got stuck on “The following GDB command is taking too long to complete:  -exec-continue”

    Pressing cancel yields this message:

    C:\SysGCC\esp8266\bin\xtensa-lx106-elf-gdb.exe –interpreter mi C:\workspace\NGDB2\VisualGDB\Debug\NGDB2
    Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.
    Bogus trace status reply from target: timeout
    Loaded image in 42220 ms
    Cannot resolve the address of _estack. Skipping stack pointer validity check.
    Invalid cast.
    The program is not being run.
    Cannot access memory at address 0x60000900
    Cannot access memory at address 0x60000900
    Invalid thread id: 1
    No registers.
    Invalid thread id: 1

    Ignoring that message, back to the original question…. yes I can successfully read exactly the bytes written at 0x0 and 0x20000

    python esptool.py –baud 115200 –port “COM19” read_flash 0x20000 245523 /c/workspace/NGDB2/VisualGDB/Debug/read-2.bin

    python esptool.py –baud 115200 –port “COM19” read_flash 0 32448 /c/workspace/NGDB2/VisualGDB/Debug/read-0.bin

    …those files compare exactly to the originals

    C:\workspace\NGDB2\VisualGDB\Debug>fc NGDB2-0x00000.bin read-0.bin
    Comparing files NGDB2-0x00000.bin and READ-0.BIN
    FC: no differences encountered
    C:\workspace\NGDB2\VisualGDB\Debug>fc NGDB2-0x20000.bin read-2.bin
    Comparing files NGDB2-0x20000.bin and READ-2.BIN
    FC: no differences encountered

    However as previously described, the code is *not* executing properly, rather the ESP8266 is spewing this repeated message out the UART at 74880 baud:

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

    load 0x3ffe8000, len 940, room 16
    tail 12
    chksum 0xc3
    ho 0 tail 12 room 4
    load 0x3ffe83b0, len 936, room 12
    tail 12
    chksum 0xfc
    ho 0 tail 12 room 4
    load 0x40100000, len 30536, room 12
    tail 12
    chksum 0xe9
    csum 0xe9
    OS SDK ver: 1.5.0-dev(950076a) compiled @ Nov  4 2016 19:29:32
    rf_cal[0] !=0x05,is 0xFF

    But this tells us a LOT! 🙂 The compile code *is* making it onto the chip, but there’s apparently something wrong then with the compiled code not executing properly. (cause:2 = exception)

    It is curious that my known-good code, confirmed to be working, has those two bytes changed when read back, and the VisualGDB read back exactly the same. Also curious that 2 separate files are needed – perhaps something wrong at 0x20000? I also don’t see the output from uploading the VisualGDB files, wondering if they too, have a 912 byte difference as when I manually uploaded my known working code?

    In the end, I’m wondering if there’s some problem with the compiler, and not GDB & not JTAG?

    February 18, 2017 at 20:46 #10458
    support
    Keymaster

    Hi,

    OK, we just got the notification that the NodeMCU got shipped, however the expected arrival date is March 21, so it will probably be faster to solve this iteratively rather than wait for the board to arrive.

    The 912-byte difference comes from the padding esptool.py adds to the file and it should be causing any troubles.

    The bytes at offsets 2 and 3 encode the FLASH memory parameters used by ESP8266. The only source of documentation we could find was the esptool.py from Espressif:

            flash_mode = {'qio':0, 'qout':1, 'dio':2, 'dout': 3}[args.flash_mode]
        flash_size_freq = {'4m':0x00, '2m':0x10, '8m':0x20, '16m':0x30, '32m':0x40, '16m-c1': 0x50, '32m-c1':0x60, '32m-c2':0x70}[args.flash_size]
        flash_size_freq += {'40m':0, '26m':1, '20m':2, '80m': 0xf}[args.flash_freq]
        flash_info = struct.pack('BB', flash_mode, flash_size_freq)

    Based on this,  “02 00” means “FLASH in DIO mode, 4 megabits, 40 MHz” and “40 20” means “32 megabits, 40 MHz” and an unknown FLASH mode. This could be related to the problem you are experiencing, so please try experimenting with the FLASH mode in VisualGDB Project Properties. Wrong FLASH mode would be consistent with what you are describing: the programming would succeed, but the chip would not start. If none of the modes work, please try using our ESPImageTool.exe to make 2 binary images from the ELF file and then manually put the 0x40 value at offset 2. Perhaps this is some undocumented value that is required on NodeMCU.

    The split into 2 images (e.g. at 0 and 0x10000) comes from the ESP8266 linker script file:

    MEMORY
{
  dport0_0_seg :                        org = 0x3FF00000, len = 0x10
  dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40201010, len = 0x6B000
}

    The data/code at the beginning of FLASH is loaded into RAM by the bootloader and the code at 0x200000 is directly executed from FLASH. You can quickly check if your image also has 2 areas by running “xtensa-lx106-elf-objdump.exe -h <ELF file>”:

      0 .data         00000370  3ffe8000  3ffe8000  000000e0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .rodata       00000138  3ffe8370  3ffe8370  00000450  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .bss          000062b8  3ffe84a8  3ffe84a8  00000588  2**4
                  ALLOC
  3 .irom0.text   0002f5a4  40210000  40210000  00007170  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .text         00006be4  40100000  40100000  00000588  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

    The 0x40200000 corresponds to the beginning of the FLASH memory and the .ir0m0.text section loaded at 0x40210000 will be programmed to FLASH at offset 0x10000). It’s hard to say why VisualMicro produces a binary that does not use 2 sections; perhaps they use a customized linker script that puts the sections adjacent to each other. We purposefully use the unmodified scripts from the ESP8266 SDK to maximize compatibility with existing projects.

    February 18, 2017 at 22:03 #10462
    gojimmypi
    Participant

    Hi –

    Interesting information, thanks. The DIO / memory, etc… yes, I’ve wondered whether when I make those change, if they are actually used at programming time. fwiw – In VisualMicro I use DIO, 4M (1M SPIFFS), CPU 80MHz, Flash 40MHz.

    So I created a new project (HTTPDemo RTOS), rather than changing existing settings – and curiously I see this error at upload time, immediately after the first step “Programming Firmware”. It never even gets to the “Connecting to GDB stub”

    VisualGDB version: 5.2.14.1374
    —————— System.NullReferenceException ——————
    System.NullReferenceException: Object reference not set to an instance of an object.
    at ESP8266DebugPackage.ESP8266StubDebugExtension.StubStartSequence.BuildSequence(String targetPath, Dictionary2 bspDict, Dictionary2 debugMethodConfig, LiveMemoryLineHandler lineHandler)
    at uc.k1(bz a, ICustomStartupSequenceBuilder b)
    at uc.l.c(bz a)
    at VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.<>c__DisplayClass1_0`1.<RunAction>b__0()

    I checked the Norton history, and it has not complained since last weekend (perhaps you recall the vgagent false alarm)

    Note that if I follow the tutorial exactly, leaving the defaults (in particular the QIO setting)… I am able to upload, but the GDB never works and we are in the infinite loop of exception errors.

    So I think we’re really onto something here with those settings.

    I’ll continue with your suggestions from prior message later today…

     

     

     

     

    February 19, 2017 at 05:51 #10464
    gojimmypi
    Participant

    Just to confirm, the output of the FC command shows first the byte from one file, then the difference in the other file.

    00000002: 02 00
    00000003: 40 20

    Thus there is no “02 00” nor “40 20” (the 02 is in the file written, the 00 is in the other file read)

    The first 8 bytes of each file:

    File Written: E9 01 02 40 9C F2 10 40   = DIO 32m; I write DIO at 4M = (4M bytes x8=32m bits)
File Read:    E9 01 00 20 9C F2 10 40   = QIO 8m; (does it get changed to QIO 1Mx8=8m?)

     

     

    • This reply was modified 7 years, 9 months ago by gojimmypi.
    February 19, 2017 at 06:10 #10466
    gojimmypi
    Participant

    ok, success! There really does appear to be a problem with changing *existing* project debug parameters (VisualGDB gets really cranky, see prior posts), but when creating a NEW project, writing to the NodeMCU with Mode=dio, size=32m (bits) allows successful single-step GDB debugging!

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

    February 19, 2017 at 15:26 #10472
    gojimmypi
    Participant

    Hi again.

    Ok, 4th reply here. (I would have appended my prior posts, but this forum app does not seem to always allow editing?)

    So as to the original topic: JTAG debugging of the NodeMCU. No luck. Despite the success of VisualGDB and the GDB debugging via UART, the JTAG method still eludes me.

    It will go through all the motions, even at times apparently stopping at the breakpoint. However I can’t single step afterward, and in fact the code is either not running, or not on the chip – even after complete power cycle. No exception errors are spewing at 74880, but there’s also no WiFi server running as compared to uploading with GDB.

    Again, although the JTAG test is successful when first setting up the project, I see errors at upload time:

    Info : TAP esp8266.cpu does not have IDCODE
    Warn : Warning: Target not halted, breakpoint/watchpoin
    t 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 suppo
    rted for Xtensa. Have halted some time after resetting
    (not the same thing!)

    I am completely open to other ideas.  🙂

    February 19, 2017 at 19:44 #10478
    support
    Keymaster

    Hi,

    Oops, the “NullReferenceException” definitely looks like a bug we would like to fix. Would you be able to describe the exact steps that cause the problem or just send us the faulty project? You can also try building our ESP8266 package on your side: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage. As we had to guess many undocumented parameters with  ESP8266, we keep the related code open-source to simplify troubleshooting of issues that cannot be reproduced on our side.

    We have tried creating a new project and changing the settings, but could not reproduce the error.

    The JTAG problems could be caused by interference from other on-board components. From a quick look at the NodeMCU schematics, it looks like JTAG pins are used to access an SD card, so this could be causing trouble. To make a clean experiment with JTAG, we would recommend attaching the TDI, TDO, TMS and TCK to the ESP-12 module on top of NodeMCU and then physically disconnecting those pins from any wiring on NodeMCU (e.g. cutting the lines on NodeMCU).

     

    February 20, 2017 at 02:22 #10485
    gojimmypi
    Participant

    I have a plain ESP12, with no accessories, and I will test JTAG programming with that – instead of trace cutting on the NodeMCU.  🙂

    In the meantime – I was able to reproduce the error mentioned above – but of course not when desired! I tried to record a video a bunch of times, but in the end no error. But now – I have a project with the exception error! Curiously, it was at new project time, and I did not at all expect it. I was simply setting up a new GDB session for the bare ESP12.

    Although I cannot tell you what sort of steps I did differently – the project itself seems to have the problem saved with it. So I uploaded the whole project to GitHub, if you’d like to take a peek and see if you see the same problem. Simply open the project,  click “Debug – Program and Start without Debugging”. It does not matter if you have an ESP8266 connected or not. Immediately after attempting the upload the exception occurs.

    https://github.com/gojimmypi/E12-GDB2

    see also: https://github.com/gojimmypi/E12-GDB2/blob/master/Error.PNG

    btw – thanks for the tip on your ESP8266DebugPackage. It looks really interesting, but I was unable to compile it. I opened a GitHub issue (ho! that you seem to have already closed and answered – thank you!). But for reference in this thread for anyone else that may be interested:

    https://github.com/sysprogs/BSPTools/issues/3

    You can get the OpenOCDPackage.dll by installing OpenOCD via Tools->VisualGDB Package Manager. Then simply add a reference to %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\OpenOCDPackage.dll and you should be able to build the ESPImageTool and the related libraries.

    Thanks again for all the help with the ESP8266! 🙂

     

    February 20, 2017 at 03:37 #10488
    support
    Keymaster

    Hi,

    Trying out a plain ESP12 sounds like a good idea and should indeed explain whether NodeMCU is causing any interference.

    Thanks for the repro project, we have managed to reproduce and fix it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1389.msi

    The problem was specific to the “program without debugging” function.

    February 20, 2017 at 16:30 #10492
    gojimmypi
    Participant

    Hello.

    I’m glad the github project I uploaded was helpful in finding & fixing that problem.

    Regarding your  ESP8266 package; I tried adding that OpenOCDPackage.dll reference, however I still get a (different) compile error. See comment:

    https://github.com/sysprogs/BSPTools/issues/3

    As for the ESP-12… well, I’ve successfully programmed it with the GDB method! I am able to set breakpoints both in init section, as well as web server section that gets triggered when I connect to the web page served up by the ESP-12. The weird thing is that when I stop debugging, the ESP-12 code is no longer running (or at least the WiFi hot spot is not seen), even after power cycle.

    I have GPIO0 and GPIO2 tied high and GPIO15 tied low with 470 ohm resistors.

    When I power cycle the ESP-12, I see this message from the serial port, just once with no more data:

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

    load 0x3ffe8000, len 940, room 16
    tail 12
    chksum 0xc3
    ho 0 tail 12 room 4
    load 0x3ffe83b0, len 936, room 12
    tail 12
    chksum 0xfc
    ho 0 tail 12 room 4
    load 0x40100000, len 30536, room 12
    tail 12
    chksum 0xe9
    csum 0xe9
    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 : 3fff0620, prio:10,stack:512
    idle_task_hdl : 3fff06c0,prio:0, stack:384
    tim_task_hdl : 3fff2c78, prio:2,stack:512
    $T05#b9

    Now, if the GDB debugging session properly uploaded the code… it should run, even when not debugging, no? I’m not familiar with the inner workings of this type of debugging, so I’m not sure if this is expected behavior.

    Thanks again for your assistance.

  • Author
    Posts
Log In Register Lost Password
Viewing 15 posts - 1 through 15 (of 16 total)
1 2
  • You must be logged in to reply to this topic.