ESP32 WROOM 32E module programs okay but doesn't run

[keebler411]

I've created a custom PCB with a ESP32-WROOM-32E-N16 module. I can program the module using the ESP-PROG adapter, but the program either doesn't run or crashes after a short while Its a simple hello world in a loop program written using Arduino. I'm using the same settings (default) except flash size that I used for the official dev kit. Occasionally I have seen the hello world output when I power cycle the board. It seems to help if I lower the baud rate. I don't always see the log messages.

I've gone through several troubleshooting steps:

https://docs.espressif.com/projects/esp ... oting.html

I am at the point of checking the capacitance. But I already have 20uF of ceramic caps right beside the power pin and the power supply traces are actually a solid plane. It feels like brownout but see EN pin notes below.

I also read about the flash mode. I flashed the program in QIO mode. Does this particular module need to run from flash in a different mode?

Strapping pins are as follows:

GPIO0: external pullup and 1uF to ground (programs fine with ESP-PROG)
GPIO2: unconnected
GPIO12: unconnected
GPIO15: unconnected
GPIO5: external pullup (maybe a problem but not likely)
GPIO4: connected to something but shouldn't matter
EN: Floating when ESP-PROG not connected (PROBLEM). BUT ESP-PROG appears to pull it high when not bootloading so I'm not sure why I can't get the program to run with it connected. I'm using it for the serial monitor.

[ESP_Sprite]

Well, sounds like you already have a few options to debug:
- You need a proper RC network on EN, which includes a pullup or such.
- If it's a brownout, it's likely because your 3.3V voltage rail can't source enough power. What does that look like?

Aside from that, what do the crashes look like? Also, on another note, you shouldn't put a C on GPIO0. If you do, your board will always power up in download mode after power up.

Generally, if you can share your schematics, we can figure out more details.

[keebler411]

I got it working. It was the missing RC network on EN. Its a really messy hack to make it work. But I was expecting another rev anyway. BTW the cap on GPIO0 is okay. The ESP-PROG has one.

I see the flash is running in DIO mode but I programmed it in QIO mode. Should I change the running mode to QIO to speed things up? Alternatively can the unused SPI pins be used for something else?

Code: Select all

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13836
load:0x40080400,len:3608
entry 0x400805f0
[     3][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, Hello, World!
Hello, World!
Hello, World!

[ESP_Sprite]

I got it working. It was the missing RC network on EN. Its a really messy hack to make it work. But I was expecting another rev anyway. BTW the cap on GPIO0 is okay. The ESP-PROG has one.

No, it is not. There's a fair few topics where people had that exact issue. The ESP-Prog does not actually have that cap either, in the schematic it's indicated as NC which means there is a footprint for it but the component is not stuffed.

[keebler411]

That explains why I initially thought the ESP PROG should have returned the EN pin to logic high. Still it works with the cap on GPIO0. I have to wonder why there are empty footprints for the RC network for EN and GPIO0. For EN the functionality is obvious, but why then for GPIO0? I don't have an issue with removing the cap. But I prefer the external pullup on GPIO0 just to be sure.

Started testing peripherals and the SPI flash storage chip works. So thats something. Thanks.