ESP32-S3-Mini-1 custom hardware- failure to boot/ invalid header message

[AL_IgorO]

We have a custom design using ESP32-S3-Mini-1 that we flash using ESP IDF tools via ESP Prog/UART

Flashing goes through just fine but on boot all we get after reset is "Invalid Header" scrolling through on UART.
The same programming script and binaries, when flashed to an ESP32-S3-DEVKITM boots and runs fine.
If we look at UART stream of a blank board we get "Invalid header" messages right out of the box.
Trying to figure out what's different between the two or what are we missing.
All strapping pins are brought to test points and are floating/using default IPD/IPU

Dev kit has ESP32-S3-Mini-1 datecode P1N8
Custom HW has ESP32-S3-Mini-1 datecode M0N8

Flashing script, efuses readout of dev board and our board and UART output attached below
Failure to boot:
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
invalid header: 0xacd54a85
invalid header: 0xacd54a85
invalid header: 0xacd54a85
invalid header: 0xacd54a85

Same firmware on ESP32-S3-DEVKITM
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x2b (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0270,len:0x2608
load:0x403b6000,len:0xb1c
load:0x403ba000,len:0x4258
entry 0x403b622c
I (35) boot: ESP-IDF v4.4-dirty 2nd stage bootloader
I (35) boot: compile time 14:21:10
I (35) boot: chip revision: 0
I (37) boot.esp32s3: Boot SPI Speed : 80MHz
I (42) boot.esp32s3: SPI Mode : DIO
I (46) boot.esp32s3: SPI Flash Size : 8MB
I (51) boot: Enabling RNG early entropy source...
I (56) boot: Partition Table:
I (60) boot: ## Label Usage Type ST Offset Length
I (67) boot: 0 nvs WiFi data 01 02 00009000 00008000
I (75) boot: 1 otadata OTA data 01 00 00011000 00002000
I (82) boot: 2 phy_init RF data 01 01 00013000 00001000
I (90) boot: 3 nvs_key NVS keys 01 04 00014000 00001000
I (97) boot: 4 storage WiFi data 01 02 00015000 00004000
I (105) boot: 5 ota_0 OTA app 00 10 00020000 00300000
I (112) boot: 6 ota_1 OTA app 00 11 00320000 00300000
I (120) boot: 7 filesys Unknown data 01 81 00620000 00100000
I (127) boot: End of partition table
I (131) boot: No factory image, trying OTA 0
I (136) esp_image: segment 0: paddr=00020020 vaddr=3c120020 size=4d424h (316452) map
I (208) esp_image: segment 1: paddr=0006d44c vaddr=3fc98620 size=02bcch ( 11212) load
I (211) esp_image: segment 2: paddr=00070020 vaddr=42000020 size=11900ch (1150988) map
I (443) esp_image: segment 3: paddr=00189034 vaddr=3fc9b1ec size=032a4h ( 12964) load
I (446) esp_image: segment 4: paddr=0018c2e0 vaddr=40374000 size=14620h ( 83488) load
I (469) esp_image: segment 5: paddr=001a0908 vaddr=50000000 size=00044h ( 68) load
I (469) esp_image: segment 6: paddr=001a0954 vaddr=600fe000 size=002b4h ( 692) load
I (483) boot: Loaded app from partition at offset 0x20000
I (517) boot: Set actual ota_seq=1 in otadata[0]
I (517) boot: Checking flash encryption...
I (518) flash_encrypt: flash encryption is enabled (1 plaintext flashes left)
I (524) boot: Disabling RNG early entropy source...
I (541) cpu_start: Pro cpu up.

[ESP_Sprite]

There's Mini-1 variants with and without PSRAM. Any chance that is the difference? If so, do you have IO26 connected to anything?

[AL_IgorO]

Interesting, we have nothing connected to pin26/GPIO26. For now we got it working by removing encryption, but still not clear why the same scripts worked on dev board. Would the presence/absence of PSRAM do that? The exact module PN on our board is ESP32-S3-MINI-1-N8, but I have no way of knowing what's on Dev board.
Can you tell from this picture or is there another way?

[ESP_Sprite]

From what I can decypher, both are PSRAM-less modules according to the packaging information sheet we have (see the xxN8 on the bottom of the module; that would be xxN8Rx for a psram-containing module). The other difference is that the one on the black board is a preproduction model (P1) while the other is a mass-production unit, but I don't know if there are actual physical differences between those.

[chegewara]

I would suggest to decode boot in this log:

Code: Select all

rst:0x1 (POWERON),boot:0x8

Vs

Code: Select all

rst:0x1 (POWERON),boot:0x2b 

Usually it's strapping pin.

[TomAatjes]

Sorry for the kick of this topic but did you ever get this sorted?

I have exactly the same issue. I have a custom board that I have in production with security on in release mode. However, I wanted to test some new things and tried to flash a board in development mode with a fresh install of ESP-IDF, VSCode and PlatformIO. But everything I try, it always results in "Invalid Header". Going back to no encryption and the code runs just fine!

As a test I did the following:
1) I loaded a new example project called “espidf-hello-world”
2) Changed the board to board = esp32-s3-devkitc-1
3) Flashed the board…
Succes! Board boots up fine.

4) I go to menuconfig in platformio
5) I check security features → Enable flash encryption on boot (READ DOCS FIRST) → Development
6) UART ROM download mode (UART ROM download mode (Enabled (not recommended)))

I flash the board again…

“invalid header: 0x115542bf”

There’s not much I could do wrong there?

[TomAatjes]

To answer myself:

It turns out that later releases of PlatformIO have broken compatibility with makeconfig and the right fuses are not set.
I am now porting everything to ESP IDF to get rid of having to use platformIO.