ESP32-S3FH4R2 Power Up Issue

[IanKibblewhite]

Hi All,

We have a project using the new ESP32-S3FH4R2 on our own board. It's a challenging design but the ESP32-S3 is really performing well and beyond expectations.

We have found a power up issue which appears to be specific to this device and are interested in whether it's a known issue or if anyone can give us direction on this. Our code is complex but we've managed to reproduce the issue using the simple blink example, suggesting it's not code.

When the board is powered up, it doesn't always boot, but it is very predictable. If the device has been running, is powered down and then powered up again within a short time it alway starts correctly. If it's powered down for more than 2.5 to 3 mins, it will never start up correctly. Our temporary workaround is to power it up, down and up again and it works flawlessly thereafter. All our ESP32-S3FH4R2 boards exhibit the same characteristic. Our board is very simple with few components and external design almost identical to that of the DevKitC. It occurs when power from a USB or directly from a power supply.

We can run the exact same blink example code on an ESP32-S3-DevKitC-1 with an ESP32-S3-WROOM-1 module and it works fine without the issue, which makes us think it may be related to the ESP32-S3FH4R2 itself.

Attached is the device we are using. Anyone got any ideas on what could cause this and a workaround?

Thanks,

Ian

[Acuario]

Have you monitored what is coming out on the device serial port?
It sounds like the device is going into boot loader mode - of which there are several.
Seeing what comes out on the serial port will let you see if this is what's happening.
I've experienced this happening very occasionally with a ESP32-D0WDQ5 Rev 3 chip.

[Sprite]

Additionally, take a look if the EN signal is in spec - on powerup it should be low long enough for Vcc to rise to a proper level. The datasheet has the details iirc.

[IanKibblewhite]

Acuario, ESP_Sprite, thank you for input. You are right. It was going into boot loader mode.

As suggested, I separated the power from the serial so that I could monitor the serial on power up, and every time it didn't start it was because it was going into boot loader mode.

I put a scope on the 3.3V Power, CPU_PU (EN), and GPIO0. The problem was with GPIO0. I was relying on the internal weak pullup on this line but I didn't realize that the internal pullup was only active after the CPU came out of reset. Any delays from capacitive loading (in my case 0.01uF switch debouncing) are with respect to the CPU coming out of reset, not with respect to powerup. In my case there is about a 5ms reset from the standard RC circuit.

Attached are the scope plots. In all plots the top trace is CPU_PU, the second trace is GPIO0 and the bottom trace is the 3.3V power.

Plot 4: Power up with GPIO0 No connection. (Correct startup)
Plot 5: Power up with GPIO0 0.01uF to Gnd. (Started in Boot Loader Mode)
Plot 6: Power up with GPIO0 external 10k pullup. (Correct startup)

In may case (plot 5) the additional delay after reset when the internal pullup becomes active was enough to make the timing marginal. I think I'll play it safe with a 10k external pullup so that GPIO0 is 1 from power up. Problem solved.

Many thanks to you both for your help,. Very much appreciated.

Best Regards,

Ian

[gunstr]

I'm soo happy I found this thread, I faced exactly the same problem. I used a 0.1uF cap across the boot switch as on the Dev board and my boards did not boot after 30min disconnection from power - quite time consuming to troublesahoot

Adding an external 10k pullup the boot signal obviously goes high immediately at power up and all my boards are now booting perfectly.

Conclution - do not rely on the internal pullup. Even if it might work without a cap it's better to avoid any potential timing issues and pull the GPOI0 high directly when power is applied.

Best Regards