StackChan doesn't boot after flashing with v1.3.1

[pboushy]

Describe the bug
Stackchan repeatedly restarts after applying v1.3.1 via esptool on a Mac

To reproduce
Steps to reproduce the behavior:

1. Hold reset button to put Stackchan in download mode.
2. Flash Stackchan to original firmware (v1.2.6)
3. Press reset button to reboot.
4. Wait for Stackchan to come up.
5. Clone repo
6. cd repo
7. download all 3 bin files from https://github.com/BrettKinny/dotty-stackchan/releases/tag/fw-v1.3.1 to current directory
8. Hold reset to put Stackchan in download mode.
9. Run:

   python -m esptool --chip esp32s3 -b 460800 \
     --before default_reset --after hard_reset \
     write_flash --flash_mode dio --flash_size 16MB --flash_freq 80m \
     0xd000 ota_data_initial.bin \
     0x20000 stack-chan.bin \
     0x610000 generated_assets.bin
   

10. Wait for it to complete and then press reset button to reboot.

(I also tried fully erasing the Stackchan: python -m esptool --chip esp32s3 erase_flash and then running the command in the QuickStart)

Expected behavior
Stackchan boot to new dotty interface.

Actual behavior
Stackchan never boots fully and shows this in logs when viewed via ESPHome:

Environment

• Firmware version/commit: 1.3.1
• Server image tag/digest: n/a
• Hardware: Stackchan
• Host OS: MacOS
• Bridge deployment: n/a

Logs
Stackchan firmware loading logs:

[00:49:49]ESP-ROM:esp32s3-20210327
[00:49:49]Build:Mar 27 2021
[00:49:49]rst:0x3 (RTC_SW_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[00:49:49]Saved PC:0x403cd3f1
[00:49:49]SPIWP:0xee
[00:49:49]mode:DIO, clock div:1
[00:49:49]load:0x3fce2820,len:0x1744
[00:49:49]load:0x403c8700,len:0xf40
[00:49:49]load:0x403cb700,len:0x3610
[00:49:49]entry 0x403c89c4
[00:49:49]I (24) boot: ESP-IDF v5.5.4 2nd stage bootloader
[00:49:49]I (24) boot: compile time Apr 23 2026 11:04:57
[00:49:49]I (24) boot: Multicore bootloader
[00:49:49]I (25) boot: chip revision: v0.2
[00:49:49]I (27) boot: efuse block revision: v1.3
[00:49:49]I (31) qio_mode: Enabling default flash chip QIO
[00:49:49]I (35) boot.esp32s3: Boot SPI Speed : 80MHz
[00:49:49]I (39) boot.esp32s3: SPI Mode       : QIO
[00:49:49]I (43) boot.esp32s3: SPI Flash Size : 16MB
[00:49:49]I (46) boot: Enabling RNG early entropy source...
[00:49:49]I (51) boot: Partition Table:
[00:49:49]I (54) boot: ## Label            Usage          Type ST Offset   Length
[00:49:49]I (60) boot:  0 nvs              WiFi data        01 02 00009000 00004000
[00:49:49]I (66) boot:  1 otadata          OTA data         01 00 0000d000 00002000
[00:49:49]I (73) boot:  2 phy_init         RF data          01 01 0000f000 00001000
[00:49:49]I (79) boot:  3 ota_0            OTA app          00 10 00020000 004f0000
[00:49:49]I (86) boot:  4 ota_1            OTA app          00 11 00510000 004f0000
[00:49:49]I (92) boot:  5 assets           Unknown data     01 82 00a00000 00400000
[00:49:49]I (99) boot:  6 coredump         Unknown data     01 03 00e00000 00010000
[00:49:49]I (105) boot: End of partition table
[00:49:49]I (109) boot: No factory image, trying OTA 0
[00:49:49]I (113) esp_image: segment 0: paddr=00020020 vaddr=3c3c0020 size=11f78ch (1177484) map
[00:49:49]I (284) esp_image: segment 1: paddr=0013f7b4 vaddr=3fca6a00 size=00864h (  2148) load
[00:49:49]I (285) esp_image: segment 2: paddr=00140020 vaddr=42000020 size=3b4f4ch (3886924) map
[00:49:50]I (828) esp_image: segment 3: paddr=004f4f74 vaddr=3fca7264 size=08430h ( 33840) load
[00:49:50]I (834) esp_image: segment 4: paddr=004fd3ac vaddr=40378000 size=1e9b4h (125364) load
[00:49:50]I (855) esp_image: segment 5: paddr=0051bd68 vaddr=50000000 size=00020h (    32) load
[00:49:50]E (856) esp_image: Image length 5225904 doesn't fit in partition length 5177344
[00:49:50]E (859) boot: OTA app partition slot 0 is not bootable
[00:49:50]E (864) esp_image: image at 0x510000 has invalid magic byte (nothing flashed here?)
[00:49:50]E (871) boot: OTA app partition slot 1 is not bootable
[00:49:50]E (876) boot: No bootable app partitions in the partition table

[Gr8fuldamned]

Adding to this thread with additional findings:

**Problem 1 — confirmed: partition size mismatch**

`stack-chan.bin` is 5,225,904 bytes but `ota_0` in the factory partition table is only 5,177,344 bytes (`0x4f0000`). The fix is to flash a custom partition table with `ota_0` at `0x500000`. The correct `generated_assets.bin` address is also `0xa20000`, not `0x610000` as the quickstart states (verified by reading the factory partition table with `esptool read-flash 0x8000 4096`).

**Problem 2 — new: NVS crash after partition fix**

After fixing the partition table, the firmware loads but crashes at:

[HAL] xiaozhi board init
ESP_ERROR_CHECK failed: esp_err_t 0x1107 (ESP_ERR_NVS_INVALID_HANDLE)
file: "./xiaozhi-esp32/main/settings.cc" line 42
func: void Settings::SetString(const std::string&, const std::string&)
expression: nvs_set_str(nvs_handle_, key.c_str(), value.c_str())

This happens regardless of NVS state — tried with factory NVS intact and with NVS erased via `erase-region 0x9000 0x4000`. The handle is invalid before `SetString` is called, meaning `nvs_open()` is failing, likely because `nvs_flash_init()` hasn't been called yet when the CoreS3 board init runs.

**Working flash command (gets past problem 1, hits problem 2):**

Generate the corrected partition table first:

```python
import struct, hashlib
entries_data = b''
entries = [
    ('nvs',      0x01, 0x02, 0x9000,   0x4000),
    ('otadata',  0x01, 0x00, 0xd000,   0x2000),
    ('phy_init', 0x01, 0x01, 0xf000,   0x1000),
    ('ota_0',    0x00, 0x10, 0x20000,  0x500000),
    ('ota_1',    0x00, 0x11, 0x520000, 0x500000),
    ('assets',   0x01, 0x82, 0xa20000, 0x400000),
    ('coredump', 0x01, 0x03, 0xe20000, 0x10000),
]
for name, etype, subtype, offset, size in entries:
    label = name.encode().ljust(16, b'\x00')
    entry = struct.pack('<2sBBII', b'\xaa\x50', etype, subtype, offset, size) + label + b'\xff\xff\xff\xff'
    entries_data += entry
md5 = hashlib.md5(entries_data).digest()
md5_entry = b'\xeb\xeb' + b'\xff' * 14 + md5
data = entries_data + md5_entry + b'\xff' * (0xc00 - len(entries_data) - len(md5_entry))
open('partitions.bin', 'wb').write(data)

Then flash:

esptool --chip esp32s3 --baud 460800 write-flash --flash-mode dio --flash-size 16MB --flash-freq 80m 0x8000 partitions.bin 0xd000 ota_data_initial.bin 0x20000 stack-chan.bin 0xa20000 generated_assets.bin

Hardware: M5Stack CoreS3 chip revision v0.2, efuse block revision v1.3. The NVS crash appears to be an initialization ordering bug — the CoreS3 board init in hal.cpp reaches Settings::SetString before nvs_flash_init() has been called.