Hello,
I got:
- STM32F103RC (Cortex-M3), - I2C EEPROM M24128 (16KB, page size 64 bytes), - Flash-FS V4.20.
I modified a FS_SPI_FlashPrg.c from an example to acces an I2C EEPROM. Taking the article http://www.keil.com/support/docs/3482.htm into consideration I described in FS_SPI_FlashDev.h the storage as 8 virtual sectors (blocks) of 2KB each. The EraseSector procedure takes care of writing 0xFF to all 64 Byte long EEPROM pages building a virtual sector.
It works so far that I can format via fformat("S0:") and write a file via f=fopen("S0:\\filename.txt", "w") followed by fputs("Test", f). Both return success, on the dump of the EEPROM the "\filename.txt" string and after some bytes the string "Test" can be seen. At the top of the EEPROM address space masks of the allocation information seem to be present, too, as described in help to EFS.
The problem is: while f=fopen("S0:\\filename.txt", "r") returns success, the following fgets(s, sizeof(s), f) (and fread(...) I tried) returns always NULL. Besides, ffind(...) gets like:
\filename.txt 0, 01-01-1980 12:00:00
Total: 0 Free: 0.
Note that the directory information you showed is all zero. 1980-01-01 00:00 is the decoded value of a 16-bit date and a 16-bit time in the MS-DOS date/time format used by the FAT file system.
And a file size of 0 means that it doesn't matter if the allocations for the file data is correct - there is no reason to look for any file system sector with file data when the directory information have already claimed that the total file size is zero.
Maybe the file system needs to write the file directory information twice. First when creating the file, and then when you close the file, to enter the reference to the first file cluster, and to enter file size and date/time. Maybe your code fails to handle something, so the file system only manages the first write, just allocating the name of the file. But the second write fails, so no update of date/time and file size.
Hello!
It's not FAT but EFS: refer to http://www.keil.com/support/man/docs/rlarm/rlarm_fs_mem_man.htm . I suppose, ffind() ( http://www.keil.com/support/man/docs/rlarm/rlarm_fs_func_maint.htm ) is not able to provide as full file information as for FAT, and some restrictions apply, that are not documented anywhere, OR ffind() is buggy when dealing with EFS. Thus, the fact that ffind() returns file size = 0, means nothing.
I implemented fs_get_time() and fs_get_date() as suggested here http://www.keil.com/support/man/docs/rlarm/rlarm_fs_func_time.htm (based upon a real battery back up'ed RTC in my CPU), but I could not register any calls to the functions when creating a file on EEPROM, though. At the same time, I've got a SD-Card in the system (SPI driven), and the Flash-FS works absolutely properly with it (FAT32), the file time support inclusive.
I have no idea, what happens, and w/o source code I cannot trace it.
This picture could be seen as a suggestion that Keils EFS might potentially use same format for file date/time information as FAT: http://www.keil.com/support/man/docs/rlarm/rlarm_fs_flashfs.htm
Of course, I could be wrong, since I haven't been using any of the Keil-supplied file systems.
Thanks for replies, PPL!
I solved the problem. It was my fault (what else): because of a wrong definition in the code I wrote always two bytes less than needed. Now it works!