Ein Atmega328 steuert einen Z80-Computer

Themabewertung:
  • 2 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 728
Registriert seit: Apr 2014
Bewertung: 5
#91
28.06.2019, 13:51

Hallo zusammen,

heute wollte ich mich mal darum kümmern, warum ich immer wieder Probleme mit meinen Programmen in Assembler habe. Sie stürzen immer dann ab, wenn ich bestimmte Speicherbereiche anspreche. Mir kam daher der Verdacht, dass es Probleme mit dem RAM gibt. Ich habe deshalb eine kleine Routine geschrieben, die den Speicher überprüft.

Die Routine "pflügt" sich durch den Speicher und ließt Byte für Byte ein. Das gelesene Byte wird dann verändert, in den Speicher zurück geschrieben, nochmals gelesen und dabei geprüft, ob der Inhalt der Speicherstelle mit dem zuvor generierten Byte übereinstimmt. Danach wird der Originalzustand wiederhergestellt.

Hier ist die Routine (in Z80-Assembler):

 
checkRAM: push hl
push bc
push de
 
ld hl,RAM_START ; Prüfung beginnt ab dem Ende des "Betriebssystems"
ld bc,0dfffh - RAM_START ; Und geht bis zum Bildschirmspeicher
checkLoop: ld a,(hl) ; Byte aus der Speicherstelle laden
ld e,a ; und in E sichern
set 7,a ; Bit 7 setzen
ld d,a ; und in D sichern
ld (hl),a ; Byte in den Speicher schreiben
ld a,(hl) ; und wieder lesen
cp d ; mit D vergleichen
jr nz,checkFail ; keine Übereinstimmung
ld a,e ; gesichertes Byte zurückholen
ld (hl),a ; und ins RAM schreiben
inc hl ; Adresse hochzählen
dec bc ; bis BC = 0
ld a,b
or c ; ist BC denn schon 0?
jr nz, checkLoop ; Nö
 
jr checkDone
 
checkFail: push hl
ld hl,txtMemFail ; Fehler im Speicher
call print
pop hl
call prtHex_Word ; an Adresse HL
checkDone: pop de
pop bc
pop hl
ret
 
 

Die Routine wird nun jedes mal, wenn ich meinen Z80Ardu starte/resette aufgerufen. Und jedes mal bekomme ich den Hinweis, dass bei Speicherstelle $D400 (Dezimal 54272) ein Fehler vorliegt.

Zunächst habe ich gedacht, der RAM-Baustein hätte einen Schlag und habe ihn mal ausgetauscht. Der Fehler besteht weiterhin! Jetzt fürchte ich eine kalte Lötstelle auf der Platine. Ich werde also die Adressleitungen und die Datenleitungen des SRAM und des Z80 noch einmal nachlöten (Dafür muss ich den halben Computer wieder zerlegen). Danach hoffe ich, den Fehler abgestellt zu haben. Denn wenn der Fehler dann noch besteht, muss ich wohl mein Schaltungsdesign noch einmal überprüfen.... Das wäre wirklich MIST!

Aber bevor ich jetzt zum Lötkolben greife, überprüfe ich zunächst einmal meine Prüfroutine... Es kann natürlich sein, dass die nicht fehlerfrei ist und dann hätte ich alles Andere umsonst gemacht.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 728
Registriert seit: Apr 2014
Bewertung: 5
#92
28.06.2019, 15:48

Also...

die Routine ist in Ordnung. Keine Fehler im Programm gefunden. Extra noch einmal durch meinen Simulator gescheucht.
Also: Adressleitungen und Datenleitungen am RAM und am Prozessor nachgelötet und erneut getestet. Leider wieder der gleiche Fehler. Zumindest am Anfang. Als der Z80Ardu dann wärmer war (Terrasse, 30 Grad), war der Fehler weg. Ergo: Thermischer Fehler. Das muss ich mir noch einmal in Ruhe ansehen.

Trotzdem ist eines noch komisch. Wenn ich für den Stack eine hohe Adresse wähle, läuft der Mist nicht. Wähle ich eine Adresse im niedrigeren Speicherbereich, dann läuft alles stabil. Mir ist nicht bekannt, dass der Stack nich in einem hohen Speicherbereich liegen darf. Schließlich wird der Stackpointer beim Start des Z80 automatisch mit 0ffffx vorbelegt. Also der höchsten möglichen Adresse.

Vielleicht ist es auch ein Fehler im Prozessor selbst. Den werde ich also auch mal noch tauschen. Aber nicht gleich. Momentan habe ich den Prozessorstack einfach mit in einen Bereich innerhalb des Hauptprogramms gelegt. Dort habe ich einfach mal 160 Bytes mit NOP's belegt und das letzte Byte dieses Bereichs als Anfang für den Stack deklariert. Das Programm liegt also drumherum. Und das funktioniert erstmal, so wie ich mir das gedacht habe. Ob der Stack so groß genug ist, weiß ich nicht. Er lässt sich aber problemlos vergrößern.

Das Ende des verfügbaren Speichers lege ich jetzt mal auf 0D3FFx. Damit fehlen mir 3072 Bytes verfügbarer Speicher. Ab 0E000x fängt der Videospeicher an, dort kann ich sowieso kein Programm ablegen.

Ich mache also jetzt erst einmal mit meinem Programm weiter. :-)

Grüße,
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 2 Gast/Gäste