I am evaluating the Keil File System Middleware. I have encountered a problem. Hopeful someone could give me a quick and clear hint.
It seems there are two types of file systems in the FS middle ware: Embedded FS and FAT FS.
Could someone tell me the differences between this two types.
I have noticed that NOR flash type be configured to use the Embedded FS type.
Could this Embedded FS be compatible with the USB Mass storage Class?(Treated as a plugged U Disk by the PC).
Could NOR Flash be configured to use the FAT FS? I have noticed the open source FAT FS doesn't distinguish the NOR Flash from other storage media.
Could a pure SPI Flash(i.e. Winbond W25Q32) be configured as the NOR Flash? The official Keil Pack includes a special NOR Flash(AT45DB642D) which supported both bus style NOR flash access method and a SPI style.
Thanks.
FAT FS is an Open Source implementation of the Microsoft FAT File System. This format is, unsurprisingly, supported on a PC.
Different file systems structure their data in different ways, usually incompatible ways, to suit the media they use. Absent a driver for a specific file system a Windows PC is not going to be able to access or use it.
Applying a NAND/NOR memory to FAT FS will depend on your erase block size, write function, and ability to handle sectors (nominally 512 bytes) and clusters in a compatible manner. Or your ability to manage/mask the underlying behaviour.
Thank your blind reply, Mr. Westonsupermare Pier. It is better than no reply.
I am ask questions special to the Keil Middleware File System, not general FAT theory.
My previous project uses an open source FAT FS. It works fine. Both the PC and my program on MCU could access files on the SPI flash I used.
I am currently upgrading my product. Since Keil ARM have included a middle ware in their tool, I personally think it would have a better quality and stability. So I am evaluating whether it is feasible to migrate my program from the open source FAT file system to Keil's solution. Unfortunately, Keil doesn't provide full source code to most of components of the middle ware. So it is an arduous work for me. It is the reason why I post my problem here to try my luck in case that someone familiar with the middle ware could help me save some time.
P.S. to my problem: I have already tricked the middle ware to initialize my SPI Flash(Winbond W25Q32) instead of the built-in AT45DB642D. And the device ID could be correctly read out.
Both fmedia and fformat functions return fsAccessDenied.
fs_ioc_get_id returns -1, indicating there is no volume available. So the PC keeps requesting me to insert disk to the removable disk. These two functions returns fsOK to me.
fres = finit("F0:"); /* Initialize NOR Flash Disk 0 */ fres = fmedia("F0:");
I have found the limitation about the Embedded File System on the Keil website.
Limitations
The following restrictions are applicable to the EFS:
This file system is not compatible with the FAT file system and cannot be used with an USB mass storage device.
Directories or folders are not supported.
File names are preprocessed to remove the path information for non-FAT file systems.
Maximum file name length is limited to 31 characters.
Timestamp information is not supported for a file.
Drive partitions are not supported.
Search within files works only for files opened in read mode.
In the Keil supplied code fs_config.h:
#if (NOR0_ENABLE) { &nor0_vol, "F0", FS_EMB | NOR0_DEFAULT_DRIVE },
The NOR flash is by default configured as embedded file system. Is it mandatory? If so, I would drop my migration idea and resign to the open source FAT FS solution.
Just cleared myself some confusing stuff.
The Keil MDK4 has a different middle ware system from Keil MDK5. The file system middle ware in MDK4 is called RL-FlashFS. While they change it to File System Component in MDK5. The RL-FlashFS seems to have SPI Flash support. I am very confused why it got dropped in a new version. I have not MDK4 and could not try it out now.
It is frustrating day that I have spent good time reading about the very different middle ware of MDK4. The two document structures are well-weaved on the Keil website.
I will spend one more day trying to solve this mystery. If I could not, I would return the open source FAT FS solution.
Can't say I've spent any time with the middleware, you can run file systems on all manner of devices, NAND, NOR, SDCARD, etc, what's important to understand is the expectations of both. There is a very wide selection of NAND/NOR parts, with different geometry/organization. NAND typically presents much larger blocks, and requires error correction and mitigation, and management of the smaller writes the file system (and user) typically throw at it. The SDCARD uses NAND, but hides a lot of the underlying issue behind the hardware interface.
You should really discuss your issues with a Keil support representative assigned to your account.
You can trick Keil's Middleware to use SPI flash with FAT file system, but flash memory must have sector-level erase capability. I have done that by modifying RAM disk driver to access SPI-attached AT45DB16 SPI flash memory, but it was a tricky job. If you have experience with open-source FAT FS, stick to it. For me it was a clean start, so I decided to use Keil's middleware for all peripherals.
regards
Dejan
Hi Zhan,
you can use the FAT FS on SPI Flash devices. Add a "Memory Card" drive which uses a MCI driver as interface to the peripheral. This MCI driver can be configured in SPI mode.
Thank you Reinhard Keil.
I have investigated the MCI interface, which indeed has a SPI option.
I found that the MCI driver interface is still very different from the SPI Flash I would use. For example, it requests SDIO driver as mandatory. And the MCI Command is not similar to the SPI Flash command.
For now I have to retreat to my previous open source solution.
I strongly advocate that the SPI Flash should be treated as equal as the NAND Flash/MCI(but not NOR Flash, which could not use FAT type FS). The "S:" label device should be recovered from the MDK4 Middleware system.
I am waiting for your update.
How do you intend to put FAT on Winbond W25Q32 device? This device can only erase 4K sectors and this is not compatible with 512B sector size required by FAT. Does your open source solution provide some sort of translation layer?
File System component supports NOR flash devices with NOR or SPI interface (you can take a look at M29W640FB.c and AT45DB642D.c driver implementation) both on drive "F:", but they can only be formatted using Embedded File System.
To my knowledge, most of the storage devices available are not compatible with the FAT requirement of 512Bytes sector size. Most of the stable file system solutions, including the one I am using have a translation layer. I suspect now whether it is the absence of a translation layer that may render the Keil middleware FS unable to use FAT FS type with the NOR/SPI Flash.
The reinvented wheel of Embedded File System could not exist simultaneously with the USB mass-storage class application. It is against with the reason of using a File System or file to facilitate data exchange. Between customized binary record and full-fledged file system, I saw little necessity of the yet another Embedded File System.
There exist AT45DB15(32,64) family of devices with small sectors (512bytes) that can be used with FAT-type file systems directly. As I said, I've modified Keil's RAM disk driver for the purpose and use it with AT45DB16 in several devices. You can do the same. The only modification is required in fs_config.h file. You should use Keil's original file, modify it and save with your project files so copmiler will use it when compiling fs_config.c instead of default one. And of course, you must write serial driver for sector read/write yourself...
Thank you, Dejan Durdenic.
I would not modify my hardware to justify the Keil's twisted middle ware design. My hardware uses a SPI Flash with 4K sector. I have returned to the open source FAT FS I adopted in my previous project. It works fine for me. So far I have not found any inconvenience.
So what is final verdict. Can we use NOR flash with Keil FAT FS or with open source FATfs library?