Hallodilo,
ich brauche Hilfe bei der Schreibsequenz eines 29F040 Flash Bausteines. Die Signalpegel werden korrekt gesetzt und funktionieren.
Die Beschreibung im AMD29F040B Datenblatt verstehe ich nicht so ganz.
Unter "Program" steht die Befehlsfolge um den Chip zur Datenübernahme zu bewegen.
XX=Adresse des Datenbytes YY

Voraussetzung: OE=high, CE=low ------- alle Werte werden nur mittels R/W beschrieben/übernommen.

Adresse 555 = AA
Adresse 2AA = 55
Adresse 555 = A0
Adresse XX = YY

1.) Die Adressen müsste doch dann $00555 = AA lauten oder kann ich auch $7A555 dafür nehmen?
Nachdem die 3 vorgegebenen Adressen geschrieben worden sind, kommt das eigentliche Anwenderbyte mit seiner Adresse.
2.) Wobei ich nicht schlau werde - kann nur EIN Byte beschrieben werden oder sind auch mehrere hintereinander möglich?
3.) Muss für jedes Byte, dass geschrieben werden soll, die Befehlsreihenfolge immer wiederholt werden?

Viele Grüße,
Bernd

Hallo Bernd!

Bernd hat geschrieben:1.) Die Adressen müsste doch dann $00555 = AA lauten oder kann ich auch $7A555 dafür nehmen?

Nimm $00555. Es könnte sein, daß der Chip evtl. auch auf $7A555 reagiert, aber das ist nicht garantiert.

2.) Wobei ich nicht schlau werde - kann nur EIN Byte beschrieben werden oder sind auch mehrere hintereinander möglich?
3.) Muss für jedes Byte, dass geschrieben werden soll, die Befehlsreihenfolge immer wiederholt werden?

Ja, du musst die Sequenz vor jedem Byte wiederholen.

Und noch was wichtiges: nachdem Du das Byte ins Flash geschrieben hast, solltest Du (am besten mit dem Toggle-Bit Algorithmus) warten bis das Byte fertig programmiert wurde.

so long,

Hias

HiassofT hat geschrieben:Hallo Bernd!
Ja, du musst die Sequenz vor jedem Byte wiederholen.
Und noch was wichtiges: nachdem Du das Byte ins Flash geschrieben hast, solltest Du (am besten mit dem Toggle-Bit Algorithmus) warten bis das Byte fertig programmiert wurde.
so long,
Hias

Hallo Hias,
Danke für deine Hilfe. Wie sieht der Toggle-Bit Algorithmus denn aus? Meinst du den "WRITE OPERATION STATUS"?
Byte schreiben und anschließend über DQ7: Data# Polling den Status abfragen?

Braucht man auf A9 eine erhöhte Spannung um einen Sector einen Schreibschutz zu geben?

Bye,
Bernd

Hallo Bernd!

Bernd hat geschrieben:Danke für deine Hilfe. Wie sieht der Toggle-Bit Algorithmus denn aus? Meinst du den "WRITE OPERATION STATUS"?
Byte schreiben und anschließend über DQ7: Data# Polling den Status abfragen?

Ich meinte den "DQ6: Toggle Bit I" Algorithmus, der ist ab der Seite nach dem DQ7 (Data# Polling) Algorithmus beschrieben. In der Freezer Flasher Software hatte ich es zuerst mit dem DQ7 versucht, aber gelegentliche Fehler gekriegt. Mit DQ6/5 lief es dann einwandfrei. Könnte natürlich aber auch ein Bug in meiner Software gewesen sein.

Braucht man auf A9 eine erhöhte Spannung um einen Sector einen Schreibschutz zu geben?

Wenn ich mich richtig erinnere, ja.

so long,

Hias

Bernd hat geschrieben:Braucht man auf A9 eine erhöhte Spannung um einen Sector einen Schreibschutz zu geben?

Nachtrag: Ja, braucht man, hier gibt's genauere Infos dazu. Setzen geht noch halbwegs, aber wieder entfernen ist - ähm - etwas kompliziert.

so long,

Hias

Hallo Hias,
ich werde mein Programm mit der D6/D5 Abfrage ergänzen, auf das Resultat bin ich gespannt.
Den Schreibschutz kann man bei dem Aufwand verwerfen.

Danke nochmals für die Hilfe,
Bernd

Hallo Bernd!

HiassofT hat geschrieben:Und noch was wichtiges: nachdem Du das Byte ins Flash geschrieben hast, solltest Du (am besten mit dem Toggle-Bit Algorithmus) warten bis das Byte fertig programmiert wurde.

Ich nehme alles zurück und behaupte ab sofort das Gegenteil: Nimm lieber den #DQ7 Algorithmus.

Ich bin zZt dabei meine Flasher Software für das Atarimax Modul anzupassen und hatte übelste Probleme mit dem Toggle-Bit Algorithmus. Nach längerer Debug-Zeit bin ich dahinter gekommen: aus einem unerklärlichen Grund (evtl. ein Hardware Problem o.ä.) "verschluckt" sich das Atarimax Modul gelegentlich und liefert identische Bytes (statt 08 4C 08 4C 08 4C ... zB 08 4C 4C 08 4C). Bei 2 gleichen Bytes denkt aber der Toggle-Bit Algorithmus, daß das Programmieren/Löschen fertig ist und hört auf... Blöd, wenn das Löschen dann noch weitere 8 Sekunden dauert in der der Chip nicht angesprochen werden kann.

Nachdem ich die Software nun auf den #DQ7 Algorithmus umgestellt habe (inkl. Timeout-Check per DQ5, so wie im Datenblatt beschrieben), klappt es aber nun zuverlässig!

so long,

Hias

Hallo Hias,
Danke für den Tipp #DQ7 doch zu verwenden. Ich habe mir irgendwie einen Bug eingefangen. Das erste Byte wird nicht geschrieben,
erst beim zweiten und weiteren läuft es. Die Routinen für den Statuszustand muss ich auch noch verbessern. Jetzt klappt
das gesamte Löschen des Chips nicht mehr, die Page löschen funktioniert noch.......
Viele Grüße,
Bernd

PS: Mal sehen wie die Auswertung der Statusbits bei meiner Hardware aussieht.

Hallo Bernd!

Bernd hat geschrieben:Jetzt klappt das gesamte Löschen des Chips nicht mehr, die Page löschen funktioniert noch.......

Das kommt mir irgendwie bekannt vor :-)

Bei mir war das Problem, daß ich beim Chip-Löschen zu kurz gewartet hatte (bzw der Toggle-Bit Algorithmus zu früh abgebrochen hat). Das Chip-Löschen dauert ca. 5-10 Sekunden, in der Zeit nimmt der Chip auch keine Kommandos entgegen.

Ich hab' dann alles auf den DQ7 Algorithmus umgestellt, dafür hab' ich eine kurze Routine geschrieben, die ich mit dem jeweils geschriebenen Byte aufrufe (bzw mit $FF beim Löschen):

Code: Alles auswählen

; DQ7 polling algorithm

WTDATA  AND #$80
        STA WTBYTE
WTDLP   LDA (DSTADR),Y
        EOR WTBYTE
        BPL WTDOK
        AND #$20
        BEQ WTDLP
        LDA (DSTADR),Y
        EOR WTBYTE
        BPL WTDOK
        JSR SETREAD
        LDY #$FF
        RTS

WTDOK   LDY #$00
        RTS

WTBYTE  .BYTE 0

Der Code prüft auch DQ5 (bei einem Fehler ist DQ5 gesetzt). Wichtig ist auch, daß man bei einem Fehler das Flash wieder mit dem "Read" Kommando in den Lese-Modus versetzt (hier mit "JSR SETREAD").

so long,

Hias

Hallo Hias,
dein Programm zum Flashen des Frezzerbausteines hatte ich mir auch schon mal angeschaut.
Deine neue Logik gefällt mir gut, ist da aber nicht ein Denkfehler drinnen?

________________________________________________________

; DQ7 polling algorithm

WTDATA AND #$80 -> Bit 7 nur erlauben
STA WTBYTE -> Zwischenspeichern
WTDLP LDA (DSTADR),Y -> Hole Statusbyte vom Flash
EOR WTBYTE -> Exklusiv Oder - 1+1=0
BPL WTDOK -> Positiv dann weg..........Wo bleibt die Abfrage nach DQ5 ob es auch erfolgreich war?
-> DQ7 zeigt ja nur an dass der Baustein beschäftigt ist.
AND #$20
BEQ WTDLP
LDA (DSTADR),Y
EOR WTBYTE
BPL WTDOK
JSR SETREAD
LDY #$FF
RTS

WTDOK LDY #$00
RTS
___________________________________________________________________________

Den ersten Fehler habe ich bei mir gefunden. Setzt du einmal OE auf High und anschließend auf Low
ohne überhaupt etwas gemacht zu haben, geht die interne Logik bei OE=High in den Programmier Betrieb
und bei OE=Low in die Statusabfrage. Ein erneutes Ein / Aus auf OE setzt alles wieder
in die Grundstellung.

Viele Grüße,
Bernd

Hallo Bernd!

Bernd hat geschrieben:Deine neue Logik gefällt mir gut, ist da aber nicht ein Denkfehler drinnen?

Ich hoffe nicht, hab' ihn genauso wie das Flussdiagramm auf Seite 15 im Datenblatt implementiert :-)

Noch ein paar Anmerkungen zum Code:

Der "Trick" an der Sache ist, daß bei Lesezugriffen Bit 7 invertiert wird solange das Flash beschäftigt ist.

In WTBYTE speichere ich Bit 7 des zu programmierenden Datenbytes.

In der Schleife vergleiche ich nun ob Bit 7 im Flash identisch ist mit Bit 7 des Datenbytes. Das geht recht einfach mit EOR: Sind die Bits gleich, ist das Ergebnis-Bit-7 "0" und das N Flag ist gelöscht (BPL fertig). Sind die Bits unterschiedlich (das Flash ist noch mit dem Programmieren beschäftigt) ist das Ergebis-Bit-7 "1" und N wird gesetzt.

Wenn die Bits unterschiedlich sind, folgt noch die Abfrage von Bit 5 (ob eine Zeitüberschreitung aufgetreten ist).

so long,

Hias

Hallo Hias,
Danke für die Erklärung, damit hast du mir sehr geholfen. Da habe ich wohl das Datenblatt nicht richtig verstanden.
Wenn zwischen erster und zweiter Statusabfrage DQ7 ungleich ist, wird anschließend DQ5 auf Timeout kontrolliert.
Da sitzt der Hund bei mir begraben......Der Chip zeigt in DQ7 nicht an, dass er im Fehlerfall mit dem Arbeiten fertig ist,
ganz im Gegenteil. Der Arbeitet weiter obwohl ein Timeout bei DQ5 vorliegt.

Danke,
Bernd

Hallo Hias,
ich hatte einige seltsame Erscheinungen bei der Befehlsausführung.
Scheinbar kann es bei der Übertragung zu Problemen kommen, wenn der 6502 Interupt freigegeben ist
und der Ablauf sich verzögert. Hat der Baustein nicht auch ein Timeout bei der Befehlsübergabe?
Ich sperre jetzt den IRQ dabei. Vielleicht ist dies ja auch die Erklärung bei deinem Verhalten beim lLesen des Statusregisters.

Viele Grüße,
Bernd

Hallo Bernd!

Bernd hat geschrieben:ich hatte einige seltsame Erscheinungen bei der Befehlsausführung.
Scheinbar kann es bei der Übertragung zu Problemen kommen, wenn der 6502 Interupt freigegeben ist
und der Ablauf sich verzögert. Hat der Baustein nicht auch ein Timeout bei der Befehlsübergabe?
Ich sperre jetzt den IRQ dabei. Vielleicht ist dies ja auch die Erklärung bei deinem Verhalten beim lLesen des Statusregisters.

Dieses Problem hatte ich bisher nur bei den Winbond und SST EEProms (29EE010/011). Diese Chips sind etwas anders zu programmieren (in Blöcken zu 128 Bytes), wartet man innerhalb eines Blocks zu lange verlässt der Chip den Programmiermodus und geht in den den Read-Modus zurück (der Rest des Blocks ist dann auf $FF).

In der Freezer Flash Software schalte ich deshalb während des Programmierens NMI, IRQ und DMA komplett ab um ungestört zu sein - damit klappt es immer einwandfrei.

In meiner für das AtariMax angepassten Flasher Software habe ich vor kurzem die NMI/IRQ/DMA Abschaltung rausgenommen und hatte damit bisher auch keine Probleme (getestet mit dem AMD 29F040 in der 8MBit Atarimax cart). Im AMD Datenblatt habe ich bezüglich eines Timeouts auch nichts finden können.

Ich hab' mal meine Software für die Atarimax Cart hochgeladen, kannst ja damit mal Testen bzw den Code vergleichen:
http://www.horus.com/~hias/tmp/aflash-100122.zip

so long,

Hias

Hallo Hias,
ich hatte die Interruptsperre in der Befehlskette eingefügt um das Schattenregister
$D013 in $03FA nach Aktivierung des Modules einzutragen. Danach wurde der IRQ wieder freigegeben.
Machmal hatte es funktioniert, meistens ließ sich der Chip nicht mehr in den Programmiermodus
schalten. Es reicht aus wenn ich nur den IRQ ohne NMI und DMA Sperre, dann klappt alles.
Vielen Dank für deine Atarimax Software. Sie hilft mir beim Verstehen des Flashspeichers weiter.

Viele Grüße,
Bernd

Hallo Bernd!

Bernd hat geschrieben:ich hatte die Interruptsperre in der Befehlskette eingefügt um das Schattenregister
$D013 in $03FA nach Aktivierung des Modules einzutragen. Danach wurde der IRQ wieder freigegeben.

Hmmm... Also eigentlich ist der IRQ egal, wichtig ist der NMI. Im VBI überprüft der Atari ob sich $D013 gegenüber $3FA geändert hat. Falls ja hüpft der XL in eine Endlosschleife.

Der IRQ ist daran nicht beteiligt, höchstens bei den Winbond/SST EEProms könnte es zu Problemen führen wenn man während des Programmierens eine Taste drückt oder sonst ein IRQ triggert (eher unwahrscheinlich, ausser die SIO2PC Software sendet unerwartet irgendwelches Zeugs).

Also: konzentrier Dich beim Modul an/ab-schalten lieber auf den NMI :-)

so long,

Hias

Hallo Hias,
ich habe den MNI mit in der IRQ Sperre aufgenommen und in der Startsequenz eine Abfrage, ob der AMD-Chip vorhanden ist, mit eingebunden.
Jetzt spielt bei mir alles verrückt... Starte ich die Software, so wird der Chip erkannt und ins Menü gesprungen. Der Chip bleibt dabei immer
noch in der Statusabfrage hängen, obwohl ich OE von Low auf High und anschließend wieder auf Low setze. Ändere ich den Zustand mittels
Monitor per der Hand, so schaltet der Chip um. Starte ich die Software ohne Änderungen das 2te mal, so wird der Chip nicht mehr erkannt
und bleibt im Read Modus.....verrückt.... .

Nochmal zum Verständnis der Logik:
OE auf High, anschließend die Befehlskette 555=AA, 2AA=55, 555=90 übermitteln.
Dann OE auf Low und Statusabfrage durchführen. Ich kann beide Bytes - Manufacturer ID mit Adresse XXX0 und Device ID mit Adresse XXX1 bei einmaligen Aufruf der Befehlskette lesen ohne
den Chip noch einmal damit zu füttern. Ist beides erfüllt, geht OE auf High und wieder auf Low, jetzt sollte eigentlich der Readmodus wieder hergestellt
sein, nur bei mir nicht.... Auch wenn ich nur ein Byte auswerte, bleibt es bei dem Fehler. Schalte ich mit dem Omnimon OE auf High und Low, geht der Chip in den Read Betrieb...

So langsam habe ich das Gefühl, der Chip mag mich irgendwie nicht

Servus,
Bernd

schonmal mit nem anderen Flash probiert?
Also ich meine nicht nur anderen Hersteller, sondern auch mit nem anderen AMD ?
Falls Du PLCC Flash benutzt, kann ich Dir ein paar ST29F040B mitbringen!
Falls Du DIL FLash benutzt, versuchs mal mit dem Chip vom Freezer.
Nicht immer hat nur die Software schuld, manchmal ist auch die Hardware (der Flash) n.i.O.

Gruß,
Wolfram.

Hallo Bernd!

Bernd hat geschrieben:Nochmal zum Verständnis der Logik:
OE auf High, anschließend die Befehlskette 555=AA, 2AA=55, 555=90 übermitteln.
Dann OE auf Low und Statusabfrage durchführen. Ich kann beide Bytes - Manufacturer ID mit Adresse XXX0 und Device ID mit Adresse XXX1 bei einmaligen Aufruf der Befehlskette lesen ohne
den Chip noch einmal damit zu füttern. Ist beides erfüllt, geht OE auf High und wieder auf Low, jetzt sollte eigentlich der Readmodus wieder hergestellt
sein, nur bei mir nicht.... Auch wenn ich nur ein Byte auswerte, bleibt es bei dem Fehler. Schalte ich mit dem Omnimon OE auf High und Low, geht der Chip in den Read Betrieb...

So langsam habe ich das Gefühl, der Chip mag mich irgendwie nicht :?:

Das ist so nicht ganz korrekt. Nachdem Du den Chip in den "Autoselect" Modus gesetzt hast und die Manufacturer und Device IDs ausgelesen hast musst Du ein "Reset" Kommando an den Chip schicken (bei AMD 29F040B einfach "$F0" an irgendeine Adresse schreiben). Dadurch kehrt der Chip wieder in den normalen "Read" Modus zurück. Das Reset Kommando muss auch dann geschickt werden, wenn beim Programmieren oder Löschen des Chips per DQ5 ein Fehler gemeldet wird (siehe Note 6 bei der "Command Definition" Tabelle auf Seite 14 im Datenblatt).

so long,

Hias

Hallöchen,
@Wolfram: Den Chip hatte ich bereits schon mal getauscht um auch diesen Fehler auszuschließen.

@Hias: Ich habe den Reset Command Befehl nie so richtig verstanden. Bei der Adresse steht ein X, unter Hinweis ist im Datenblatt weiter zu finden
X = Don’t care, frei übersetzt - nicht sicher -.Ich wusste nicht, welche "nicht sichere Adresse" ich mit einem $F0 beschreiben sollte. Dank dir läuft
jetzt das Programm so wie es sein sollte. Die DQ5 Auswertung ergänze ich noch damit. Wir werden uns wahrscheinlich erst auf der JHV wiedersehen,
ich schulde dir da noch das eine oder andere Bierchen.

Viele Grüße,
Bernd