ESP32 does not start FW when powered up

I’m not sure if this is a hardware or firmware issue. When I flash firmware using mos into my ESP32, it starts the FW as soon as the flash completes. If I then power off the ESP32 and then back on, the FW does not start.

Is there something special I need to do to get the FW to start when the device is powered up?


It should start right away. Are you powering up through VIN/GROUND or the USB?

I have several random problems, when I power it up from VIN, as there is a peak current consumption as Wifi Starts, it could not be solved by placing a capacitor, so I ended up powering the unit from USB

Currently USB. I’m going to try the VIN this weekend and see…

I think the definitely solución is to delay in 1 or 2 seconds the wifi start from the library. That should avoid the initial peak current at boot. Let me know if you manage to modify it. The USB power is protected by a diode that is not present in the VIN power

Thanks, I’ll try this and report back.

No joy. It does not start when powered via USB or VIN. The only time it starts is if MOS is running when I plug it in to USB, or right after I flash it.

Are you powering up with a 2AMP usb source? I do not have any trouble from USB (not same luck from VIN)

No I’m powering it from my MacBook Pro when using USB.

My issue may be the board I’m using. It has no reboot button, instead it has a CP2102N which is supposed to handle reset as appropriate.

Try a standard 2A usb (like the ones that comes with android devices), check the specs for at least 2A current output

Wow, I plugged it into a 2A wall cube (that plugs into an electrical outlet) and it came up and booted. So we’re back to this being a current inrush issue?

But then, why would it matter if I have mos running or not?

For me it was that, the problem (I think), is that even with 2A through VIN, it still gets stuck on Wifi Start peak consumption, USB input has a diode that prevents that peak, although through VIN, the problem is random, but my units are headless, so I cannot risk a boot hang from VIN.

Yo don’t need MOS for the device to run, MOS is for logging and flashing (testing), after that, OTA updates are your best mate once you have an update for an stable firmware

Well what I meant about mos, is that if I plug it in to my MacBook USB port and mos is running, it boots. All is good. If mos is not running, it does not boot. So if this is current inrush related, what i it about mos running that makes it boot?

My device will also be headless but I need to power via VIN so I’ll have to find a fix for that.

Thanks for your help!

Theres something when power up from a PC, that signals something to the board maybe. As a solution I’m currently using this conectors for plugging through USB

Maybe you should play with delaying the Wifi Start from the library

Are you sure the status of the boot strapping pins is as it should be?

No, I’m not…

I’m reading about it here (which I see is what you linked):

At startup I get a report about GPIO2:

[Nov 25 23:56:29.558] e[0;32mI (10883) gpio: GPIO[2]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 e[0m

I’m not really following it but I just started…

UPDATE: As I look at the boards datasheet, I see he used GPIO2 as the SD card chip select. I also see that GPIO2 is related to boot, so maybe there is an issue there.

Check the boot mode message too.

What board are you using?

Strangely, there does not seem to be a boot message as described. I couldn’t find it.

Here is the board:

These are the first messages after reset

[Nov 26 09:33:36.638] ets Jun  8 2016 00:22:57
[Nov 26 09:33:36.638]
[Nov 26 09:33:36.638] rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[Nov 26 09:33:36.638] configsip: 0, SPIWP:0xee
[Nov 26 09:33:36.638] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[Nov 26 09:33:36.638] mode:DIO, clock div:1

I don’t see anything like that. If I use mos to do a reboot, my first messages are:

[Nov 26 09:56:32.120]  J 1 otadata          OTA data         01 00 0000d000 00002000 00000000[0m
[Nov 26 09:56:32.120] [0;32mI (81) boot:  2 app_0            OTA app          00 10 00010000 00180000 00000000[0m
[Nov 26 09:56:32.120] [0;32mI (89) boot:  3 fs_0             FS               01 82 00190000 00040000 00000000[0m
[Nov 26 09:56:32.121] [0;32mI (97) boot:  4 app_1            OTA app          00 11 001d0000 00180000 00000000[0m
[Nov 26 09:56:32.127] [0;32mI (106) boot:  5 fs_1             FS               01 82 00350000 00040000 00000000[0m
[Nov 26 09:56:32.138] [0;32mI (114) boot: End of partition table[0m
[Nov 26 09:56:32.138] [0;32mI (118) boot: OTA data 0: seq 0x00000001, st 0x10, CRC 0x157a2b85, valid? 1[0m
[Nov 26 09:56:32.149] [0;32mI (126) boot: OTA data 1: seq 0x00000000, st 0x00, CRC 0x00000000, valid? 0[0m
[Nov 26 09:56:32.155] [0;32mI (133) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x2cca0 (183456) map[0m
[Nov 26 09:56:32.202] [0;32mI (189) esp_image: segment 1: paddr=0x0003ccc8 vaddr=0x3ffb0000 size=0x02974 ( 10612) load[0m
[Nov 26 09:56:32.208] [0;32mI (192) esp_image: segment 2: paddr=0x0003f644 vaddr=0x40080000 size=0x00400 (  1024) load[0m
[Nov 26 09:56:32.219] [0;32mI (196) esp_image: segment 3: paddr=0x0003fa4c vaddr=0x40080400 size=0x005c4 (  1476) load[0m
[Nov 26 09:56:32.225] [0;32mI (205) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xc68d0 (813264) map[0m
[Nov 26 09:56:32.432] [0;32mI (418) esp_image: segment 5: paddr=0x001068f0 vaddr=0x400809c4 size=0x0fccc ( 64716) load[0m
[Nov 26 09:56:32.461] [0;32mI (447) boot: Loaded app from partition at offset 0x10000[0m
[Nov 26 09:56:32.466] [0;32mI (447) boot: Disabling RNG early entropy source...[0m
[Nov 26 09:56:32.472] [0;32mI (447) cpu_start: Pro cpu up.[0m
$ mos console
Using port /dev/ttyUSB0
[Nov 26 17:27:09.261] ets Jun  8 2016 00:22:57
[Nov 26 17:27:09.264]
[Nov 26 17:27:09.264] rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)