[Han Vertegaal]

Thank you ivanroberto! That helped. Now I can flash finally flash my code.

I’m not sure whether this change is the ‘approved’ method to support a larger device, but for now it works. The original segment length was 240K, and the change you proposed increased that to 368K. For a 4MB device (ESP12E) that is still less than I would expect to be able to use. The file eagle.app.v6.new.2048.ld contains a size of 0xE0000 = 896K, which I will now use to get me some extra space. As my application grows I will eventually find out what the real available length is.

Thanks again.

 

[Han Vertegaal]

Hello again,

The new toolchain works fine. At first I had some trouble getting past the flashing stage as there seemed to be a failure to communicate with the GDB Stub, but that turned out to be a baud rate problem: the GDB stub rate was set at 115200 instead of 74880. With that solved, I could set the first breakpoint and step through the code. So far so good. Thank you for your efforts in this.

I’ve also run into another problem which at first sight seemed unrelated. I’m working with the RTOS based HTTPDemo sample, and on line 128 it calls wifi_set_opmode(SOFTAP_MODE). At that point the program apparently crashed, with the connection to the GDB Stub lost, and the module not appearing in the list of APs. When I replaced this statement with wifi_set_opmode_current(SOFTAP_MODE), the program continued and the AP did appear. I remembered having fiddled with the Debug settings in the project properties, particularly the SPI FLASH Mode. It was changed from ‘qio’ to ‘dio’. Undoing this change and restoring the original call at line 128 fixed everything. I’m just mentioning this so that others can learn from my mistakes.

Thanks again for your help.

 

[Han Vertegaal]

Success! It worked this time. I still had to change the second sleep to 25ms, but the I got the following output:

C:\Users\Han\Desktop\ESP8266\BootloaderTest\bin\Debug>BootloaderTest COM3 74880
Connecting...
Syncing...
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
Exception: System.Exception: Timeout reading reply
 at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop
\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 60
 at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266Bootloade
rClient.cs:line 165
Extra output from COM port:
-----------------------
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
>>> c0
>>>0108020007071220
Sync successful.

 

[Han Vertegaal]

No, hardwiring GPIO0 to GND does not fix the synchronisation.

[Han Vertegaal]

Hello,

Sometimes I do get the boot mode “1,6”. I haven’t found out exactly what it depends on, but it I did see a change when I flashed the device using Arduino, whereas before it was flashed with NodeMCU firmware. At any rate, neither mode “1,6” nor “1.7” allow a successful sync. While searching for the significance of the different boot messages, I saw both “1,6” and “1,7”, but no explanation of the difference. Interestingly, both Arduino (which uses ESPTool as far as I know) and the NodeMCU-flasher can flash the device without any problem.

The GPIO2 and GPIO15 lines are always high and low respectively.

At the first sleep (5 ms), RST = low and GPIO0 = high. At the second sleep (50 ms) RST = high and GPIO0 = low. GPIO is apparently set as output at some point during the reset because a signal appears on that line. See also: https://zoetrope.io/tech-blog/esp8266-bootloader-modes-and-gpio-state-startup. At the final sleep (5 ms) RST remains high and GPIO0 is 1.8V which is somewhat indeterminate.

When the sync command is send to the ESP8266, nothing is returned from the device.

 

 

[Han Vertegaal]

No, unfortunately there is no successful sync. I do see the message ‘ets Jan  8 2013,rst cause:2, boot mode:(1,6)’ appear after the reset, but nothing happens after that.

[Han Vertegaal]

It seems the GPIO0 signal was held low for too short a time. The RC network (12k/100nF) on the reset input causes the reset to rise rather slowly. A delay of 50 ms gets the board in the correct mode reliably.

The output from the bootloader test program then becomes as follows:

Connecting…
Syncing…
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
Exception: System.Exception: Timeout reading reply
at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 60
at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 179
Extra output from COM port:
———————–
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
Exception: System.Exception: Timeout reading reply
at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 60
at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 179
Extra output from COM port:
———————–
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
Exception: System.Exception: Timeout reading reply
at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 60
at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 179
Extra output from COM port:
———————–
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
Exception: System.Exception: Timeout reading reply
at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 60
at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 179
Extra output from COM port:

[Han Vertegaal]

This is the output from the test program:

C:\Users\Han\Desktop\ESP8266\BootloaderTest\bin\Debug>BootloaderTest COM3 74880

Connecting…
Syncing…
<<<0008240000000000070712205555555555555555555555555555555555555555555555555555555555555555
>>> 0d
Exception: System.Exception: Unexpected reply from ESP8266
at ESP8266DebugPackage.ESP8266BootloaderClient.RunCommand(Command op, Byte[] data, Int32 chk) in C:\Users\Han\Desktop
\ESP8266\BootloaderTest\ESP8266BootloaderClient.cs:line 66
at ESP8266DebugPackage.ESP8266BootloaderClient.Sync() in C:\Users\Han\Desktop\ESP8266\BootloaderTest\ESP8266Bootloade
rClient.cs:line 162
Extra output from COM port:

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

load 0x40100000, len 28740, room 16
tail 4
chksum 0xcd
load 0x3ffe8000, len 2888, room 4
tail 4
chksum 0xbc
load 0x3ffe8b50, len 15252, room 4
tail 0
chksum 0x4f
csum 0x4f
? ?? ? ?? ? ???? ??? ??? ?? ?????? ? ? ? ??? ?????? ?? ?? ? ? ??? ? ? ????????? ? ???
? ? ?? ? ?????? ? ??? ? ? ? ? ?? ? ??? ?? ???? ? ———————–

The boot mode:(3,6) seems incorrect, but when I use use a terminal and start in download mode, I see:

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

ESP8266BootloaderClient::Sync manipulates the DTR and RTS lines, but not in a way that initiates flash programming. (see this schematic). However, I don’t know if that was the intent.

 

 

[Han Vertegaal]

Update: I installed the Arduino IDE and tried a few samples. It flashes the device without any problems, and it even exercises the DTR and CTS lines of the CP2102 USB/UART bridge such that it is not necessary to hold the flash key to place the module in flash programming mode.

This leads me to conclude that there is nothing wrong with my hardware setup, but rather a problem with the debug settings in the project properties (I have tried most permutations), or that there exists some deeper incompatibility between VisualGDB and the nodemcu devkit 1.0.

[Han Vertegaal]

When listening at 74880 bps after flash & reset, I get the following:

“ets Jan   8 2013,rst cause:2, boot mode:(1,6)”

[Han Vertegaal]

Hello,

Yes GPIO15 is wired to ground through a resistor. Also, I have been able to use the ESP8266Flasher (https://github.com/nodemcu/nodemcu-flasher) to flash the nodemcu firmware.

[Han Vertegaal]

Thanks. I disabled DNSv6 advertisement (RFC 5006) in my router, and that seems to work.

[Han Vertegaal]

The IntelliSense update lasted indefinitely (at least more than half a day). I created a new empty C++ project, and that had the same problem. A repair of VS2013 finally solved the problem.

[Author]

Posts