should esp-storage::FlashStorage implement embedded_storage and embedded_storage_async nor_flash traits?

[giomf]

Hey,

I just encounter a crate that I want to use. However I can not use it without an manual wrapper implementing embedded_storage_async::nor_flash traits around esp_storage::FlashStorage.

I was asking myself if its a good idea if esp_storage::FlashStorage should implement these? Maybe take it as feature or am I overseeing something which speaks against it? AFAIK all supported chips use NOR flash, right?

[bugadani]

The blocking version will be in the next release. Async flash operations are not supported because that would require all your code to be in RAM.

[igrr]

(Just in case someone opens the above programming guide link for the ESP32 and misses the fact that the content for newer chips is a bit different.)

On newer SoCs (C3/S3 and later) there is hardware support for automatic Flash program/erase suspend. If cache is disabled and CPU tries to access the cache while a flash program or erase operation is on-going, the hardware can automatically send a suspend command to the Flash chip, re-enable the cache, and perform the requested read operation only at the cost of extra latency.

Later, software needs to resume the suspended Flash operation.

This mode of operation does have limitations, but in a few cases allows for keeping most of the application code in Flash.

[igrr]

Another case when Flash operations don't need to preempt the program is when the program .text and .rodata are copied to PSRAM and executed from there.

[Dominaezzz]

Another case when Flash operations don't need to preempt the program is when the program .text and .rodata are copied to PSRAM and executed from there.

I've never understood this properly. Why is it okay to not disable the cache when using xip from psram? Psram, flash cache and flash are accessed via the same bus still.

Though as I type this I don't know why the cache needs to be disabled for flash operations.

(I have read the esp-idf doc several times over and never understood why)

[igrr]

Why is it okay to not disable the cache when using xip from psram?

It's because you know that there won't be any cache misses which will result in the cache controller fetching a piece of code or rodata from Flash. The only cache misses will be for virtual addresses which are mapped to PSRAM. It is safe to access PSRAM while Flash has a program or erase operation on-going, because PSRAM and Flash have different CS lines. The cache controller can send (via SPI0) the command to PSRAM to fetch the code without affecting the Flash.

Though as I type this I don't know why the cache needs to be disabled for flash operations.

This is beacuse of two reasons:

• SPI Flash related: once you send a program or erase command to an SPI flash, it's not allowed to send read commands until the programming or erasing operation is finished, cancelled or suspended. By disabling the cache, we guarantee that the cache controller won't send a command.
• ESP hardware related (applies to older chips, like ESP32 and ESP32-S2): there is no arbitration between SPI0 (used by the cache controller) and SPI1 (used by the software) when accessing the actual SPI bus to which the Flash is connected. In newer chips, there is a hardware arbiter, so for example a read command sent by the cache controller using SPI0 will not be disrupted by a read command sent by software using SPI1. The arbiter will wait for the first one to complete before allowing the second one to go through.

Hope that clarifies it a bit, let me know if you need further details!

[Dominaezzz]

Ohhhh I see, it's the arbitration bit I was missing. Thanks for the fantastic explanation.

One last thing, you said newer chips have a hardware arbiter and "The arbiter will wait for the first one to complete before allowing the second one to go through".
On older chips (the S2 in particular), is there some other arbiter/hardware that coordinates PSRAM and flash access?
More concretely, esp-idf supports XiP on PSRAM for the S2, if code being executed from PSRAM (via SPI0/cache controller) tries to read from flash (via SPI1), how are the operations/CS lines managed?
Does the flash operation pause PSRAM access (by de-asserting its CS pin) temporarily to complete (or vice versa)?
Or is there some hardware to wait for one operation to complete because making another?

Or is this a "The ESP32-S2 only has a single core so concurrent PSRAM/flash access isn't possible" kinda thing?

[giomf]

For anybody running into the same problem but still want to use sequential-storage. If by chance you use embassy you could use this wrapper to create an adapter from a blocking to an async storage.

If not, a simple own implementation should do it too.

Im currently testing it but so far it looks good.

[yanshay]

I've been using sequential storage for quite some time (but not under intensive load) and it works well.