Hallo zusammen, ich hoffe, hier liest noch jemand mit. Ich bin vom CTDO und habe mir dort einen Borg nach Tunix' toller Bauanleitung im CTDO-Wiki gebaut. Ich stehe jetzt allerdings vor einem Problem, dessen Debugging ich offenbar nicht wirklich auf die Kette bekomme. Daher wende ich mich an diese Liste hier. Ich habe zu Testzwecken und um auf einen gemeinsamen Nenner alles an einer vorkompilierten Labor-Firmware ohne seriellen Bootloader durchgeführt. Gleiches passierte aber auch auf einer selbstgebauten Firmware, auf der ich jeglichen Bus-Support und alle Spiele nicht mit eingebaut habe, weil ich momentan eh noch keinen Joystick besitze. Und zwar hängt sich mein Borg nach einer gewissen Zeit auf. Initial war diese Zeit so 30 Minuten, ich habe dann nach den Empfehlungen des Wikis einen Abblockkondensator eingelötet, seitdem kam es auch schon mal vor, dass der Borg auch mal gute 2 Tage durchgehend lief, bis er wieder irgendwo einfror. Bei welcher Animation genau ließ sich nie so wirklich vorhersehen, also nicht nur bei der Spirale oder dem Lagerfeuer, wie das Laborwiki vermutet. Teilweise friert der Borg auch in einem Zustand ein, in dem sämtliche LEDs abgeschaltet sind. Ich habe danach erstmal alle Lötstellen nochmal überprüft, und auch mal einen anderen Controller eingesetzt, im Verdacht, dass der irgendwie einen an der Klatsche haben könnte. Die Laufzeiten mit dem neuen Controller sind wieder um einiges kürzer, und bewegen sich irgendwo im Bereich um einer halben Stunde maximal. Wohlgemerkt, der Rest der Schaltung ist derselbe. Ich habe seitdem die Brownout Detection im Verdacht. Die Fuses sind auf 4,3V Brownout gesetzt, und ich nehme einfach mal an, dass das Netzteil das nicht richtig liefern kann. Obwohl ich bereits 2 Netzteile getestet habe - ein 5V 2,4A Netzteil, und dann ein 5V 3A Netzteil, ein Modell, was im CTDO-Wiki als geeignet angegeben wurde. Ich habe sogar mal mein Labornetzteil drangeklemmt, was nominell bis zu 5A liefern können soll, mit dem Resultat, dass die Borgware laufend neugestartet ist, bevor in der initialen Laufschrift das w von www.das-labor.org komplett zu sehen war. Ein weiteres Indiz für was auch immer ist die Tatsache, dass ich nach den Empfehlungen des Wikis mal das EEPROM nach einem Reset und einem Freeze ausgelesen habe, und dort nicht nur die erwähnten 0xFF drin stehen. Ich bin auf diesem Gebiet zwar noch ein ziemlicher Neuling, aber es scheint so, als sei der Dump in Sektionen unterteilt, die alle jeweils mit einer Folge anfangen, die ähnlich aussieht wie :20072000 und dann mehrere Bytes Daten kommen. Bei einigen Sektionen sind sämtliche darauf folgenden Bytes Fs, allerdings ist bei manchen Sektionen das letzte Byte ein anderer Wert. Ich habe zu guter Letzt mal die serielle Schnittstelle, bzw. die Shell dadrauf beobachtet, wenn ein Freeze passiert. Die letzten Meldungen, die ich da drauf bekomme, sehen wie folgt aus:
Command is too long. Dies kann sich je nach Lust und Laune der Technik auch noch ein paar mal wiederholen, inklusive Promptzeichen, bis dann zusammen mit der Animation auch die serielle Konsole komplett einfriert. Und das letzte Symptom: Der Einschaltcounter zeigt bei mir teilweise absurd hohe Werte an. Nach einem Reset des EEPROMs und eines funktionierenden Durchlaufs von guten 2 Tagen stand der Counter bei über 27000. Ich habe den Borg dabei nicht durchgehend beobachtet, aber das würde ja bedeuten, dass er alle 6-7 Sekunden neu gestartet haben müsse, was definitiv nicht der Fall ist. Auch der neue Microcontroller zeigt mittlerweile Einschaltcounts über 200 an, obwohl ich ihn vielleicht maximal 10-20 Mal neu gestartet haben dürfte. Ich habe Tunix gegenüber auf dem 33c3 erwähnt, dass es ja auch interessant sein könnte, zu gucken, wie der Borg reagiert, wenn ich mein Amateurfunkgerät mit nicht wenig Leistung, was daneben steht, mal diesbezüglich ausprobiere, aber ich möchte anmerken, dass ich das noch nicht getan habe, und das damit also nichts zu tun hat ;) Bis auf WLAN, Zigbee und ein paar 433MHz Funksteckdosen ist hier in der Wohnung nichts, was absichtlich Strahlung erzeugt, und ich gehe mal davon aus, dass die AVR gegen solche geringen Leistungen verhältnismäßig resistent sein dürften, bevor da irgendwelche Bits kippen. Ich bin mittlerweile mit meinen Ideen am Ende, und frage daher mal hier nach, ob solch ein Verhalten vielleicht schon mal irgendwo aufgetreten ist, oder ob noch Ideen existieren, wo ich den Hebel noch ansetzen könnte. Vielen Dank schonmal, und viele Grüße, ttk -- --- Before printing this email, think if it is really needed.
Hallo Tatonka, Am 04.01.2017 um 22:50 schrieb Simon Szustkowski:
Und zwar hängt sich mein Borg nach einer gewissen Zeit auf. Initial war diese Zeit so 30 Minuten, ich habe dann nach den Empfehlungen des Wikis einen Abblockkondensator eingelötet, seitdem kam es auch schon mal vor, dass der Borg auch mal gute 2 Tage durchgehend lief, bis er wieder irgendwo einfror. Bei welcher Animation genau ließ sich nie so wirklich vorhersehen, also nicht nur bei der Spirale oder dem Lagerfeuer, wie das Laborwiki vermutet. Teilweise friert der Borg auch in einem Zustand ein, in dem sämtliche LEDs abgeschaltet sind.
ist das Bild beim Freeze denn noch sichtbar? In dem Fall läuft zumindest der Timer-Interrupt noch, der das Zeilenmultiplexing macht. Ansonsten läuft die Borgware-2D eigentlich ziemlich stabil. Ich weiß von mehreren Wochen ;)
Ich habe danach erstmal alle Lötstellen nochmal überprüft, und auch mal einen anderen Controller eingesetzt, im Verdacht, dass der irgendwie einen an der Klatsche haben könnte. Die Laufzeiten mit dem neuen Controller sind wieder um einiges kürzer, und bewegen sich irgendwo im Bereich um einer halben Stunde maximal. Wohlgemerkt, der Rest der Schaltung ist derselbe.
Platinen sind nicht auszuschließen. Mehr Tipps als Lötstellen absuchen und bei Bedarf mit Flussmittel nachlöten kann ich Dir da nicht geben :( Im ungünstigsten Fall sind die Leiterbahnen beschädigt (Haarrisse, Produktionsfehler, etc.).
Ich habe seitdem die Brownout Detection im Verdacht. Die Fuses sind auf 4,3V Brownout gesetzt, und ich nehme einfach mal an, dass das Netzteil das nicht richtig liefern kann. Obwohl ich bereits 2 Netzteile getestet habe - ein 5V 2,4A Netzteil, und dann ein 5V 3A Netzteil, ein Modell, was im CTDO-Wiki als geeignet angegeben wurde.
Bei fehlerhafter Brownout-Detection stürzt der Borg16 ziemlich sicher bei der Spiralanimation ab. Wenn das unabhängig von der Animation passiert, liegt die Ursache vermutlich woanders. Du kannst ja mal einen Oszi an die Versorgungsleitungen des ATmegas klemmen (das sind die, an denen Du den Abblockkondensator angelötet hast) und schauen, was sich da so tut. Wenn die Spannungsschwankungen dort zu groß sind macht der Controller komische Dinge.
Ein weiteres Indiz für was auch immer ist die Tatsache, dass ich nach den Empfehlungen des Wikis mal das EEPROM nach einem Reset und einem Freeze ausgelesen habe, und dort nicht nur die erwähnten 0xFF drin stehen. Ich bin auf diesem Gebiet zwar noch ein ziemlicher Neuling, aber es scheint so, als sei der Dump in Sektionen unterteilt, die alle jeweils mit einer Folge anfangen, die ähnlich aussieht wie :20072000 und dann mehrere Bytes Daten kommen. Bei einigen Sektionen sind sämtliche darauf folgenden Bytes Fs, allerdings ist bei manchen Sektionen das letzte Byte ein anderer Wert.
Der Tipp im Wiki bezieht sich auf Situationen, in denen das originale Firmware-Image nicht mehr vorliegt. Memory Corruption kann sich dadurch äußern, dass im EEPROM oder im Flash an unbeschriebenen Bereichen vereinzelt andere Werte als 0xFF auftauchen (0xFF ist der Grundzustand bei EEPROM und Flash). Sicher ist das aber nicht. Was Du Dir da angeschaut hast, ist das Intel-HEX-Format, das entgegen des Namens kein reiner Hexdump sondern eine speziell formatierte Textdatei ist. Ich finde es einfacher, ein HEX- in ein Raw-Image zu konvertieren und dieses dann mit einem Hex-Editor zu betrachten: # avr-objcopy -I ihex -O binary MyImage.hex MyImage.raw Das Flash lässt sich so auslesen (direkt im Raw-Format): # avrdude -c usbasp -p m644p -U f:r:image.raw:r Das EEPROM lässt sich so auslesen (direkt im Raw-Format): # avrdude -c usbasp -p m644p -U eeprom:r:eeprom.raw:r Es werden ungefähr 170-180 Bytes im EEPROM benutzt, der Rest sollte 0xFF sein. Aber Du kannst es Dir auch einfacher machen. In Deinem Fall liegt das ursprüngliche Kompilat ja vor, mit dem Du ein Verify gegen den tatsächlichen Flash-Inhalt machen kannst: # avrdude -c usbasp -p m644p -U f:v:image.hex Dann weißt Du, ob die Bits tatsächlich verrotten.
Ich habe zu guter Letzt mal die serielle Schnittstelle, bzw. die Shell dadrauf beobachtet, wenn ein Freeze passiert. Die letzten Meldungen, die ich da drauf bekomme, sehen wie folgt aus:
Command is too long.
Die Fehlermeldung tritt auf, sobald der Zeilenpuffer voll ist. Kann sein, dass die Schnittstelle Zeichen erkennt, wo keine sein sollen, zum Absturz sollte das aber nicht führen. Wenn die Abstürze auch bei deaktivierter Shell auftreten, würde ich die Ursache woanders vermuten.
Und das letzte Symptom: Der Einschaltcounter zeigt bei mir teilweise absurd hohe Werte an.
Der Counter war schon immer buggy. Um das EEPROM zu schonen, gibt es einen Ringspeicher, damit nicht immer das gleiche Byte beschrieben wird. Leider verhält sich die Implementierung nicht sehr intelligent, wenn der Ringspeicher aufgebraucht ist, was dann zu absurden Zählerwerten führt. Ist bekannt, ich hatte aber nie den Nerv, den betreffenden Code zu sanieren. Gruß, Christian
Ahoi, nach einiger Zeit melde ich mich mal wieder. Das Problem ist nämlich immer noch nicht behoben, ich habe aber einige Maßnahmen getroffen, um das Problem weiter einzugrenzen. Vielleicht hilft dir die folgende Symptomatik ja beim Debuggen (mir nicht, ich bin mittlerweile restlos überfragt). Und zwar habe ich erstmal alle Lötstellen mit etwas frischem Lot mal nachgezogen, um kalte Lötstellen definitiv ausschließen zu können. Desweiteren bin ich jetzt im Besitz eines Labornetzteils, um auch ein flaky Netzteil ausschließen zu können. Dabei ist mir direkt der erste Bug aufgefallen: Das Netzteil hat auch eine Ampere-Anzeige, sowohl zum Einstellen einer Strombegrenzung, als auch, wenn man den Ausgang dann einschaltet (das geht da noch mal separat zum Hauptschalter), um die aktuelle Stromabgabe anzuzeigen. Wenn man dieser Anzeige glauben darf, saugt der Borg maximal nicht mehr als 1A aus dem Netzteil raus. Unter der Berücksichtigung, dass die Dimensionierungsempfehlung der Schaltnetzteile auf 3A nicht ganz aus der Luft gegriffen ist, wundert mich das. Es traten zwischendurch extrem seltsame Fehlerbilder auf. Um es mal lapidar auszudrücken: Irgendwas mit dem Zeitmultiplexing schien da nicht ordentlich funktioniert zu haben. Ich hatte ein Fehlerbild, in dem einer der zentralen Pixel sehr hell war, und um den herum flackernd Pixel in einer enger werdenden Spirale rotierten. Ich würde auf die DNA-Animation als Grundlage tippen, nur dass da was mit dem Row/Col-Sync kaputt war. Das zweite Fehlerbild war eine Pixelreihe auch eher in der Mitte, deren einzelne Pixel in variabler Intensität geflackert haben. Ich tippe hierbei auf die Propeller-Animation ohne senkrechte Auslenkung. Beide Fehlerbilder traten bis jetzt genau einmal auf, und waren nach einem Reboot des Borgs komplett weg. Ich habe weiterhin ab und an sporadische Ausfälle einzelner Spalten, so wurden bei Snake die rechte Spielfeldbegrenzung mal nicht gezeichnet (bis auf die Eckpixel, also eigentlich nichts physisches), und beim Breakout flackerten rechts unterhalb der schwebenden Steine ab und an mal einzelne Pixel auf. Einmal sogar hat der Reboot im Fehlerfall geklappt. Der Borg ist in der Feueranimation stehen geblieben, und hat eine Sekunde später wieder den Begrüßungstext angezeigt. Wohlgemerkt, in 90% der Freezes wird noch ein Bild angezeigt, es bleibt nur einfach stehen. Manchmal ist es auch komplett schwarz. Ich werde in absehbarer Zeit (d.h. nach der nächsten Klausur) mal beim CTDO vorbei gehen, ich will mal mit einem Oszilloskop die Spannung, die zwischen dem VCC und dem GND-Beinchen anliegt, messen, und gucken, wie viel Jitter da drin ist. Vielleicht gibts ja einen Peak genau dann, wenn das Teil abstürzt - in welche Richtung der Peak dann geht, bleibt erstmal noch offen. Vielleicht ein Spannungseinbruch, oder ähnliches. Ansonsten habe ich zumindest auf der Softwareseite alles verifiziert, da ist alles okay. Auch das Speicherabbild, wie in deiner letzten Mail beschrieben. Und jetzt mal rein prophylaktisch: Wie viele Platinen habt ihr im Labor noch rumfliegen? Falls ich nämlich auf absehbare Zeit nichts weiter finden sollte, würde ich gerne noch eine weitere Platine erwerben - die Reichelt-Warenkörbe sind ja noch aktuell, nehme ich an? Da das ganze aber wieder mit Kosten und Arbeit verbunden ist, und bedeuten würde, dass ich vor der aktuellen Situation komplett kapituliere, wird das allerdings die Ultima Ratio sein. Gruß, ttk Christian Kroll <chris@das-labor.org> schrieb am Do., 5. Jan. 2017 um 01:42 Uhr:
Hallo Tatonka,
Am 04.01.2017 um 22:50 schrieb Simon Szustkowski:
Und zwar hängt sich mein Borg nach einer gewissen Zeit auf. Initial war diese Zeit so 30 Minuten, ich habe dann nach den Empfehlungen des Wikis einen Abblockkondensator eingelötet, seitdem kam es auch schon mal vor, dass der Borg auch mal gute 2 Tage durchgehend lief, bis er wieder irgendwo einfror. Bei welcher Animation genau ließ sich nie so wirklich vorhersehen, also nicht nur bei der Spirale oder dem Lagerfeuer, wie das Laborwiki vermutet. Teilweise friert der Borg auch in einem Zustand ein, in dem sämtliche LEDs abgeschaltet sind.
ist das Bild beim Freeze denn noch sichtbar? In dem Fall läuft zumindest der Timer-Interrupt noch, der das Zeilenmultiplexing macht. Ansonsten läuft die Borgware-2D eigentlich ziemlich stabil. Ich weiß von mehreren Wochen ;)
Ich habe danach erstmal alle Lötstellen nochmal überprüft, und auch mal einen anderen Controller eingesetzt, im Verdacht, dass der irgendwie einen an der Klatsche haben könnte. Die Laufzeiten mit dem neuen Controller sind wieder um einiges kürzer, und bewegen sich irgendwo im Bereich um einer halben Stunde maximal. Wohlgemerkt, der Rest der Schaltung ist derselbe.
Platinen sind nicht auszuschließen. Mehr Tipps als Lötstellen absuchen und bei Bedarf mit Flussmittel nachlöten kann ich Dir da nicht geben :( Im ungünstigsten Fall sind die Leiterbahnen beschädigt (Haarrisse, Produktionsfehler, etc.).
Ich habe seitdem die Brownout Detection im Verdacht. Die Fuses sind auf 4,3V Brownout gesetzt, und ich nehme einfach mal an, dass das Netzteil das nicht richtig liefern kann. Obwohl ich bereits 2 Netzteile getestet habe - ein 5V 2,4A Netzteil, und dann ein 5V 3A Netzteil, ein Modell, was im CTDO-Wiki als geeignet angegeben wurde.
Bei fehlerhafter Brownout-Detection stürzt der Borg16 ziemlich sicher bei der Spiralanimation ab. Wenn das unabhängig von der Animation passiert, liegt die Ursache vermutlich woanders.
Du kannst ja mal einen Oszi an die Versorgungsleitungen des ATmegas klemmen (das sind die, an denen Du den Abblockkondensator angelötet hast) und schauen, was sich da so tut. Wenn die Spannungsschwankungen dort zu groß sind macht der Controller komische Dinge.
Ein weiteres Indiz für was auch immer ist die Tatsache, dass ich nach den Empfehlungen des Wikis mal das EEPROM nach einem Reset und einem Freeze ausgelesen habe, und dort nicht nur die erwähnten 0xFF drin stehen. Ich bin auf diesem Gebiet zwar noch ein ziemlicher Neuling, aber es scheint so, als sei der Dump in Sektionen unterteilt, die alle jeweils mit einer Folge anfangen, die ähnlich aussieht wie :20072000 und dann mehrere Bytes Daten kommen. Bei einigen Sektionen sind sämtliche darauf folgenden Bytes Fs, allerdings ist bei manchen Sektionen das letzte Byte ein anderer Wert.
Der Tipp im Wiki bezieht sich auf Situationen, in denen das originale Firmware-Image nicht mehr vorliegt. Memory Corruption kann sich dadurch äußern, dass im EEPROM oder im Flash an unbeschriebenen Bereichen vereinzelt andere Werte als 0xFF auftauchen (0xFF ist der Grundzustand bei EEPROM und Flash). Sicher ist das aber nicht.
Was Du Dir da angeschaut hast, ist das Intel-HEX-Format, das entgegen des Namens kein reiner Hexdump sondern eine speziell formatierte Textdatei ist. Ich finde es einfacher, ein HEX- in ein Raw-Image zu konvertieren und dieses dann mit einem Hex-Editor zu betrachten: # avr-objcopy -I ihex -O binary MyImage.hex MyImage.raw
Das Flash lässt sich so auslesen (direkt im Raw-Format): # avrdude -c usbasp -p m644p -U f:r:image.raw:r
Das EEPROM lässt sich so auslesen (direkt im Raw-Format): # avrdude -c usbasp -p m644p -U eeprom:r:eeprom.raw:r
Es werden ungefähr 170-180 Bytes im EEPROM benutzt, der Rest sollte 0xFF sein.
Aber Du kannst es Dir auch einfacher machen. In Deinem Fall liegt das ursprüngliche Kompilat ja vor, mit dem Du ein Verify gegen den tatsächlichen Flash-Inhalt machen kannst: # avrdude -c usbasp -p m644p -U f:v:image.hex Dann weißt Du, ob die Bits tatsächlich verrotten.
Ich habe zu guter Letzt mal die serielle Schnittstelle, bzw. die Shell dadrauf beobachtet, wenn ein Freeze passiert. Die letzten Meldungen, die ich da drauf bekomme, sehen wie folgt aus:
Command is too long.
Die Fehlermeldung tritt auf, sobald der Zeilenpuffer voll ist. Kann sein, dass die Schnittstelle Zeichen erkennt, wo keine sein sollen, zum Absturz sollte das aber nicht führen. Wenn die Abstürze auch bei deaktivierter Shell auftreten, würde ich die Ursache woanders vermuten.
Und das letzte Symptom: Der Einschaltcounter zeigt bei mir teilweise absurd hohe Werte an.
Der Counter war schon immer buggy. Um das EEPROM zu schonen, gibt es einen Ringspeicher, damit nicht immer das gleiche Byte beschrieben wird. Leider verhält sich die Implementierung nicht sehr intelligent, wenn der Ringspeicher aufgebraucht ist, was dann zu absurden Zählerwerten führt. Ist bekannt, ich hatte aber nie den Nerv, den betreffenden Code zu sanieren.
Gruß, Christian
_______________________________________________ Borg16 mailing list Borg16@das-labor.org http://das-labor.org/mailman/listinfo/borg16
-- --- Before printing this email, think if it is really needed.
Am 16.03.2017 um 20:18 schrieb Simon Szustkowski:
Wenn man dieser Anzeige glauben darf, saugt der Borg maximal nicht mehr als 1A aus dem Netzteil raus.
Das Lastverhalten des Borgs ist durch das Multiplexing extrem unbeständig, wodurch Du im besten Fall nur eine Art Mittelwert siehst (billige Multimeter steigen da zum Beispiel direkt aus). Volle Belastung hast Du auch nur dann, wenn alle Pixel auf volle Helligkeit geschaltet sind ("test 3" auf der seriellen Konsole), aber selbst da schaltet der Controller die Spaltentreiber beim Zeilenwechsel kurz ab.
Es traten zwischendurch extrem seltsame Fehlerbilder auf. Um es mal lapidar auszudrücken: Irgendwas mit dem Zeitmultiplexing schien da nicht ordentlich funktioniert zu haben [...]
Das ist in etwa das, was man sieht, wenn die Spannungsversorgung am Controller zu stark schwankt.
Ich habe weiterhin ab und an sporadische Ausfälle einzelner Spalten, so wurden bei Snake die rechte Spielfeldbegrenzung mal nicht gezeichnet (bis auf die Eckpixel, also eigentlich nichts physisches), und beim Breakout flackerten rechts unterhalb der schwebenden Steine ab und an mal einzelne Pixel auf.
Hört sich nach kalten Lötstellen in der LED-Matrix oder nach Kabelbruch an. Im schlechtesten Fall haben die Spaltentreiber einen weg, ist aber eher unwahrschenlich. Ich hatte mal einen UDN2981A, der nach einer gewissen Zeit einen Ausgang stillgelegt hat. Wenn das Flackern auftritt, schalte mal alle LEDs per serieller Konsole an und schau wo auf dem Weg zur LED-Spalte der Spannungsverlust auftritt.
Wohlgemerkt, in 90% der Freezes wird noch ein Bild angezeigt, es bleibt nur einfach stehen. Manchmal ist es auch komplett schwarz.
Es kann gut sein, dass durch einen Glitch nur das Hauptprogramm abgestürzt ist. Solange das von der ISR genutzte RAM unangetastet bleibt, wird das Multiplexing durchaus weiter funktionieren und den letzten Stand im Framebuffer darstellen.
Ich werde in absehbarer Zeit (d.h. nach der nächsten Klausur) mal beim CTDO vorbei gehen, ich will mal mit einem Oszilloskop die Spannung, die zwischen dem VCC und dem GND-Beinchen anliegt, messen, und gucken, wie viel Jitter da drin ist. Vielleicht gibts ja einen Peak genau dann, wenn das Teil abstürzt - in welche Richtung der Peak dann geht, bleibt erstmal noch offen. Vielleicht ein Spannungseinbruch, oder ähnliches.
Einzelne Peaks oder Spannungseinbrüche wirst Du eher nicht sehen, dafür ist die Spannung an diesen Pins viel zu wechselhaft. Schau besser, wie breit und "gleichmäßig" der Bereich ist, in dem sich die Spannung bewegt.
Ansonsten habe ich zumindest auf der Softwareseite alles verifiziert, da ist alles okay. Auch das Speicherabbild, wie in deiner letzten Mail beschrieben.
Es spricht eh alles für ein Hardware-Problem.
Und jetzt mal rein prophylaktisch: Wie viele Platinen habt ihr im Labor noch rumfliegen? Falls ich nämlich auf absehbare Zeit nichts weiter finden sollte, würde ich gerne noch eine weitere Platine erwerben - die Reichelt-Warenkörbe sind ja noch aktuell, nehme ich an?
Leerplatinen sind AFAIK noch haufenweise da. Aber bevor Du irgendwas kaufst: Ich habe noch ein paar Teile in meinem Fundus, die ich in absehbarer Zeit eh nicht anrühren werde und Dir vermachen würde, wenn die weitere Fehlersuche nichts zu Tage fördert. Gruß, Christian
participants (2)
-
Christian Kroll
-
Simon Szustkowski