Hello,
I have the DK-57TS-LPC3250 demo kit from FDI (LPC3250) (www.teamfdi.com/.../touch-screen.php)
I'm using the demo version of uVision (because we are still evaluating which RTOS and IDE we will be using)
I would like to program some of the examples into the NAND flash but I seem to be missing the Flash Algorithms for this Large Page (LP) flash.
Does anyone have these algorithms they could send to me?
I'm new to uVision so if this does not make sense please feel free to clarify for me.
Thanks
Can you explain? (maybe a link?)
At this moment, Keil's FlashFS can only work with devices that are directly mapped into the memory space of your processor, or memory mapped IO - like some NOR flash devices, RAM drives, SD cards (this is an exception: they are addressed via a SPI interface - see the provided MCI driver) - but addressing a NAND flash is typically not based on memory mapped IO and requires dedicated processor pins. I asked Keil support about this, and they said that they are working on it, but cannot guarantee a finish date yet. Don't forget bad block management, both based on manufacturer written data and runtime collected information!
Both bad block management and wear leveling are needed.
The bad block management can be hardest because where do you store the bad block list if your intended sector for that information is broken?
In the end, the complexities are quite high to integrate wear leveling and bad block management into a well working solution. Definitely not funny to implement for a project. And you basically need to run the code on a PC that can simulate any random combination of errors just to verify that the code copes with multiple broken blocks management blocks.
Per,
The Samsung's K9F1G08U0B data sheet states that "The 1st block, which is placed on 00h block address, is guaranteed to be a valid block up to 1K program/erase cycles with 1bit/512Byte ECC.". That is where I store the status of the device - because of the ECC but also because I am reusing the same software for another project that lacks the i2c EEPROMs that the project on which I implemented this has...
That helps a lot, since you can then store the sector addresses of your base structures there, and only rewrite the first sector when your main badblock sector or main root allocation sector fails.
The normal way is to have a magic signature and have the software scan sectors (normally using an allocation algorithm of preferred locations to reduce the number of sectors that needs to be scanned) to be able to find a valid "root" sector even if the flash already contains a number of previous, but now broken, root sectors.
Few people would like units that bricks if they have a file system that relies on a single sector and can't cope with a failure of that sector.
but remember to keep two copies of the bad block data so if you get a power fail while updating your block zero you dont end up loosing all that valuable bad block information.
Thanks for the tip - I already have a processor pin to detect a power failure!
In other words: this is already taken care of, but thanks anyway.