v1.17.0 crash-loop on boot (MultiBoard S3) — v1.16.0/v1.15.1 boot fine on same hardware

Describe the bug After updating from v1.15.1 to v1.17.0, the device crash-loops immediately on every boot — it never reaches the Marauder splash screen. The exact same flashing process, same tool, same hardware, with v1.16.0 or v1.15.1 instead of v1.17.0, boots and runs cleanly.

To Reproduce Steps to reproduce the behavior:

1. Starting firmware: v1.15.1, working normally.
2. Flashed with esptool v5.4.0, --erase-all, all four files written and hash-verified successfully by esptool (so this isn't a bad/corrupted flash):
   • esp32_marauder.ino.bootloader.bin @ 0x0 (pinned to the v1.17.0 tag, FlashFiles/FlipperZeroMultiBoardS3/)
   • esp32_marauder.ino.partitions.bin @ 0x8000 (same source)
   • boot_app0.bin @ 0xE000 (same source)
   • esp32_marauder_v1_17_0_20260916_multiboardS3.bin @ 0x10000 (from the v1.17.0 release assets)
3. Chip resets and immediately crash-loops (see log below) — never reaches the splash/menu.

Isolation Repeated the identical process (same tool, same offsets, same hardware) with v1.16.0 and separately with v1.15.1 — both booted cleanly, info command responded normally, settings dumped correctly, no crash. Only v1.17.0 exhibits this.

Expected behavior Device boots normally into Marauder, as it does on v1.16.0 and v1.15.1.

Environment

• Hardware: Flipper Zero MultiBoard S3
• Chip: ESP32-S3 (QFN56), revision v0.2
• Flash: 16MB (manufacturer 68, device 4018, quad I/O, 3.3V)
• esptool: v5.4.0
• Flashing method: esptool CLI, write_flash -z --erase-all --flash_mode keep --flash_freq keep --flash_size keep

Crash log Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled. Guru Meditation Error: Core 0 panic'ed (Unhandled debug exception). Debug exception reason: Stack canary watchpoint triggered (IDLE) Core 0 register dump: PC : 0x40056f60 PS : 0x00060036 A0 : 0x82051e5e A1 : 0x3fcf6af0 A2 : 0x3fcf6b00 A3 : 0x3c10bc98 A4 : 0x00000060 A5 : 0x3fcf6b00 A6 : 0x3c10bbbf A7 : 0x3c10bbc8 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x60000000 A11 : 0x00000001 A12 : 0x420513ea A13 : 0x3fcf6ca0 A14 : 0x00000000 A15 : 0x3fc9b658 SAR : 0x0000000a EXCCAUSE: 0x00000001 EXCVADDR: 0x00000000 LBEG : 0x40056f5c LEND : 0x40056f72 LCOUNT : 0x00000005 Backtrace: 0x40056f5d:0x3fcf6af0 |<-CORRUPTED ELF file SHA256: 3dba28c0206ddb52 E (380) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0 Rebooting...

This exact crash (same PC, same backtrace, same ELF SHA256) repeats on every single boot attempt — fully deterministic, not intermittent. EXCCAUSE alternates between IllegalInstruction and LoadProhibited across different boot attempts, but the PC/backtrace/ELF hash stay identical.

Additional context Also noticed esp_core_dump_flash: No core dump partition found! — the crash happens too early for the core dump partition (if configured) to help capture more detail; may be worth adding one to the MultiBoard S3 partition table for future debugging of early-boot crashes like this.