Does one have to disable interrupts before using FlashStorage::write?
#26
Comments
|
I'd expect the ROM functions to disable interrupts on their own - plus by default we call them in a critical-section 🤔 Is there anything special in your code which causes this problem? I could try to reproduce it on my own but maybe it's easier if you can share the exact steps |
|
I'm a little limited on time right now to provide a full reproduction.
second core:
|
|
Ah ... I can imagine interrupts triggered on the other core to cause problems while one core is accessing the (detached) flash. |
|
Now after further thinking: We need to completely halt the other core during flash access |
|
A bit of further reading here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_flash/spi_flash_concurrency.html and https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_flash/index.html#implementation-details. Interrupts can fire but all code must be in IRAM already. And like @bjoernQ already said, both cores must be stalled/spinning until the flash operation is complete. I think the best bet, for now, is to disable interrupts and make the core we want to run the flash operation on spin until the other core has acquired some mutex or something to signal that it will wait until we're done with flash. All of this is actually quite involved, and will mostly likely need some help from esp-hal? |
|
This also probably has implications for esp-wifi and its scheduler too, we don't want to starve that completely, fun problem to solve I guess :D. |
|
Slightly off-topic but how does one put code in IRAM in Rust? |
|
With great difficulty, there is no way (in GCC or Rust) to recursively apply a linker_section attribute. This means whilst a top level function may be put inside an IRAM section, it doesn't mean function calls inside the function will be either. You have to check yourself that all code ends up in IRAM. In esp-idf there is a fuzzy checker which tries to warn you if you call code which isn't in IRAM from an IRAM placed function. |
|
I think I remember I have seen code in esp-idf where they just paused and unpaused the other core. But maybe I'm wrong .... Need to check that. Even if it runs non interrupt code it might cross a cache page. It's certainly very bad if whatever the other core runs is very time critical. In that case everything on the other core should be in RAM. So probably pausing the other core should be an optional default You could also try to manually pause the other core in the meantime and see if that helps. Regarding recursively checking the call tree for non-IRAM functions we could try what cargo-call-stack does (I think compiling to WASM and parse that ... not sure I remember it correctly but definitely not fun). |
I'm seeing this backtrace on a ESP32S3 when ISRs are being ran on the same core:
Backtrace
The text was updated successfully, but these errors were encountered: