flash NAND a zapis bez vymazani bloku

[Libor Konečný]

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 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/20190428/41d84ff1/attachment-0001.html>