It may actually not be a corruption of the filesystem but some timing issue on the mount procedure. To test that we could disable the auto formatting on mount failures.
True. A couple of Espressif guys have jumped on the issue, and I have provided some more information for them. I think key will be reproducing it.
The issue may also be dependant on the hardware version, i.e. it could be caused by the bug that caused the SD speed issue on the first 3.1 batch.
That was definitely a hardware issue with the CP2102 chip. I don’t think related to ESP in any way. Regards, Mark.
On 23 Nov 2018, at 10:34 PM, Michael Balzer <dexter@expeedo.de> wrote:
It may actually not be a corruption of the filesystem but some timing issue on the mount procedure. To test that we could disable the auto formatting on mount failures.
The issue may also be dependant on the hardware version, i.e. it could be caused by the bug that caused the SD speed issue on the first 3.1 batch.
I only have tried the idf update on my batch 1 module (my bench / development module). I think most of our edge testers also have that version.
Regards, Michael
Am 23.11.18 um 02:32 schrieb Mark Webb-Johnson:
I have raised the following github issue to Espressif:
https://github.com/espressif/esp-idf/issues/2730 <https://github.com/espressif/esp-idf/issues/2730>
Environment
Development Kit: none Kit version (for WroverKit/PicoKit/DevKitC): none Module or chip used: ESP32-WROVER 16MB IDF version (run git describe --tags to find it): v3.2-beta1-208-g0d7f2d77c Build System: make Compiler version (run xtensa-esp32-elf-gcc --version to find it): (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0 Operating System: macOS Power Supply: USB Problem Description
TLDR: Between May and July 2018 a change was made to esp idf master that is causing corruption on FAT filesystems mounted on SPI flash.
Our project uses a partitions.csv as follows:
# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M The 'store' partition is formatted as FAT, as follows:
esp_vfs_fat_mount_config_t m_store_fat; wl_handle_t m_store_wlh; memset(&m_store_fat,0,sizeof(esp_vfs_fat_sdmmc_mount_config_t)); m_store_fat.format_if_mount_failed = true; m_store_fat.max_files = 5; esp_vfs_fat_spiflash_mount("/store", "store", &m_store_fat, &m_store_wlh); We have previously used a clone of esp idf master, dated around May 22 2018, without issues. The partition is very reliable.
However, on Jul 6 2018, we updated our clone to use the latest esp idf master at that time. Shortly afterwards, users started to report that their 'store' filesystem contents were corrupted. We rolled back.
We have now tried again (updating on Oct 20 2018 to v3.2-beta1-208-g0d7f2d77c) and immediately had the same issue. Random corruption of FAT filesystem in SPI flash.
Expected Behavior
No corruption of FAT filesystem.
Actual Behavior
Corruption of FAT filesystem.
Steps to reproduce
Create a partition in SPI flash, and mount FAT filesystem Read and write to files on FAT filesystem Reboot Observe random corruption and unmountable filesystem Code to reproduce this issue
esp_vfs_fat_mount_config_t m_store_fat; wl_handle_t m_store_wlh; memset(&m_store_fat,0,sizeof(esp_vfs_fat_sdmmc_mount_config_t)); m_store_fat.format_if_mount_failed = true; m_store_fat.max_files = 5; esp_vfs_fat_spiflash_mount("/store", "store", &m_store_fat, &m_store_wlh); Debug Logs
n/a
Other items if possible
Please advise if you need anything further.
I think the timeline is correct (the issue is in esp idf master some time between May and July 2018), but please let me know if you know differently (or update the github issue with your comments).
Regards, Mark
On 23 Nov 2018, at 6:19 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
esp-idf and OVMS branches are back to the working version.
In case you also lost your config: I also just fixed a bug on restoring into an empty /store partition.
Regards, Michael
Am 22.11.18 um 22:34 schrieb Michael Balzer:
See https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/165 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/165>
I'll reset both master branches now.
If you're about to pull, please wait until I've reverted the branches.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev