Open jacobbenlewis opened 4 years ago
Hi there,
Regarding the erroneous behaviour, from what I've seen in the issue tracker and experienced myself, behaviour like this can often be a result of an issue in the implementation of the hardware abstraction layer, i.e. the implementation of the flash read/write/erase functions. It might be worth double-checking those and also double-checking the preconditions specified here are satisfied as a first port of call.
I have written a set of tests for the platform I'm using which helped me to reveal a number of issues in my implementation. I have not tried running the official SPIFFS test suite on the platform I'm using but that could possibly be a better option.
This sounds like some similar posts but I haven't gotten a clear direction on how to solve the problem so I'll post.
I have an 8MB Winbond Spi flash part, split into 2 Spiffs volumes, one about 6MB and the other 2MB. Onto the 6MB volume I copy (4) roughly 550KB files. The copy operation takes about 25 seconds per file over FTP. Then I delete those files and copy one of them back and it takes 35 seconds. Then when I try to copy a second one back on I get "Volume Full" errors.
I've tried messing with these settings with no real improvement and more often other types of errors, but am open to suggestions.
I've also tried manually calling garbage collection, and increasing SPIFFS_GC_MAX_RUNS from 5 to 15 with still not much improvement.
Any suggestions on how to improve this situation?
I'm considering going to LittleFs, but not sure how much better it'll be. Anybody have similar experience there?
Also open to suggestions on other types of non volatile memory that will work better? I've looked into FRAM and MRAM but neither have parts above 1MB.
Thanks