Ha az olvasás megy, és nem csak úgy tűnik, hogy igen..., akkor az írásnál a legvalószínűbb rejtett gond az időzítések problémája! Nem láttam, hogy mivel próbálod írni...de próbálj minden port művelet után minimális késleltetést beiktatni! Ez nagyban segíti a hibakeresést. Utána egyenként ki lehet majd gyomlálni, ha már megy...
A legjobb viszont, ha van logikai analizátorod. Nekem az segített igazán, amikor vagy két éve egy BIOS frissítés sikertelensége miatt kénytelen voltam egy komplett USB-s EEPROM égetőt csinálni... Anélkül csak szívtam...és sehogy se jöttem rá, mi a gond..., de analizátoron gyönyörűen látszott...!

Van analizátorom, de ehhez nem kell.
Van logikai jelző ceruzám is és azzal is végig követtem a pancsokat és persze műszerrel is kimértem a kábeleket, hogy mindent ott van e ahol kell.
Ráadásul visszajelzés képen egy LCD kijelző is van és arra folyamatosan kiíratom az adatokat illetve a visszajelző lábakat is figyelem.
Többször ellenőriztem a bekötést és a lábak bekötéseit is.
Jelenleg egy 18F4550-el hajtom mert ez van próba panelben most hirtelen amihez tudtam nyúlni.
Az adatokat 8bit-ben küldöm ki és váltogatom A-1 lábat. (LSB)
Az időzítéssel egészen 1ms-ig elmentem, szóval annak elégnek kellett volna lennie, de ha haza megyek kipróbálom többel, 10 majd 100ms-al is..
Bár utóbbi már kicsit túlzásnak tűnik.
Sajnos szerintem az olvasás sem jó, mert mindig csak nullákat olvas ki, de szerintem ha üres a memória akkor 0xFF-eket kellene vissza kapjak, legalább is az adatlap szerint.
Gondolkodtam rajta, hogy hátha védelem van a chippen, de az adatlap szerint unprotekted módban adják ki..

De ha védve is lenne akkor is olvasni tudni kellene róla, de szerintem az sem megy.
A MAN. ID és DEVICE ID-éket akartam kiolvasni de az sem megy...

Nana...!!! Analizátor itt olyan, mint egyéb helyen egy jó szkóp!!!

Igen, elvileg az olvasásnak akkor is mennie kell, ha a védelmet aktiváltad már! Ha nem megy, akkor addig mással ne is kísérletezz, mert értelmetlen...! Az üres IC-ben FF-ek lesznek mindig...
Javaslom szerezz egy hasonló párhuzamos flash eepromot valami régi alaplapról, amiben tuti van adat, és azt próbáld meg kiolvasni! A kiolvasás 100% kompatibilis minden ilyen eszköznél, az írásnál lehetnek kiterjesztett módok is.
Viszont...ált., ha egyszer bekapcsoltad a védelmet valami próbálkozás során, az úgy is maradhat akár! Emlékeim szerint...
msec-es időzítés nem kell a portírásoknál, néhány NOP teljesen jó már. Ha nem kondiztad agyon...legalábbis!

Szerintem nem értetted meg

Nincs olyan, hogy "talán" ez vagy az rossz. Ha azokon a lépéseken egyesével mész végig, 100.0% eséllyel fogsz beleütközni minden létező hibába. Példának okáért abban sem lehetsz biztos bármi más módon, hogy csak 1 hibáról van szó, és nem több hiba összességéről. Persze ha te a vaktában lövöldözést szereted jobban, ám járd azt az utat.

Nem adtam ki olyan parancsot ami még véletlenül is levédené a memóriát, de az tény, hogy az olvasásnak akkor is kellene mennie, de sajna nem megy..
2 memóriát vettem sajna mind kettővel ugyan az a gond..
Az analizátor azt mutatja mint a kijelző, szóval az adatok jók legalább is amit küldenék.
Olvasáshoz meg nem kell semmi, ezért is furcsa, hogy csak 0-ákat olvas ki.
Ameddig nem olvas addig tényleg felesleges is bármi mást csinálni.

pajti2: Egyesével végig mentem már ezeken amit említettél, ezek alapok, de nem hoz eredményt, ezért gyanakodom arra, hogy hibás a chip.
Már csak a memória küldöm íróval megírása és olvasása van vissza.
Ha az sem fog menni akkor tuti a chip a rossz, ha igen akkor küldök bele adatot és ismét elejétől írom meg a rutinokat.
Volt már amúgy ilyen, nem olyan régen egy hőszenzor kapcsán, 2őt vettem és mind kettő hibás volt.

Te nem adtál ki _szándékosan_..., ám a jó ég tudja milyen tranziensek miatt attól még akár az sem kizárt, hogy előállt!
Ám ha nem olvas, akkor ott generális gond van, ugyanis ahhoz semmi nem kell, csak kb 3 vezérlő láb megfelelő szintje, és egy cím...ami mindig van, max nem az, amit szeretnél! Tehát adatnak kötelező lenne megjelenni a kimeneteken. Ha nem így van, akkor keresd az elkötést!

A másik, a logikai analizátor nem azért kell elsősorban, hogy megbizonyosodj, jó adatot küldesz e ki...mert ha a portra 55h-t írsz ki, akkor annyi is lesz ott! Max az a kérdés, _mennyi_ idő múlva áll be ez az állapot ?!! Mivel egy mikrovezérlő elég gyorsan tudja váltogatni a portok állapotát, nem biztos, hogy amikor az adat kiírása után a vezérlő lábbal be latch-eled, akkor abban a pillanatban, _valóban_ a kiküldött adat már létezik e az adat/cím lábakon! Na ehhez kell az analizátor!

Ezt követem végig a kijelzőn.
Hiszen a PORT állapotát folyamatosan figyelem, hogy mikor mi van rajta.
Az időzítéssel meg elhúztam az időt, hogy észre is vegyem, ha történők változás.
Nem történik.
Elkötés nincs már 100szor végig néztem, de mindjárt megint megnézem.
Ez a bajom, hogy az olvasás annyira egyértelmű, hogy nem is értem miért nem megy.
Nem kell csak a megfelelő lábakat beállítanom és meg kellene jelennie az adatnak.
De semmi...
Ezért gyanakszok most már a chip-re.
Holnap kiderül, hogy jó e.
Sajna nem is olyan régen belefutottam egy ilyen hibába, (DS18B20) 1 hétig kínlódtam mire kiderült, hogy a szenzor rossz.
Nem is egy, hanem mindjárt 2 volt rossz és persze én mindenből elsőnek 2őt rendelek, hogy ha az egyik rossza lenne vagy tönkre tenném fejlesztés közben akkor még ott legyen a másik.
Most is így tettem és mind kettővel ugyan az a gond.

ui: egy valamit nem csináltam meg, az pedig az, hogy a nem használt D8-D14-es lábakat nem kötöttem be, tehát azok lebegnek.
Elvileg BYTE módban nem is kell vele foglalkozni, legalább is az adatlap szerint.

Fogod a chip-et es az osszes cimvezeteket valami biztos szintre allitod. A CE, OE es WE labait H-ba teszed. Ekkor a kimeneteit mondjuk egy 4.7k elllenallassal el tudod vinni H-ba is meg L-be. (Tehat +5V-ot illetve GND-t kotsz a kimenetre egy 4.7k-n keresztul es a kimeneten mered a feszultseget.) Ha ez megy, akkor a chip kimenetei nem zarlatosak a tap vagy fold fele. Ha ezek utan a WE-t hagyod H-ban, CE-t, OE-t L-be teszed, akkor a kimeneteken valaminek meg kell jelennie. Ami azt jelenti, hogy egy 4.7k-s ellenallassal nem tudod elmozditani a kimeno feszultseget, mert a chip meghajtja a kimenetet. Ez egy hirtelen teszt, nem kell hozza mikrokontroller meg analizator, csak egy ellenallas meg egy muszer. Ezzel a meressel bizonyos tipusu hibat lehet bizonyitani. Aztan lehet folytatni, hogy a WE-t is L-be teszed, ekkor megint nagyimpedanciasba kell menjen az adat busz, tehat megint el tudod huzni egy ellenallassal barmelyik tap iranyaba.

Nem érted még mindig a lényegét...
Pedig ennél részletesebben már nincs értelme magyarázni...

Ja igen..., vannak időkorlátok is egyes üzemmódokra! Így tetszőleges időzítést NEM iktathatsz be bárhová, tesztelés céljából!

De mondtam már, végy kölcsön egy régi alaplapból BIOS ic-t! Abban van adat, az olvasást tudod vele tesztelni, és működőképes a példány is! Nincs egy ilyen alaplap sem a közeledben ? Ezek foglalatosak szoktak még lenni, simán kiveheted...

Köszönöm, Uraim.
Mindent ellenőrzök és jelentkezem.

Uraim, az adat I/O lábakat vagy is itt a 8bit-es adatlábakat kötelezően fel kell húzzam 5v-ra?

Az adatlaphan a setup és hold időkre vannak minimális érték (0, 10 .. 50ns) megadva, amit a program egyetlen utasítás végrehajtási idejével biztosítható. A többi időknél tipikus érték van csak megadva. Még az írás is kezdeményezhető rövid WE alacsony idővel (Twp min. = 35ns) csak a RY/BY# jel magas szintjére kell várakozni. Szerintem lehet "végtelenül lassan" is vezérelni.
A RESET# lábat hova kötetted? Egy portbitre? Próbáld meg a Vcc bekapcsolása után 50 .. 100 us várakozás (Tvcs min.= 50us) után egy minimálisan 500ns hosszú reset jelet kiadni majd magas szintre vinni és várakozni még minimum 25 us -et (Tready max.).

Igen, a RESET láb port biten van, és bekapcsolás után az init-ben magas szintre van állítva.
Próbáltam nincs változás.

Most beállítottam közvetlen olvasásra, semmi sallang, és így ugyan látható, hogy valamit olvas, csak mivel random ugrál és nem folyamatosan 0xFFFF-eket látok, arra gyanakszom, hogy a bement lebeg és zajokat szed össze és ezt mutatja a kijelzőn.
Ha kiveszem a foglalatból a memóriát akkor is szed össze valami zajt és ezt mutatja is, de nyilván itt más értékeket.

No, most hirtelen eljutottam odáig, hogy az ID amit kiolvastam még is jó volt, programozóval is ugyan az az adat jön. Úgy néz ki, hogy az adatok is jók voltak, de mivel nem tudtam megnézni, hogy milyen adatok vannak a memóriában ezért azt hittem hibás értékeket mutat.
Most már csak azt szeretném tudnom, hogy hogy a viharba lehet egy teljesen új memóriában ilyen kusza összevissza adat, mikor én nem írtam bele semmit.
Mind kettő memóriában ugyan az az adat volt.
Lehet ezzel az adattal tesztelték?

Most töröltem és írtam bele olyat amit majd ki fogok tudni olvasni és ellenőrizhetem.
Remélem innen már könnyebb dolgom lesz.

Jaja...tesztelték, és lusták voltak törölni a végén, igaz?

A memória biztosan üres volt..., ellenben a te próbálkozásaidnál bármi előfordulhatott!

Mind kettő memóriában bitre pontosan ugyan azt nyomtam véletlen?
Nem hinném...
Főleg, hogy minden esetben csak 10címet írtam vagy akartam írni.. (az első 10 címet)

Véletlenek nincsenek

De...elismerem, hogy a lusta kínai volt a ludas

Ha nem ures a chip, akkor az hasznalt. Ha kinabol vetted, akkor siman lehet is. Esetleg gyarilag elore programozott. Ilyen is van ritkan, hogy megrendelesre a gyar felprogramozza valami adattal. De ezeket ritkan lehet kereskedelmi forgalomban kapni.

Igen, és az volt a furcsa, hogy mind kettőn ugyan az az adat volt.
No mindegy töröltem, a memória biztosan jó..

Az olvasás már működik, azt ellenőriztem és szépen olvassa az adatokat amelyet rá töltöttem, de az ID-t már nem tudom lekérdezni.
Az ID lekérdezéséhez, elsőnek ki kell adjam 4 ciklusban a szükséges parancsot:

A meghívása értelemszerűen csak a függvény:


Megnéztem programozóval és erre a memória ellenőrzésre ezt hozza: MGF ID: 03, CF, 00, 05
Még korábban nekem a 0xCF-et írta ki, de most csak FF-et hoz.
A többi mint pl.: Device ID Top Boot Block, Device ID Bottom Boot Block és a Sector Protect Verify-re 0x00-át hoz.
Ezt tuti nem jó.
Véleményem az, hogy valamiért a kódbeírás nem működik.
Vagy is maga az írási részben van valami hiba, de nem tudom mi lehet az.
Próbáltam hosszabb - rövidebb időkkel, variálva CE, WE, OE lábakat...stb.

Sajnos nincs egyelőre siker.

Nos a helyzet a következő.
Reggel óta kínlódok vele, de valamiért nem veszi be a memória a parancsokat.
Próbálom az ID-ét lekérni és próbáltam kiadni a törlés parancs szekvenciákat, de semmi eredménye.

Minden esetben az utolsó beállított címről kiolvassa a memóriában tárolt adatot.
Tehát mint fentebb írtam, az a 0xFF az a Manufacturer ID utolsó parancsának címe miatt van, ugyan is ezen a címen (cím: 0x00) 0xFF adat van.
Ha más címet adok meg, akkor azon a címen szereplő adatot olvassa ki. (tiszta dili)

Valamiért nem veszi figyelembe a kiküldött és beírt parancsokat.
Ilyet még nem láttam, kikészít ez a memória..
Parancsokat ellenőriztem, vezetékeket ellenőriztem (műszerrel, Logikai analizátorral), címek és adatok rendben kimennek, memória össze vezérlő lába rendben van és vezérel.

Az olvasás továbbra is megy tökéletesen, de mást egyszerűen nem tudok vele csinálni ami azért nagy baj..
Próbáltam kiadni a RESET parancsokat is ami a beépített algoritmusokat kapcsolgatja, de semmi.
Nincs több ötletem...

Azt hiszem amikor az eprom íróval beírtam az adatot, akkor valahogy levédte az epromot vagy is valamilyen védelmet aktiválhatott rajta.
Olvasgatva az adatlapot csak ez lehet a probléma.
Ha aktiválva van az adatvédelem, akkor minden parancs beírási kísérlet végeredménye, hogy olvasási módba állítja vissza a memóriát.
Ezért nem tudom írni..

Most már csak azt kellene tudnom, hogyan tudom a védelmet kikapcsolni mert erről elég homályos az alaplap.
Gondolom nem kell egy 5v-ról működő memóriának 12v a RESET lábra, pedig mint ha ezt írná.

No akkor most jön a csillói dolláros kérdés:
Lakik valaki Pesten aki segítene egy AM29F800 memória kezelő programjának megírásában?
Adott minden, próbapanel összekötözve, memória jelenleg üres, de van hozzá programozóm most kölcsönbe, PICkit2 és noti, feltelepített programokkal.

18F4550 van a próbapanelen.

Nem tudom mi lehet a gáz, de véleményem szerint nem fogadja a parancsokat.
Sőt biztos, mert semmit nem csinál az olvasáson kívül.
A program megírva 90%-ban, de az írás, ID lekérés (ez érdekes módon programozóval sem működik,{az ID lekérés}) , törlés és egyéb olyan funkció amibe a parancsokat ki kell küldeni nem működik.

Ha valaki tudna segíteni az jó lenne.
Blahán vagyok városon belül meg tudom oldani a közlekedést, tömegközlekedés útvonalán.
Előre is köszi.

Még egyszer, utoljára ajánlom figyelmedbe a logikai analizátort, mint legmegfelelőbb eszközt a debugoláshoz..., mielőtt csillió dollárt kifizetnél valakinek!
Vagy ha nem tudod megfelelően használni, akkor kérj segítséget hozzá...!

Mond már meg miért fontos ez ennyire?
Analizátorral mit fogok látni?
8 csatornás max, és én 19bit-en küldöm ki a címzést, 8bit-en az adatokat, + vagy 5-6 vezérlő bit.
Csak az adatok kiküldésének figyelésével nem jutottam sehová, már próbáltam. (meg csak ez a 8bit le is fedi a 8 csatornát)
Idők ennyire nem játszanak, hogy amiatt ne működne.
Már a számszerűség törvénye miatt is el kellett volna találnom a megfelelő konfigot, annyiféle variációban néztem már.

A csillió dolláros kérdés pedig csak egy irónia volt, ne szó szerint értsd..

Minden adat tökéletesen kiköltésre kerül, minden cím megérkezik a memóriába, mindent ellenőriztem.
Kontakt tökéletes, adatok tökéletesek akkor mi a fenéért nem akar működni.
Olvasás működik, az írásnak is kellene mennie.

Mert a hardver nem kérdez..., nem úgy működik, ahogy azt te szeretnéd, hanem ahogy az általad létrehozott fizika megszabja! Arról pedig neked nincs fogalmad..., csak elképzelésed, hogy minek kéne történnie, de hogy a valóságban mi zajlik, azt csak akkor tudod meg, ha konkrétan, nagy sebességgel a vezérlő jelekre szinkronozva megnézed, hogy pontosan az élváltás pillanatában mit lát a hardver ?!! Az messze nem mindig ugyanaz, amit te gondolsz, vagy kiadsz, mert létezik olyan az elektronikában, amit úgy hívnak a tranziensek világa!
Üdv benne....

Értem, akkor kérlek mond el mit tegyek?
8 csatornám van hová kössem és mit figyeljek?

Hát a 8 csatorna az elég szerény..., vele nem tudod kivitelezni, hogy legalább a 8 bites adatbájtok sérülésmentes átvitele megtörténik e a szükséges pillanatban. Ehhez is legalább 9 bit kéne.
Így max részlegesen tudod ellenőrizni..., talán úgy, hogy a legfelső bitet konstansra veszed, de a tranziensek miatt sajnos ez így nem garancia a 100%-ra.
Én mindenképpen egy legalább 16 csatornás analizátort javasolnék, legalább 10Msps-en járatva. Akkor is, ha te lelassítottad az algoritmust, a tranziensek ugyanúgy fix, gyors lefolyással fogják végezni "áldásos" hatásukat, mert az R-L-C parazita tagokra nem hat a program végrehajtási sebessége! De legalábbis csak igen közvetve...
Ekkor annyi dolgod van, hogy ahol a vezérlő jelek élt váltanak, nézed, hogy az adat/cím vonalakon, ténylegesen az az adat látszik e az adott pillanatban! Ugyanezt fogja látni az IC is.
Amikor ez egyezni fog a doksiban leírt értékekkel, legalább az élváltás pillanataiban, akkor fog működni az EEPROM is.

Akkor ez padhelyzet.
És most még egy 16csatornás analizátort nem vennék..
Otthon van oszcilloszkópom is, de az is csak 2 csatornás, vagy 4 nem is tudom már.
A lényeg, hogy az is kevés lenne.

Úgy gondolod, hogy élváltásnál nincs ott az adat ahol kell lennie? (parancs)
Az olvasás meg azért megy mert egyértelműen a címkiadással megjelenik a kimeneten az adat?
Ezt sajnos nem fogom tudni ellenőrizni.

Igen...valahogy úgy!
Mindent lehet, csak akarni kell..., kicsit bonyolultabb, de a semminél még a 8 csatorna is jobb!!
Mekkora sebességet tud ?
Analóg szkóppal is próbálkozhatsz, ha ciklikussá teszel valami teszt programot, és nagy felbontásban nézed egyenként az adat/cím vonalakat, másik csatornán valamelyik vezérlő lábra szinkronozva. Csak nem felejtsd el a 10-es osztót használni, máskülönben lőttek a konzekvens vizsgálatnak...