Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » CPU geht auf HALT, warum? » Themenansicht

Autor

Thread - Seiten: -1-

000
28.02.2022, 18:50 Uhr
robbi
Default Group and Edit

Bei einem defekten BIC gibt die CPU HALT aus, und ich komme nicht weiter.
Der BIC startet, der Bildschirm wird gelöscht und anstelle der Systemmeldung ist nur ein Prompt auf der HOME-Position zu sehen. Die CPU geht auf HALT.

Wenn ich den Code richtig verstehe. wird ein DI (Interrupt Disable) ausgelöst, und es soll ein Banktest und noch etwas mehr ausgeführt werden, bis die Systemmeldung erreicht wird.
Die Suche ist etwas umständlich, weil man im Code ständig seitenweise hin und her gejagt wird. Ein Büchlein mit dem Code - wie beim Z9001 - habe ich nicht bzw. gibt es wohl nicht. 300 Seiten auszudrucken, ist auch keine Lösung.
Auf dem Bildschirm ist die Suche zum Ko.... .

Frage:
Warum geht eine CPU in den HALT Zustand. Sie erwartet einen Interrupt (sagt die Literatur), der ist aber gesperrt.
Eine Suche mit CPU und HALT brachte hier keine brauchbaren Ergebnisse.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 28.02.2022 um 18:52 Uhr von robbi editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
28.02.2022, 19:23 Uhr
Enrico
Default Group and Edit

Ich weis dazu nur, dass es den Halt-Befehl gibt,
Code weis ich so nicht.
Ab da wird nur Halt ausgeführt. Die CPU macht dann nur noch Refresh.
Dort kommt man nur mittels Interrupt raus.
Ob an Deiner Stelle dort wirklich ein Halt-Befehl ausgeführt werden soll,
oder dieser durch Datensalat zustande kommt, weis ich nun nicht.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
28.02.2022, 19:32 Uhr
ambrosius

Die CPU geht nur bei Abarbeitung des Befehls HALT (Code $76) in den Halt-Zustand. Dort werden intern NOP-Befehle ausgeführt ($00), welche nach außen aber nicht sichtbar sind (Adress- und Datenbus). Den kann sie nur mittels maskiertem (INT) oder nichtmaskierbaren (NMI) Interrupt oder Reset verlassen. Wahrscheinlich taucht irgendwo der Halt-Befehl auf, sei es durch zufällig gekippte Bits.
--
viele Grüße
Holger

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
28.02.2022, 19:46 Uhr
robbi
Default Group and Edit

Danke ambrosius.
Die Vermutung mit einem gekippten Bit hatte ich auch schon.

Da ich schon 8 Schaltkreise gesockelt habe (die werden wieder rückgebaut) kommt es auf das Auslöten des EPROMs nun nicht mehr an. Den lasse ich dann aber gesockelt.
Seit dem EPROM-Ausfall von fünf Stück bei Klaus (FTL) bin ich nicht mehr so zögerlich, EPROMs zu verdächtigen.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 28.02.2022 um 19:49 Uhr von robbi editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
28.02.2022, 20:00 Uhr
Germaniumröhre

Der Halt kann auch durch Störimpulse erzeugt werden. Das tritt dann aber nicht regelmäßig auf.

Viele Grüße
Bernd
--
Kombjuder sorgen für Arbeit, die man ohne Diesem sicherlich nicht hätte.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
01.03.2022, 07:51 Uhr
volkerp
Default Group and Edit

in bicsys.lst

Quellcode:


  744                  A;RST38 = absturz oder break
  745                  A;
  746 0400  CD FE3D    ARST38:    CALL    XRST38
  747 0403  F3         A    DI
  748 0404  76         A    HALT

Eine andere Stelle mit HALT gibt es nicht.
Du müsstest suchen, ob und wo ggf. der RST ausgelöst wurde.
Der RST 38h wird im SCP als Bios-Monitor-Ansprung genutzt.

Ich würde testweise den SCPROM (N120) entfernen/disablen.
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Dieser Beitrag wurde am 01.03.2022 um 07:54 Uhr von volkerp editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
01.03.2022, 13:29 Uhr
robbi
Default Group and Edit

Erst einmal herzlichen Dank für das Quellcodebuch mit über 700 Seiten.

Bisher habe ich den Quellcode bei der Fehlersuche noch nicht gebraucht.

Da Du mir angeboten hattest, ihn auch bei mir ablegen zu dürfen, würde ich jetzt davon Gebrauch machen. Für die Fehlersuche ist das sehr hilfreich und der Code ist ziemlich SYPS K1520 kompatibel, so daß nicht nur ein Exrobotroner damit was anfangen kann.

Die Stelle habe ich gestern auch entdeckt und den Einsprung noch nicht gefunden.
Das HALT ist sehr stabil.

Nachtrag:
Es war anzunehmen, daß FF (RST38H) der Auslöser für den Fehler ist. Beide EPROMs sind aber in Ordnung. "Ich bin so klug alswie zuvor."
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 01.03.2022 um 21:41 Uhr von robbi editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
05.03.2022, 19:49 Uhr
robbi
Default Group and Edit

Der Quellcode gibt Auskunft über das Startverhalten. Soweit ich mitbekommen habe, wird nach dem Fehlerbild das erste Mal auf den RAM zugegriffen. Es liegt also möglicherweise am RAM.
Alle Adreß- und Datensignale waren unauffällig. Mich ärgerte schon, daß 6 (sechs) russische Muxer KP531KP11 verbaut waren. Sie waren aber nicht im Bayrisch-Malz-Format, sondern in mattgrauem Plastgehäuse verpackt. Deshalb habe ich meine übliche Reaktion, entfernen aller russischen Muxer, nicht durchgeführt. Ein großer Fehler!
In meiner Not habe ich heute angefangen, die Muxer zu wechseln, und was soll ich sagen, der erste war's.

Nochmals danke für den Quellcode. Der ist nun fast unbezahlbar.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 05.03.2022 um 20:09 Uhr von robbi editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
05.03.2022, 21:47 Uhr
volkerp
Default Group and Edit

Ich gratuliere!
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]