Wear leveling pro AT45DBxxx

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Pátek Listopad 28 06:05:40 CET 2014


Jak myslite to, ze se da zapisovat po Bytech? V dalsim pak uvadite, ze 
neni dobry napad znovu programovat blok bez mazani... A jestli jsem to 
pochopil, zapisuje/maze se vzdy nejmene jeden blok 512+16B najednou, ma 
to 2 vnitrni RAM buffery, s tema se da delat cokolii po bytech ale zapis 
se provede vzdy s celym bufferem, predpokladam.


Dne 27. 11. 2014 23:29, Jan Waclawek napsal(a):
>> AT45DBxxx je MLC tj. multi  level cell.
> Mate na to nejaky zdroj? Lebo ja o tom silne pochybujem. MLC su typicky
> NAND FLASH najvyssich kapacit, a urcite sa u nich nedosahuje endurance
> 100k, skor tak 100; a retention tiez nie je 20 rokov, skor tak 2.
>
> Toto bude normalna NOR FLASH.
>
> Ide tu o iny problem - pri mazani/programovani susednych tranzistorov je aj
> neprogramovanty pamatovy tranzistor vystavovany ucinkom vyssieho napatia
> skrz rozne uniky zo susednych programovanych tranzistorov. Vyrobca pocita
> s worst case (t.j. ze vsetky mazania/zapisy prebiehaju v blizkosti jedneho
> konkretneho tranzistora) a predpisuje ten refresh pre tento pripad,
> pravdepodobne aj s ohladom na medzne prevadzkove hodnoty (najma teplotu).
> Ak sa tie zapisy "rozprestieraju" rovnomerne na cely sektor, tak to take
> horuce nebude; ale samozrejme to netreba riskovat a treba dodrzat predpis
> vyrobcu. Na celkovy endurance by to zase az taky dramaticky vplyv mat
> nemalo, len je to otrava naviac. Skor by ma zaujimalo, ci sa do tych
> erase/write cyklov rataju aj zapisy neuplnych page.
>
> Doporucujem si pozriet aj ine seriove NOR FLASH - tie Atmel/Adesto su
> pomerne nestandardne; maju sice featury navyse, ale Vy ich mozno az tak
> potrebovat nebudete.
>
>> Nelze tedy zapisovat bit, ale myslim, ze dva-ctyri byte by mohlo byt uz ok. Netestoval jsem to.
> Jasne je to v datasheete napisane, ze sa da zapisovat po byte.
>
>> Dale v datasheet je primo uvedeno, ze se nesmi provadet zapis bez predchoziho mazani. Muselo by se zkusit zda je citlive na opakovany zapis nejake hodnoty krom FF. Nevim jak to tam je uvnitr zapojene.
> Nevidim dovod to skusat, ak to priamo vyrobca nedoporucuje. Bez znalosti
> veci mozete situaciu aj vyrazne vyhorsit - pri programovani nejde o to
> napumpovat co najviac naboja cez ten tenky oxid, ale o to napumpovat
> dostatocne mnozstvo naboja s co najmensim poskodenim toho oxidu. Ak
> netusite, co spravi "prebijanie", mozete ten oxid aj vyznamne poskodit a
> cely endurance aj retention ide do kelu. U seriovych FLASH, kde je aj tak
> kopec logiky, by som to nepokladal za pravdepodobne, skor tam nejaka
> "ochrana" bude, ale naco to skusat. Aj kebyze mate trpezlivost a
> prostriedky odskusat si, ci to ma alebo nema na retention/endurance vplyv,
> stale tu ostava moznost, ze vyrobca zmeni technologiu pri zachovani
> vonkajsich znakov, a cely vyskum ide do kelu.
>
> Len velmi zriedkavo som videl explicitne dovolenu/predpisanu moznost
> opakovaneho programovania uz naprogramovaneho bitu, byte ci inej
> programovacej jednotky - jedine, na co si v tejto suvislosti teraz
> spominam, je FLASH v mcu radu XC800 od Infineonu.
>
>
>> Jinak Wear leveling sezere docela dost pameti pro realizaci na nejakych par bytech. Dat na to FAT je taky docela problem s vypadkem napajeni. Spise si udelat svuj vlastni  jednoduchy system. Obcas se nazyva jako LOG system neboli zapisovat postupne
>> dokola.
> +1
>
> wek
>
>
>
>> Dne 27. 11. 2014 v 9:00 Jaroslav Buchta napsal(a):
>>> Nedavno tu v nejakem vlakne byl nakousnut tento problem pro bezne FLASH, ted bych rad realizoval FAT fs na subj.
>>> YAFFS je asi kanon na vrabce pro tak malou pamet, ale tato flash ma pro kazdou 512B stranku 16B navic - vi nekdo o standardnim algoritmu?
>>> Zatim me napada jen v techto 16B udrzovat informace o kazde strance, jeste zbyde 14b na ext. hamminguv kod, na zacatku celou pamet precist a v RAM si udelat tabulku mapovani sektoru. V kazdem sektoru by byla informace o poctu zapisu, logicka adresa
>>> - a to asi staci. Pri prepisu by se vybral po urcitem poctu e/w cyklu jiny nemapovany blok s nejmensim poctem zapisu, tim by se nahradil prepisovany blok.   Asi by bylo dobre mit cache pro par bloku  a zapisovat s nejakym zpozdenim, blbe je, ze
>>> muze dojit k vypnuti pred zapisem ale to se muze stat i primo pri zapisu zmen... Zabere to ale dost RAM, pokud je SDRAM tak nebude problem ale jinak jo...
>>> k te FLASH nekolik postrehu:
>>> Chapu dobre, ze behem 100000 e/w operaci v jednom sektoru (128 bloku) musi byt bloky, kterych se to netykalo, refreshovany r/e/w cyklem?
>>> Asi neni mozne provadet opakovane zapisy bez mazani (nulovat bity)? V datasheetu jsem o tom nic nenasel a vzhledem k predchozimu omezeni... (YAFFS1 to tak myslim dela a z diskusi jsem vypozoroval, ze nektere NAND FLASH to blbe snaseji)
>>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com



Další informace o konferenci Hw-list