ESP32 Forum

I've run into a brick wall on this problem, I'm hoping someone can help.

My setup is an identical development config with each type of module:

- VSCode 1.58.0 + PlatformIO 5.2.0a9
- ESP-PROG board for code upload, icon file upload and reading serial output
- Platform: espressif32
- Board type: esp32dev
- Framework: arduino
- Partition table: default.csv

I made a simple board for my PM2.5 pollution sensor using the ESP32-WROOM-32 module. I can flash my firmware, then "Build Filesystem Image" of my small icons, and "Upload Filesystem Image" into the board and it works well. SPIFFS successfully initializes, the icons are read and displayed correctly via my web server code.

During testing I found that the WiFi power of the WROOM-32's PCB antenna wasn't good enough for my outdoor needs, so I got some ESP32-WROOM-32U modules with the U.FL connector. I built up a new identical board with the WROOM-32U module.

The code and filesystem images flash without any problems but then I get a bootloop like this over and over:

rst:0x3 (SW_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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
ets Jun 8 2016 00:22:57

Everything I've read says the WROOM-32U module is a drop-in replacement for the WROOM-32 from a hardware and firmware standpoint so I don't understand why uploading the filesystem image into SPIFFS isn't working. I have tried multiple modules and fiddled with all of the usual suspects in platformio.ini.

Adding some debug code, the WROOM-32 identifies itself as #define EFUSE_RD_CHIP_VER_PKG_ESP32D0WDQ6 0

but the WROOM-32U identifies itself as #define EFUSE_RD_CHIP_VER_PKG_ESP32D0WDQ5 1

which is in the efuse_reg.h header file but not listed anywhere in the Espressif documentation that I can find. So that's weird!

Any nuggets of wisdom?

Thanks, Mike.

That indicates the package type the ESP32 chip is in. The silicon die is exactly the same (given the same chip revision), but one is in a 6x6mm QFN, the other is in a 5x5mm QFN package.

Just spitballing here: we sell these modules with different sizes of flash (4M-16M); perhaps your project uses >4M and you switched to a 4M module?

Thanks for the quick reply. It's good to know that the silicon die is the same.

Both modules I'm working with identify themselves containing 4MB of external flash. My firmware is around 1.1 MB and the SPIFFS image is about 100KB so I'm way under the capabilities of the module. The partition table has a single 2MB factory partition and a 512KB SPIFFS partition.

Depending on the phase of the moon, I get different error loops when I push the reset button. Just now I'm getting:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

Is there any clue from the flash read error code 1000 or what's happening on line 371 of ets_main.c?

Any known problems with PlatformIO in this situation? I'm beginning to suspect a tooling issue. I could try going back to Arduino IDE and see if I can just get it to work at all.

Perhaps I'll try to find a dev board on the market with the U.FL connector and the JTAG interface and try to replicate the issue.

Thanks!

Ah, there's actually one difference between the various ESP32-Wroom modules: the later modules have the flash GPIO pads N/C, while the earlier ones have them connected to, well, the flash (The idea was that no one used them anyway and they led to support issues, hence the removal of the connections.) If your non-U versions had that and you somehow routed or connected those NC pads to something, replacing that with an -U version that does have those pads connected leads to issues.

Thanks, I'll check on that.

EDIT: I checked and I have nothing connected to the Flash pins GPIO6-11 or the NC pin 32 in the schematic or PCB. I buzzed the pins and there does not seem to be any shorts to power, ground or other pins.

I also checked the Strapping pins and nothing is connected except for the MTDI & MTDO which are used by the JTAG system.

I'll try to find a production module to test.

Thanks for your help, if you think of anything else please let me know!