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