ESP32 GPIO 0 Clock Input: Good Crystal Startup Delay?

[pilkyton]

The ESP32 can receive clock signal on GPIO 0 to sync with external Ethernet PHYs.

But as most people know, the clock signal interferes with the ESP32 bootstrap pin (GPIO 0 chooses between regular/firmware flashing boot modes).

Therefore, it's necessary to delay the clock signal startup to happen *after* the ESP32 has finished reading the GPIO 0 boot mode setting value. This can be done by tying the Crystal's "Enable" pin to the "EN" voltage that also turns on the ESP32. And then using a time-delay chip/discrete circuit to delay the crystal "enable" signal to happen X milliseconds after the ESP32 receives the "EN" voltage.

But to do this correctly, it's necessary to know how much crystal startup delay is TOO MUCH or TOO LITTLE.

Let's look at the timing values I was able to find in ESP32 documentation:

• I was reading the ESP32 datasheet for my ESP32-WROOM-32E, and it says that the ESP32 first waits until the voltage is high enough to start the ESP32. After the voltage is high enough, it waits 3-4 milliseconds, and then it spends 1 millisecond reading the bootstrap pin values into the latches. After that, the bootstrap GPIOs become regular I/Os. This is described on Page 14, Table 5 of https://www.espressif.com/sites/default ... eet_en.pdf
• So this means that it's safe to start the crystal roughly 6 milliseconds after the ESP32 "EN" pin has received full power. But that would be extremely close to the dangerous threshold where the GPIO 0 "boot setting" is still being read, so the crystal startup should obviously be delayed more than just 6 milliseconds.
• Secondly, the documentation says that ESP32 takes around 318 milliseconds from "power-on" until the app_main firmware code begins to execute, as described here: https://docs.espressif.com/projects/esp ... -time.html
• And lastly, the documentation above says that various optimization flags and eFuses can be used to set a faster, less-logging/less-validation startup mode where it only takes roughly 30 milliseconds from "power-on" until app_main executes.

Based on this, my assumptions are:

• Assumption 1: I assume that the crystal MUST be started *BEFORE* app_main begins to execute. Meaning the crystal should be started BEFORE 300 milliseconds have passed.
• Assumption 2: It's safe to start the crystal 6ms after EN power-on, but it's too close to the edge, so a safer "minimum" delay time would be something like 20 milliseconds instead.
• Assumption 3: If the ESP32 has been configured for fast startup (around 27ms), the crystal should be started before 27ms have elapsed.

So this would mean there's a safe crystal delay range of 20ms (minimum) to 295ms (maximum) in normal ESP32 startup mode, and 20ms (minimum) to 25ms (maximum) in fast ESP32 startup mode.

I have picked a 200ms startup delay, but I am questioning whether I should have aimed for 20 milliseconds instead...

[MicroController]

• Assumption 1: I assume that the crystal MUST be started *BEFORE* app_main begins to execute.

Not sure about this one. Depends on when(/where) GPIO 0 gets configured to be the clock input...

Update:
Seems that the ethernet IO pins, including the clock input, are not set up until esp_eth_mac_new_esp32(...) is called from the main application, see the example.

[pilkyton]

If anyone is reading this in the future:

- Olimex's popular design is awful and totally incorrect. It had way too much delay (around 500ms if I remember off the top of my head), and did not start the crystal fast enough, so code had to be added to ESP-IDF SDK (happens when the board type is set to Olimex when compiling software) to accommodate its slow startup: https://github.com/espressif/arduino-esp32/issues/6142
- The correct startup delay is below 300ms. Then you will be sure the crystal is running before the ESP32 begins executing code (which happens around 320ms).
- Our final board ended up around 280-290ms startup delay and it works perfectly with no need for custom hacks.

However, if you burn efuses to make the ESP32 boot faster (less startup diagnostics etc), it may start as quickly as 30ms, and would need a much faster crystal startup. It's extremely rare to find any timing chip that can accurately do a 20ms timing though. So just... don't burn efuses!