ESP32 Forum

I'm calling esp_partition_mmap() to memory-map a flash partition, and then esp_partition_erase_range() and esp_partition_write() to write to it. Most of the time (95%?) this works fine, but intermittently I see errors where, after a write, part of the mapped memory is still filled with FF instead of the data I wrote.

I thought this might be a race condition with the flash controller (maybe the write takes longer than it indicates and sometimes it hasn't finished by the time the read occurs) so I added a 100ms delay after the write; that seems to help somewhat, but it's not a complete fix.

My only other hypothesis is that this is due to CPU cache coherency, but the spi_flash code looks like it's careful to disable/enable caches. I'm not familiar with the ESP32's cache system, but I assume it's doing the equivalent of a memory-barrier.

Any ideas?

Here's some rough code showing the kind of thing I do:

It might be due to stale cache after erase if the cache is not automatically flushed.

Yeah, that's what I'm thinking too; as I wrote above:

My only other hypothesis is that this is due to CPU cache coherency, but the spi_flash code looks like it's careful to disable/enable caches.

However I have no idea what additional cache might be at fault, nor how to flush it.

Well spi_flash_write and spi_flash_erase will call spi_flash_mark_modified_region but it does not actually flush the cache until spi_flash_ensure_unmodified_region is called. So I don't know if there is a rule that you are supposed to unmap and remap memory if you are going to write/erase it.

Looking through the spi_flash sources I found calls to a Cache_Flush() function; this looked promising, so I added to my code just after calling esp_partition_write(). That appears to have fixed the problem.

I believe those should only be called inside flash guarded section.

FYI, I've filed an IDF issue on Github.