STM32U5A5: Azure FileX FAT12 with more than 4096 byte (or 4096 cluster of 512 byte)

[Riscy]

I have written quite a bit of code to familiarize myself better with Azure FileX with 192K sram, and so far, it is working well under ThreadX. The Azure FileX documentation made clear that FAT12 has a maximum number of bytes of 4096 per filename which is confirmed via code inspection within FileX. I struggle to find logic to report errors if exceeded the filename size. 

Below is the response of the test code where a command invokes file write each 512-byte data (sector) with UDT1970 timestamp and DWT in uSec string embedded on the test pattern (see below). Using the same filename, I repeat the write roughly every 1 second until I achieve 5120 bytes and then inspect the timestamp string as shown below. I found there was no error for exceeding 4096 bytes, and the DateTime looks consistent after 4096 bytes, i.e. it does not loop back to start after 4096 bytes.

I found a reference to another source where FAT12 supports filename with 4096 clusters, not byte. So, I am a tad confused there. (See FAT12 in https://www.wikiwand.com/en/File_Allocation_Table)

Comment?

#BTN-1:FXWRITE(1;0s/Tiscy/Data1.hex)
---INFO: eWRITEDATA
Filename Path /Tiscy/Data1.hex:
Writing Data to file: 512 (byte)
File Size: 5120 (byte)
#BTN-3:FXREAD(2;0s/Tiscy/Data1.hex)
---INFO: eREADDATA
File Size: 5120 (byte)
Filename Path /Tiscy/Data1.hex:
UDT1970:0x659983F6           Note:1st sector
DWT:0x003B7953
UDT1970:0x659983F7
DWT:0x0047B8D4
UDT1970:0x659983F8
DWT:0x0051FEA2
UDT1970:0x659983F8           Note:4th sector 2048 byte written
DWT:0x005C4E98
UDT1970:0x65998419
DWT:0x00BA2933
UDT1970:0x6599841B
DWT:0x00D1ABBA
UDT1970:0x6599841C
DWT:0x00DD525C
UDT1970:0x6599841C           Note:8th sector 4096 byte written
DWT:0x00E74D9C
UDT1970:0x6599841D
DWT:0x00F46B3D
UDT1970:0x6599841E
DWT:0x010414A6
Total Byte transferred: 5120

 

#BTN-2:FXREAD(1;0s/Tiscy/Data1.hex)
---INFO: eREADDATA
File Size: 5120 (byte)
Filename Path /Tiscy/Data1.hex:
00000000: 55 44 54 31 39 37 30 3A 30 78 36 35 39 39 38 33 | UDT1970:0x659983
00000010: 46 36 0A 44 57 54 3A 30 78 30 30 33 42 37 39 35 | F6.DWT:0x003B795
00000020: 33 0A 00 EE 11 55 33 EE 11 55 33 EE 11 55 33 EE | 3....U3..U3..U3.
00000030: 11 55 33 EE 11 55 33 EE 11 55 33 EE 11 55 33 EE | .U3..U3..U3..U3.
00000040: 11 55 33 EE 11 55 33 EE 11 55 33 EE 11 55 33 EE | .U3..U3..U3..U3.

[Pavel A.]

Hi, sorry the question is not clear. Do you refer to limitation of file *name* length or the data size? There's absolutely no sense in limiting the file *data* size to 4096 bytes. As soon as you fill one block or cluster, the filesystem will automatically allocate and continue to other block. There's no sense in returning any error when this occurs. Anyway the max. file *data* size on FAT12 volume depends on the cluster size and the max. is 256 MB.

 

[Tesla DeLorean]

Not making a lot of sense. The chain can only describe 4096 clusters (limit probably 4078), but the clusters presumably can be quite large. A FAT table is a linked list of where the next block/cluster of data is on the media, and some special markers to flag the end-of-chain.

The trade-off here being the amount of space consumed / wasted with large clusters

Not sure it's got much of anything to do with "file name size"

4KB Sectors works well with QSPI memories, and newer hard drives.

[Riscy]

Thank you; I shall ignore the comment in FileX and Documentation in FileX, which stated 4096 byte limits.  I do agree they are misleading. FATFS has detailed rights for FAT12. Thanks.