After soft reset, ESP8266 can detect incorrect crystal frequency (actual 26MHz, detected 40MHz) (ESPTOOL-153)

[CaptKrisp]

• Operating system: Mac 10.14.6
• Python version: 3.7.4

Full esptool.py command line as run:

eclipse/php-2018-12/Eclipse.app/Contents/Eclipse//arduinoPlugin/packages/esp8266/tools/python3/3.7.2-post1/python3 eclipse/php-2018-12/Eclipse.app/Contents/Eclipse//arduinoPlugin/packages/esp8266/hardware/esp8266/2.6.3/tools/upload.py --chip esp8266 --port /dev/cu.usbserial-A400gwOQ --baud 115200 erase_flash --before no_reset --after soft_reset write_flash 0x0 Eclipse-Workspace/project_ESP-dev/ESP8266-07_DevBoard/project_ESP-dev.bin

Full output from esptool.py

esptool.py v2.8
Serial port /dev/cu.usbserial-A400gwOQ
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 40MHz
MAC: 84:0d:8e:aa:5c:1c
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Erasing flash (this may take a while)...
Chip erase completed successfully in 2.1s
Compressed 700272 bytes to 440794...

What is the expected behaviour?

Detect/Display configured Crystal frequency of 26MHz

Do you have any other information from investigating this?

The module is ESP8266-07 (listed as "Generic ESP8266 Module" in both Arduino IDE and Eclipse IDE) with 1MB flash, 26MHz crystal.
--Other build configs ... most not relevant but listed for the curious --
Upload speed: 115200
Crystal Freq: 26MHz (as printed on crystal case)
Flash Size: 1MB (FS:64KB OTA:~470KB) ... currently no longer using OTA since code is > 470KB
Flash Frequency: 80MHz ... <- this is my usual config but have also tried 40MHz
Flash Mode: have tried DOUT/DIO/QIO
lwIP Variant: v2 Higher Bandwidth ... <- this is my usual config but have tried all except "v1.4 compile from source"
Espressif FW: nonos-sdk 2.2.1+119
SSL Support: All SSL ciphers ... Not using SSL anywhere in project
VTables: Flash
Erase Flash: All Flash Contents
CPU Freq: 80MHZ

Flash: 25080 ... Chinese knockoff, I believe

Is there any other information you can think of which will help us reproduce this problem?

I suspect this is a misidentified/calculated crystal frequency but only for Generic module.
Does not seem to have any effect on application function.
Occassionally reports correct crystal freq of 26MHz.

If change Crystal Freq config to 40MHz then usually esptool reports 26MHz but sometimes reports as 40MHz (exact opposite behaviour from when 26MHz is selected in configuration).

[projectgus]

Hi @CaptKrisp,

Thanks for providing all this detail.

One question: What serial interface are you using to flash the ESP8266?

---

If change Crystal Freq config to 40MHz then usually esptool reports 26MHz but sometimes reports as 40MHz (exact opposite behaviour from when 26MHz is selected in configuration).

Actually esptool doesn't look at anything in the Arduino config (for either the binary or the command line arguments) to print the "Crystal is 40MHz" line. It tries to guess this entirely from the hardware configuration (the serial baud rate is divided from the crystal frequency, it know the current configured serial port baud rate and can read back the ESP8266's UART divider value, so it multiplies these two values to guess the crystal frequency).

If change Crystal Freq config to 40MHz then usually esptool reports 26MHz but sometimes reports as 40MHz (exact opposite behaviour from when 26MHz is selected in configuration).

This won't change esptool's detection routine at all, but does the application work if you set the Crystal Freq config to 40MHz?

The good news is that this value is only printed for informational purposes so nothing will malfunction because of it, but it'd be good to know why esptool v2.8 is getting it wrong. My guess is it's something to do with the USB/serial interface or driver.

[CaptKrisp]

Hello @projectgus,
Thanks for your reply.
The serial interface is FTDI-232 USB-to-RS232.
I thought I had read somewhere that the "Crystal is xxMHz" is a calculation based on baud rate, but I couldn't remember where I read it and was unable to locate it again. Although, that introduces a bit of a mystery of why the reported/calculated MHz isn't always consistent since on the host side the baud rate is consistent and the upload software would never see the data rate on the pseudo-TTL side of the interface, unless esptool is reading the FTDI registers which doesn't seem likely.

Changing the crystal freq config to 40MHz doesn't appear to have any effect on upload or program execution.
Since the upload command doesn't specify the crystal freq I had assumed the config value is used in compiling the core for any internal timing/clock divider calculations. But then again, as I mentioned, changing to 40MHz doesn't seem to have any effect on program execution. However, I haven't fully tested that theory but have noticed that my personal time library keeps accurate time no matter which crystal freq is configured.

It may also be of interest to mention that whenever I upload the same code (actually nearly the same) to any of my ESP8266-01 modules I always see the correct 26MHz reported during the upload. It is only on the ESP8266-07 that I see this incorrect guess of the crystal freq.

Anyway, I'm glad this isn't an actual bug. And this report can be closed. :)
Thanks very much for your reply.

Cheers,
Cap

[projectgus]

Hi @CaptKrisp ,

That seems quite unusual. If you feel like checking some more:

• Do you ever see a warning like "WARNING: Detected crystal freq nMHz is quite different to normalized freq 40MHz. Unsupported crystal in use"? This should be printed if the detection deviated by more than 1MHz.
• If you connect your FTDI adapter at 74880bps and reset the ESP-07, do you see some early boot messages like this? The baud rate for these early boot messages will be 74880 for a 26MHz crystal and 115200 for a 40MHz crystal.

[CaptKrisp]

Hi @projectgus ,

No, I haven't ever seen any warning message during the upload.
Setting baud rate to 74880 does print the startup messages:

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

load 0x4010f000, len 1392, room 16 
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld
V2
Mo

And, of course, the usual first few characters displayed is garbage when baud rate 115200.

I verified that this is the same no matter if configured for 26MHz or 40MHz crystal.
Does/should configuring the crystal freq have any impact on core compilation or program execution? If I recall correctly, with Atmel devices the crystal freq is used to set MCU fuse bits. However, it's been over a year since I switched from Atmel devices to ESP devices so I'm not 100% confident that I remember it correctly.

Also, I'm wondering if using Eclipse IDE instead of Arduino IDE might cause some odd behaviour in the resulting program code under various conditions. Any thoughts on this?

Thanks again for your interest in this issue.
Cap

[projectgus]

Hi @CaptKrisp ,

That's really odd! I have no explanation for this.

Does/should configuring the crystal freq have any impact on core compilation or program execution?

I don't actually work on the ESP8266 Arduino core, so I don't know what this setting does - sorry.

I can tell you that it doesn't change any persistent settings in the chip, or have any influence on the early boot ROM messages like you've printed printed above, or change any interactions that esptool.py does. Anything it changes is 100% runtime configuration after the Arduino sketch has loaded, and should be fully undone by a hardware reset or power cycle.

So I'm at a bit of a loss - it seems 100% confirmed that you have a 26MHz crystal, your FTDI chip seems to be setting the correct baud rate properly, and esptool's detection routine is confidently detecting a 40MHz crystal but only on this module.

Happy to keep this issue open to see if anyone else has the same problem, we might be able to determine a pattern.

[CaptKrisp]

HI @projectgus ,

Here is something interesting. Today I started tinkering with using BearSSL and changed the CPU freq to 160MHz in accordance with https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/bearssl-client-secure-class.html.

Now every code upload shows the correct crystal freq of 26MHz.
[edit] Correction, it isn't always showing correct crystal freq but it does much more often.

Cheers,
Cap

[projectgus]

Hi @CaptKrisp ,

That is interesting! How are you resetting your module each time you upload from esptool?

Angus

[CaptKrisp]

Hi @projectgus ,

I use 2 momentary switch buttons. Currently all my modules are installed on boards which have both buttons, 1 for reset (between RST and GND) and 1 for programming (between GPIO0 and GND).

Also, I'm no longer certain of the "much more often" displaying correct crystal freq. I usually pay no attention to the output from esptool except the chip erase time (I always do full erase with the upload) and the compiled code size.
During yesterday's many code uploads I tried to pay more attention to the displayed crystal freq. For the times that I did remember to look at the freq it did seem to be more often but I'm no longer convinced it is much more.
I'll try to monitor it more today for a better idea of whether it actually does increase or was my imagination.

[edit] I should mention that 99% of the code uploads are to my development board, which after code upload the module is still in boot mode 1, so I don't usually need to manually push the 2 buttons to upload new code but instead have the code issue ESP.reset().

Cheers,
Cap

[CaptKrisp]

Hi @projectgus ,

I believe I have this complete "resolved". As mentioned earlier, usually I have the code issue ESP.reset() instead of manually pushing both buttons when it's time to upload new code to be tested.
Whenever code is uploaded after the module is reset using ESP.reset() esptool always shows crystal freq of 40MHz. And when I use the buttons to reset the module then esptool always shows correct crystal freq of 26MHz.

My declaration of "much more often" displaying correct crystal freq a couple days ago was indeed accurate but only because at the time of tinkering with BearSSL I had also changed the upload baud to 921600 (which is auto adjusted to 460800 before upload begins). About 50% of the uploads at this baud do no restart the module after the upload so I am forced to push the reset button before the module begins executing the code. This also forced me to push both buttons to put the module in serial programming mode. And THAT was the times which correctly displayed the crystal freq.

I think we now have a clear picture of at least "when" the wrong crystal freq is displayed.

Cheers,
Cap

[projectgus]

Ah, I should have thought of this myself earlier!

Coming from a software reset, the ESP8266 may have the internal bus clock set to a different frequency already. We can/should account for this in crystal detection.

Thanks for bearing with me figuring this out. I'm not sure when this will be fixed, but please keep this issue open for now as documentation.

Angus

[danieltwagner]

Apologies for the potentially unrelated message, but this was the top Google result for a related issue about incorrect crystal frequencies that I discovered with an ESP8266 connected via a CH340G, and it turned out that in my case MacOS Catalina came with its own driver that was conflicting with the previously-installed custom driver or otherwise not working correctly. The symptom was a message like:

esptool.py v2.8
Serial port /dev/cu.wchusbserial14130
Connecting........_
Chip is ESP8266EX
Features: WiFi
WARNING: Detected crystal freq 156.38MHz is quite different to normalized freq 40MHz. Unsupported crystal in use?
Crystal is 40MHz

I found the resolution here: https://community.platformio.org/t/troubleshooting-ch340g-issues-on-macos/9522 (uninstall the 3rd party driver), and hope that this might help others stumbling across this report. After switching back to the native driver the crystal is correctly reported as 26MHz, and I can read the boot sequence with 74880 baud, which also failed with the 3rd party drivers (giving only garbage at all baud rates I tested, including 74880).