intermittent startup when powered from DC supply

[Oliver2003Taylor]

Hi everyone! I’ve been working on an ESP32 project using MicroPython for a Wi-Fi sensor logger, and while the code works great once it’s actually running, I’m hitting a bit of a wall with startup reliability... It’s strange because when I use a bench supply or USB, it boots up perfectly, but as soon as I switch to a small DC supply through a regulator, it occasionally just hangs. It won't start the MicroPython runtime until I manually hit the reset button, which is a big issue since I meed this project to run unattended.

I’m really trying to dig into the why behind this rather than just finding a quick fix for one board. I’m curious to learn how sensitive the MicroPython interpreter is to things like voltage ramp-up speed, and if there are soecific ways to handle the EN and BOOT pins to make the startup sequence more 'bulletproof' for always-on devices. are there any known MicroPython-specific quirks compared to ESP-IDF that I should be designing for??? I’d love to hear from anyone who has deployed similar projects in the field. I’m really here to learn from the discussion and understand the design logic so I can make my future projects more reliable. Thanks in advance for any insights!

[davefes]

Is the ESP32 on a dev board? Is it a 5V supply? I would check the output voltage versus the current capability of your regulator. I leave boot.py as is and in main.py print a message that I am waiting 2 seconds for a CTLR-C, maybe you are getting that far. Are you trying to enable WiFi on bootup?

I always put a 1uF cap across the EN button, you will find that recommended in several sources.

[Oliver2003Taylor]

I’ve ruled out print-based debugging, but your point regarding supply stability and reset timing is likely the culprit. for context, I’m using a custom ESP32 module based PCB (not a dev board) with an external 3.3 V regulator. I’ll be probing the power-on reset (POR) waveform and watching for brownout conditions during the initial Wi-Fi/radio current spikes. if the regulator’s ramp rate is too slow, the ESP32 could be releasing reset before the rail is fuly stable, which would explain the inconsistent boot behavior across diferent power sources. appreciate the insight.

References I’m checking:

Espressif Hardware Design Guidelines, Section 2.1 (power-up timing)

MicroPython reset diagnostics (machine.reset_cause() for brownout detection)

[Josverl]

It won't start the MicroPython runtime until I manually hit the reset button,

Do you have anything in place to allow external monitoring of the startup process that allows you to verify exactly where it stops?
Either a simple pin state, or a neopixel changing color depending on the steps in the startup?
I use a neopixel to do that on a project that has been running and restarting for multiple years now, though that is more or less permanently powered and no deep sleep involved.

I know that the ESP32 have a few rather significant power spikes on enablement of the WLAN stack that can be influenced by external circumstances beyond whatever is happening on your board. Wifi spectrum, neighbour gaming, lease expired etc etc That may ask more power in 5% of the cases than the HW design accounts for.
Checking for a brownout restart reason on boot would be my first thing to understand , and bulletproof

https://embeddedprep.com/esp32-brownout-tutorials/amp/

[davefes]

Correction: Looking for a print msg in terminal is not appropriate for your problem.

[Oliver2003Taylor]

I think you're absolutely right about the WiFi power spikes; I suspect the current draw during the WLAN initialization is exactly where the brownout or hang is occurring on my custom PCB. I’ve actually started using a 'status LED' sequence similar to your Neopixel suggestion. Currently, the board hangs before the first LED toggle in my boot.py, which reinforces the idea that it's a low-level hardware or power-rail stability issue during the very first stage of the bootloader or radio init...

I’m going to look into the EN pin RC delay and adding more bulk capacitance (10uF - 22uF) closer to the ESP32 VCC pins to buffer those spikes. I'll report back once I see if stretching the reset delay allows the LDO to stabilize enough for the radio to kick in...

[ekspla]

adding more bulk capacitance (10uF - 22uF) closer to the ESP32 VCC pins to buffer those spikes.

This is not necessarily a good idea because a large capacitor induces a higher inrush current spike.

[Oliver2003Taylor]

adding more bulk capacitance (10uF - 22uF) closer to the ESP32 VCC pins to buffer those spikes.

