-
Notifications
You must be signed in to change notification settings - Fork 13.3k
SPIFFS fails to work #4111
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
Comments
Further analysis shows that the core runtime may be corrupting the FS. If I upload the FS bin and then immediately (not allowing the sketch to run) download the SPIFFS using read_flash I can see that the FS is fine. What is uploaded looks like what was downloaded. If I then let the sketch run and again download the FS I can see that it is completely different. All the files are gone. |
@weswitt this is starting to sound like a format() gone wrong |
@devyte that's what I thought too, but I rebuilt everything with SPIFFS_READ_ONLY enabled so that format can never happen. If I run a simple sketch that never calls SPIFFS.begin then the flash area for the SPIFFS remains as it was when uploaded. If the sketch just calls SPIFFS.begin then the SPIFFS region gets hosed. I also added some debug prints in spiffs_api to notify when format happens and those never appear so it doesn't seem like a format issue. Debug Output: |
After enabling more diagnostics in SPIFFS is see the output below. What is happening is that spiffs_obj_lu_scan is returning SPIFFS_ERR_NOT_A_FS when called from SPIFFS_mount. Looks like SPIFFS does not like the data that is laid down in the flash region. I suppose this point to the tool creating the SPIFFS image. And the reason that I was seeing a changed FS is because the mount path will format the FS when the mount fails. In my view this is really bad API semantics. The mount API should simply return an error code and allow the caller to deal with it. Performing a destructive operation like this is really bad. I cannot think of ANY operating system that does this or has done this. Linux, NO. Windows, NO. MacOS, NO. SPIFFSImpl: allocating 512+240+1400=2152 bytes |
OK, I rebuilt SPIFFS with SPIFFS_USE_MAGIC set to zero to disable the FS integrity checks. Sure enough the FS now mounts. It seems that MKSPIFFS and the Arduino IDE both are creating filesystems with too many unerased blocks -- in my case there are 16 of them. Anyone have any insight on this? Debug Output from Mount:
|
@weswitt you have mentioned "current releases of everything". Just to clarify, does that mean that you are installing version 2.4.0 using boards manager? Or using git version of the core and installing tools (including mkspiffs) using get.py? I'm asking because this issue looks like a mismatch between SPIFFS configuration in mkspiffs and in the sketch. This could be due to incompatible versions of the core and mkspiffs. However I have just tested FSBrowser example with the latest git version (which includes Edit: i have edited your posts to compress long sections of build/debug output using details/summary tags to make the topic easier to read. Hope you don't mind. |
I've built MKSPIFFS using the master repo so it is as current as possible. And I'm using 2.4.0 release of core, not the git master branch version. |
MKSPIFFS and Arduino cores both use 0.3.7 of SPIFFS so there should not be any mismatch. |
2.4.0 is likely not compatible with latest mkspiffs, it uses mkspiffs-0.2.0-no_magic_length release. Could you please try building the filesystem using mkspiffs version which is installed together with the core? If building mkspiffs manually, make sure you set build flags to match SPIFFS config in esp8266 core:
|
Regarding mismatch: indeed, SPIFFS versions are likely the same. However SPIFFS configuration in spiffs_config.h has recently been changed on mkspiffs side. At the moment it does not match spiffs_config.h in ESP8266 arduino core. Therefore the build script used to produce releases for ESP8266 modifies some of the flags from their default values (as shown in my above comment). |
Would this have any bearing on an issue I am having trying to use the eeprom.read/write api? I used the CheckFlashConfig sample and added a print for all the spiffs.info data and it is returning an error and bad data for the totalBytes and usedBytes which is throwing off other functions: SPIFFS_info: rc=-10024, err=-10024 Flash ide size: 16777216 snippet: |
never mind, wasn't calling SPIFFS.begin. Flash ide size: 16777216 |
I resolved this. I built MKSPIFFS with SPIFFS_USE_MAGIC_LENGTH=0 and SPIFFS_ALIGNED_OBJECT_INDEX_TABLES=1 and it now works. |
Arduino IDE > Tools > Board Selected as ESP8266 (your version) > SPIFFS (4M 1M SPIFF) atleast |
Using the current releases of everything I cannot get a simple sketch that reads from SPIFFS to work.
Using the IDE I simply compile & upload the sketch and then using the IDE I upload the SPIFFS image. When the sketch runs it finds NO file in the file system. This seems very straight forward but I cannot make this work. I have verified that a sketch can successfully write and read to the fs so it seems that the SPIFFS upload is broken or for some reason the core implementation cannot read from an uploaded SPIFFS. Any help would be appreciated.
Sketch:
Arduino build log:
The text was updated successfully, but these errors were encountered: