The ESP-WROOM-32 minus lid sitting on a NODEMCU ESP-32S module.
An unfortunate thing about the breadboard-style ESP32 adapters is that most of them don’t include any bulk capacitor at all, and the ESP modules themselves don’t incorporate bulk capacitors. ESP32s are very “bursty” in their power usage, mostly due to WiFi. As a result, it can be hard to make them work reliably in these kinds of breadboard setups.
In addition to the large electrolytic on the breadboard power rail (which is probably quite high ESR), I’d recommend adding a low ESR electrolytic, or a tantalum or ceramic capacitor with a reasonable capacitance (10uF+). Put them as close to the module as possible, try to minimise the breadboard wires or breadboard traces in the current path. Soldering to the module itself would be the best!
@Ken_Taylor, if your sometimes-glitching module is also this type then it may be worth trying the same things.
(The other alternative, now that third party dev boards like the one @Harvs posted are on the market, is to switch to these. All the designs I’ve seen include an on-PCB bulk capacitor.)
I use a plain board (pictured earlier in this thread). The electrolytic cap is a low ESR 470uF. I will attempt to solder it directly to the board at the module’s pins. Not easy as there is very little room between the sockets and the module (which is 0.05" pitch)…
I’ve figured this out, The boot time is the same as documented by @eyal but the time stamps on log messages increase too fast during boot because the wrong CPU frequency is used as a clock divider during second stage boot. More detail on Github.
Interestingly, I learned the ESP32 doesn’t need an external oscillator. It boots from ROM using an internal phase locked loop (PLL) clock. An external oscillator is included in the package we use and is selected by setting a register value in the second stage boot to change the CPU clock source.
Last meeting their was doubt expressed as to whether the ESP32 could be run without an external oscillator. It was pointed out that a phase locked looped (PLL) clock still needs an oscillator. Looking at the technical reference manual section 3.2.2 - Clock Source says:
The ESP32 can use an external crystal oscillator, an internal PLL or an oscillating circuit as a clock source.
Specifically, the clock sources available are:
• High Speed Clocks
– PLL_CLK is an internal PLL clock with a frequency of 320 MHz.
– XTL_CLK is a clock signal generated using an external crystal with a frequency range of 2 ~ 40 MHz
The oscillator source for the PLL clock is not specified however it is implied it is internal.
The XTL_CLK on the modules we use is 40 Mhz but the CPU clock speed can be various multiples of that so presumably the XTL_CLK clock also uses a PLL. If the PLL_CLK and the XTL_CLK both use a PLL and the same external crystal they are not separate clocks. The PLL clock is defined as internal and specified to operate at 320 MHz. The PLL_CLK could not be specified as a fixed frequency if the variable frequency XTL_CLK source is used and would therefore require a second crystal at a fixed frequency if it was not internal. This seems unlikely.
Almost certainly going to be an internal RC oscillator feeding the PLL.
It’s very common across vendors to start on the internal RC oscillator then switch over to an external xtal during boot code. Normally it falls back to the RC oscillator if the xtal fails to start, with ARMs M-series having a interrupt to allow user code to deal with a failed external oscillator.
So if you want, you may be able to try it out by shorting the xtal pins and seeing if the it still starts with a boot message about the oscillator. You may also find the current IDF doesn’t handle it.
This is certainly true for ATmega chips. You can use the internal clock but as I guess you’d be aware, if you require a greater degree of accuracy then an RC circuit with high precision resistors or a crystal and capacitors is required. I usually use a crystal.