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