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.
Thanks for you reply!
The reading functions/ffind return nothing/weird information always: both just after the file creation sequence (like format-write-close) and full reboot afterwards. Unfortunately, I've got no source code of Flash-FS - just FS_CM3.lib accompanied with the header files/File_Config.c and some examples/drivers (the legacy :)), - so I cannot comprehend what's going on inside.
My hope is merely, someone here may have dealt with the issue and solved it, but on my opinion, FS has a bug handling the EFS allocation: open file returns OK but the following reading operations retrieve nothing!
I can see and trace the calls to my I2C EEPROM support inside of FS_FlashPrg.c while FS tries to open and read a file: my I2C functions return correct bytes from the allocation area (high addresses) but FS seems not to be satisfied with the retrieved information because it breaks without trying to read the content of the opened file from the low addresses, and fgets/fread return NULL.
I've used sf0_spi.ProgramPage()/.ReadData() to write to/dump the EEPROM content beyond the file system just to test whether my I2C EEPROM support works correctly. Everything was OK, so I can exclude possible failures in the communication with the I2C EEPROM.
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!