Hi @BryceHuang
I just wanted to make a follow up on this.
Basically The the file size should be determined by the size of the buffer given to fx_file_write
And also the file size can increase thanks to the fx_file_seek,
Below and output example where I use a 1K byte file.
FILEX example.....
Open RAM Disk.....
Create TEST.TXT.....
Write TEST.TXT.....
Recovered text file is:
FileX supports an unlimited number of media devices at the same time, including RAM disks, FLASH managers, and actual physical devices. It supports 12-, 16-, and 32-bit File Allocation Table (FAT) formats, and also supports Extended File Allocation Table (exFAT), contiguous file allocation, and is highly optimized for both size and performance. FileX also includes fault tolerant support, media open/close, and file write callback functions.Designed to meet the growing need for FLASH devices, FileX uses the same design and coding methods as ThreadX. Like all Azure RTOS products,FileX is distributed with full ANSI FileX provides the very best deeply embedded filesystem technology in a manner that is easy to understand and easy to use! The FileX Application Programming Interface (API) makes the services intuitive and consistent. You won't have to decipher
Close TEST.TXT.....
If this issue persisted, please share any changes you have made to the filex_levelx_spiflash example. As well return errors you saw from the filex APIs.
In the case you need to adapt further the driver for your memory, I would suggest to start with ramdisk version for the demo, this version does not use Level X, as RAM does not wear like flash. Set DEMO_SECTOR and DEMO_DISK parameters accoriding your flash memory. The advantage of this that RAM does not have the sector size constrains that flash have. I use the ramdisk demo as a base to diagnose issues and determine if the errrors are located within the flash driver itself.
Best regards,
Diego
Also SDK 2.14.0 for the LPC55s69 is already there so you may try this latest SDK
