flash NAND a zapis bez vymazani bloku
Libor Konečný
support na mikrovlny.cz
Středa Květen 1 16:02:13 CEST 2019
Ano ECC je zapnuty, zapisuji do bufferu 2048+64 bajtu.
Tedy cca zapis do bufferu pameti : for 0 to 2112 SPIwrite[buf++];
Ale v buf jsou vzdy same 0xff a uzivatelskych 512 dat a zapise se
execute cely buffer.
Adresa si myslim je pocitana spravne tedy DIV 2048 a zapsani do 16 bitu
pri prikazu Execute.
(zkousel jsem najit nejaky drivery a tam to maji taky tak).
Nic uz me nenapada, data se zapisuji spravne do adresy 0x77FF a pak to
zapisuje spravne az od 0x8000 .
Nad 7800 se to prepisuje.
nepomaha posunout zapis adresy o cely blok, opakuje se to, je tam
evidentni zavislost, ale netusim jaka ;-)
Ty spare data se musi nejake zapisovat (4x16bajtu) pri zapisu po 512
bajtech dat , nestaci tam mit taky 0xFF?
LK
Dne 1.5.2019 v 12:38 Slavo Tomascik napsal(a):
> A ECC controller je teda teraz zapnuty? Tazko hadat, preco k tomu
> dojde pri cca 31kB. Zle generovana adresa stranky? Niekde zabudnute
> pripocitanie spare oblasti? Prepisanie buffra pred ukoncenim
> programovania stranky?
> NOR a NAND pamete sa nedaju porovnavat. NAND _su_ komplikovane. Je to
> dan za vysoke kapacity. No ked sa ide dosledne podla dataheetu...
> Skoro kazdy vyrobca MCU ma kniznice pre pracu s NAND. Treba hladat tam.
>
> Slavo T.
>
> On Tue, Apr 30, 2019 at 8:41 PM Libor Konečný <support na mikrovlny.cz
> <mailto:support na mikrovlny.cz>> wrote:
>
> Tak zapis po 512 bajtech pomohl, ale trapim se dale....
> Kdyz zapisu cca 31kbytes, tak zapis dalsi page totalne jakoby
> prepsala i castene page pred ni.
> Se mi nechce verit, ze by to bylo tak komplikovane.U NOR paralelni
> flash mi to nedelalo.
> SPI sbernici mam napsanou vlastni a vyuzivam 4 bitove cteni na
> jeden clock, ale ani po jednom bitu neni zmena k lepsimu.
> SPI radic z procesoru s presnym casovanim nepouzivam.
> Je mozny problem v casovani ?
> U paralelni NOR tam to casovani musi byt presne, ale u NAND SPI taky ?
>
> Existuje nejaky levny USB programator, ktery bych koupil pro test?
> Existuje SDK s podobnou SPI NAND pameti?
> Zkusim jeste jineho vyrobce.
>
> Dekuji
> LK
>
>
> Dne 28.4.2019 v 22:11 Slavo Tomascik napsal(a):
>> Aha, tak to je jasne. ECC je podmienka. Bud pouzivat integrovany
>> controller, alebo si napisat vlastny. To je NAND pamet. Zapisom
>> sa menia hodnoty susednych buniek, citanim sa menia bunky, bunky
>> nedrzia hodnotu...
>> Bez ECC ani byte.
>>
>> Slavo T.
>>
>> On Sun, Apr 28, 2019 at 9:34 PM Libor Konečný
>> <support na mikrovlny.cz <mailto:support na mikrovlny.cz>> wrote:
>>
>> Ano je to tento obvod.
>> Dekuji vsem za hodnotne podnety.
>>
>> Tu kapitolu jsem cetl, ECC mam vypnuty =0, ale nebylo mi
>> jasne, ze je podminkou minimalni blok strikne 512.
>>
>> Jaky je vyznam pri ECC=1 a spare area ? Je lepsi mit ECC 1
>> nebo 0?
>> Ja budu potebovat jen 2048 bajtu na stranku, opetovny zapis
>> bude tak jednou do roka, nez se pamet zaplni.
>> Cteni bude hodne caste.
>>
>> Upravim tedy zapis do pameti na min 512, data totiz maji
>> ruznou delku, tak to bude komplikovanejsi.
>> A otestuji jeste vydrz na pocet ctecich cyklu.
>>
>> LK
>>
>>
>>
>> Dne 28.4.2019 v 21:14 Slavo Tomascik napsal(a):
>>> Zdravim,
>>>
>>> ak je to tento obvod,
>>> https://www.mouser.sk/datasheet/2/877/Toshiba%20Memory%20America%20Inc_10242017_TC58CVG0S3HxAI-1218038.pdf
>>> tak je v datasheete priamo kapitola
>>> 6.4. Several Programming Cycles on the Same Page (Partial
>>> Page Program)
>>> nie je to celkom jasne napisane, ale mam za to, ze treba
>>> zapisovat 512B, aby fungoval ECC controller.
>>>
>>> Slavo T.
>>>
>>>
>>> On Sun, Apr 28, 2019 at 8:21 PM Libor Konečný
>>> <support na mikrovlny.cz <mailto:support na mikrovlny.cz>> wrote:
>>>
>>> Zdravim osazenstvo.
>>> Jelikoz jsem zde fachmani na pameti, prosim je o radu.
>>> Poprve pouzivam SPI NAND NOR flash 1Gbit TC58CVG0S3HxAI,
>>> zapisuji a ctu
>>> data pres buffery 2048 bajtu, takova mirna podivnost.
>>> Coz neni problem, problem je jak zapisovat sekvencne
>>> data, ktere mi
>>> chodi pres tcpip stack a maji velikost, par desitek bajtu.
>>> Napsal jsem driver za par hodin, overil funkcnost a vse
>>> se zdalo ok,
>>> zajasal jsem ze konecne vec, ktera sla rychle ;-)
>>> Ale jen do nejake doby, kdy se pak bajty zacaly menit,
>>> tedy jako by do
>>> nejakeho nahodneho bitu se zapsala 0.
>>>
>>> Zapis mam reseny tak, ze poprve vymazu blok , bajty jsou
>>> na 0xFF
>>> Pak do bufferu (2048) nastavim same 0xFF a nahradim je
>>> bajty k zapsani (
>>> adresa zapisu je posunute o delku predchozich).
>>>
>>> Udelal jsem test, kdy do bufferu nastavim
>>> 0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,.........
>>> A zacnu jej bez mazani zapisovat a porovnavat.
>>> Po cca 110-122 zapisech se objevi chyba, tedy jakoby
>>> se dostal 0nit
>>> do jedineho bytu a data jsou tedy nespravne, ukoncuji
>>> zapis a vytisknu
>>> si debug.
>>> Co je zahada, ze vzdy na stejne adrese, ale pri podobnem
>>> mnozstvi cyklu.
>>> Zkousel jsem davat ruzne zpozdovaci smycky, MCU uz
>>> nedela vubec nic
>>> navic, zadne preruseni atd..
>>> Dneska jsem si komunikaci odchytnul na analyzatoru a
>>> taky nic, to co tam
>>> ma prijit tam prijde.
>>> Bad block taky neni na dane adrese.
>>>
>>> Nicmene stejny zapis jsem resil u ST25 (spi pameti, ale
>>> nejsou NAND) a
>>> tam to fungovalo bez problemu.
>>> Stejnou logiku zapisu jsem take rovnez pouzival u NAND
>>> flash HYNIX,
>>> takove ty tenke, ale paralelni a taky bez problemu.
>>> Mazat to pred zapisem je nesmysl, blok ma totiz 132kBytes.
>>>
>>> Ma otazka je tedy, zda se s tim nekdo setkal, a zda budu
>>> muset zapis
>>> vyresit tak ze budu cekat az se naplni buffer 2048 a pak
>>> jej zapsat +
>>> dodelat nejaky timeout.
>>>
>>> A nebo se to zkratka neoporucuje a budu muset resit
>>> driver, kdy zapisu
>>> do page maximalne jednou ?
>>>
>>>
>>> Dekuji
>>> LK
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored by www.HW.cz
>>> <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored bywww.HW.cz <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> <http://www.HW.cz>
>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list - sponsored bywww.HW.cz <http://www.HW.cz>
>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>> http://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20190501/fc400a2c/attachment.html>
Další informace o konferenci Hw-list