Sziasztok!
Adott egy MT29F4G08 (x8) Nand Flash, az alábbi szervezéssel:
Ha Page read-del olvasom, és 4096 byte-onként, akkor hiányos a tartalom (megvan az eredeti, hogy minek kell benne lennie), ha viszont 4096 + 2X64 bytot (4224) olvasok fel, akkor visszakapom az eredeti tartalmat. Azt a 64 byte-ot ugyanúgy használja adattárolásra?
Beleásta már magát valaki ennyire mélyen a NandFlash lelkivilágába?
Üdv: Jácint
Szia,
Miben találtad ezt a NAND flasht?
0
Szia!
Egy Ekinops routerben.
0
Szia,
Olvasd ki teljesen ahogy nippur írta, a múltkori autós radiós gps-es témával mi lett a végeredmény?
0
Szia!
Az sajna nem sikerült, kiolvasták a jót, átírták a rosszba, de nem javult meg. A két IC-t direkt keresztbe tettem fel a panelokra, így biztosan a Nand-ban van a hiba.
Most JTAG-gel kínlódom, már tudom olvasni, de iszonyat lassú. Page read, sequential, de így is csak 20Mega óránként, 50MHz-es TCK-val. Nézegetem magát a read subrutint, hogy mitől lassú.
0
Ez nem valami okos router? Ciscoéknál mintha váltogatná a flast bootoláskor egyik másik eszközében.
0
Hasonló kategória, mint a CISCO, ugyanúgy LINUX alapú. De nem is ennek a tartalma érdekes, viszont ehhez van komplett JTAG program, és hardver, fejlesztői környezettel. Megvan a rutin is a flash olvasáshoz és az íráshoz is, viszont nagyon lassú a folyamat. Tegnap mértem, Page olvasásánál csak az RE vonalat kell ki-be kapcsolgatni, hogy megjelenjen a következő adat, de 38kHz-et mértem. Ezzel óránként 20Mbyte-ot tudok olvasni.
0
Üdv!
A 2048 byte a tényleges tartalom, a 64 byte pedig a tartalék, ami a hibajavításra szolgál alapvetően, de van más funkciója is. A kettő együtt (2048+64 byte) ad ki egy Page-t, de a valós információ 2048 byte. Nand írásnál, olvasásnál viszont lényeges a tartalék byte-okat is kezelni, így az a Dump része.
0
Szia, szerintem ez a fajta architektura a wear leveling-re (írásokból adódó elhasználódás intelligens kezelése) szolgál.
Vagy ellenőrző összeg van benne :)
0