Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » KC mit Problem bei RAM Modul im Busdriver » Themenansicht

Autor Thread - Seiten: -1-
000
07.03.2021, 22:10 Uhr
schlaub_01



Hallo,
heute brauche ich mal Eure Hardware-Expertise. Ich habe hier einen KC85/4 zur Reparatur, der ein seltsames Problem hat, wenn ein RAM Modul im Busdriver gesteckt ist. Durch den RAMTEST3 ist das Problem aufgefallen, man kann das aber auch ganz einfach nachstellen. Wenn ich den internen RAM4 abschalte und das Modul aktiviere, dann müsste ja ein Speicherblock in diesem Bereich mit dem Modul arbeiten. Wenn ich aber jetzt DISPLAY 4000 ausführe, dann wechseln manchmal die Inhalte, was eigentlich nicht sein sollte. Mit meinem eigenen KC funktioniert das auch alles problemlos und beim eigentlichen Eigentümer konnten wir den KC so auch als Verursacher einkreisen.
Ich habe alle Signale soweit mit dem Oszi und Logik Analyzer angeschaut und konnte keine Probleme feststellen. Eine Sache bringt eine Behebung des Problems: Entferne ich den D12 auf der oberen Platine des KCs, der für die Modulkette verantwortlich ist, und lege eine Verbindung zwischen Pin 3 und 6, dann funktioniert der RAM Test problemlos. Am Timing kann es aber auch nicht liegen, beide KCs haben etwa 50 ns zwischen /MREQ und dem MEO Signal. Aber irgendwas muß in der Modulkettensteuerung sein. Ein Schreiben auf den RAM konnte ich aber bei DISPLAY nie erkennen - scheint also etwas anderes noch zu sein - eventuell Refresh. Im Grundgerät funktioniert der RAM-Test mit dem Modul jedoch ohne Probleme.
Vielleicht hat jemand von Euch noch eine Idee, was ich noch untersuchen könnte - ich sitze schon seit Tagen und finde das Problem irgendwie nicht. So was seltsames hatte ich aber auch noch nie.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
07.03.2021, 22:12 Uhr
PIC18F2550

Avatar von PIC18F2550

Was für ein Modul ist das.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
07.03.2021, 22:25 Uhr
schlaub_01



Das ist unabhängig vom Modul. Habe ein 64k Modul und ein 16k Modul getestet. Und die Module sind auch von mir und nicht vom Eigentümer des Problem-KCs.
Wie gesagt, mit jeweils einem anderen KC läuft ja alles.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
08.03.2021, 09:00 Uhr
PIC18F2550

Avatar von PIC18F2550

Anderer Busverbinder?
Was ist mit I/O, Module?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen

Dieser Beitrag wurde am 08.03.2021 um 09:01 Uhr von PIC18F2550 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
08.03.2021, 09:39 Uhr
schlaub_01



Nein, der Busverbinder ist von mir, ebenso wie der Busdriver. Wie gesagt, mit anderen KCs funktioniert ja alles. Es muß am Grundgerät liegen. Ich werde heute nochmal schauen, ob ich auf den Datenleitungen noch etwas sehe. Das ist der einzige Unterschied zum Grundgerät - beim Busdriver gibt es noch Inline-Widerstände. Wenn also da was gegentreiben würde, kann das im Grundgerät möglicherweise vom Modul ausreichend übertrieben werden, wärend die Serienwiderstände im Busdriver schon den Strom begrenzen. Allerdings funktioniert beim KC zu viel dafür...
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
08.03.2021, 12:36 Uhr
PIC18F2550

Avatar von PIC18F2550

Sind das dRAM Module?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
08.03.2021, 12:59 Uhr
schlaub_01



Ja M011 und M022.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
08.03.2021, 16:08 Uhr
PIC18F2550

Avatar von PIC18F2550

Kannst Du ein SRAM oder ROM Modul mal Testen?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
08.03.2021, 19:10 Uhr
schlaub_01



Hallo Tim,

ein ROM Module habe ich mal ausprobiert. Da kann ich stabil die Daten lesen. SRAM Modul habe ich leider nicht, aber da könnte ich was basteln. Ich habe mir mal mit einem geliehenen Logic Analyzer, der auch analoge Aufzeichnungen machen kann, die Datenleitungen mal beim Fehlerfall im RAM-Test mal angeschaut, aber die Pegel sind in Ordnung.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
08.03.2021, 21:01 Uhr
PIC18F2550

