Hallo Besucher, der Thread wurde 31k mal aufgerufen und enthält 283 Antworten

letzter Beitrag von ralf02 am

Unbekannter DCF77 - Einschub

    Zitat von fepo

    ralf02


    Dann baue doch Deine Veränderung wieder zurück und teste nochmal

    Ich hatte ja zu keinem Zeitpunkt etwas verändert, sondern nur Teile mit gleichen Werten ersetzt. Ich glaube aber auch nicht, dass die Impulslänge so entscheidend ist. Die Software wird sicherlich so gestrickt sein, dass zur Unterscheidung der Impulse in "kurz" oder "lang" der Mittelwert, also 150 ms genommen wird ... Immerhin funktioniert diese Platine ja jetzt besser als die vorherige.

    Ich habe auf dem Flohmarkt wieder einen Zera DCF77-Empfänger gefunden (der dritte) und dachte, mit den bisherigen Reparaturerfahrungen und 2 funktionierenden Referenzempfängern würde ich den schnell ans Laufen bekommen. Leider nicht. Hier ein Foto von der aktuellen Platine:



    Nach dem Einschalten sollten eigentlich die 6 Siebensegmentanzeigen mit "00 00 00" starten und dann sollte die Uhr starten, unabhängig davon, ob ein DFC77-Signal empfangen und richtig dekodiert wird. Das ist bei meiner Uhr aber nicht der Fall, sondern es leuchtet nur die ganz rechte Anzeige, mal eine null oder eine andere Zahl, zuletzt nur der wagerechte mittlere Strich:



    Die mittlere LED, die das Funktionieren der CPU anzeigt, leuchtet nicht. Der blaue Taster, mit dem normalerweise auf Datumsanzeige umgeschaltet wird, hat keine Funktion. Ich habe als erstes die werksmäßig gesockelten ICs (CPU, Eprom und die beiden Rams) quergetauscht, diese sind okay. Ich war zuerst davon ausgegangen, dass ein Fehler bei der Ansteuerung der 7-Segmentanzeigen vorliegt, da die Signale am CD4076 nicht mit denen einer funktionierenden Platine übereinstimmen. Insbesondere kein Takt an Pin 7:



    Also habe ich den CD4076 ersetzt, ohne Änderung. In der Folge habe ich dann auch den CD4011, den 74LS145 und den CD4543 ersetzt, leider ohne Erfolg. Hier die Beschaltung dieser ICs:





    Jetzt ist die Frage, warum startet die Uhr nicht ? Möglicherweise doch ein Problem rund um die 1802 CPU ? Die CPU selbst, Eprom und die beiden Rams hatte ich ja bereits quergetauscht, die sind wohl okay. Daher meine Frage an alle Hardware-Profis, insb. Natas , kinzi , Ruudi , wo könnte hier das Problem liegen ?


    An der CPU hatte ich bereits gemessen, Takt ist da. Am Datenbus ist Aktivität. Alle Tantals hatte ich vorsorglich bereits getauscht.

    Was sagt die Stromaufnahme, ist die im "normalen" Bereich, die Anzahl der leuchtenden LEDs (dabei schaun, ob die gemultiplext sind oder konstant leuchten...) einbezogen?


    Adressbus müsste ja auch Aktivität zeigen, statistisch gesehen mit abnehmender Frequenz je höher die Adressleitung...


    Dekoder für die div. Chip-Select-Leitungen von RAM, ROM und den IO-Bausteinen prüfen, sprich kommt da überhaupt was raus, bei RAM und ROM sollte es relativ "hochfrequent" sein, aber auch die I/O müssen regelmäßig angesprochen werden...


    Ansonsten mit Kältespray und Fön arbeiten und ganze Baugruppe auf Haarrisse in den Leiterbahnen sowie schlechte Lötstellen untersuchen...


    Ach ja: der DIN-Steckverbinder des Einschubs sieht sehr oxidiert aus, eventuell lag das Teil mal mit der Backplane nach unten im Wasser, d.h. Kontakte reinigen, den ganzen Einschub dann mal in nem funktionierenden Rack betreiben und vorsichtshalber auch die IC-Sockel auf der PCB mit z.b. Drahtenden von einem Widerstand oder Silberdraht -möglichst OHNE Lötzinn-Überzug!- durchputzen, besonders auf gute Masseverbindung der ICs achten, denn C-MOS sind besonders latch-up gefährdet, wenn GND fehlt!


    Wenn zu wenig oder aber deutlich zu viel Stromverbrauch vorliegt, kalte oder heiße ICs (für "kalt" kann man punktuell mit Kältespray nachhelfen und schaun, wie schnell die "abtauen") sind immer auffällig, das Ideal liegt wie fast immer in der Mitte...


    Bin gespannt auf die Rückmeldungen ,-)


    Pegel an Reset-Leitung mit Oszi beobachten und Taster mit dran löten und immer mal wieder während der Behandlung mit Fön und Kältespray resetten, um zu sehn, ob es vielleicht temporär hoch kommt...

    Vielen Dank für die Hinweise.

    Zitat von Ruudi

    Was sagt die Stromaufnahme, ist die im "normalen" Bereich, die Anzahl der leuchtenden LEDs (dabei schaun, ob die gemultiplext sind oder konstant leuchten...) einbezogen?

    Die defekte Platine zieht 130mA. Eine funktionierende Platine, die "00 00 00" anzeigt, zieht 155mA. Also ca. 25mA Differenz für 5x6 + 5 = 35 Segment-LEDs (gemultiplext), ich würde schätzen das ist im normalen Rahmen, also keine Auffälligkeiten beim Stromverbrauch.


    Zitat von Ruudi

    Ach ja: der DIN-Steckverbinder des Einschubs sieht sehr oxidiert aus, eventuell lag das Teil mal mit der Backplane nach unten im Wasser, d.h. Kontakte reinigen, den ganzen Einschub dann mal in nem funktionierenden Rack betreiben und vorsichtshalber auch die IC-Sockel auf der PCB mit z.b. Drahtenden von einem Widerstand oder Silberdraht -möglichst OHNE Lötzinn-Überzug!- durchputzen, besonders auf gute Masseverbindung der ICs achten, denn C-MOS sind besonders latch-up gefährdet, wenn GND fehlt!

    Viele Teile der Platine sind sehr oxidiert. Die Kontakte der Messerleiste sind allerdings schön gold-/messingfarben blank, da war wohl eine Federleiste / Backplane drauf und hat sie geschützt.


    Ich habe mal die Schaltung rund um die 1802 CPU aufgezeichnet:



    Pin 4 der CPU ("Q") muss high sein, damit die mittlere LED im Frontpanel leuchtet. Diese LED zeigt an, dass der Computer arbeitet.


    Im Datenblatt steht zum Pin "Q": "Single bit output from the CPU which can be set or reset under program control. During SEQ or REQ instruction execution, Q is set or reset between the trailing edge of TPA and the leading edge of TPB."


    Das Q-Bit kann demnach per Software gesetzt werden. Also läuft das Programm bei dieser Uhr offenbar nicht. Da ich bereits alle ICs, die mit der Ansteuerung der 7-Segm.-Anzeigen zu tun haben, ausgetauscht habe, müsste die Ursache doch bei der CPU / ROM / RAM oder zugehörigen ICs liegen ?


    Ich werde mir erstmal die Aktivität am Daten- und Adressbus genauer anschauen. Der Adressbus ist übrigens nur 8 Bit breit, aber es können trotzdem 65536 Adressen angesprochen werden, indem erst das High- und dann das Low-Byte übertragen wird.

    Ich sehe 6 gesockelte Bauteile wurden die schon in einer known working Platine getestet?

    Zitat von ralf02

    Der Adressbus ist übrigens nur 8 Bit breit, aber es können trotzdem 65536 Adressen angesprochen werden, indem erst das High- und dann das Low-Byte übertragen wird.

    Das ist mehr oder minder "normal", sprich bei vielen CPUs und erst recht µCs so, das nicht gemultiplexte vom 65xx ist eher die Ausnahme ;-)


    Aber: da gibt es dann ein Multiplex-Signal (TPx) aus der CPU raus, das regelmäßig wechseln muss, damit die CPU die ganzen 16bit auch raus bringt und ein externes Latch, das diese Daten zwischenspeichert, d.h. weitere Fehlermöglichkeiten.


    Aber ich würde zuerst mal nur dieses Umschaltbit sowie die /CS resp. /CE oder /EN Leitungen von ROM, RAM(s) und eben auch den I/O-Chips, also allem, was irgendwie auch am Datenbus hängt anschauen, das muss alles regelmäßig mal angesprochen werden, d.h. low werden, wenn es wie oben gezeigt Low-Active-Signale sind. Manche bausteine haben auch mehrere dieser Anschlüsse und selbst Kombinationen mit High-Activ sind nicht ungewöhnlich, siehe auch die MOS Bausteine wie 653x oder auch die ROMs dort.


    Sparte eben ein paar Gatter für die Adressraum-Selektion ein und somit Kosten und Platinenplatz.


    Also erstmal an den Ziel-ICs diese Chip-Select Pins vermessen und wenn dort feste Pegel herrschen (und nicht wenigstens einer je Chip Aktivität zeigt, sollten es mehrere sein), dann den passenden Dekoder-Chip finden (sofern nicht direkt mit der CPU, sprich den Nx Ausgängen verbunden) und durchmessen, die hängen eingangsseitig dann am Adressbus (und/oder den Nx Leitungen) und eben ausgangsseitig an den Chip-Select-Leitungen, Enables oder wie auch immer das je Chip und Datenblatt benannt wurde.


    /MRD wird wohl auch in I/O Cyclen bedient und ist dann quasi baugleich zu den vom 65/68xx gewohnten R/W-Signal, wobei scheinbar auf diese Weise aber ne Art direkter Pfad von externen RAM zum selektierten I/O Kanal möglich ist, ähnlich eines DMA, während /MWR nur in SpeicherSCHREIBzyklen aktiv ist.


    Wenn das Alles stimmt und auch am kompletten Adressbus (z.b. aus Sicht von RAM und ROM) Betrieb herrscht, dann sollte auch die LED vom Q-Port brennen, also zum testen CPU raus und mal beide Pegel direkt an den Pin legen, vielleicht ist die ja auch defekt oder der Vorwiderstand/Leiterbahn etc.


    So lange die nicht brennt scheint das Programm nicht zu laufen oder hat Fehler, aber das meldet die Kiste doch vermutlich dann durch blinken oder Fehlercode im Display, da war doch was beim ersten Patienten, oder?


    Als Nächstes wären dann die Control-Bus Signale interessant, /Wait /INT und die DMA-Leitungen sollten alle inaktiv sein, sonst kann die Kiste nicht vernünftig anlaufen, bestenfalls am INT könnte etwas Bewegung sein, der Rest müsste bei dem kleinen System normalerweise inaktiv sein.


    TPA und MEMRD resp. MEMWR sollten so aussehen:



    Möglicherweise sind die Chip select Leitungen auch durch die CPU Signale Nx abgebildet, aber natürlich kann man auch memory-mappen selbst wenn die CPU mehr Möglichkeiten hat, d.h. das hängt von der Verschaltung ab. An SC0 und SC1 sollte auch immer Bewegung sein, das sind die State-Ausgänge, mit denen die CPU kund tut, in welchem internen Cycle sie gerade ist (was den 65xx großteils leider fehlt, siehe Diskussion aktuell hier im Thread um die cmd G65SC02 basierte PC-Karte...)


    Und:

    Kontaktprobleme resp. umgeknickte oder "daneben" gesteckte Pins nochmals kontrollieren, das sind so die Klassiker, womit man sich selbst viel Sucharbeit spendieren kann...


    Wenn das Alles nix bringt, würde ich zu einem Arbiträrgenerator, USB-IO-Block oder gleich zu nem entsprechend programmierten PIC oder Atmel greifen und den (über passend verdrahteten Adapter) im CPU-Sockel plazieren und dann mal "zu Fuß" diverse Adressen ansprechen samt aller notwendigen Control-Signale wie R/W, ALE oder wie sie bei dieser CPU eben alle heißen, letztlich ist das ja auch nix Anderes als bei anderen CPUs auch, da ja die Peripherie-Chips immer die gleichen Bedingungen brauchen, um zu funktionieren... Ein Logic-Analyzer parallel dazu (selbst billigste Ausführungen tun es da!) zum Rücklesen der gesetzten Pegel etc. ist natürlich auch hilfreich, aber ohne Stimulation allein sicher nicht sonderlich zielführend...


    Wenn man auf diese Weise das RAM testen und das ROM auslesen kann, dann könnte man auch mal durchzählen am Adressbus und stoppen, sobald das Enable-Signal an den Chips der LED-Ansteuerung sich verändert, dann kennt man schon mal die Basisadresse dieser I/O-Blöcke und kann dann dort probieren, die auch extern anzusteuern.


    So ein Programm, das die CPU nachempfindet, aber selbst via RS232 (also USB mit COM-Adapter) erreichbar ist, das ist nicht weiter kompliziert und schnell erstellt, vermutlich findet sich sowas auch im WWW schon halbwegs passend.


    Dürfte aber leichter sein, eine bekannte und flashbare Plattform anzusteuern, als sich ein Testprogramm für die originale CPU zu schreiben. Alternativ kannst Du aber auch Deinen KIM da mal mit ins Spiel bringen und zum debuggen verwenden, z.b. über ne angeschlossene 6522 oder 6821 kann man ja die Signale der CPU auch generieren und passend einspeisen...

    Zitat von Ruudi

    Aber ich würde zuerst mal nur dieses Umschaltbit sowie die /CS resp. /CE oder /EN Leitungen von ROM, RAM(s) und eben auch den I/O-Chips, also allem, was irgendwie auch am Datenbus hängt anschauen, das muss alles regelmäßig mal angesprochen werden, d.h. low werden, wenn es wie oben gezeigt Low-Active-Signale sind. Manche bausteine haben auch mehrere dieser Anschlüsse und selbst Kombinationen mit High-Activ sind nicht ungewöhnlich, siehe auch die MOS Bausteine wie 653x oder auch die ROMs dort.

    Ich habe jetzt erstmal am Datenbus der CPU gemessen, alle 8 Bits liegen im Gegensatz zu einer früheren Messung, wo dort noch Aktivität war, nun statisch auf 1,9 Volt. Die I/O Control Lines N0, N1 und N2 liegen auf 0 Volt. Am Adressbus liegt auf allen Leitungen ein "Rauschen" mit ca. 1 Volt Amplitude bis auf MA1, dort ist ein halbwegs rechteckiges Signal mit 5 Volt Amplitude.


    Vielleicht hat die CPU (nunmehr) einen Schaden ? Ich prüfe sie mal in einer funktionierenden Platine.

    So ich habe mal die CPU in einer anderen Platine getestet, damit funktioniert die Uhr. Die CPU ist also in Ordnung. Mit dem Eprom aus der defekten Uhr läuft die an sich funktionierende Uhr nicht (alle Anzeigen bleiben dunkel). Mit dem "guten" Eprom aus der funktionierenden Uhr ändert sich bei der defekten Uhr aber auch nicht viel, außer dass bei MA0 und MA1 nunmehr Aktivität ist und die rechte 7-Segment-Anzeige jetzt ein "E" zeigt.

    Na ja, das ist ja schon mal ein Teilerfolg, denn das E könnte vermutlich für Error stehen und somit aber anzeigen, das die CPU läuft und "nur" ein Problem mit RAM oder I/O etc.

    existiert...


    Also weiter bei der munteren Fehlersuche, würde das RAM nun auch nochmals umbauen und auch die Sockel jeweils etwas durchputzen, wie oben beschrieben...


    n.B.: Bei den uralten C-MOS Sachen und dem derzeit kalten und trockenen Wetter ist ESD-Schutz oberste Prio, d.h. mit Armband und/oder Tischmatte, aber beides jeweils über Schutzwiderstand geerdet, sonst macht man sich mehr kaputt !

    Zitat von ralf02
    Zitat von Natas

    Ich sehe 6 gesockelte Bauteile wurden die schon in einer known working Platine getestet?

    Die beiden SRams (256x4) hatte ich schon quergetauscht. Die anderen ICs (74LS145, 4011, 4076, 4543) und auch die Rams habe ich im Retro Chip Tester geprüft, sie sind okay.

    Sorry hab mich verzählt die beiden wichtigsten Kanditaten fehlen aber CPU und EPROM.


    Wie ich sehe hast du das ja nachgeholt :-)

    Heute habe ich die Fasssungen von CPU, Eprom und den beiden Rams inspiziert und mit exakt passendem Silberdraht "gereinigt". Außerdem alle Leiterbahnen zwischen diesen ICs geprüft und die Beine der ICs mit feiner Feile ein bischen "angeschliffen". Hat alles nichts geändert.


    Ich habe jetzt mal die Spannungen / Signale an allen 40 Pins der CPU gemessen:


    1. 0,8 VDC

    2. 5 VDC

    3. 5 VDC

    4. 0

    5. 0

    6. 5 VDC

    7. 262,144 kHz

    8-15. Datenbus (an allen Bits gleiches Signal):



    16. 5 VDC

    17-20. 0

    21. 3.5 VDC

    22-24. 0

    25. MA0 1.5 VDC

    26. MA1:



    27-32. MA2-7 1.5 VDC


    33+34. (beide gleiches Signal):



    35. 5 VDC

    36. 5 VDC

    37. 5 VDC

    38. NC

    39. Takt:



    40. 5 VDC


    An sich müsste die CPU doch arbeiten ? CPU, RAM, Eprom sind getestet .... was könnte ich noch probieren ?

    Zitat von ralf02

    8-15. Datenbus (an allen Bits gleiches Signal):

    Das sieht so aus als ob da nichts wäre was Daten auf den Bus legt, was natürlich erklären würde warum die CPU nichts sinnvolles macht.