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