Hallo in die werte Runde, Es geht um einen attiny13a, welcher ein Lauflicht aus sechs LEDs (Charlieplexing) abhängig von der Umgebungshelligkeit ein- oder ausschaltet. Anbei ein handgezeichnetes Schaltbild. Die Schaltung existiert zwei mal. Einmal auf einem Steckbrett und einmal fest verlötet auf einer Lochrasterplatine. Erstere wird direkt aus dem AVR-Programmer mit Strom versorgt (3.3V), letztere aus einem kleinen einzelligen Li-Ion-Akku, welcher wiederum an einem TP4056-Modul hängt. Für Tests ist zusätzlich ein rs232-Pegelwandler-Modul (MAX3232) angeschlossen: Gnd und Vss direkt vom Programmer bzw. Akku, PB3 als serieller Ausgang des Mikrocontrollers (bitbanging). Zwischen Gnd und Vcc ist ein 100n-Keramikkondensator, zwischen Gnd und PB4 eine Fotodiode mit der Kathode an Gnd und der Anode am PB4. Das Programm ist auf beiden Umgebungen dasselbe (siehe Anhang, Kommentare stehen direkt im Quellcode. Entwickelt wurde das ganze im avr-Simulator von Gerhard Schmidt). Wenn ich das Programm starte (egal ob Steckbrett oder Lochraster), funktioniert es so wie erwartet. Das Lauflicht wird abhängig von der Helligkeit ein- bzw. ausgeschaltet. Den ADC-Wert bekomme ich alle zehn Sekunden am seriellen Ausgang ausgegeben, alles gut so weit. Allerdings hängt sich der Mikrocontroller nach einiger Zeit auf. Manchmal erst nach mehreren Stunden, manchmal nach schon vielleicht 30 Minuten. Konkret reagiert er nicht mehr, wenn es dunkel oder hell wird, und es kommen auch keine seriellen Daten mehr raus. Ich weiß leider nicht, warum. Ich vermute einen Programmfehler, denn das Problem tritt sowohl auf dem Steckbrett als auch der Lochrasterplatine im fest verlöteten Zustand auf, allerdings nach nicht reproduzierbaren Zeitabständen. Für sachdienliche Hinweise wäre ich sehr dankbar.
Angehängte Dateien:
-
schaltplan.png
5,9 KB
Stephan E. schrieb: > Für sachdienliche Hinweise wäre ich sehr dankbar. Wie hast du den Watchdog konfiguriert? Nicht jeder µC mag es, wenn sein Reset-Pin frei in der Luft hängt. Ziehst du den durch einen internen Pull-Up definiert auf High-Pegel?
Stephan E. schrieb: > https://www.mikrocontroller.net/attachment/694843/schaltplan.png Das ist kein Schaltplan.
Einen internen Pullup haben die AVRs. Ist nicht gerade extrem störsicher, aber sollte funktionieren – insbesondere kann das eher nicht zum beobachteten Verhalten (Firmware fährt sich fest) führen, sondern würde ja eher zu einem Reboot führen. Watchdog ist standardmäßig aus. Ich habe allerdings keine Lust, mich durch 500 Zeilen Assemblercode zu wuseln.
Jörg W. schrieb: > Ich habe allerdings keine Lust, mich durch 500 Zeilen Assemblercode zu > wuseln. Der ist so wie der "Schaltplan".
H. H. schrieb: > Stephan E. schrieb: >> https://www.mikrocontroller.net/attachment/694843/schaltplan.png > > Das ist kein Schaltplan. Er ist schrecklich (vor allem extrem pixelig klein skaliert und mit schlechtem Kontrast), aber die wesentlichen Details enthält er schon.
Rainer W. schrieb: > Stephan E. schrieb: >> Für sachdienliche Hinweise wäre ich sehr dankbar. > > Wie hast du den Watchdog konfiguriert? Der Watchdog ist als "interrupt-only" konfiguriert, er macht keinen reset. Er wird alle 0.125 Sekunden aufgerufen. Danach läuft die Hauptschleife ein mal durch und geht am Ende dieser Schleife in den Schlafmodus. Bis zum nächsten aufwecken durch den Watchdog. > Nicht jeder µC mag es, wenn sein Reset-Pin frei in der Luft hängt. > Ziehst du den durch einen internen Pull-Up definiert auf High-Pegel? Der Reset-Pin hängt auf der verlöteten Lochraster-Platine tatsächlich in der Luft. Am Programmer ist der Reset-Pin aber angeschlossen und wird mutmaßlich durch den Programmer oben gehalten.
Jörg W. schrieb: > Einen internen Pullup haben die AVRs. Ist nicht gerade extrem > störsicher, aber sollte funktionieren – insbesondere kann das eher nicht > zum beobachteten Verhalten (Firmware fährt sich fest) führen, sondern > würde ja eher zu einem Reboot führen. > > Watchdog ist standardmäßig aus. > > Ich habe allerdings keine Lust, mich durch 500 Zeilen Assemblercode zu > wuseln. Das würde ich natürlich auch nicht verlangen. Allerdings sieht das Forum vor, daß Quellcodes mitgeliefert werden - falls doch mal jemand einen Blick riskieren möchte. Vielleicht hat jemand mit Erfahrung einen Tipp für mich, der beim beschriebenen Problem der übliche Verdächtige sein könnte? Ggf. gibt's auch eine KI, die den Code mal durchschauen könnte.
- µC zusätzlich zum 100n KeKo noch mit einem kleinen Elko (Richtwert 47µ) puffern - Reset mit RC Glied 10n gegen Masse und 10K gegen Ub beschalten - serielle Schnittstelle mal probeweise im Code auskommentieren. Der Tinny hat die serielle Schnittstelle nicht in Hardware, sondern sie muß in SW emuliert werden. Da gibt es Implementierungen, die hängen sich gern auf. - die Fotodiode könnte man auch noch durch ein kleines RC-Glied beruhigen Immerhin hat er nicht nur Prosa, sondern überhaupt einen Schaltplan, der kein Wimmelbild ist und keine 6 MB groß ist. Also fast alles richtig gemacht ;-)
Stephan E. schrieb: > Am Programmer ist der Reset-Pin aber angeschlossen und wird mutmaßlich > durch den Programmer oben gehalten. Das wäre aber sehr ungewöhnlich. Wenn der Programmieradapter inaktiv ist, dann ist der Pin am Programmieradapter normalerweise hochohmig. Und dann reichen ein paar cm Leitung schon zum Empfang von Radiowellen. Der interne Pullup des Mikrocontrollers ist schwach, zudem reagiert er wesentlich empfindlicher als normale I/O Pins, da er anders definierte High/Low Pegel hat.
Hans W. schrieb: > Und dann reichen ein paar cm Leitung schon zum Empfang von Radiowellen. Ja, aber dann würde der Controller einen Reset machen, statt in einer Endlosschleife hängen zu bleiben. Gerald B. schrieb: > serielle Schnittstelle mal probeweise im Code auskommentieren. Der Tinny > hat die serielle Schnittstelle nicht in Hardware, sondern sie muß in SW > emuliert werden. Da gibt es Implementierungen, die hängen sich gern auf. Wäre natürlich ein Punkt. Wenn Stephan einen Logikanalysator hat, könnte man damit ein paar Testmuster stattdessen ausgeben und so ungefähr nachvollziehen, an welchen Stellen die Software noch lang kommt, bevor sie klemmen bleibt.
Gerald B. schrieb: > - µC zusätzlich zum 100n KeKo noch mit einem kleinen Elko (Richtwert > 47µ) puffern > - Reset mit RC Glied 10n gegen Masse und 10K gegen Ub beschalten > - serielle Schnittstelle mal probeweise im Code auskommentieren. Der > Tinny hat die serielle Schnittstelle nicht in Hardware, sondern sie muß > in SW emuliert werden. Da gibt es Implementierungen, die hängen sich > gern auf. > - die Fotodiode könnte man auch noch durch ein kleines RC-Glied > beruhigen Vielen Dank für die Tipps! Ich werde sie allesamt ausprobieren, testen und mich dann nochmal melden. @Jörg W.: Einen Logikanalysator besitze ich leider nicht. Ich bin nur ein kleiner Hobbybastler ohne nennenswerte Ausstattung (hat man ja schon am Schaltbild gesehen....).
Stephan E. schrieb: > Ich bin nur > ein kleiner Hobbybastler ohne nennenswerte Ausstattung (hat man ja schon > am Schaltbild gesehen....). Kein Papier, kein Kuli...
H. H. schrieb: > Kein Papier, kein Kuli... Das papierlose Büro wird schon seit Jahrzehnten beschworen - er hat es :P
Gerald B. schrieb: > H. H. schrieb: >> Kein Papier, kein Kuli... > > Das papierlose Büro wird schon seit Jahrzehnten beschworen Ja, das war alle paar Jahre aufs neue "das" große Thema der CeBIT. Anschließend stieg der Papierbedarf stark an... > - er hat es :P Allerdings in der grausamen Version.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.