Cache disabled but cached memory region accessed error when writing to flash

[maxsydney]

I am intermittently encountering this error when writing data to flash. I have done a bit of poking around in the config to see which settings will influence whether this error occurs, but so far I am unable to stop this from happening unless I remove the ESP_INTR_FLAG_IRAM flag from rmt_driver_install.

Steps required to produce error

• Active communication over owb rmt (DS18B20 in this case)
• Mounts SPIFFS file system (using esp_vfs_spiffs_register)
• Write data to filesystem

This error will occur perhaps 1/10 writes. Presumably this is related to whether an RMT interrupt is firing when the flash is accessed. I have not been able to produce this error when reading from flash, but reads are happening less frequently in my application.

Any ideas on what might be causing this?

[DavidAntliff]

Hi, I'm sorry I don't know enough about how the interrupts and FLASH system works on the ESP32 to give you much advice.

I have a couple of other projects that use the RMT, such as the Frequency Counter, so perhaps you could try using that with your FLASH writer and see if you have the same problem?

If so, then I'd suggest contacting Espressif directly, either through their GitHub Issues or via their forum.

[maxsydney]

Hi David.

I have looked into this a bit further and cannot find a good explanation for this behaviour. It looks like you are using the default rmt callback function, which is placed into IRAM (so not sure why we are getting an error here).

Is it possible that the ESP_INTR_FLAG_IRAM could be removed for this driver? Here is the description of this flag.

///< ISR can be called if cache is disabled

I think this is probably useful if an interrupt MUST be handled within a period of time. I don't think this is the case here?

[DavidAntliff]

Hi Max,

I don't know what the implications might be for removing that flag - best to ask the Espressif team directly. I've had good experiences with contacting them through their forum, they do tend to reply in most cases.

If you do ask on the forum, please post or send me a link to the discussion and I'll keep an eye on it also.

[maxsydney]

Thanks David. You can find the question posted on the forum here https://esp32.com/viewtopic.php?f=2&t=26144

[alemariusnexus]

Just wanted to say that I'm experiencing the same error. For me, it only seems to happen when compiling with size optimizations (-Os), not with -O2.

I've posted a reply with more info and some stab-in-the-dark findings in the forum thread. It's currently waiting for moderator approval.

[kriegste]

Any news? I came across the exact same problem. Here it happens when updating the firmware OTA, during the flash being written. Which is exceptionally bad when trying to fix a faulty firmware. It indeed only crashes with -Os and not with -Og. That is not helpful in the bug fixing process either.

[DavidAntliff]

Any news?

Nothing that I'm aware of - best bet is probably to try and get one of the Espressif devs into the linked discussion at esp32.com above, see what they think.

If there's any indication that my code is doing something incorrectly and causing this fault then I'm more than happy to fix it, I just don't know what that might be, yet.

[kriegste]

I'm going to force-inline those functions mentioned (called in the isr) and see and report what happens.

Edit:
The problem is in these files: components/hal/esp32*/include/hal/rmt_ll.h (one per chip type). I gave every function an __attribute__((always_inline)). No crashes so far, but I've only reflashed just a couple of times since then. Time will tell.

[kriegste]

The issue is about to be fixed officially
espressif/esp-idf#9487