I am trying to get USB MSC with FFat running on an ESP32-S3. As I use a small Flash variant (4MB Flash), I am using a custom partitions table as following:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x140000,
app1, app, ota_1, 0x150000,0x140000,
ffat, data, fat, 0x290000,0x160000,
coredump, data, coredump,0x3F0000,0x10000,
The ffat section starts at 0x290000. When I use the “Upload Filesystem Image” option or invoking “platformio run --target uploadfs --environment esp32-s3 -v”, the following command is run:
"/Users/xxx/.platformio/penv/bin/python" "/Users/xxx/.platformio/packages/tool-esptoolpy@src-e9520c52db7d0ecbb98379d0d58b38a9/esptool.py" --chip esp32s3 --port "/dev/cu.usbmodem11201" --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 2691072 .pio/build/esp32-s3/fatfs.bin
There occurs the wrong address because 2691072 = 0x291000 and the filesystem is placed at 0x291000 - this is exact one flash memory block too late - it should go to 0x290000. Interestingly, FFat.begin() can work with that, however, if there is no filesystem and I do FFat.begin(true) it formats the filesystem itself and then it starts at 0x290000 in memory.
This is not a big issue until you want to expose the FAT via USB MSC. Then the host computer will read the first block from 0x290000 which is just filled with 0xff and can not open the volume. I can try to work-around and dynamically set a different offset for MSC, depending on where the FFat VBR is located - but this is not nice - is this a known bug or a feature?