Writing to flash freezes the whole system on ESP32-S3

[florianL21]

Bug description

When trying to write to flash through esp_storage on the ESP32S3 while both cores are active, the whole system freezes.

This is 100% reproducible with the provided example.

It seems to be some combination of having the WIFI stack and the second core running when trying to write to the flash. It seems to be a bit timing sensitive but with the provided example it usually happens within a maximum of 3 erase calls.

When commenting out lines 66 to 68 in main.rs makes all calls to erase succeed and system will never freeze.

To Reproduce

1. git clone https://github.com/florianL21/esp_storage-bug.git
2. Run cargo run --release
3. Observe the logs, you can see that system will freeze up at latest after a few writes to flash.

This is my log for reference:

     Running `espflash flash --monitor --chip esp32s3 --flash-size=32mb --flash-freq 80mhz --flash-mode qio --partition-table=partition_table.csv target/xtensa-esp32s3-none-elf/release/test-setup`
[2025-09-02T20:31:47Z INFO ] 🚀 A new version of espflash is available: v4.0.1
[2025-09-02T20:31:47Z INFO ] Serial port: '/dev/ttyACM0'
[2025-09-02T20:31:47Z INFO ] Connecting...
[2025-09-02T20:31:48Z INFO ] Using flash stub
Chip type:         esp32s3 (revision v0.1)
Crystal frequency: 40 MHz
Flash size:        32MB
Features:          WiFi, BLE
MAC address:       ********
Partition table:   partition_table.csv
App/part. size:    439,024/2,097,152 bytes, 20.93%
[2025-09-02T20:31:48Z INFO ] Segment at address '0x0' has not changed, skipping write
[2025-09-02T20:31:48Z INFO ] Segment at address '0x8000' has not changed, skipping write
[00:00:03] [========================================]     280/280     0x10000                                                                                                                                                                                                                                                                                                                [2025-09-02T20:31:52Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40379f6d
0x40379f6d - <u32 as core::ops::bit::BitAndAssign>::bitand_assign
    at ******/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/ops/bit.rs:719
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:1
load:0x3fce3818,len:0x16f8
load:0x403c9700,len:0x4
load:0x403c9704,len:0xc00
load:0x403cc700,len:0x2eb0
entry 0x403c9908
I (33) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (33) boot: compile time Jun  7 2023 08:07:32
I (34) boot: Multicore bootloader
I (38) boot: chip revision: v0.1
I (42) boot.esp32s3: Boot SPI Speed : 80MHz
I (47) boot.esp32s3: SPI Mode       : SLOW READ
I (52) boot.esp32s3: SPI Flash Size : 32MB
I (57) boot: Enabling RNG early entropy source...
I (63) boot: Partition Table:
I (66) boot: ## Label            Usage          Type ST Offset   Length
I (73) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (81) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (88) boot:  2 factory          factory app      00 00 00010000 00200000
I (96) boot:  3 otadata          OTA data         01 00 00210000 00002000
I (103) boot:  4 app0             OTA app          00 10 00220000 00300000
I (111) boot:  5 app1             OTA app          00 11 00520000 00300000
I (118) boot:  6 storage          Unknown data     01 83 00820000 00a00000
I (126) boot: End of partition table
I (130) boot: Defaulting to factory image
I (135) esp_image: segment 0: paddr=00010020 vaddr=3c000020 size=128c8h ( 75976) map
I (161) esp_image: segment 1: paddr=000228f0 vaddr=3fc917a0 size=0216ch (  8556) load
I (164) esp_image: segment 2: paddr=00024a64 vaddr=40378000 size=097a0h ( 38816) load
I (178) esp_image: segment 3: paddr=0002e20c vaddr=00000000 size=01e0ch (  7692) 
I (180) esp_image: segment 4: paddr=00030020 vaddr=42020020 size=4b2ach (307884) map
I (261) boot: Loaded app from partition at offset 0x10000
I (261) boot: Disabling RNG early entropy source...
INFO - vendor id    : 0d (AP)
INFO - dev id       : 02 (generation 3)
INFO - density      : 03 (64 Mbit)
INFO - good-die     : 01 (Pass)
INFO - Latency      : 01 (Fixed)
INFO - VCC          : 00 (1.8V)
INFO - SRF          : 01 (Fast Refresh)
INFO - BurstType    : 01 (Hybrid Wrap)
INFO - BurstLen     : 01 (32 Byte)
INFO - Readlatency  : 02 (10 cycles@Fixed)
INFO - DriveStrength: 00 (1/1)
INFO - 8388608 bytes of PSRAM
INFO - Embassy initialized!
INFO - Core 1 spawning tasksINFO
 - esp-wifi configuration EspWifiConfig { rx_queue_size: 5, tx_queue_size: 3, static_rx_buf_num: 10, dynamic_rx_buf_num: 32, static_tx_buf_num: 0, dynamic_tx_buf_num: 32, ampdu_rx_enable: true, ampdu_tx_enable: true, amsdu_tx_enable: false, rx_ba_win: 6, max_burst_size: 1, country_code: "CN", country_code_operating_class: 0, mtu: 1492, tick_rate_hz: 100, listen_interval: 3, beacon_timeout: 6, ap_beacon_timeout: 300, failure_retry_cnt: 1, scan_method: 0 }
INFO - IPv4: DOWN
WARN - esp_wifi_internal_tx 12290
INFO - System is still running
INFO - System is still running
INFO - System is still running
INFO - System is still running
WARN - !Going to write to flash. This may freeze the system!

Expected behavior

System does not freeze.
Maybe the erase returns with an error if something went wrong.

Environment

• Target device: ESP32-S3-WROOM-2-N32R16V
• esp-hal 1.0.0-rc.0
• esp-storage 0.7.0
• esp-hal-embassy 0.9.0
• embassy-executor 0.7.0

[Dominaezzz]

You're not allowed to write to flash whilst the other core is executing from it. You have to suspend the other core first

[florianL21]

Is this documented somewhere and I missed it?
I also have an example where I park the second core before writing to flash and indeed it does not crash most of the time.
But I cannot seem to make it work reliably, possibly because I have no way of knowing if the second core is already suspended or not.

[florianL21]

Also, if this is the case why does it not freeze if I get rid of the WIFI stack on the first core?
Theoretically this hasn't changed that the second core is executing from flash while the first one is writing, right?

[bjoernQ]

Is this documented somewhere and I missed it?

Seems it's not yet and it should get added to the docs.

Also, if this is the case why does it not freeze if I get rid of the WIFI stack on the first core? Theoretically this hasn't changed that the second core is executing from flash while the first one is writing, right?

It's a bit more complex - in that example the 2nd core doesn't do too much and without the first core doing much, too (i.e. not running wifi) there is a chance that a lot of the code runs from cache and things might work - maybe not reliable but you can be lucky.

Adding wifi to the picture changes that (like doing anything more complex on one of the cores)

[florianL21]

I see. That seems logical.

But this raises another question for me:

If I am supposed to park the second core how can I know that it actually stopped running?
In my project where I ran into this issue I am calling the park_core function to park the second core but it seems that the core may still keep running for a bit longer after that function returns.
I didn't find any interface in the system module that I can seemingly use to check if core 1 is running or parked.
So does this mean that I am supposed to implement some detection mechanism myself? This can ofc be done but it seems suboptimal to me.

In general I am a bit surprised to see such behavior as neither of the two APIs I am using (start_app_core or any of the esp_storage APIs) are unsafe, yet I can still cause the whole system to go into a seemingly undefined state.

[bugadani]

Ideally we should solve this inside esp-storage. Unfortunately, that is hard to do generally - code doesn't HAVE to be running from flash, and in that case the core doesn't have to be parked... We can likely add a marker type that you, the user would have to select - UnsafeNoPark, ParkOtherCore, or mabye some other strategy if we can come up with them.

That parking the core returns before the core actually stops running (if this really is the case), should be considered a bug.

[florianL21]

Just to be very clear, the park_core call returning before the core is actually parked was just an assumption of mine. I could not find any statements in the documentation that detail whether this function is blocking or not.
I assumed that it returns sooner as simply doing:

park_core()
flash.write()
unpark_core()

Still freezes the system in some cases

[Dominaezzz]

In general I am a bit surprised to see such behavior as neither of the two APIs I am using (start_app_core or any of the esp_storage APIs) are unsafe, yet I can still cause the whole system to go into a seemingly undefined state.

Strictly speaking, unsafe has to do with rust rules being broken, not necessarily the hardware or environment rules.

In safe rust, you can still have deadlocks, memory leaks (my favourite) and race conditions.

Still freezes the system in some cases

Out of curiosity does it still freeze if you add a sleep after parking?

[florianL21]

Strictly speaking, unsafe has to do with rust rules being broken, not necessarily the hardware or environment rules.

Yes you are right ofc. But in other parts of the HAL these mechanics are used more by convention to signal to the user to be careful with using these APIs.
At least this is how I interpreted the park_core function being unsafe.

Out of curiosity does it still freeze if you add a sleep after parking?

Yes it does, but only about 20% of cases. I currently have a delay of 50ms after calling park_core. I figured that this should be plenty.

Maybe I can try to modify my example code to provoke this behaviour. I will give an update here once I have something.

[bjoernQ]

I tried to reproduce the part about park_core not parking the core immediately and cannot reproduce that.

I can easily get to the point where not calling it will freeze everything but calling it immediately before calling erase (like in your example) it works 100% of the time for me - curious about a reproducer showing that behavior