Wear leveling / FAT failed to mount

[d.cook]

I'm getting an error I can't track down when trying to mount a FAT partition with wear leveling. The error is as follows:

Code: Select all

E (657) wl_flash: initSections(269): result = 0x00000104
E (667) wl_flash: init(161): result = 0x00000104
E (667) wl_ext_safe: init(73): result = 0x00000104
E (667) wear_levelling: wl_mount: init instance=0x00000000, result=0x104
E (677) vfs_fat_spiflash: failed to mount wear levelling layer. result = 260

This appears to refer to an ESP_ERR_INVALID_SIZE error from a call to write in initSections. I can't seem to make sense of what it is that is an invalid size though.

I try and set things up according to the wear leveling example:

Code: Select all

    static wl_handle_t wlhnd = WL_INVALID_HANDLE;

    const esp_vfs_fat_mount_config_t cfg = {
            .max_files = 4, // Max OPEN files
            .format_if_mount_failed = true
    };

    esp_err_t err = 0;
    if ((err = esp_vfs_fat_spiflash_mount("/spiflash", "secure", &cfg, &wlhnd)) != ESP_OK) {
        ESP_LOGE("storage", "failed to mount FAT, error %d", err);
    }

My partition is specified as follows:

Code: Select all

# Name,   Type, SubType, Offset,   Size, Flags
secure,   data, fat,     0xa000,  0x3000, encrypted

Is this an issue with my setup?

EDIT: I should probably also mention that this is with a 512 sector set in the wear levelling component config, however I've had the same issue with 4096.

[ESP_igrr]

You probably need to have a significantly larger partition... WL itself uses 4 sectors (so 16kB) on top of the size made available to FAT. IIRC, for FAT32 the minimum sector count is 128, which makes total partition size 528kB.

[d.cook]

Does that minimum sector count always assume the sector size is 4096B? i.e. is the minimum sector count 1024 with 512B sectors, or would 128 sectors still be fine? As I understand, the ability to set 512B sectors is made possible by the wear-levelling layer, but I'm not sure what influence it has over the requirements of FATFS.

On a related note, is it possible (or at least straight-forward) to use FATFS without wear-levelling? I am using FAT as neither SPIFFS or NVS seem to support encryption, however our application doesn't write to the partition very often, making wear-levelling perhaps a bit overkill.

Thanks!

[ESP_igrr]

Does that minimum sector count always assume the sector size is 4096B? i.e. is the minimum sector count 1024 with 512B sectors, or would 128 sectors still be fine?

I think it should still be 128, although i am not 100% sure what happens inside FATFS. I think only the sector count is used when calculating disk geometry (sectors/cylinders/heads).

On a related note, is it possible (or at least straight-forward) to use FATFS without wear-levelling?

Certainly possible, but you will have to write some code to do that.
Essentially, you need to implement something similar to components/fatfs/src/diskio_spiflash.c, except that instead of wl_read/wl_write/wl_erase you will use esp_partition_{read,write,erase}. Additionally you need something almost identical to components/fatfs/src/vfs_fat_spiflash.c, where you don't call wl_mount, and instead of calling ff_diskio_register_wl_partition, you call your own function, e.g. ff_diskio_register_partition, defined in your diskio implementation.
That should work fine for read-only partitions or partitions which are written very rarely (e.g. factory configs).

[d.cook]

I tried adjusting to different partition sizes, eventually just copying the table from the wear levelling example. It appears that no matter what, I get the same error while using the encrypted flag. For development, I don't actually have encryption enabled yet; I had assumed that the flag would be ignored in that case as it is everywhere else. Can I assume that once I enable encryption, it should work fine with the partition flag?

[ESP_igrr]

This is, perhaps, because esp_partition_write only checks partition's 'encrypted' flag to decide whether to call spi_flash_write or spi_flash_write_encrypted. I think it also needs to check whether encryption is enabled in efuse. It should then either return an error (you asked to write to an encrypted partition but there is no way of doing that) or silently perform unencrypted write.

[d.cook]

I tried it with encryption enabled, on a FAT partition with size 84K (512B sector size, which should be >128 sectors). I now get the following error:

Code: Select all

W (263) vfs_fat_spiflash: f_mount failed (13)
I (263) vfs_fat_spiflash: Formatting FATFS partition
E (263) vfs_fat_spiflash: f_mkfs failed (14)

Error 14 is defined as:

Code: Select all

FR_MKFS_ABORTED,		/* (14) The f_mkfs() aborted due to any problem */

which isn't terribly descriptive

Are there any known issues with formatting at runtime with encryption enabled?

[ESP_igrr]

Just to be sure this is not a size issue, can you try doubling that partition size? If it still fails then the issue is probably related to encryption.

[d.cook]

I bumped the partition size for FAT to 128K and that seemed to work. I'll test that again with encryption enabled when I get a chance, but I expect it should be fine as I realized later I had been getting the same issue without it as well.

Thanks!