Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Garbage collection issues #273

Open
jacobbenlewis opened this issue Oct 21, 2020 · 1 comment
Open

Garbage collection issues #273

jacobbenlewis opened this issue Oct 21, 2020 · 1 comment

Comments

@jacobbenlewis
Copy link

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.

    SpiFFS.SPIFFS_SINGLETON                 = false;
    SpiFFS.SPIFFS_CFG_PHYS_SZ             = 65536*88;
    SpiFFS.SPIFFS_CFG_PHYS_ERASE_SZ = 256*16;
    SpiFFS.SPIFFS_CFG_PHYS_ADDR       = 0;
    SpiFFS.SPIFFS_CFG_LOG_PAGE_SZ     = 256;
    SpiFFS.SPIFFS_CFG_LOG_BLOCK_SZ  = 256*16;

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

@samcaulfield-ubotica
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants