| Автор |
Съобщение |
|
LamiLami
Ранг: Минаващ
Регистриран на: Чет Ное 10, 2005 2:17 am Мнения: 35
|
 NAND Flash Организация
Здравейте.
Правя един дивайс с NAND flash и ми е необходима относително вискока сигурност на данните (дублиране).
Дайте някоя идея ...
|
| Нед Дек 21, 2008 11:19 am |
|
 |
|
mk912
Ранг: Новодошъл
Регистриран на: Съб Сеп 15, 2007 11:24 pm Мнения: 109
|
Някъде по шитовете бях чел че за по-сигурно се записват 2 пъти данните върху един и същ адрес. Просто повтаряш записа и ставало по-сигурен.
|
| Нед Дек 28, 2008 6:22 pm |
|
 |
|
3aek
Ранг: Форумен бог
Регистриран на: Вто Яну 10, 2006 2:40 pm Мнения: 2258
|
първо прочиташ таблицата с bad-sectors и не пишеш там, после след като запишеш проверяваш ако се е записало без грешка и не работиш с някакви високи температури надеждноста си е като на нормален флаш
|
| Нед Дек 28, 2008 7:22 pm |
|
 |
|
ДедоБоре
Ранг: Форумен бог
Регистриран на: Нед Ное 21, 2004 11:31 pm Мнения: 10088
|
и един бобър трябва да го завие в станиол
ако са ти важни данните:
- пиши в два различни чипа, с разделени захранвания
- брой колко пъти си писъл в сектора, това е изчерпаем ресурс
- подсигури захранването по време на писане
- загледай се внимателно в тепературните режими
- използвай ЕСС с голям излишък и битово разместване. ако може не пиши никога важна данна само в един блок
- на кякакъв период рефрешвай данните
ще ползваш ли някаква файлова система или просто очакваш да пишеш с пикче във флеша?
|
| Нед Дек 28, 2008 9:08 pm |
|
 |
|
plameniv
Ранг: Форумен бог
Регистриран на: Нед Окт 10, 2004 9:55 am Мнения: 1718
|
 ???
Къде го прочете това ?
Само ще скапеш паметта с един излишен запис , ако направиш 5000 записа все едно са 10000 с това. Двойно по малко живот!
За да не се записва многократно и да се скапе паметта от презаписи най добре е да се прочита преди запис и да се сравни резултата ако е едно и също просто не записваш. Защо да правиш излишен запис при положение че е същото 
_________________ Избийте баламите и тарикатите сами ще умрат!
Няма невъзможни работи - има много трудни работи!
----------------------------------------------------------------------------------
"Я в Москве с киркой уран найду, при такой повышенной зарплате" !
|
| Пон Дек 29, 2008 1:17 am |
|
 |
|
LamiLami
Ранг: Минаващ
Регистриран на: Чет Ное 10, 2005 2:17 am Мнения: 35
|
10x Experts
С пикче няма да стане, взел съм един Cortex.
И май ще се откажа от дублирането, за сега чипа е само един.
Ако прочета една грешна клетка, това значи ли да я обявя за изгоряла и да отпиша страницата ?
Т.е. възожно ли е грешката да е при четенето а не при записа ?
http://www.yaffs.net Вижте какво намерих изглежда надеждно работи и без ОС.
|
| Вто Яну 06, 2009 12:27 am |
|
 |
|
mk912
Ранг: Новодошъл
Регистриран на: Съб Сеп 15, 2007 11:24 pm Мнения: 109
|
Не бях влизал във форума отдавна но преди малко си направих труда специално за почитателите на бобрите и другата фауна:
Double Programming for High Reliability Systems
- те така се казва апликейшън нота на Spansion.
А иначе го бях чел именно заради проект при който броя записи за живота на устройството нямаше да надхвърлят 1000,
но пък всеки един беше важен и ми беше през поялника дали ще съкратя живота на тъпата памет или не.
|
| Нед Яну 11, 2009 8:24 pm |
|
 |
|
ДедоБоре
Ранг: Форумен бог
Регистриран на: Нед Ное 21, 2004 11:31 pm Мнения: 10088
|
mk912,
мисля, че това се отнася за "нормални" флешове (NOR). и може би е специфично точно за някои видове клетки на тази фирма. не случано пишат да си сътрудничиш интензивно с тях, при създаването на алгоритъма на запис. други фирми предлагат други техники за писане, като всички целят създаване на сравнително стабилни напрежения при програмиране.
обаче NAND флешовете са друго животно. клетката няма нищо общо с тази на НОР-флеша и стресовите ситуации са от друго естество и обикновено имат влияние върху целия сектор. повторен запис може да доведе до "Over-programming" и може да се отрази в неправилно четене на съседни битове, които иначе са програмирани вярно.
|
| Вто Яну 13, 2009 1:17 pm |
|
 |
|
woody
Ранг: Форумен бог
Регистриран на: Вто Юли 31, 2007 2:55 pm Мнения: 1792 Местоположение: София
|
Четете си конкретните датачаршафи на производителя и не екстраполирайте.
Едни можеш безпроблемно да им пишеш едни и същи данни (или само да се свалят битове) в една клетка/страниця, други губят заряда и трябва да има цикъл на триене след всяко писане. Бидейки различни по технология единственото което е общо между тях е май само думата "флаш".
На слука!
|
| Сря Яну 14, 2009 3:58 pm |
|
 |
|
ДедоБоре
Ранг: Форумен бог
Регистриран на: Нед Ное 21, 2004 11:31 pm Мнения: 10088
|
то май наистина си е риболов в мътни води 
|
| Чет Яну 15, 2009 5:19 pm |
|
 |
|
kornox
Ранг: Минаващ
Регистриран на: Пон Яну 26, 2009 6:38 pm Мнения: 1
|
За относително висока сигурност са ти нужни 2 неща:
1) Bad blocks allocation system
2) ECC (error correction code)
Относно алокирането на лоши сектори: Идеята е предварително да заделиш някаква част от блоковете, които ще използваш само реалокиране на повредени блокове.
Пример:
1G-bit NAND Flash = 1024 blocks x 64 pages x 2112 Bytes
Запазваме блокове 824-1023 за реалокиране и съответно пишем само в блокове 0-823.
Създава се структура с 2 елемента: BadBlockNumber и MirrorBlockNumber
Създава се масив от този тип с големина BAD_BLOCKS_NUMBER, в нашия пример = 1024-824=200
Всяка функция за запис/четене в/от блок N първо проверява дали блок N не фигурира като лош в масива. Ако да, чете се MirrorBlockNumber
и за него също се прави проверка (все пак блоковете за backup също може да са дефектни).
По този начин си създаваш драйвер, коъто прави реалокацията прозрачна за горното ниво.
Важното е тази структура да се записва също във флаша, за да може при стартиране да се знае кои са вече намерените лоши блокове.
Нужно е тя да има специфичен маркер за разпознаване, пореден номер (за да използваш винаги последната валидна структура) и CRC.
При power up правиш изчитане на всички 1024 блока и търсиш тази структура.
Относно error correction, по-големите Cortex имат Flexible static memory controller (FSMC), който може да го прави вместо теб.
Софтуерно може така:
Всяка страница е 2112 байта => 2048 + 64. Тези 64 са абсолютно достатъчни за запазване на ECC информация и за CRC на първите 2048 байта.
Ако CRC не излезне, правиш ECC корекция и разбира се реалокираш целия блок, презаписваш го с коригираните данни и така.
Надявам се това да ти помогне, или поне да те ансочи в правилната посока.
Успех!
|
| Пон Яну 26, 2009 7:17 pm |
|
|