Stale reads from mapped addresses after spi_flash_write() (IDFGH-275)

[snej]

Environment

• Development Kit: SparkFun ESP32 Thing
• IDF version: f198339 (branch release/3.1)
• Development Env: Make
• Operating System: MacOS
• Power Supply: USB

Problem Description

When SPI flash has been mapped into address space via spi_flash_mmap, then after calling spi_flash_write the corresponding mapped addresses sometimes read as stale (erased, 0xFF) data.

The only reliable workaround I've found is to call the following after the write:

Cache_Flush(0);
Cache_Flush(1);

Expected Behavior

Bytes read from memory correspond to the newly-written data.

Actual Behavior

About 5% of the time, the bytes read from memory are still uninitialized (0xFF). This often persists even if a delay is added in between the write and the read.

Steps to repropduce

1. Call esp_partition_mmap
2. Call esp_partition_write to write data into the mapped area of flash
3. Examine memory locations corresponding to the write, and compare against the data written

Code to reproduce this issue

void *mapped;
esp_partition_mmap(partition, 0, partition_size, SPI_FLASH_MMAP_DATA, &mapped, &handle);
...
esp_partition_erase_range(partition, 0, 4096);
esp_partition_write(partition, 0, data, dataLength);
assert(memcmp(data, mapped, dataLength) == 0);    // sometimes fails

[snej]

FYI: I previously asked about this on the ESP32.com forum.

[iMazstick]

@snej I'm not sure whether my current issue is what you described but this is the closest I have seen. I have enabled flash encryption along with NVS encryption. I can write data to my nvs partition and read it using: esp_partition_write() and esp_partition_read(), respectively. This works. The issue becomes apparent when I call:

esp_partition_read()
esp_partition_write()
esp_partition_read()

The first read returns non-human readable data, not what I am expecting (I suspect these are encrypted).

I also tried to search for the Cache_Flush() calls you mentioned. but could not find it anywhere. I am usig the latest version of the SDK v3.00 as of writing this.

Any help on this would be much appreciated.

Thanks.

[snej]

@marienifura: I found the Cache_Flush() calls in the components/spi_flash directory of the IDF sources.

[iMazstick]

@snej Thanks. I managed to find it but unfortunately it doesn't seem to have helped in my case.

[jmattsson]

@iggr / @projectgus Could we get this over to the 3.3 branch too, pretty please?

[projectgus]

@jmattsson Can do. GitHub issue will be updated when the backport commit lands.