Hello experts, I am developing a C165 based mass storage device and need to implement a FAT file system on flash. I've read a lot about problems with the life time of NAND due to repeated read/write of the FAT and ST talk about wear levelling software and journeling which are basically jump tables relating vitual addresses to physical addresses to combat the problem. I know that there are commerical file systems offered by companies and would really like to know if anyone has experience of any of these or selecting NAND for this purpose. All advice and links greatly appreciated, Best regards, Malcom.
The FAT formatted flash I use is written so rarely that I do not have any such problems; however, in another flash app I do have that problem. What I do is that I rely on the fact that erases flash is 0xff. arrays[16] // pointers to 16 "start points" pseudo code so to read I do the following while (array[index].mark != 0xff) index++ index -- index point to last written array - use it to write while (array[index].mark != 0xff) index++ if index = 16 erase this part of flash and set index =0 index point to array to write With the above, I have multiplied the endurance of the flash 16 times Erik
"I rely on the fact that erases flash is 0xff." Aren't you also relying on your data never containing the value 0xFF? Or, at least, relying on your data never starting with the value 0xFF?
http://www.8052.com/forum/read.phtml?id=69803
I did not try to show complete code, just the principle, but OK: one byte, of what is written in an area, (.mark in the above) is written zero when an area is written to. That byte (could be just a bit) has no other purpose. Erik
Malcom; The 165 device is a good device but just a little old. Have you considered any of the newer ARM chips? Keil has a flash file system with some of their ARM tools. It also supports TCP/IP and the LPC2140 has USB. Of course, I don't know your application but if you are not tied down to the 165, I would spend just a little time to review some of the newer chips. I know this does not address your original questions. Just had to butt in. Bradford
The usual CompactFlash format is the MS-DOS style FAT. If your flash is supposed to be read and written by other devices, you'll need to stick with the standard file systems, even if they weren't designed with a concern for wear-levelling properties. If your flash is read only by your own software, then you have more freedom to choose other systems. I've had to deal with three commercial flash file systems. They were all marketed for the same reason -- reliable persistent storage, with the emphasis on reliable, as for telecomm devices. These products are supposed to be robust against random loss of power, resets, and the like. Not one of them really worked. It would be fairly routine for the code to announce the file system was corrupted after we pulled a card out of a shelf and plugged it back in. It's nice that the file system detects the fact that it's corrupted and reformats itself, but it still loses all your data. The whole point of paying for such a thing is for someone to have done the hard work of getting it right. Anybody can write file system code that corrupts data on loss of power. If you try to write such a thing yourself, be warned that it's more difficult than it seems. You essentially have to consider every word in your data structur and every instruction in your module as to what will happen if hardware suddenly stops working at any point. I looked briefly at the JFS code for Linux, but it was way too big and bulky for my needs. NAND flash adds an extra layer of complexity, in that sectors of NAND have a much higher failure rate. NAND devices are usually treated much like hard disk drives, where there is more space than really needed in NAND chip, bad sectors are detected and remembered, and extra good sectors used in their place. A NAND flash more or less requires a full-blown file system to handle these bit failures during operation. NOR devices are simpler to use and more reliable on a bit-by-bit basis, but less dense and thus more expensive. The largest sizes, like those 1GB CF cards, are generally not available in NOR technology. Typical flash lifetimes (even for NOR flash) are 100,000 erase cycles, and it's not hard to find parts rated for 1,000,000 cycles. 100K erase cycles is 30 erases a day for 10 years. Questions to ask yourself: What are the needs of your application for update frequency? Are you really changing data that often? Do you really need a file system, which is to say file names, a directory structure, variable sized files generally composed of lists of fixed size blocks, random access to small amounts of data at arbitrary locations inside the file, and all that? Or do you just need to store some data in flash? Do you need redundant data storage in case of bit failure? Loss of power during an erase operation?
Hi Al, Thanks for your insight! I didn't relise how old the C165 was as it is the only USB chip that infineon have. So I find that the new LPC2148 dev kit comes with a working Mass Storage Device example which is great, wish it had been available 6 months ago, I spent 5 weeks coding that from the specs for C165.... The LPC2148 has code flash on-board and USB too but has no address bus for external memory. I'm developing a data logger which writes to file every 4 seconds (hence the concerns about Flash life). The ARM (with USB) limits me to serial memory. I need about 4Mb space. Ideally I would use battery backed RAM to avoid the flash wear problem but haven't found it in high enough densitys. So if I went the ARM route what would you suggest for 4Mb storage over SPI/SSC/I2C? Best regards, Malcom
Hi Drew, Thanks for your reply, some very good points. My device is a data logger updating at 4sec intervals, hence the wear concerns for flash. If I used MMC cards would the wear leveling be done by the MMC protocal? All these card based digital camcorders must have the same problem repeatedly writing to the memory card so does that mean they have a tranlation layer? Best regards, Malcom
Malcom; I'm not qualified to suggest a solution to your problem, but I do have some thoughts. I was not aware of the Keil LPC2148 Eval Board until your post. I downloaded the schematics and noted the board uses an SPI interface for a Compact Disk card. Will this be fast enough for your application? I also note that newer gigbit Compact Flash cards are downright cheap. What I don't know is their page organization. What is the minimum erase/write page size? With a large device size and small page size, you could erase/ write different pages each time rather than grinding a few pages to failure. I once worked with a SiLabs device that recored 16 bytes once a minute. By cycling though the entire device, the estimated failure from their specs was 57 years. You mentioned that you write every 4 seconds and that you needed 4Mb(bytes?). Does this mean you are writing the full 4Mbytes each 4 sec cycle? I have a friend that recently had a similar problem with a data logger project. Best that I remember, he went with battery back RAM of some type. The interface was SPI or I2C because the large memory requirements required a hughmongous parallel bus and his project had limited PC board space. I will review with him and send any info that he might suggest. Bradford
Hello again, Thanks again for your thoughts. My logger files are about 900Kb and I will need to write several files each day. The 4Mb requirement comes from needing several days worth of files stored. I've got 2 options:- 1. Use on-board SRAM (approx 40Kb) to buffer data which can then be written to flash in chunks. 2. Use battery backed SRAM. Which I've looked for but failed to find in large (~4Mb) densitys using serial protocals. Would be very grateful if your friend could recommend a large serial SRAM. Think this would be the best solution. Best regards, Malcom
The LPC2148 has code flash on-board and USB too but has no address bus for external memory There are plenty of LPC21xx devices with external memory interface. Erik
That is true but none with USB too. Thanks, Malcom
Malcom, Have you tried "hammering on Philips' door"? The 2148 is so new that it is not even listed in the LPC device table, maybe there is another device, not in the table, that is what you want/need. I would hunt up an actual FAE, not a "first line responder" and ask "if and if not, when" Erik
Malcom; Once again I was in error. My friend had the same problems trying to locate a large serial SRAM. He uses the Maxim-IC DS1270W as an on chip battery backed SRAM. It has parallel access. For his 12Mbyte Flash, he uses the SST25LF080 4 wire SPI device. It is an 8Mbit device arranged as 1Mbyte x 8. He plans to use the SSTVL160 device as 2Mbyte x 8. It has the same footprint but was not available for his prototype. Both types have small page size so erasures are reduced. His datalogging device is a slave to a larger system. For rapid access, he saves data in the SRAM. If not accessed in X time he then writes to Flash for long time storage. Once again he writes smaller blocks to sequential pages as a circular que. He erases only when he needs to overwrite an old block of data.
Hello again Al, Thanks for the info. I've found a 16Mb SPI flash and will do exactley the same thing. Cheers, Malcom