so for our future C6748 product we want a great big pool of nonvolatile flash with a file system. we have the option, obviously, of SD card or NAND flash since the 6748 supports both of those memory types.
we got the LCDK and we were able to get the FATfs PSP driver project to work for the SD card project and the NAND flash project.
so far they seem to be the same project with a few different basic calls.
So i was tasked with asking the experts: Which is better? we don't plan on removing this thing from the unit (the SD card will just stay on the board forever) so that would suggest the NAND flash (it doesn't hurt that it is also cheaper) so i would think that that is the obvious choice. however we would really like to know if there are known issues or something we are not thinking about with NAND. are there some extreme advantages to using an SD card instead? do the NAND drivers have issues? do the SD cards handle bad blocks and wear better? the PSP projects seem to be pretty much the same thing so it seems like they are about the same amount of effort to get working.
any help would be appreciated.
Cobsonchael,
I just went through this same process! SD cards have processors in them that handle bad blocks, wear leveling, etc., if you choose NAND flash YOU are the one that needs to take care of these issues. In my opinion, it comes down to either sacrificing writing time or time spent coding your own wear leveling code. I ended up using NAND flash for my project and I think I would have used an SD card if I had to do it over. I am no expert, but this has been my experience so far. A good place to learn about NAND is the Wikipedia article in the link below. Good luck.
http://en.wikipedia.org/wiki/Flash_memory
You will find the following article by my colleagues useful too
http://www.eetimes.com/design/memory-design/4216897/Software-and-hardware-challenges-due-to-the-dynamic-raw-NAND-market
Will try to address your queries further, as needed in coming days.
Things like level of wear tear expected, product life cycle, product volume and if 4bit ECC on OMAPL138 for NAND can be a limitation from your NAND vendor would be additional things to consider.
Regards
Mukul
Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.
well from what i am reading the drivers handle the error correction and wear handling. are you saying that the drivers only do a mediocre job and that the SD card would do a much better/reliable job than the drivers?
What David and Mukul's articles mention is correct. The firmware inside the card is having better algorithms over the NAND. But the flip side is that it might be using MLC/TLC NAND instead of SLC NAND. SLC NAND is more reliable and less prone to bit errors when compared to others. But higher density is not really possible.
Have you explored the options of eMMC(MoviNAND) and SATA for the design? What is the read/write throughput that you are targeting for your device? What is the size of non-volatile storage required for your design?
-Renjith | www.pathpartnertech.com | Verify the answer if you think your query is resolved
I've just been looking at ST's NAND08GAH0A & NAND16GAH0D devices which claim to have in-built error handling, wear leveling and garbage collection. These look very tempting.
I'm taking over the embedded side of a large vehicle data logging project soon. The device sits and listens to 4 CAN buses and needs to store selected data on some sort of FLASH memory. In the past they have used micro SD cards, but these have proven unreliable, presumably due to the extremely heavy read-write traffic that they are subjected to. I'm interested to know what high (circa 2GB) capacity solutions there are that would be robust enough to be used in a vehicle with perhaps 12 hours a day constant reading and writing.
You might want to check the ST's NANDs you mentioned above will be supported by BOOT ROM during bootup.
Reliability wise, you SLC NAND will be better than MLC/TLC NANDs. Managed NANDs like eMMC, SD/MMC etc use MLC mostly.
1. What is your requirement for Capacity? > 2GB?
2. What is the throughput required that you need for your application?
3. If the data is less, and it is mostly read/erase/write continuously, have you taken into account of the wear leveling in NAND?
4 . How critical is the data? Is couple of bit errors acceptable (ie, video data) ?
well the requirements for our project haven't entirely been defined yet. but i do know some of the answers to your questions
1. size: we are unsure what size we will need at this point.
2: throughput: we will be pulling data when read time is not that big of an issue. it will mostly be used to just store data for later review. there won't be any real time reading requirements.
3: we will be doing a bit of writing to the flash and we are aware of the wear leveling required in NAND.
4) data: the data will be pretty important because it will contain things such as custom file headers, compressed audio, etc so we don't want to mess that stuff up. there will also be parts of just text and bitmaps which will be slightly less important to get 100% right.
From whatever little I understand from the requirements, I think the SLC NAND with 4-bit ECC support might be appropriate for you.
Have you check the Flash File System support on SYS-BIOS? Which is the FFS that you are planning to integrate? If this is a head ache, then MMC/SD/eMMC will be the better options.
I suggest you to go through this post where the customer is facing issues in NAND after long time.
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/206710/734726.aspx
i have looked into the FATFS support with SYS bios. the plan is to use it right now even though it appears to be an incomplete driver with poor support from TI.
our first prototype board has an SD card.
i'll look through the post you linked.
You won't be able to run FAT on NAND flash directly. It will not work. You need to have a middle layer for Flash File System to be integrated(eg. YAFFS, JFFS, UBI) and FAT will only run on top of that.
well the FATFS drivers using the PSP bulk media interface seem to work fine on the LCDK
also, we do not plan on booting from NAND so that post you linked doesn't help me.
For Bulk media drivers FAT will work as all the accesses are in blocks and there is no spare area involvement.
A question for Renjith. With respect to Linux, I've assumed in the past that I needed a jounalling flash file system like JFFS2 to handle wear-leveling and power fail. Most FFS appear to support NAND on NOR. With NAND though, where are the bad blocks handled? In the NAND driver? Wouldn't a block access still need the spare area to keep track of bad blocks? Is the spare area the same area as the ECC or OOB thing? Sorry not quite up on the terminology yet.
Norman,
FFS will do couple of things.
1. Manage bad blocks. It can be stored in kernel memory in RAM and finally stored in couple of pages dedicated for this purpose. Or it can be stored in the spare area of flash. Different FFS' has different approaches.
2. Manage writes while taking care of erase block size. eg, Even if I want to write to a single page of 2k, I need to erase a complete block of 128k. So I need to read and backup the entire block before erasing and then modify the required page and write back the whole block if required.
3. Wear leveling support
etc..
If you use FATFS directly, the above listed operations won't be possible.