atari-home.de - Foren
Allgemeines => Atari - Talk => Thema gestartet von: czietz am Sa 31.10.2020, 20:23:12
-
"Red herrings" sind falsche Fährten.
Ich werde öfter gefragt: Wie würdest Du diesen oder jenen Fehler suchen und beheben? Da ich heute ein Problem in meinem 1040STE lösen musste, schreibe ich meine Gedanken und Versuche unten auf. Ich finde, sie sind lehrreich, gerade weil ich diverse Dinge probieren musste, bevor ich die wahre Ursache gefunden habe.
Mein 1040STE wollte heute nicht booten. Nach dem Atari-Logo (er startet unter TOS 2.06) aber noch vor dem Beginn des Speichertests war Schluss, mit einer wechselnden Anzahl an Bomben. Wahrscheinlich RAM, dachte ich zuerst. Die SIMMs in den Rechner haben verzinnte Kontakte, die offensichtlich mit der Zeit korrodieren. Das kenne ich bereits. SIMMs raus und wieder rein oder Kontakte reinigen hilft. Also das Diagnose-Cartridge für den STE genommen, doch der RAM-Test lief ohne Fehler durch. Falsche Fährte Nr. 1.
Dann fiel mir auf, dass der Absturz immer zusammen mit dem ersten Zugriff auf die Floppy auftrat. Aha, das Netzteil gibt langsam den Geist auf, dachte ich. Das Netzteil im 1040STE ist noch original und wenn das Floppylaufwerk anläuft, zieht der Rechner erheblich mehr Strom. Ich habe einen Adapter, um STFs/STEs aus meinem Labornetzteil zu versorgen. Eingebaut, Absturz nicht behoben. Falsche Fährte Nr. 2.
Also zurück zum Diagnose-Cartridge. Tatsächlich, auch dort kam es bei Floppy-Tests zu schweren Fehlern: Bus-Error oder „bad instruction fetch“. Da befürchtete ich, dass etwas Schwerwiegenderes kaputt war, sah mich schon Floppy-Controller oder DMA-IC auslöten. Das sollte falsche Fährte Nr. 3 sein, wie sich später herausstellte.
Gegentest: Floppy-Laufwerk abgeklemmt. Nun kommt der Rechner problemlos über den Speichertest beim Booten. Danach 4 Bomben, aber das ist der bekannte Bug in TOS 2.06, wenn kein Laufwerk angeschlossen ist. Kein Hardwarefehler und auch keine falsche Fährte, denn das wusste ich ja zum Glück.
Bevor ich mich an die Ersatzteilsuche machen wollte, wollte ich aber noch sehen, was EmuTOS zu der Sache zu sagen hat. Mein STE hat ein per Software umschaltbares TOS; was natürlich schwierig ist, wenn er gar nicht so weit bootet, dass ich überhaupt Software starten könnte. Zum Glück kann man mit dem Diagnose-Cartridge (Menüpunkt „Examine Memory“) auch auf beliebige Speicherstellen bzw. Register schreiben und so konnte ich manuell den Befehl einhacken, mit dem mein STE auf EmuTOS umschaltet.
Mit angeschlossenem Floppy-Laufwerk stürzte EmuTOS auch ganz früh ab, noch vor dem Willkommensbildschirm und mit einer unleserlichen Fehlermeldung. Mit abgestecktem Laufwerk kam es bis zum Desktop (hurra!), um dann dort mit einem Bus-Error abzustürzen – dieses Mal aber mit leserlicher Fehlermeldung. Zuerst dachte ich, dass offenbar noch mehr kaputt war. Bei genauer Betrachtung des Fehlers fiel mir jedoch auf, dass EmuTOS hier bei einem Blitter(!)-Zugriff abstürzte.
Da hat es Klick gemacht: Was ist die Gemeinsamkeit zwischen Floppy/DMA und Blitter? Beide können den Bus übernehmen, um ohne CPU Daten zu übertragen. Insbesondere Blitter und CPU machen das komplett untereinander aus, ohne dass andere Chips (z. B. die GSTMCU) beteiligt wären. Was, dachte ich mir also, wenn die Übergabe des Busses nicht richtig funktioniert und DMA bzw. Blitter etwas schreiben, wenn die CPU Code lesen will? Das würde die Abstürze natürlich erklären. Ein weiterer Durchlauf mit dem Diagnose-Cartridge zeigte: Auch dort verursacht die Nutzung des Blitters Fehler, ähnliche Fehler wie der Zugriff auf das Floppy-Laufwerk.
Kontaktproblem an der CPU? Daher die CPU vorsichtig aus dem PLCC-Sockel gezogen, wieder eingebaut: STE läuft wieder! Wie unwahrscheinlich, dass bloß eine der Leitungen, die für den Bus-Zugriff zuständig sind, einen schlechten Kontakt hatte. Wäre es eine Daten- oder Adressleitung gewesen, der STE hätte gar nichts mehr gemacht und mein Verdacht wäre viel früher auf die CPU gefallen.
Ich hoffe, es war halbwegs unterhaltsam, den Fehlersuchprozess mitzuverfolgen. Und es zeigt, wie wertvoll EmuTOS auch bei der Fehlersuche ist.
-
Solche Beschreibungen sind goldwert und tatsächlich sehr hilfreich. Statt wild zu probieren gibt dies eine logische Reihenfolge vor.
Danke und bitte mehr davon (soll natürlich nicht heißen, dass ich mir bei Dir defekte Rechner wünsche).
-
Danke auch von meinerseite für die Gedankengänge.
Letztlich stelle ich immer wieder fest, das es oftmals Kontaktfehler sind und weniger
defekte Bauteile. Ich hatte auch schon solche Effekte. Kabel abgezogen wieder angesteckt
erst ging nichts und dann kam doch alles wieder. Oder der Blitter im Sockel hatte Kontaktprobleme.
Dann "nass" eingebaut und alles lief wieder.
Ich glaube wenn man alles verlöten würde was in den Sockeln steckt hätte man vermutlich
kaum noch solche Fehler. Allerdings wer macht das schon.
Das mit dem manuell einhacken um EmuTos zu starten ist natürlich ganz speziell. Da müsste ich schon passen.
-
Es lohnt ja vielleicht die vergoldeten speziellen Atari PLCC Sockel bei BEST zu bestellen ...
-
Ja, wirklich interessant Christian, auch wenn ich wünschte das du ein wenig mehr in die Tiefe gehen würdest. Danke
Es lohnt ja vielleicht die vergoldeten speziellen Atari PLCC Sockel bei BEST zu bestellen ...
Klar, für Best lohnt sich das und für das Transportunternehmen auch.
-
Sehr interessant zu lesen! Zeigt mir einmal mehr wie wenig ich mich eigentlich mit der ST(E)-Hardware auskenne, z.B. die Kommunikation der verschiedenen Komponenten untereinander (Blitter, DMA, CPU).
Erinnert mich ein wenig an mein erstes "Herantasten" an meinen 520STM vor zwei Jahren.
Nach 25 Jahren Einlagerung lief er ca. zwanzig Minuten einwandfrei, nur um dann unterschiedlich viele Bomben zu schmeissen und zu resetten (bzw. bei den Bomben einzufrieren bei KAOS-TOS).
Nach beherztem reindrücken aller gesockelten ICs (Tipp hier aus dem Forum!) läuft er seitdem ohne murren!
So ein Diagnose-Cartridge ist natürlich auch 'ne feine Sache.
-
Schönen Dank für diese Fehleranalysen. Sie sind sehr hilfreich!
-
Danke für diesen Bericht! Es ist immer gut zu wissen, wie eine Lösung zustande kommt.
-
Es lohnt ja vielleicht die vergoldeten speziellen Atari PLCC Sockel bei BEST zu bestellen ...
Da die CPU-Pins weiterhin verzinnt sind (PLCC-68ks mit vergoldeten Pins gibt's m.W. nicht), wäre das eine extrem teure Investition, die das Problem nicht behebt. Im Gegenteil können Kontaktstellen aus unterschiedlichen edlen Metallen (z.B. Gold und Zinn) die Korrosion sogar verstärken.
-
Interessant ...
-
Es gibt Literatur dazu, die mindestens bis in die 1980er-Jahre zurückreicht. Hier ein Paper, das speziell gesockelte ICs behandelt (DIP, aber die Resultate dürften auf PLCC übertragbar sein):
The results obtained from this 18 month study have shown that both Au/Au and solder/solder lubricated DIP/socket systems perform reliably with no significant increase in contact resistance. This suggests that lubricated solder/solder systems are a viable alternative to the conventional Au/Au system. However, with the conditions of our test, this is not the case when dealing with the dissimilar metal systems (Au/ solder or solder/Au). […] It is therefore concluded that the use of dissimilar interfaces in DIP/socket applications is unacceptable from our experience in the field and the results of our laboratory studies.
Aus: J. Mottine and B. Reagor, The Effect of Lubrication on Fretting Corrosion at Dissimilar Metal Interfaces in Socketed IC Device Applications, in IEEE Transactions on Components, Hybrids, and Manufacturing Technology, vol. 8, no. 1, pp. 173-181, March 1985, doi: 10.1109/TCHMT.1985.1136469 (https://dx.doi.org/10.1109/TCHMT.1985.1136469).
(Anm.: "Au" ist das chem. Symbol für Gold. Hervorhebung von mir.)
Ein Weg, um verzinnte Kontakte länger stabil zu bekommen, ist demnach schmierendes Kontaktspray ("lubrication" im o.g. Paper). Kann jemand eins empfehlen?
PS: Wenn Feuchtigkeit dazu kommt - aber das ist im Atari hoffentlich nicht der Fall -, dann hat man mit verschiedenen Metallen zusätzlich noch ein elektrochemisches Problem.
-
Ein Weg, um verzinnte Kontakte länger stabil zu bekommen, ist demnach schmierendes Kontaktspray ("lubrication" im o.g. Paper). Kann jemand eins empfehlen?
Ich nutze DeoxIT D5 von Caig Laboratories, um Kontaktprobleme zu beseitigen und danach durch gleichzeitige Schmierung auf lange Sicht zu verhindern:
https://caig.com/deoxit-d-series/
Kratzende oder aussetzende Potis und Fader behandele ich damit ebenso, wie Sockel und Kontaktleisten.
Das Mittel ist teuer und nicht an jeder Ecke zu bekommen.
In Deutschland bietet das z.B. Music Store aus Köln an:
https://www.musicstore.de/de_DE/EUR/Caig-Laboratories-DeoxIT-200ml-D5S-6P/art-GIT0049419-000
Manchmal bekommt man es aber auch bei Amazon.de
-
Ich nutze DeoxIT D5 von Caig Laboratories, um Kontaktprobleme zu beseitigen und danach durch gleichzeitige Schmierung auf lange Sicht zu verhindern:
https://caig.com/deoxit-d-series/
Kratzende oder aussetzende Potis und Fader behandele ich damit ebenso, wie Sockel und Kontaktleisten.
Das Mittel ist teuer und nicht an jeder Ecke zu bekommen.
Danke. Der Hersteller erwähnt ausdrücklich, dass es nicht nur Oxid entfernt sondern auch schmiert, also genau das richtige für lange Zuverlässigkeit, glaubt man dem o.g. Paper. Ich habe mir eine Dose bestellt.
Was den Preis angeht: Regelmäßige Fehlersuche in Retroelektronik ist auch nicht "billig", wenn man die vergeudete Zeit dafür anrechnet. Und bei Kontaktspray gilt ja nicht "viel hilft viel", sodass eine 200-ml-Dose sicher lange halten wird.
-
Was den Preis angeht: Regelmäßige Fehlersuche in Retroelektronik ist auch nicht "billig", wenn man die vergeudete Zeit dafür anrechnet. Und bei Kontaktspray gilt ja nicht "viel hilft viel", sodass eine 200-ml-Dose sicher lange halten wird.
In der Tat. Meiner bisherigen Erfahrung nach ist DeoxIT sehr sparsam einsetzbar, hat man erstmal raus, wie man mit der Düse umgehen sollte. Das Mittel ist gut dosierbar. Bin sehr gespannt, welche Ergebnisse Du erzielst.
-
Bin sehr gespannt, welche Ergebnisse Du erzielst.
Ich habe vorhin die bekannten Schwachstellen an meinem STE (SIMMs bzw. deren Sockel und den CPU-Sockel) mit Deoxit benetzt. Ob's eine positive Wirkung hat, werde ich erst in ein paar Monaten wissen, denn aktuell lief der Rechner ja ohnehin wieder -- siehe Anfang des Threads.
-
Ich habe vorhin die bekannten Schwachstellen an meinem STE (SIMMs bzw. deren Sockel und den CPU-Sockel) mit Deoxit benetzt. Ob's eine positive Wirkung hat, werde ich erst in ein paar Monaten wissen, denn aktuell lief der Rechner ja ohnehin wieder -- siehe Anfang des Threads.
Nun, da ich den STE nach gut 3 Monaten (wegen dieser spannenden Fragestellung übrigens: https://www.atari-forum.com/viewtopic.php?f=28&t=40138) wieder ausgemottet habe, kann ich ergänzen: Bisher scheint das Deoxit gut zu wirken. Keine Zicken mit dem RAM wie sonst.
-
Nun, da ich den STE nach gut 3 Monaten (wegen dieser spannenden Fragestellung übrigens: https://www.atari-forum.com/viewtopic.php?f=28&t=40138) wieder ausgemottet habe, kann ich ergänzen: Bisher scheint das Deoxit gut zu wirken. Keine Zicken mit dem RAM wie sonst.
Nachtrag: Jetzt ist ein Jahr herum. Früher musste ich alle paar Monate an den SIMMs im STE "wackeln", damit er wieder lief. Jetzt: Keine Probleme! Damit würde ich sagen: DeoxIT D5 hat mich überzeugt. Danke für die Empfehlung damals, @dbsys.
-
Nun, da ich den STE nach gut 3 Monaten (wegen dieser spannenden Fragestellung übrigens: https://www.atari-forum.com/viewtopic.php?f=28&t=40138) wieder ausgemottet habe, kann ich ergänzen: Bisher scheint das Deoxit gut zu wirken. Keine Zicken mit dem RAM wie sonst.
Nachtrag: Jetzt ist ein Jahr herum. Früher musste ich alle paar Monate an den SIMMs im STE "wackeln", damit er wieder lief. Jetzt: Keine Probleme! Damit würde ich sagen: DeoxIT D5 hat mich überzeugt. Danke für die Empfehlung damals, @dbsys.
Gern geschehen! DeoxIT D5 hat auch bei mir schon das eine oder andere kleiner Wunder vollbracht. Ich freue mich, daß damit auch unzuverlässige Ataris "kuriert" werden können.