Avatar von PIC18F2550

Stimmt auch die REFSH Leitung?

Sram wähte gut.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
08.03.2021, 22:03 Uhr
Bert



Hallo Sven,

in solchen Fällen schreibe ich mir kleine Testprogramme, die eine bestimmte Aktion (Schreiben/Lesen/IO-Zugriff) permanent in einer Schleife ausführen.

Das Problem hier klingt für mich trotzdem nach einem Timing-Problem.
Wenn ich das richtig sehe, gehen im Grundgerät alle relevanten Signale direkt von der CPU auf den Expansionsport und es gibt nur in der D002 ein paar Treiber:

Die Laufzeiten sollte man sich vielleicht am Besten direkt an einem RAM-Chip anschauen (RAS,CAS,WR,Data).

Grüße,
Bert
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
08.03.2021, 23:01 Uhr
schlaub_01



Hallo Bert,

ja da suche ich ja auch gerade. Aber sieht von den Zeiten nicht so schlecht aus. Refresh ist zwar etwas knapp mit 560 ns, müsste aber trotzdem noch reichen. Ich habe eben noch nicht herausfinden können, ob es am Schreiben liegt oder am Refresh. Vermute aber mal eher am Refresh, denn das Schreiben komplett mit 0 und 1 vom RAMTEST3 scheint ja zu funktionieren, denn da wird ja auch zwischendurch noch auf den Programmspeicher zugegriffen, so daß die Signale auch mal wackeln.
Das Problem passiert eigentlich immer beim Einzelbit-Test. Da werden erst verschiedene Bitmuster geschrieben, mit Walking One and Zero und danach wird ein FF geschrieben. Dann erfolgt auf verschiedenen Adressen die Prüfung auf 0 (vom vorhergehenden Beschreiben mit 0) und da gibt es die Fehler. Es kippen auch nicht nur einzelne Bits, oft sind es auch mehrere. Wäre ja mal interessant, was in so einem DRAM passiert, wenn man nicht refreshed. Wohin kippen die Bits in diesem Fall?

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
09.03.2021, 08:47 Uhr
PIC18F2550

Avatar von PIC18F2550

Wo die hinkippen ist unterschiedlich aber sie kippen immer in eine Richtung.
Die Blockgröße ist Speichergröße / Refeshbreite.

das währen beim, U2164 mit 7Bit = 512 Byte.

Beachte ein Sprecher lesem wirkt wie ein Refesh auf dem Block.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
14.03.2021, 10:43 Uhr
schlaub_01



So, bin leider heute erst wieder zu neuen Tests gekommen. Seltsamerweise macht jetzt auch mein KC sporadische Fehler an der gleichen Stelle. Könnte mal jemand von Euch so nett sein und den Test in gleicher Konstellation machen? Also quasi M052 im Grundgerät mit einem beliebigen anderen Modul und ein M011 im Busdriver im Slot 10. Beim RAMTEST3 springt er bei mir immer mal mit einem Fehler beim Einzelbittest (E) raus. Das ist irgendwie schon sehr seltsam. Was mir aufgefallen ist- auf meinem RAM Modul sind russische DRAMs verbaut (RU5). Hat jemand eventuell ein Datenblatt von dem IC, welches etwas ausführlicher ist, als das was man so im Netz findet?

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
14.03.2021, 10:52 Uhr
PIC18F2550

Avatar von PIC18F2550

Hast du den Test mit einem SRAM Modul mal gemacht?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
14.03.2021, 10:55 Uhr
schlaub_01



Hallo Tim,

ich habe aktuell kein SRAM Modul.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
14.03.2021, 11:09 Uhr
PIC18F2550

Avatar von PIC18F2550

Dann musst du zwei Tests machen.

1. In Assembler eine Zelle mit 5Ah füllen, die selbe auslesen und einfach üner CAOS ausgeben.
Hier sollte auch das 5A erscheinen.

2. Aus dem CAOS eine Zelle mit 5A füllen, etwas warten und an schließend anzeigen lassen.

Den test mehrfach wiederholen.

Sollte das Ergebnis immer richtig sein so liegt kein Refesh Problem vor.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
14.03.2021, 11:15 Uhr
Enrico
Default Group and Edit


Das geht mit dem Testprogramm aber wesentlich einfacher....
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
14.03.2021, 11:29 Uhr
schlaub_01



