get nothing running with V3 rc1, not even hello-world

[jumjum123]

@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

[ESP_Angus]

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.

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

[ESP_Angus]

@ESP_Angus why is the default to use gpio matrix now instead of mux?

Other configs (PICO-D4, D2WD, manually remapping SPI pins) used the GPIO matrix already. The fix which introduced this change also fixed a bug with dummy cycle counts for 80MHz SPI flash support. Cycle counting is different with/without the GPIO matrix, so my guess is that the change is to make it consistent across all chip types & configs. Have double-checked this, though.

[costaud]

I think the cause to this issue is that compiling the firmware with 40Mhz option and burning the flash with 20Mhz mode.
Since the options are introduced during compile time, the download options should be the same as the ones of compiling.

[costaud]

@ESP_Angus why is the default to use gpio matrix now instead of mux?

In order to get better timing for the signals.