This is not necessarily a good idea because a large capacitor induces a higher inrush current spike.

you re right, I haven't thought about it before.

[davefes]

Does WiFi get initialised before your boot.py runs? I didn't think so.

Adding a large capacitor like 1000uF on the output of your power supply would cause a problem if you are switching that supply on and off. If is the running all the time then that capacitor will act like a small battery and help to supply whatever current the device needs on start-up.

Have you got a schematic that you can share?

[peterhinch]

This sounds like an electrical issue. When you use the questionable supply, how are you switching it on? If you are switching the mains supply it's possible that the 5V level rises too slowly to trigger the chip reset mechanism. You need to get your hands on an oscilloscope and see what's actually going on.
[EDIT]
It later struck me that an explanation was in order.
A microcontroller usually has a reset pin which is typically pulsed low to reset the chip. This must be done after power up to ensure it starts correctly. To make this automatic, typically the pin is connected via a capacitor to gnd and via a resistor to Vcc. These have a time constant CR=T which is on the order of 200ms. If power is applied quickly (t<T), the chip gets a stable Vcc while reset is still held low by the capacitor. After time ~T the capacitor charges sufficiently for the reset state to be removed, and the chip runs. If power is applied gradually (t > T), the reset state can be removed before the chip has a valid Vcc, leading to incorrect startup.

[Oliver2003Taylor]

Thanks Peter, that’s a fair point. To clarify, this is a custom ESP32-based PCB, not a standard dev board, which increases the likelihood of a layout-specific power issue. I’ve kept the MicroPython environment minimal to isolate the fault, so I agree this points toward a hardware Power-On Reset (POR) or sequencing failure. I’m now focusing on the 3.3V rail ramp rate and browwnout triggers during the initial radio calibration, as those transients likely explain the inconsistency across different power sources. I appreciate you reinforcing the need to separate hardware fundamentals from software symptoms.

[ekspla]

It seems to me that this is a power supply issue, as well.

First of all, avoid using high resistive connections (e.g. breadboard) in DC supply. Use solder joints instead.

ESP32 is known to be a power hungry device. The current spikes can easily exceed 0.5 A in startup and in using WIFI,
see, for example, here. Use a power supply sufficient for the current spikes.

You seem to have a bench supply, a small power supply and a voltage regulator, presumably of a low voltage dropout (LDO)
type. The voltage regulator itself might be also the reasoning. This is because dropout voltage of some cheap LDO
regulators increases abruptly by increasing the current, thus requires a large headroom voltage.

I would suggest testing your voltage regulator by using your bench supply instead of the small power supply. Change
output voltage of the bench supply to the input of regulator and test. CAUTION: Do not exceed maximum input voltage
of the regulator. You can see the head room voltage required to startup in the tests.

If the output voltage of your small power supply is 5 V, I recommend using a very low dropout voltage regulators, say
rated dropout voltage of less than 1 V at 1 A. You might think this is overkill, but the cost of a regulator is not a
problem if you do not plann to use it in mass productions. For example, the one I am using in my current project with ESP32 is
MIC37100, which is rated 280 mV dropout at 1A and it costs less than 2 US$.

[Oliver2003Taylor]

This is a custom ESP32 module-based board, not an off-the-shelf dev kit. While the schematic follows Espressif’s reference design, I suspect the physical layout or the regulator's transient response is causing the inconsistency. I’m currently re-verifying the power-up sequencing and the EN/BOOT strapping levels under load, as these are the most likely areas where my board deviates from a standard dev board's behavior. I’ll report back with oscilloscope measurements of the 3.3V rail ramp and reset timing shortly.

[flong-dev]

It’s hard to meaningfully diagnose this without basic hardware data.
For power-up issues on ESP32, the first step should really be measurement, not speculation.
To move this forward, it would help to provide:
schematic of the power path
oscilloscope capture of 3V3 during power-up
EN / RESET pin waveform relative to VDD
In most cases like this, comparing the waveforms of the two power supplies with an oscilloscope can reveal the cause.