SD card vs NAND flash

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

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?

Cobsonchael,

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?

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.