Assembler habe ich leider wenig Erfahrung. Ich habe es mal mit Basic probiert und das Modul in den 4000er Bereich gelegt. Dann habe ich die Adresse 17000 einmal beschrieben und mehrfach nacheinander ausgelesen. Mit Basic sind da ja auch genug lange Zeiten zwischen den Zugriffen. Nach einiger Zeit kippt dann 0x5A auf 0xFF.

Viele Grüße,
Sven.

Nachtrag: Gegenprobe ohne D12 auf der Aufsatzplatine mit verbundenen Pins 3 und 6 (direkte MEO Verbindung) funktioniert der Test bestens. Es muß als ein mehr als knappes Timing sein. Komisch, daß das noch nie so aufgefallen ist.

Dieser Beitrag wurde am 14.03.2021 um 11:35 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
14.03.2021, 11:38 Uhr
kaiOr

Avatar von kaiOr

Hatte damals ähnliche Probleme bei meinem Turbo-KC, eine Batterie schneller GALs hatte einzelne CPU-Signale emuliert. Deren Flanken waren zu hart, so das im D002 eine Art Burst ankam im D001 aber alles problemlos lief.

Könntest mal testweise 1nF zw. /MREQ der CPU und GND hängen.

Dieser Beitrag wurde am 14.03.2021 um 11:42 Uhr von kaiOr editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
14.03.2021, 15:15 Uhr
PIC18F2550

Avatar von PIC18F2550

Es kippt aber nicht wieder Zurück?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
14.03.2021, 15:57 Uhr
PIC18F2550

Avatar von PIC18F2550

Laut Stromlaufplan wird das Refesh Signal (RAS) wird direkt aus dem /MERQ gebildet.

Hast du das M011 in der D002 auch in den Schächten 8 und C getestet?

Es besteht durchaus die Möglichkeit das die Datenbustreiber mit einem Falschen DIR Signal angesteuert werden. (DIR2, DIR3)

Sollte es auf alle 4 Schächten nicht gehen kommt noch DIR1 hinzu.

Kanst Du das Modul in allen Schächten testen?
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
14.03.2021, 18:36 Uhr
schlaub_01



Auch in den anderen Schächten gibt es das Problem, aber wie gesagt, der Busdriver selber war nicht das Problem, der ist von mir.
Ich habe jetzt unter Basic auch nach dem Schreiben des Wertes eine Pause gemacht und dann ist auch schon der erste gelesene Wert auf 255 gekippt. Also scheint das wirklich ein Refresh Problem zu sein, aber mit dem Analyzer sehe ich immer 560 ns CAS Zeit und mit dem langsamsten RAM müsste laut Datenblatt eine Zeit von 285 ns ausreichen. Das ist schon echt seltsam. Nur seltsam, daß das MEO Signal so einen Einfluß hat und wenige ns weniger schon wieder ausreichend sind. Wäre wirklich super, wenn einer den RAMTEST3 bei seinem Busdriver mal ausprobieren könnte.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
023
14.03.2021, 20:46 Uhr
PIC18F2550

Avatar von PIC18F2550

Kanst du mal ein Bild von RAS und CAS vom dRAM und CLOCK und M1 über mehrere zugriffe hier reinstellen?

Wenn du das MEI und MEO mit einfangen könntest wäre besser.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
024
14.03.2021, 20:59 Uhr
schlaub_01



Hallo Tim,

hier die Aufzeichnung beim RAMTEST3 Einzelbittest. Zuerst wird der Wert geschrieben und dann gelesen. Aber das funktioniert ja alles noch. Erst später wird auf verschiedenen Adressen nur zurückgelesen. Die Signale sehen aber genauso aus. Da ist kein Unterschied feststellbar.




Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
025
14.03.2021, 21:37 Uhr
PIC18F2550

Avatar von PIC18F2550

Du hast recht das sieht gut aus.

Was noch interessant währe ist die Muxer Steuerung.

Kritisch währe das Lesen wenn die Umschaldung der RAS auf die CAS Adresse zu spät erfolgt.

Schau mal wie sich D17 pin 2 / 4 im RAS/CAS so machen.
Da werkelt auch noch ein C23 mit 100pF rum.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
026
15.03.2021, 09:40 Uhr
maschinist58



hallo ich würde auch gern eine platine m021 nehmen

sorry falscher beitrag !!!!!

