Es handelt sich um einen Toellner-Generator 7706. Das Gerät läuft, die Spannungen sind alle da. Der Abgleich ist ok bis zum Sweep-Board. Da klemmt es nun leider. Normalerweise müsste bei Sweep eine Frequenz von 10kHz angezeigt werden - die man dann mit dem Trimmer auf der Platine abgleicht. Die tatsächlich angezeigte Frequenz liegt Faktor 10 daneben. Ein Abgleich per Trimmer schlägt fehl. Die Funktion der Karte ist gestört. Es ist die Frage ob das selbst repariert werden kann oder nicht. Hier ein Plan der Karte. Im Gerät gibt es einen Mikrocontroller der diese Karte anspricht. U602 ist ein Xilinx-Baustein (mit Programmieranschluß X600?). Der Karte wird die Start-Frequenz, die Stop-Frequenz, die Periodendauer und die Betriebsart mitgeteilt. Es kann dann gestartet und angehalten werden. Die Karte läuft also weitgehend autark und hat einen eigenen Speicherbaustein U607. Rechts im Bild sind 2 DA-Wandler, die die Steuer-Spannung für den Sweep aufbereiten. Der untere hängt über R611 an der 5V-Referenzspannung REF. 8bit bestimmen grob den Bereich, den dann der obere 12bit Wandler jeweile feiner unterteilt. Zusammen sind das also 20bit. Der obere OP-Amp U611 liefert das Sweepout-Signal. Die Platine scheint Kommunikationsprobleme zu haben. Der Dialog mit dem Hauptprozessor scheint gestört. Im Display steht bisweilen Unsinn. Mit der Sweep-Platine aus einem Zweitgerät geht es. Es fragt sich was defekt ist. Ich hatte das board das sehr häßlich mit einem Lack überzogen war mit Isopropylalkohol auf der Rückseite abgewaschen. Ob dabei statische Aufladung möglich war - keine Ahnung. Funken spürte ich keine. Die Spannungen müssten da sein. Das Gerät läuft ja sonst. Wie findet man hier einen Fehler?
Angehängte Dateien:
-
sweep.png
220 KB
Angehängte Dateien:
-
P1000615_small.jpg
370 KB -
P1000621_small.jpg
250 KB -
tastenabfrage.png
34 KB -
stecker_tasten.png
9,6 KB
hier Fotos von der Platine. Der große Baustein ist U602 (Xilinx). Dieser übernimmt die Kommunikation zur CPU im Generator, den Zugriff auf den Speicher U607 und die beiden DACs U608 und U609. Auf manche Eingaben zum Sweep reagiert das Gerät falsch oder gar nicht. Der Fehler dazu muss auf der Platine liegen - denn mit einer Austauschplatine geht es. Zum Bedienen gibt es Tasten "Start", "Stop", "Manual", "Sweep", "lin/log". Siehe tastenabfrage.png. Über Stecker X7 geht das zur Prozessorplatine. Der Mikrocontroller U10 (80C552) verarbeitet das und kommuniziert mit dem Sweepboard. Wie sich die Funktion genau aufteilt zwischen U10 und dem Xilinx-Baustein U602 auf der Sweepplatine weiß ich leider nicht. Vermutlich schickt U10 Kommandos an U602 und dieser macht was draus. U602 legt Daten in seinem eigenen RAM auf der Sweep-Platine ab und wickelt damit den Sweep ab. Über die Tasten soll man "Start" und "Stop"-Frequenz eingeben können. Anfangs sollte Start=1kHz sein und Stop=10kHz. Beide standen auf ca 1kHz. Die Einstellung klappt nicht wie gewünscht. Teilweise wird Mist im Display angezeigt. Manchmal reagiert das Stellrad scheinbar nicht. Man sieht nicht was innen passiert. Es ist mir nun gelungen Start auf 33mHz und Stop auf 100mHz zu stellen.
Es gelingt manchmal "Start" im Display zu verändern und dann gelingt es irgendwann auch "Stop" zu verändern. Nur merkt er sich dann das eine nicht. Wenn man zurückschaltet ist der alte Wert weg. Die Bedienlogik erscheint gestört. Am Ausgang erscheint manchmal das was bei "Stop" angezeigt wird und manchmal das was bei "Start" gemacht wird. Es gelingt mir nicht einen Sweep von 1-2kHz einzustellen. Die mHz sind schwer auf dem Oszilloskop zu kontrollieren.
Kondensatoren sind wenige auf dem Board - jeweils 10uF 63V bei +-12V und 5V. Die Spannungen im Gerät scheinen ok.
Der Xilinx XC2064-FPGA kam 1985 in "115um-Technologie" mit 1000 Gattern als das erste kommerziell nutzbare feldprogrammierbare Gatearray: "Xilinx co-founders Ross Freeman and Bernard Vonderschmitt invented the first commercially viable field-programmable gate array in 1985 – the XC2064" "1985 ‐ Xilinx XC2064 – 115 µm technology and 1000 gates" Heutige FPGAs haben bis über 1 Mio Gatter. Da sollte das alte Teil wohl noch etwas einfacher zu durchschauen sein. Leider habe ich damit keinerlei Erfahrung. Vielleicht liegt der Fehler ja nicht ausgerechnet an diesem Teil.
:
Bearbeitet durch User
Eine µC / FPGA Platine, die nicht richtig läuft zu reparieren ist ausgesprochen schwer. Das Problem scheint ja bei der µC-Funktion zu liegen. Wenn die Versorgung in Ordnung ist, ist kaum noch was zu machen. Das ist eher etwas für einen Komplett-austausch. Die Frage ist höchstens noch, ob man die Sweep-funktion braucht und der Ersatz lohnt. Moderne Generatoren auf DDS Basis sind ggf. nicht mehr so teuer und in vieler Hinsicht besser.
"115um-Technologie" - wenn das stimmt sollte es deutlich robuster und unempfindlicher sein als die winzigen Strukturen die man heute kennt. Daher vermute ich momentan daß dieses Teil wohl eher nicht defekt sein wird. Der Pinabstand ist großzügig. Man könnte es sogar in einen Sockel setzen.
Ulrich H. schrieb: > Eine µC / FPGA Platine, die nicht richtig läuft zu reparieren ist > ausgesprochen schwer. das vermute ich auch. Es gibt ein paar Stellen wo man versuchen kann etwas zu messen. Es ist wohl eher als Lernobjekt zu sehen. Wirtschaftlich ist so eine Suche sicher nicht. Die Bedienung ist halt recht einfach gehalten. Ein Knopf für "Startfrequenz", einer für "Stopfrequenz", einer für Betriebsart "Mode", einer für Periodendauer, einer für Lin/Log. Das Gerät kann 30Vss. Die meisten heutigen DDS können das nicht. Unterlagen dazu gibt es meist auch nicht. Reparierbar also wohl eher nicht. Es sind dann wohl eher Wegwerfgeräte. Diese Philosophie gefällt mir nicht. Lieber lerne ich etwas und versuche zu verstehen. Vermutlich kann man den Baustein auch auslesen? So eine Art Schnittstelle scheint ja dran.
Ulrich H. schrieb: > Die Frage ist höchstens noch, ob man die Sweep-funktion braucht gerade diese Funktion wollte ich eigentlich nutzen. Der 8551-Generator bis 50MHz hat diese leider nicht.
Ulrich H. schrieb: > Komplett-austausch das wäre denkbar. Fragt sich ob jemand so ein Teil hat - ein Ausschlachtgerät? Keine Ahnung was das kostet. Ersatzteile können teuer sein.
hier ist ein Datenblatt des FPGA: http://www.datasheetarchive.com/dlmain/Datasheets-8/DSA-154578.pdf
Die Bedienung über die Tasten sollte eher mit der µC Platine zusammenhängen. Die gezeigte Platine sollte nur das umsetzen der Rampen erledigen. Viel mehr sollte in so einen alten FPGA nicht reinpassen. Ein möglicher Zusammenhang zwischen der Sweep Platine und den Problemen bei der Bedienung könnte eventuell über Signalstörungen kommen: Die Platine scheint eine Menge Schieberegister als eine Art Porterweiterung zu nutzen. Wenn das dann über mehrere Platinen geht, könnte ggf. die Signalqualität (für so etwas wie das Taktsignal) kritisch werden. Ein Punkt wäre da auch noch die Steckkontakte und ggf. Lötstellen an den Steckern. Auf der Unterseite sieht es da in der Mitte des rechten Steckers etwas nach einem Wisker oder Kratzer aus. Funktioniert denn die Einstellung der Start/stop Frequenzen wenn die Sweep Platine ganz fehlt ?
Ulrich H. schrieb: > Funktioniert denn die Einstellung der Start/stop Frequenzen wenn die > Sweep Platine ganz fehlt ? wenn die Platine fehlt kommt ein Error 05. Ansonsten ist das Verhalten genauso konfus wie mit Platine. Es ist so als ob die Platine tot ist. Der Quarzoszillator läuft - 10MHz. Die Kommunikation geht auch zumindest so weit um den Fehler 05 zu vermeiden. Ganz kaputt kann das FPGA also nicht sein.
Ulrich H. schrieb: > Wenn das dann über mehrere Platinen geht, könnte ggf. die > Signalqualität (für so etwas wie das Taktsignal) kritisch werden. Es gibt auch die CPU-Platine - mit dem Motherboard über ein 40-pol-Flachbandkabel verbunden. Die CPU scheint korrekt Zugriff auf das Motherboard zu haben. Die Relais dort werden angesprochen. Der Selbsttest ist ok. Der automatische Abgleich hat geklappt, wobei auch das steckbare Triggerboard mit eingebunden worden ist. Keine Fehlermeldung dabei. Es scheint so als ob die Verbindung von der CPU zum Motherboard ok ist. Die Stecker auf dem Motherboard zur Sweep-Platine scheinen auch ok. Jedenfalls hat die andere Sweep-Platine problemlos gearbeitet. Bleiben die Stecker auf der Sweep-Platine selbst. Der "Whisker" scheint ein kleiner Kratzer zu sein. Der Widerstand zwischen dem unteren und oberen Pin lag um ~30kOhm. Kein Kurzschluss.
Hallo, ich würde als erstes Mal wieder die Frequenz ins Auge fassen. Da ist ein Quarz drauf. Schwingt der an und hat der die richtige Frequenz? Wenn die Timings nicht passen wirst du auch keine richtige Funktion bei deiner Schnittstelle zu µC und so weiter haben. Bei dem Poti wo du die Frequenz einstellen kannst. Haben da die Bauteile außenrum noch die richtigen Werte (nicht das ein C kaputt ist)? Das könntest du messen. Falls da nichts auffälliges ist, dann wird es wilder! Gruß, Jens
Angehängte Dateien:
-
sweep_bauteile.png
37 KB
Jens schrieb: > ich würde als erstes Mal wieder die Frequenz ins Auge fassen. ok. > Da ist ein Quarz drauf.. richtige Frequenz? es sind stabil 10MHz zu messen. Beidseits sinusförmig - in etwa gleiche Amplitude. > Wenn die Timings nicht passen wirst du auch keine richtige Funktion bei > deiner Schnittstelle zu µC und so weiter haben. klar. > Bei dem Poti wo du die Frequenz einstellen kannst. Haben da die Bauteile > außenrum noch die richtigen Werte (nicht das ein C kaputt ist)? Danke für den Hinweis Jens. > Das könntest du messen. Das habe ich gemacht. Ein ausgeprägter Kurzschluss an den C's ist nicht zu finden. Manche Cs liegen ja parallel zu ICs. Da wundert es dann nicht wenn das Ohmmeter 18.6k oder 24k zeigt, trotz Einstellung niedriger Mess-Spannung. Der Wert über C608 liegt bei 13kOhm. Da ist ein AD706JR. Das 2.2k-Poti hat 1.12k in Mittelstellung. Scheint ok. Hier zur Orientierung der Bauteilplan. > Falls da nichts auffälliges ist die 3 Elkos könnte ich tauschen. Je 10uF. Bei der jüngeren Platine war einer ausgelaufen und hatte eine Leiterbahn und einen Widerstand zerstört. > dann wird es wilder! es muss einen Grund geben daß das Board nun spinnt. Das lief ja mal. Ich lötete nur 2 Drähte ab und entfernte die hässlich schrumpelige Schicht auf der Platinenrückseite mit Tempotaschentuch und Alkohol. Sind die Teile nun etwa besoffen? Gruss, Matthias
Die Gezeigte Platine sollte nicht so direkt für die Bedienung der Tasten und des Display verantwortlich sein. Wenn überhaupt dann nur indirekt über Störungen, die auf den µC Platine zurückwirken. Leider wird es schwer sich die Signal anzusehen: man wird wohl eine DSO benötigen, denn die Signale sind eher nicht einfach periodisch. Außerdem kann ggf. der Tastkopf schon merkliche Rückwirkungen haben, wenn man nicht aufpasst. Ein wichtige Signale wären Pin 10 und 11 am Stecker X601. Ein bisschen mehr zum Aufbau wäre nicht schlecht. Ist der Stecker( X601) mit den Digitalsignalen so eine Art digitaler Backbone, mit mehr Platinen parallel ?
Ulrich H. schrieb: > Die Gezeigte Platine sollte nicht so direkt für die Bedienung der Tasten > und des Display verantwortlich sein. Wenn überhaupt dann nur indirekt > über Störungen, die auf den µC Platine zurückwirken. ja. Sieht so aus. Das Gerät spinnt ohne die Platine so wie mit. > Leider wird es schwer sich die Signal anzusehen: man wird wohl eine DSO > benötigen, denn die Signale sind eher nicht einfach periodisch. da habe ich leider nichts. Fragt sich welche Bandbreite da genügen würde. Einsteigergeräte schaffen keine 100MHz. Steile Flanken werden dann verzerrt dargestellt. > Außerdem kann ggf. der Tastkopf schon merkliche Rückwirkungen haben, > wenn man nicht aufpasst. ich nehme einen Iwatsu-Tastkopf 10:1. Der sollte bis 350-400MHz gehen. > Ein wichtige Signale wären Pin 10 und 11 am Stecker X601. ok. Ja, da wäre ein DSO wertvoll. Oder ein Logikanalysator mit Speicher. Es macht wohl wenig Sinn dazu selbst etwas mit AVR aufzubauen. > Ein bisschen mehr zum Aufbau wäre nicht schlecht. Ist der Stecker( X601) > mit den Digitalsignalen so eine Art digitaler Backbone, mit mehr > Platinen parallel? Es gibt mehrere Platinenplätze. Die Steckerbelegung ist jedoch nicht streng parallel. Vertauschen darf und kann man die Platinen nicht. Die Stecker haben jeweils andere Abstände.
Ulrich H. schrieb: > man wird wohl ein DSO benötigen angeboten wird gebraucht: Gould Digitaloszilloskop 4072, 100 MHz 175 EUR VB oder Oszilloskop HAMEG HM1507 150MHz Analog Digital Scope 299 EUR VB. Das wäre dann wohl wieder eine neue Baustelle.
Der Fehler wird dann eher nicht auf der hier gezeigten Platine liegen, sondern eher beim µC wo die Tasten und Anzeigen usw. daran sind. Um die Signale zu beurteilen bräuchte man wohl schon ein eher besseres DSO, so ab 50 MHz Bandbreite. Es ginge halt um die Qualität der Falnken, also so die ersten 10-50 ns. Ein Logic-analysator wäre ggf. hilfreich wenn man den FPGA komplett per revers Engeniering ersetzten will, aber kaum um die Qualität der Signale zu beurteilen.
Ulrich H. schrieb: > Der Fehler wird dann eher nicht auf der hier gezeigten Platine liegen, > sondern eher beim µC wo die Tasten und Anzeigen usw. daran sind. seltsamerweise lief die CPU mit den Tasten und Anzeigen scheinbar einwandfrei wenn die Sweep-Platine aus dem 7711A eingesteckt wurde (das Gerät das den Fehler auf der PLL-Platine hatte). Daher nehme ich stark an daß eben diese Sweep-Platine eine Macke hat und sonst nichts. Die Trigger-Platine habe ich noch nicht getestet. > Um die Signale zu beurteilen bräuchte man wohl schon ein eher besseres > DSO, so ab 50 MHz Bandbreite. Es gibt billige DSOs von Hantek. Die haben 100 MHz, 2 Kanäle und ggf. auch 16 Logikkanäle wenn man ~100 EUR mehr ausgeben möchte. > Es ginge halt um die Qualität der Falnken, > also so die ersten 10-50 ns. die Flanken kann ich sicher auch mit dem 2467-Oszi sehen. Wenn ein paar davon kommen sollte ich die sichtbar machen können. Bei eigenen Entwicklungen ließ ich immer eine Schleife rennen. Das ist hier nicht so einfach. Ich habe ja den Quellcode nicht. Vielleicht ist eine Testroutine in der Software. Da müsste ich bei Toellner fragen. Bei HP gibt es so etwas und bei Keithley auch. > Ein Logic-analysator wäre ggf. hilfreich > wenn man den FPGA komplett per revers Engeniering ersetzten will, aber > kaum um die Qualität der Signale zu beurteilen. das stimmt. Es ist halt die Frage ob die Flanken ein Problem haben. Das TXD-Signal klingt wie seriell. Der CCLK-Eingang am FPGA Pin 60 ist über R602=100 Ohm und C605=22pF verlangsamt. Der 80C552 kann nicht so sehr schnell diese Leitungen takten. Er hat einen 16MHz-Quarz. Am Port 4 dieser CPU sind 8 Jumper angebracht - möglicherweise für Testzwecke? Weitere 3 Jumper an Port 5. Leider weiß ich nichts Näheres darüber.
Angehängte Dateien:
-
cpu.png
99 KB
Hier ein Ausschnitt der CPU-Platine. Links sind die Jumper J1 bis J8 und J16, J17. J12 ist parallel zu einem Servicekontakt X2 links unten.
Ulrich H. schrieb: > so eine Art digitaler Backbone, mit mehr > Platinen parallel ? so eine Art Backplane ist es schon. Es sind auf der linken Seite hinter CPU-Platine und Anzeigenplatine das Sweepboard, das Triggerboard und rechts hinter der Endstufe das AM-Board und das PLL-Board. Nicht jede Platine bekommt jedes Signal.
Die Datenverbindung ist wohl seriell, ähnlich SPI: Pin 10 vom Stecker X601 als Takt, Pin 11 vom Stecker X601 als Daten, und separate Leitungen für die Wahl des Ziels (anders als bei SPI über Flanke): (z.B. Pin12 für U600, Pin15 15 von X602 für den FPGA, Signale vom FPGA für U605 und U606). Von der Funktion ist es wohl so, dass der 8 Bit DAC ein Muster aus dem Speicher (RAM) Ausgibt, das zuvor da reingeschrieben wurde. Der 12 Bit DAC wird wohl langsamer beschrieben, direkt über das Serielle Interface. Der 12 Bit DAC ist als Multiplizierter hinter den 8 Bit ADC geschaltet, dient also mit dem OP als eine Art variabler Verstärker. Dass die Sweep Platine die Bedienung stört ist schon komisch, aber vielleicht auch ein Ansatz um den Fehler zu finden. Mit der eigentlichen Bedienung und Anzeige hat die Seppe Platine nichts zu tun. Das müssen also irgendwelche Störungen sein, die den µC auf der anderen Platine aus dem Konzept bringen. Mögliche Wege, die mir einfallen wären da 1) die Versorgungsspannung 2) Störung von Taktsignalen, die auch noch für andere Teile genutzt werden (etwa das TX Signal) 3) Signale von der Platine, die zu häufig Interrupts auslösen. Das könnten eventuell die Leitungen 4 oder 14 am Stecker X601 sein. Das Taktsignal sollte man sich mal ansehen. Die RC Kombination vor dem FPGA zeigt ja schon das es ggf. kritisch sein kann. Um zu sehen ob die Erzeugung der Rampe klappt, wäre Der Ausgang des 8 Bit DAC wohl der richtige Punkt, also Pin 1 von U612.
Ja - das Protokoll ist seriell. Wenn ich auf "Sweep" drücke und dann auf "Start" und am Drehrad drehe wird etwas vom Hauptprozessor zum FPGA übertragen. Es sind am Pin 10 von X601 Impulspakete zu sehen - 20 Stück paarweise hintereinander. Die Paare haben eine Breite von je 9us und 11us Pause. Dann folgt 24us Pause bis zum nächsten Paar. Vermutlich sind das die Werte für den 12bit DAC. Das ganze Paket ist ~500us lang. Wenn man noch feiner auflöst kommt ein sauberer Takt mit 500ns Abstand zwischen den Flanken.
Beim Drehen des Gebers nach "Sweep", "Stop" kommt ein Impulspaket von ~1000us Länge. Das Display reagiert darauf nur leider oft nicht, obwohl die CPU ja weiß was sie da geschickt hat. Es ist so als ob da eine Art Rückmeldung fehlt. Irgendeine Rückmeldung muss funktionieren. Sonst käme ja wohl bei Einschalten eine Fehlermeldung daß die Platine nicht da ist.
Es ist schon klar das es synchrone serielle Daten sind: nur ist Pin 10 der Takt und Pin 11 sind die Daten: wohl von der CPU zur Sweep Platine und ggf. auch noch anderen Teilen (z.B. Tasten / Anzeige). So viel kann man aus dem 74HC... Teil der Platine erkennen. Der Pin 10 entspricht dem SPI Takt. Die Frage ist da vor allem ob die Flanken sauber sind, insbesondere die steigende (z.B. für HC595). Das Signal sollte von der CPU Platine kommen, jedenfalls nicht von der Sweep Platine. Der Unregelmäßige Takt spricht etwas für Software SPI und 9 bzw. 11 µs passt auch auch etwa zur µC Geschwindigkeit. 20 Pulse passt aber nicht zu den 74HC... Schieberegistern: da sollen es eigentlich immer vielfache von 8 Pulsen sein (U600 könnte auch 7 Bits (notfalls 5) gebrauchen). Ein Teil könnte in Richtung FPGA gehen, oder halt zu anderen Platinen. Ein Takt zwischen den Flanken klingt verdächtig - was ist damit gemeint. 500 ns sind auch zu kurz um von der CPU zu kommen. Wenn die Daten für den 12 Bit AD sind, dann wohl als 4 Pulse für den FPGA (um zu zeigen das es Daten für den AD sind) und 16 Pulse für die Daten. Das Ziel der Daten könnte man ggf. an den Pins der Schieberegister sehen. Erst einmal wäre eher die Frage ob die Digitalen Signal auch passen (Spannungsleven, Flanken, Spikes ?). Pin 8 sind Daten zurück, bei der Sweep Platine - vermutlich vor allen für Debug-Zwecke, denn das sind Daten aus dem RAM, die zuvor von der CPU kommen müssen. Der FPGA setzt nur irgendwie die Adressen dazu.
Eine Hoffnung wäre ja, dass nur eines der Schieberegister defekt ist.
Ulrich H. schrieb: > seriell: Pin 10 Takt, Pin 11 Daten: von CPU zur Sweep Platine ja. > Pin 10 SPI Takt. Die Frage ist da vor allem ob die > Flanken sauber sind, insbesondere die steigende (z.B. für HC595). ja, die Flanken sehen sauber aus. > Das Signal sollte von der CPU Platine kommen ja. Das ist so. > Der Unregelmäßige Takt spricht etwas für Software SPI und 9 > bzw. 11 µs passt auch auch etwa zur µC Geschwindigkeit. Das sind ganze Pulspakete. > 20 Pulse passt > aber nicht zu den 74HC... Schieberegistern: da sollen es eigentlich > immer vielfache von 8 Pulsen sein gut möglich. In diesen Pulspaketen mit dem beschriebenen Abstand stecken ja eine Menge einzelne Pulse. > Ein Teil könnte in Richtung FPGA gehen, oder halt zu anderen Platinen. > Ein Takt zwischen den Flanken klingt verdächtig - was ist damit gemeint. > 500 ns sind auch zu kurz um von der CPU zu kommen. die 80C552-CPU hat einen 16MHz-Quarz. http://www.nxp.com/documents/data_sheet/80C552_83C552.pdf Auf dem Stecker von der CPU zum Motherboard liegen Signale wie "TXD" und "Sweeprun". Der TXD-Pin der CPU P3.1 Pin25 geht über einen 74LVC2G125-Treiber zum Motherboard und dort dann wohl zum Sweepboard. Auf dem CPU-Board sitzt neben der CPU auch noch ein XC9572XL-7VQ64C im TQFP64-Gehäuse mit JTAG-Interface. Der wird wohl als Frequenzzähler genutzt. > Wenn die Daten für den 12 Bit AD sind, dann wohl als 4 Pulse für den > FPGA (um zu zeigen das es Daten für den AD sind) und 16 Pulse für die > Daten. Das Ziel der Daten könnte man ggf. an den Pins der > Schieberegister sehen. Erst einmal wäre eher die Frage ob die Digitalen > Signal auch passen (Spannungsleven, Flanken, Spikes ?). Der Level sieht ok aus. Die Flanken sehen steil aus. Spikes sind schon zu sehen oben und unten. Das kann auch an der Tastkopfmasse liegen die nun leider weit weg ist vorne an der BNC-Buchse. Besser wäre die viel kürzer anzuschließen. > Pin 8 sind Daten zurück, bei der Sweep Platine - vermutlich vor allen > für Debug-Zwecke, denn das sind Daten aus dem RAM, die zuvor von der CPU > kommen müssen. Der FPGA setzt nur irgendwie die Adressen dazu. Es ist die Frage ob das FPGA die Daten auch bekommt. Schieberegister ok? Und ob es die Daten versteht und korrekt rückmeldet. Da die andere Sweep-Platine ja einwandfrei arbeitet muss auf der defekten Platine etwas defekt geworden sein. Statische Aufladung? Beim Abwaschen mit Alkohol? Funken hatte ich keine bemerkt.
User schrieb: > Eine Hoffnung wäre ja, dass nur eines der Schieberegister defekt ist. ja. Das wäre leicht mit dem Heißluftfön wechselbar. Letztlich sind ja die Eingänge empfindlich. Auch das FPGA hat Eingänge. Die gehen ziemlich ungeschützt auf die Stecker. U600 und U601 könnte man tauschen. Das FPGA ist nicht so leicht zu ersetzen. Das ist auch programmiert. Die Strukturen scheinen jedoch recht groß zu sein. Daher könnte das ggf. robuster sein als die CMOS-Schieberegister.
Die CPU nutzt sowohl den RXD, als auch den TXD-Pin als Ausgang. Beide werden mit einem Treiber 125 gepuffert und landen auf der Sweep-Platine mit den Namen RXDW und TXD.
Die beiden Signale RDAN und WRAN werden von der CPU-Platine über das FPGA dort über je einen 125-Treiber gesendet. Das scheint eine Art Schreibe- und Lese-Signal für das FPGA auf der Sweep-Platine zu sein.
Die Signale ADR und TSIG kommen auch von der CPU-Platine über das FPGA dort über je einen 125-Treiber. Vielleicht ist ADR die Adressauswahl für das RAM auf der FPGA-Platine?
Das FPGA ist programmierbar, aber das Programm ist vermutlich irgendwo auf der CPU Platine gespeichert - jedenfalls nicht auf der Sweep Platine. Von daher wäre ein Austausch da noch möglich. Bein Schreiben der Konfigurationsdaten in das FPGA wird ggf. schon geprüft ob die Daten auf richtig ankommen - eine falsche FPGA Konfiguration könnte ja Schäden verursachen. Das dürfte dann auch der Punkt sein wo der µC die Platine erkennt und ggf. einen Fehler ausgibt. So viele Rückmeldungen vermute ich da nicht von der Sweep Platine zurück zum Rest. Das eine Schieberegister für die Rückrichtung kann nur begrenzt Informationen auslesen. Für viel mehr als einen Selbsttest taugt das nicht - das sollte also, wenn überhaupt, nur beim hochfahren passieren. Die Übertragung könnte man erkennen am Pin 1 von U610. Die Leitung 8 am Stecher X601 wird vermutlich noch anders genutzt - sonst wäre da nicht die Diode drin. Andere Leitungen für eine Rückmeldung wären nur die vom FPGA. Sonst sehe ich da auch nicht so viel Notwendigkeit für eine Rückmeldung - ggf. noch so etwas wie das Ende eines Sweeps. Insbesondere sollte das Einstellen der Werte an der Anzeige noch nichts direkt mit der Sweep Platine zu tun haben und da wäre ein Kontrolle nicht so wichtig - ein einfaches Schreiben der Daten sollte da reichen. Wo die Daten hingehen kann man in Grenzen an den Schieberegistern sehen (pin 12 beim hc595). Die Daten gehen erst einmal an alle und werden dann nur beim eigentlichen Ziel auch an die Ausgänge weitergeleitet - teils direkt, teils nur über das FPGA. Es muss ja nicht mal sein, das die ganzen Pulse für die Sweep-Platine sind.
Die Leitung ADR = Pin 12 an X601 ist die Auswahl für das Schieberegister U600. Das könnte so etwas wie eine Auswahl des Ziels sein - genaues wissen wir aber nicht. Jedenfalls sind da noch einige Bits ungenutzt. Die Konfigurations- Daten für das FPGA kommen über CCLK und DIN, mit einer Rückmeldung über D/_P
Die Analyse ist ja spannend. Danke Ulrich ! Da muss ich mal schauen was als nächstes günstig zu messen wäre. Es wäre auch denkbar einen AVR zu nehmen und mit dem etwas auszuwerten. Oder so einen Logikanalysator erwerben. Ein China-Ding? Manchmal ist es besser etwas günstig zu kaufen als selbst ewig herumzubasteln. Es sei denn man will dabei etwas lernen. Einen AVR hätte ich da. Ein paar byte RAM hat der ja auch. Schnell ist er auch. Dumm ist halt nur daß manchmal beim Drehen des Knopfs scheinbar etwas klemmt. Dann geht es wieder eine ganze Weile. Die andere Möglichkeit ist einfach mal ein paar der preisgünstigen chips auf Verdacht zu wechseln. Die kosten ja nicht die Welt. Entweder es geht dann oder der Fehler liegt dann am FPGA oder an der Leiterplatte selbst. Das alte FPGA wird wohl nicht so einfach zu bekommen sein. Auch ein RAM-Baustein ist noch auf der Platine.
Bei so einem spradisch auftrtendem Fehler besteht die reelle Möglichkeit das es ein Problem mit den Signalpegeln oder ähnliches ist. Der SPI - Takt als empfindlichstes Signal scheint aber schon mal OK. Das ist erst einmal was für ein Oszilloskop, um sich auch die anderen Signal anzusehen. Einen Logigkanalysator kann der AVR eher nicht gut ersetzen und ist da keine brauchbare Basis (ggf. sehr schlecht mit einem XMega). Wenn möglich will man relativ viel RAM haben, und eine relativ schnelle Anbindung zum PC (USB). Bei den China-Teilen müsste man mal sehen was es da gibt. Für einige Speziallfälle, wie das Abhöhren des SPI Bus könnte man den AVR eventuell nutzen. Das wäre dann so etwas wie ein SPI Sniffer - wegen des begrenzten RAMSs wäre auch da aber ein schnelles Interface zum PC hilfreich. Von der Idee halt Takt und Daten ans SPI Interface des AVR und dann mehrere der Chip-selekt (bzw. Strobe) Signale, etwa über einen Port und Pin Change abfragen. Wie man ggf. andere Paketlängen behandelt ist noch die Frage. Die Daten kommen dann mehr oder weniger direkt zum PC zur Auswertung. Eventuell findet man da ja auch schon einen Plan und SW im Netz - so abwegig ist die Anwendung nicht.
Ulrich H. schrieb: > Bei so einem spradisch auftrtendem Fehler besteht die reelle Möglichkeit > das es ein Problem mit den Signalpegeln oder ähnliches ist. Der SPI - > Takt als empfindlichstes Signal scheint aber schon mal OK. Das ist erst > einmal was für ein Oszilloskop, um sich auch die anderen Signal > anzusehen. das kann ich ja tun. Das Oszi habe ich ja. Leider weiß ich nicht ob der Fehler so sporadisch ist. Es scheint so als ob nicht alles tot ist auf der Karte. Bei der anderen Karte war das Problem ja dieser auslaufende Cap. Das Fehlerbild war chaotisch. Alles war weg nach Austausch von ein paar Teilen und Flicken dieser Leiterbahn. Ist die Frage was hier die Ursache ist. > Einen Logigkanalysator kann der AVR eher nicht gut ersetzen und ist da > keine brauchbare Basis (ggf. sehr schlecht mit einem XMega). ok. Ich hätte einen Arduino Nano 3 rumliegen. > Wenn möglich will man relativ viel RAM haben, und eine relativ schnelle > Anbindung zum PC (USB). leider ist das RAM nicht riesig. Besser als nichts jedenfalls. Externe RAMs sind halt langsamer. > Bei den China-Teilen müsste man mal sehen was es da gibt. Da gibt es erstaunlich billige Sachen wie z.B. dies: http://www.ebay.de/itm/Logic-Analyzer-24MHz-8CH-USB-Logic-Analyzer-/371047856017. Nicht mal 9.-. Ist halt die Frage was das taugt. Bauen kann man dafür nichts. > Für einige Speziallfälle, wie das Abhöhren des SPI Bus könnte man den > AVR eventuell nutzen. Das wäre dann so etwas wie ein SPI Sniffer - wegen > des begrenzten RAMSs wäre auch da aber ein schnelles Interface zum PC > hilfreich. Eine Idee wäre das was da gesendet wird byteweise alle z.B. 250ns ins RAM zu erfassen. Wenn das RAM voll ist zum PC schicken und dort dann anzeigen und dekodieren. Es ist natürlich recht begrenzt von den Möglichkeiten. Besser als das Analog-Oszi jetzt. > Von der Idee halt Takt und Daten ans SPI Interface des AVR > und dann mehrere der Chip-selekt (bzw. Strobe) Signale, etwa über einen > Port und Pin Change abfragen. Wie man ggf. andere Paketlängen behandelt > ist noch die Frage. Die Daten kommen dann mehr oder weniger direkt zum > PC zur Auswertung. so schnell sind die preiswerten Interfaces zum PC wohl nicht daß man da mit 250ns-Raster Bytes in Echtzeit übertragen könnte. > Eventuell findet man da ja auch schon einen Plan und > SW im Netz - so abwegig ist die Anwendung nicht. gute Frage. Logikanalysatoren gibt es sicher auch als Studienarbeit an einer Uni. Fragt sich ob so ein China-Teil für knapp 10.- nicht sinnvoller ist. Das ist wenigstens fertig. Der Versand dauert halt lange und die Beschreibung ist wenig aussagekräftig. Dieses Ding gibts in Finnland: http://www.ebay.de/itm/USB-Logic-Analyzer-8ch-24MHz-Limited-edition-/231071636948. Mit input buffer 74HC245. Main chip: CY7C68013A. Keine Ahnung wie groß der Speicher ist. Die Software gibt es hier: https://www.saleae.com/downloads. Die 34-Kanal-Version ist deutlich teurer: http://www.ebay.com/itm/331155858136.
Angehängte Dateien:
-
P1000679_data_small.jpg
5,4 KB
Hier das Signal an Pin 11 der Leiste X601. Es ist ein Pulszug. Negative Pulse. An Pin 5 der Leiste X601 kommt beim Drehen des Gebers ein negativer Puls von ~400ns Breite.
Bei ebay gibt's zahlreiche billige XC2064s. http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0&_nkw=xc2064&_sacat=0 Wieso nicht einfach mal ein paar davon kaufen und die testhalber tauschen? Da die Xilinx-Dinger SRAM-basiert sind, hat man da auch keine so dämlichen Probelme mit EEPROM-Auslesen wie bei den Altera-FPGAs Mit Heissluftlötstation und kräftig Flussmittel ist das auch keine so schwierige Sache. Das TC5565 RAM daneben gleich auch.
Tomate schrieb: > Bei ebay gibt's zahlreiche billige XC2064s. vielen Dank für den Hinweis ! 1.80 ist supergünstig. Der Versand aus den USA ist halt leider recht teuer. Der Zoll wird wohl auch zuschlagen? > Wieso nicht einfach mal ein paar davon kaufen und die testhalber > tauschen? gute Idee. > Da die Xilinx-Dinger SRAM-basiert sind, hat man da auch keine > so dämlichen Probelme mit EEPROM-Auslesen wie bei den Altera-FPGAs ok. > Mit Heissluftlötstation und kräftig Flussmittel ist das auch keine so > schwierige Sache. ja. Das müsste schon gehen. > Das TC5565 RAM daneben gleich auch. das hat derselbe Händler wie oben.
Bei 1,80 wird der Zoll nicht so viel ausmachen - das geht Prozentual, wenn überhaupt. Ein paar 10% machen da den Kohl nicht fett. Das Ram sollte kaum für den Fehler verantwortlich sein - das werden vom FPGA die Adresssen und das WE / OE Signal für generiert, und die Daten kommen per Schieberegister vom µC bzw. gehen zum ADC und Schieberegister für die Rückrichtung. Bei eine defekten RAM könnte man ggf. Glitches im Sweep erwarten, aber nicht viel mehr. Die Bedieunung sollte das nicht bereinflussen. Über Pin 8 von X601 bzw. besser Pin 9 von U610 könnte man sehen ob da überhaupt Daten zurück zum µC gehen - außer in der Selbsttestphase vermute ich eher nicht. Der Pegel am Pin 8 wäre aber auch interessant. Das sollte überwiegend high (4-5 V) sein, mit einigen Pulsen (auf etwa 0,8 V), wenn sich auf den anderen Platinen was tut. Negative Pulse würde ich eher nicht erwarten. Eigentlich sollten alles CMOS Pegel sein, also irgendwo zwischen 0 und 1 V für Low und 4-5 V für high.
Ulrich H. schrieb: > Bei 1,80 wird der Zoll nicht so viel ausmachen - das geht Prozentual, > wenn überhaupt. Ein paar 10% machen da den Kohl nicht fett. das dachte ich auch. Der alte 50MHz-Generator kostete 300$. Einfuhrabgabe US $77,82. Versand US $45,36. Bezahlt habe ich 238.15 EUR + 81.79 EUR Versand + Zoll. Ein altes Fluke überlegte ich. Da wäre die Einfuhr viel teurer als das Gerät selbst gekommen. > Das Ram sollte kaum für den Fehler verantwortlich sein ok. > Über Pin 8 von X601 bzw. besser Pin 9 von U610 könnte man > sehen ob da überhaupt Daten zurück zum µC gehen - außer in der > Selbsttestphase vermute ich eher nicht. siehe das Bild. So sieht das aus wenn ich am Geber drehe und Stop(?) gewählt habe. Vorne triggert das Oszi. Da ist ein kurzer Puls von 20ns nach unten zu sehen. Nach ~4us geht es low und bleibt ~2us low. Dann kommt eine Pause von ~12ms. > Der Pegel am Pin 8 wäre aber > auch interessant. Das sollte überwiegend high (4-5 V) sein, mit einigen > Pulsen (auf etwa 0,8 V), wenn sich auf den anderen Platinen was tut. das wird wohl ähnlich aussehen.
Angehängte Dateien:
Matthias W. schrieb: > Der Pegel am Pin 8 wäre aber auch interessant. hier das Bild von Pin8 X601. Auch das wiederholt sich nach ~12ms.
Ulrich H. schrieb: > Bei 1,80 wird der Zoll nicht so viel ausmachen Zum Warenwert wird der teure Versand hinzuaddiert und darauf dann die Abgabe berechnet. Da kommt schon was zusammen. Es kann sein daß beim Zoll ausgepackt wird und weitere Versandkosten entstehen. So was hatte ich auch schon mal.
Hier das Ergebnis der Widerstandsmessung an den FPGA-Pins mit einem DMM im 20kOhm-Bereich und Mess-Spannung <0.7V. Pin Wert [kOhm] 1 0 2 7,89 3 7,91 4 8,52 5 7,89 6 7,89 7 7,89 8 8,52 9 8,52 10 3,61 11 4,74 12 4,74 13 4,75 14 7,89 15 7,87 16 7,87 17 8,49 18 3,6 19 7,88 20 4,74 21 8,5 22 8,51 23 7,88 24 8,51 25 3,6 26 3,6 27 8,3 28 6,2 29 7,85 30 5,3 31 7,85 32 7,83 33 8,43 34 8,43 35 0 36 8,45 37 8,48 38 8,09 39 8,47 40 4,93 41 8,07 42 8,07 43 8,36 44 8,52 45 6,85 46 8,38 47 8,49 48 8,5 49 8,49 50 8,5 51 8,51 52 3,6 53 8,49 54 8,49 55 8,49 56 8,49 57 8,45 58 8,44 59 5,2 60 8,41 61 4,73 62 4,74 63 8,47 64 4,74 65 8,51 66 8,51 67 8,49 68 8,5
Die einzelnen Werte sind schwer zu beurteilen. Das hängt ggf. auch von der Schaltung im DMM ab, denn es sind ja keine Ohmschen Widerstände. Vielfach ist es halt auch der FPGA und 1-2 Logic ICs - die müssen auch nicht alle so gleich sein. So wirklich fällt mir da nichts auf - ein bisschen komisch ist vielleicht noch der Unterschied zwischen den Pins 40 und 41 bzw. 42. Das kann aber auch einfach eine andere Zusatzfunktion des Pins sein. Interessant wird es erst im Vergleich zur anderen Platine. Dabei sollte man auf die Polung achten - also selbe Leitung an GND.
Ulrich H. schrieb: > Interessant wird es erst im Vergleich zur anderen Platine. hier dazu die Werte:
1 | defekt ok |
2 | Pin Wert [kOhm] |
3 | 1 0 0 |
4 | 2 7,89 4,95 |
5 | 3 7,91 4,95 |
6 | 4 8,52 8,05 |
7 | 5 7,89 4,96 |
8 | 6 7,89 4,96 |
9 | 7 7,89 4,96 |
10 | 8 8,52 8,05 |
11 | 9 8,52 8,05 |
12 | 10 3,61 3,32 |
13 | 11 4,74 4,96 |
14 | 12 4,74 4,96 |
15 | 13 4,75 4,96 |
16 | 14 7,89 4,96 |
17 | 15 7,87 4,95 |
18 | 16 7,87 4,95 |
19 | 17 8,49 8,05 |
20 | 18 3,6 3,32 |
21 | 19 7,88 4,96 |
22 | 20 4,74 4,95 |
23 | 21 8,5 8,07 |
24 | 22 8,51 8,06 |
25 | 23 7,88 7,45 |
26 | 24 8,51 8,05 |
27 | 25 3,6 3,32 |
28 | 26 3,6 3,32 |
29 | 27 8,3 7,82 |
30 | 28 6,2 7,83 |
31 | 29 7,85 7,46 |
32 | 30 5,3 8,06 |
33 | 31 7,85 7,44 |
34 | 32 7,83 7,44 |
35 | 33 8,43 7,97 |
36 | 34 8,43 7,98 |
37 | 35 0 0 |
38 | 36 8,45 8 |
39 | 37 8,48 7,99 |
40 | 38 8,09 7,49 |
41 | 39 8,47 8 |
42 | 40 4,93 4,61 |
43 | 41 8,07 7,47 |
44 | 42 8,07 4,57 |
45 | 43 8,36 7,58 |
46 | 44 8,52 7,99 |
47 | 45 6,85 7,81 |
48 | 46 8,38 7,86 |
49 | 47 8,49 7,98 |
50 | 48 8,5 7,97 |
51 | 49 8,49 8 |
52 | 50 8,5 7,97 |
53 | 51 8,51 7,99 |
54 | 52 3,6 3,32 |
55 | 53 8,49 7,99 |
56 | 54 8,49 7,98 |
57 | 55 8,49 8 |
58 | 56 8,49 7,98 |
59 | 57 8,45 7,98 |
60 | 58 8,44 7,91 |
61 | 59 5,2 7,96 |
62 | 60 8,41 7,9 |
63 | 61 4,73 7,43 |
64 | 62 4,74 7,42 |
65 | 63 8,47 7,98 |
66 | 64 4,74 7,44 |
67 | 65 8,51 8,03 |
68 | 66 8,51 8,02 |
69 | 67 8,49 8,02 |
70 | 68 8,5 8,06 |
da sind teilweise deutliche Unterschiede. Siehe z.B. Pin 2,3,5,6,7,14,15,16,19.
:
Bearbeitet durch User
es sieht so aus als ob mit dem Bus DS0 .. DS7 etwas nicht in Ordnung ist. An diesem Bus hängen das FPGA (XC2064), U601 (HC164) links und der DA-Wandler U608 (AD7545) rechts oben.
:
Bearbeitet durch User
schauen wir die abweichenden Widerstandswerte an den FPGA-Pins zwischen dem defekten Board links und dem ok-Board rechts näher an. auffällige Abweichungen gibt es bei + Pin 2,3,5,6,7,14,15,16,19 = DS4,DS3,DS2,DS1,DS0,DS3,DS4,DS5,DS6 seltsam ist die Messung bei Pin 20 bzw. 61. Da sollte dasselbe Signal DS7 liegen. Bei der defekten Platine hatte ich gemessen 4.74 bzw 4.73kOhm. Bei dem heilen Board jedoch 4.95 und 7.43. Messfehler? Abweichung bei + Pin 28 Ladesignal zu U610 + Pin 30 Pin nicht im Plan zu finden + Pin 42 Rückführsignal Zeitbasis von U603B + Pin 45 D/P-Steuersignal Eingangspin + Pin 59 Clocksignal für U606 + Pin 61 + Pin 64
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.