Small update on this bug, there's currently a mismatch where if you compile the bootloader with SPI Flash freq 40MHz and then flash with frequency set to 20MHz, this will happen. The fix will be to read the value set at flashing time (which is written into the bootloader's image header). Workaround is to make sure the bootloader is compiled with the same flash frequency which is used at flashing time.
jumjum123 wrote:@ESP_ANGUS,
thanks for the feedback. Good to know, that problem is not between my ears, at least this time
In addition to question from @wifive:
There are some other configs for example, which are board specific.
Isn't there a way to recognize them automatic ?
I understand the reason for changing default of XTAL, but this happens only in special cases. Why bother everybody ?
- Flash SPI mode
- Flash SPI speed
- Flash size
- Main XTAL frequency
The reason for removing automatic detection of the crystal is we need to consider companies shipping in production, where the bug may only manifests under certain conditions. This may create a risk for them if the issue only shows up after QA. We are looking to revisit this in a future IDF version, there's a strong chance we can remove the detection bug and restore autodetection as the default.
Detecting flash size is done by esptool.py at flashing time by default. I believe the Windows GUI Flasher also detects the size when you connect.
Automatic detection of flash modes and speeds is hard, because it can be error prone. The maximum flash frequency is a physical property of the PCB and the flash chip - a high clock frequency may work under some conditions (temperature, timing, interference, etc.) and fail under others. Similarly, quad SPI flash modes may work fine if the relevant module pins are connected - but if those pins are also connected to some other peripheral then it can suddenly stop working if the ESP32 enables that peripheral. For these options we've opted to set sensible defaults, and let people change them if they need to.