Unexpected reply from ESP8266

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

 

 

[support]

Hi,

Can you try hardwiring GPIO0 to ground so that it’s always set to 0? Does that fix the bootloader synchronization?

[Han Vertegaal]

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

[support]

OK, we’ve compared our bootloader to the esptool.py once again and it looks like the only difference is that esptool.py retries the sync several times after each reset. Can you try replacing the Sync() method in the bootloader test tool with this:

        public void Sync()
        {
            _Port.SetTimeouts(500, 1, 500, 0, 0);
  
            List<byte> syncMagic = new List<byte> { 0x07, 0x07, 0x12, 0x20 };
            for (int i = 0; i < 32; i++)
                syncMagic.Add(0x55);

            for (int i = 0; ; i++)
            {
                try
                {
                    if (i % 5 == 0)
                    {
                        _Port.EscapeFunction(SerialPortStream.CommFunction.CLRDTR);
                        _Port.EscapeFunction(SerialPortStream.CommFunction.SETRTS);
                        Thread.Sleep(5);
                        _Port.EscapeFunction(SerialPortStream.CommFunction.SETDTR);
                        _Port.EscapeFunction(SerialPortStream.CommFunction.CLRRTS);
                        Thread.Sleep(5);
                        _Port.EscapeFunction(SerialPortStream.CommFunction.CLRDTR);
                        Thread.Sleep(5);
                    }

                    _Port.Purge();
                    RunCommand(Command.ESP_SYNC, syncMagic.ToArray());
                    for (int j = 0; j < 7; j++)
                        RunCommand(Command.ESP_NO_COMMAND);
                    _Port.SetTimeouts(5000, 0, 5000, 0, 0);
                    return;
                }
                catch (Exception ex)
                {
                    if (i >= 20)
                        throw;

                    Console.WriteLine("Exception: " + ex);
                    Console.WriteLine("Extra output from COM port:");
                    for (;;)
                    {
                        byte[] data = new byte[512];
                        int done = _Port.Read(data, 0, data.Length);
                        if (done == 0)
                            break;
                        Console.Write(Encoding.ASCII.GetString(data, 0, done));
                    }
                    Console.WriteLine("-----------------------");
                }
            }
        }

If this does not help, please try running this version of esptool.py and attach its output. It should show what is sent to the device and when the device replies.

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

 

[support]

Thanks for verifying this. We have updated our ESP8266 toolchain to include the fix.

Please try the r5 build from here: http://gnutoolchains.com/esp8266/

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

 

[support]

Hi,

Good to know it works now. It’s hard to say what could be causing the wifi_set_opmode() bug, can be that a simple rebuild just fixed it. If you encounter it again, feel free to let us know.

[Author]

Posts