Dieser Beitrag wurde am 15.03.2021 um 09:46 Uhr von maschinist58 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
027
15.03.2021, 17:59 Uhr
schlaub_01



Aber die Umschaltung von RAS auf CAS dürfte ja für das Refresh keine Rolle spielen, da Resfresh im RAM Modul ja das CAS blockiert. Außerdem müsste sich das Problem ja dann auch im Grundgerät zeigen. Ich nehme heute mal noch ein paar Signale mit einer (hoffentlich) funktionierenden Konfiguration auf.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
028
15.03.2021, 18:46 Uhr
PIC18F2550

Avatar von PIC18F2550

RD und WR haben unterschiedliche RAS breiten.
Es besteht die möglichkeit das auf einer anderen Adresse gelesen wird als geschrieben wurde.
Die entsprechenden Adressen müssen vor RAS bzw. CAS stabil anliegen.
Das Fehlerbild ist das gleiche wie ein Refreshfehler.
Mach mal eine Aufnahme von RAS, CAS und den beiden Steuersignahlen vom Adressmuxer.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
029
15.03.2021, 20:33 Uhr
schlaub_01



so, noch die gewünschte Aufnahme, aber sollte auch passen:


Was mir mit meinem KC noch aufgefallen ist, daß ich ab und zu die gleichen Probleme bekomme, wenn ich meinen Busverbinder mit Flachbandkabel benutze. Auch die Idee vom Kai mit dem Kondensator am /MREQ läßt den Test ein Stück weiterlaufen, bringt dann aber später wieder Fehler. Die ganze Sache scheint irgendwie extrem empfindlich zu sein. Aber die Signale sehen ja nicht so schlecht aus. Sehr seltsame Sache. So lange habe ich mich auch noch nie festgebissen, aber mich interessiert hier die wirkliche Ursache, die ja wirklich am KC liegen muß, denn beim Eigentümer des KCs lief der Test ja mit einem anderen KC und den gleichen Modulen, Busverbindern und Busdriver durch.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
030
15.03.2021, 21:52 Uhr
Enrico
Default Group and Edit


Schau doch mal wie die Wait-Zyklen im Bustrteiber eingestellt.
Ev. sollte der Rechner da wenigstens /M1 drin haben, oder auch gleich bei RAM-Zugriffen.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
031
15.03.2021, 21:56 Uhr
PIC18F2550

Avatar von PIC18F2550

Das signal am Pinn 3 kommt etwas zu früh.
Signallaufzeiten können dazu führen das das MERQ zu früh aktiviert wird.
In den anderen Modulen wird der MERQ mit einem D-FF verzögert.

Schau mal nach den C23 ob der taub ist.
Mach mal einen 2 rein.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
032
15.03.2021, 22:10 Uhr
schlaub_01



Die Wait Zyklen waren auf /M1 eingestellt. Ich habe die mal auf alle Zugriffe umgestellt, aber das bringt keine Besserung. In den Zeitdiagrammen sieht man die Verlängerung beim Lesen und Schreiben, aber das Wait wirkt sich nicht auf die Refresh-Zyklen aus, da dort das MEI auf low liegt.

Viele Grüße,
Sven.

Dieser Beitrag wurde am 15.03.2021 um 22:31 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
033
15.03.2021, 22:15 Uhr
schlaub_01



Hallo Tim,

dann müsste das Problem ja an allen meiner M011 Module sein. Pin 4 muß auch eher als Pin 2 kommen, denn da ist ja noch der Inverter drin. Die RAS Adresse wird ja mit der fallenden Flanke von RAS aktiviert und an der Stelle ist da ja stabil. Du mußt ja noch davon ausgehen, daß eine zusätzliche Verzögerung noch bis zum Ausgang vom D17 dazukommt. D.h. am RAM werden die Adressen noch später umgeschaltet. Das passt schon so. Funktioniert ja im Grundgerät auch perfekt. Die RAS Adresse wird ja direkt durch MREQ gebildet, da gibt es keinerlei Abhängigkeiten, weder von MEO noch REFRESH.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
034
16.03.2021, 13:43 Uhr
PIC18F2550

Avatar von PIC18F2550

Nein muss nicht.

Alle Bauteile haben unterschiedliche Laufzeiten.

Um das zu Kompensieren wurdem häufig Kondensatoren in die Signalleitungen eingesetzt.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
035
16.03.2021, 20:35 Uhr
schlaub_01



Also, weder 220pF noch 330pF brachten eine Änderung des Problems - mit den 330pF habe ich jetzt zusätzlich 50ns Verzögerung am Pin 2 vom D17.

viele Grüße,
Sven.

Dieser Beitrag wurde am 16.03.2021 um 20:35 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
036
16.03.2021, 21:42 Uhr
PIC18F2550

Avatar von PIC18F2550

Ok da fällt mir erstmal auch nichts weiter ein.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
037
16.03.2021, 21:51 Uhr
schlaub_01



Geht mir genauso ;-)
Mir unbegreiflich ist, daß ohne den MEO IC D12 und direkter Brücke alles läuft. Das MEO Signal hat mit dem Refresh ja eigentlich nichts zu tun, denn das RAS geht ja direkt vom MREQ Signal aus. Ich habe auch nochmal alle Verzögerungszeiten mir angeschaut und das passt perfekt. Etwa 10-15 ns Durchlaufzeiten typisch pro Gatter. Das MEO dürfte ja eigentlich auch gar nicht so ein knappes Problem sein, denn jedes Modul bringt ja im Prinzip auch nochmal eine Verzögerung mit und dadurch wird am UND Gatter D12 ja so lange das MEO nicht High, bis alle Module mit ihren MEO Signalen ja auf High gehen.
Da ist bestimmt noch ein anderes Signal, was ich jetzt nicht so vordergründig auf dem Schirm habe. Aber manchmal sieht man den Wald vor lauter Bäumen nicht.
Trotzdem vielen Dank für die Unterstützung - ich bin ja für jede Idee dankbar.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
038
17.03.2021, 20:35 Uhr
ambrosius



Hast Du mal mit dem Oszi auf Reflektionen bzw. Spikes auf dem Bus gesucht? Könnten vielleicht auch die Ursache sein. Ist aber nur so eine Idee. Ich hatte das mal auf einem überdimensionalen K1520-Käfig.
--
viele Grüße
Holger
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
039
22.03.2021, 19:38 Uhr
schlaub_01



Hallo Holger,
Dein Hinweis war richtig. Insgesamt sehen die wichtigsten Signale, direkt an der CPU gemessen, nicht gerade wie im Bilderbuch bzw. nach dem Datenblatt aus. Das Read Signal war am schlimmsten betroffen und hat viele kleine Spikes nach Low, aber auch extreme Überschwinger nach High, bis zu 5,5V. Wenn ich eine kleine Kapazität (da reichen 40pF) nach Masse lege, sieht das Signal viel besser aus und der RAMTEST im Busdriver läuft durch. Man sieht auch schon wenn man nur ein Modul steckt, daß sich das Signal ansonsten extrem verändert. Ich vermute mal, daß es irgendwo eine Reflektion gibt, die Probleme verursacht. Jetzt läuft auch mein selbstgebastelter Bus Connector mit normalem Flachbandkabel ohne Probleme mit meinem KC.
Aber warum das genau bei dem KC so extrem auftritt und scheinbar bei anderen nicht, das beschäftigt mich trotzdem. Im Grundgerät hat man ja auch nach dem Read einen Schmitt-Trigger IC eingesetzt, im Busdriver sind da aber noch zusätzliche Serien-Widerstände vor den Buffern. Sehr seltsam...

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
040
22.03.2021, 19:57 Uhr
ambrosius



Habe jetzt nicht alles noch einmal durchgelesen:
- sind die Versorgungsspannungen sauber? Nicht, daß von da irgendetwas mit reinkommt.
- Schwingt evtl. etwas in diesem KC? Oder es wird beim Betrieb etwas zum schwingen angeregt?
Sind nur ein paar Ideen dazu.
--
viele Grüße
Holger
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
041
22.03.2021, 21:06 Uhr
schlaub_01



Ja, hatte ich auch schon alles im Verdacht, aber sieht gut aus. Hatte sogar mal ein Labornetzteil dran, um Probleme vom Netzteil auszuschließen. Masse hatte ich auch nochmal direkt vom Netzteil auf die obere Platine gezogen, aber das brachte auch nichts.
Aber so im direkten 1:1 Vergleich mit einem meiner KCs sehen die Signale nicht anders aus. Betrifft ja auch wirklich nur das M011 im Busdriver. Der KC Eigentümer hatte auch noch 256k Module, die problemlos liefen.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek