Moin! Ich habe hier gerade etwas, was mich tatsächlich mal etwas verzweifeln lässt. Ich habe hier ein von mir gebautes Gerät, welches nun schon seit Jahren seinen Dienst tut. Seit heute aber nicht mehr. Der Controller initialisiert SP, 2 Timer, Ports, TWI, ein paar Variablen und das Display (4x40, 2x 44780) und fährt langsam die Hintergrundbeleuchtung (bis 70mA) mit einer PWM hoch. Normalerweise passiert danach noch mehr, aber nun startet der Controller an dieser Stelle neu. Also habe ich das Controllerboard ausgebaut und gemessen. Spannung stabil 5V und AC bis 100MHz 50mV Ripple vor allem durch PWM, Reset ist fest bei 5V. Board an den Programmer gepackt, neu geflasht. Geht wieder. Board wieder eingebaut, geht nicht mehr. Board wieder raus, Chip (ATmega168) gewechselt, geflasht. Selbes Spiel. Direkt nach dem flashen läuft das Programm. Nach dem Reset auch, nach einem Powercycle nicht mehr. Dann hilft auch kein Reset mehr. Sowohl direkt nach dem flashen, als auch nach einem Powercycle werden die selben korrekten Daten aus dem Flash gelesen. Es sitzen auch genug Blocker auf dem Board, welche ich nun auch schon getauscht habe. Layout ist auch unproblematisch und die Wege kurz. Auf dem Board befindet sich neben dem ATmega168 noch ein 7805 (welcher am Programmer aber nicht in Funktion ist und damit nicht Fehlerquelle sein kann), ein FET für die Hintergrundbeleuchtung und sonst nur Steckverbinder, welche bis auf Display und ISP aber gerade nicht verbunden sind. Auch ohne Display startet der Controller neu. Ich habe den Eindruck, dass in dem Moment die IRQs eingeschaltet werden. Ist aber nur ein Timer. Die Fuses sind bis auf DIV/8 unverändert. Also auch kein BOD aktiv. Schlüsse: - Die Hardware kann es nicht sein, denn nach neuflashen funktioniert es. - Die Software kann es nicht sein, denn sie lief Jahre lang anstandslos und nach neuflashen ja auch. - Es muss aber etwas sein, denn es funktioniert ja nicht! Die Frage ist also: Was bewegt den AVR dazu, direkt nach dem Flashen anstandslos zu arbeiten und nach einem Powercycle ständig zu reseten? Ideen? Vorschäge? Tips? Erfahrungen damit? Gruß Jobst
Jobst M. schrieb: > Reset ist > fest bei 5V. Wie sieht der Reset denn beim Powerup aus? Idealerweise würde der Controller ja ein paar ms nach erreichen der vollen Betriebsspannung erst loslaufen. Das ist auch IMHO dein Problem. Spendiere dem Board mal testweise einen vernünftigen Reset-Baustein, oder mache es als test manuell (also Pin auf GND halten beim Powerup, dann manuell auf 5 V legen. Ich wette, dann hast Du keinerlei Probleme mehr. Als nächstes fragst Du jetzt, warum es jahrelang funktioniert hat, gell? Weil es jahrelang recht dicht dran am Nichtfunktionieren war. Und jetzt ist halt ein Sonnenfleck mehr vorhanden, oder die Luftfeuchtigkeit ist um 1% gesunken... was auch immer, oder ein Kondensator hat 5 % seiner Kapazität eingebüßt.. Werner
Jobst M. schrieb: > Also auch kein BOD aktiv Vielleicht solltest du den auch mal einschalten. Auf 4,3 V. Das könnte Dein Problem auch ggf. sofort lösen. Werner
Werner schrieb: > Wie sieht der Reset denn beim Powerup aus? Wird im Gerät von einem weiteren Controller gesteuert. Im ausgebauten Zustand kommt er vom Programmiergerät. Ist 'ne Flanke ... Werner schrieb: > Ich wette, dann hast Du keinerlei Probleme mehr. Leider falsch. Kein Unterschied. Schrieb ich oben ja auch schon: Jobst M. schrieb: > Dann hilft auch kein Reset mehr. Ich schalte aber den BrownOut mal ein ... ... keine Änderung. Werner schrieb: > oder ein Kondensator hat 5 % seiner Kapazität eingebüßt.. Die sind schon alle getauscht und eigentlich recht unkritisch. Gruß Jobst
stell mal die Takteinstellung auf +64mSek. Wenn du ein 2 Kanaloszi hast vergleiche mal den Spannungsanstieg an VCC und am Resetpin. Versorge das LCD mal extern oder puffere es besser könnte sein das der Elko mit der Zeit nachgelassen hat. auch die PWM könntest du ja etwas glätten falls diese den µC stört. Es könnte deswegen mit dem Programmieradapter funktionieren weil er die Versorgungsspannung etwas stützt oder einen zusätzlichen Pullup für den Reset Pin hat.
Jobst M. schrieb: > nach einem Powercycle ständig zu reseten? - Watchdog aktiv? - Interrupt ohne Handler? - POR funktioniert ohne BOD nur, wenn sich die VCC immer bis 0V entladen kann.
Thomas O. schrieb: > stell mal die Takteinstellung auf +64mSek. Wenn du ein 2 Kanaloszi hast > vergleiche mal den Spannungsanstieg an VCC und am Resetpin. Der ResetPin wird nach aktivieren der Betriebsspannung von mir über den Programmer aktiviert. Das brauche ich keine Zeit zu messen, da sie von mir abhängt. > Versorge das LCD mal extern oder puffere es besser könnte sein das der > Elko mit der Zeit nachgelassen hat. auch die PWM könntest du ja etwas > glätten falls diese den µC stört. Jobst M. schrieb: > Auch ohne Display startet der Controller neu. ... und dann fließt auch kein PWM-Strom. > Es könnte deswegen mit dem Programmieradapter funktionieren weil er die > Versorgungsspannung etwas stützt oder einen zusätzlichen Pullup für den > Reset Pin hat. Nein, es ist egal, ob die Spannung ausschließlich aus dem Programmieradapter oder aus dem Gerät kommt. Es funktioniert nach einem Powercycle auch an dem Programmieradapter nicht. Gruß Jobst
Peter D. schrieb: > - Watchdog aktiv? Nein. Edit: Selbst wenn er aktiv sein sollte, sollte sich der AVR dann nicht in beiden Fällen gleich verhalten? > - Interrupt ohne Handler? Nein - würde auch das Verhalten nicht erklären. SOLLTE ein IRQ ohne Handler ausgelöst werden, werden die Tasten eben nochmal abgefragt. > - POR funktioniert ohne BOD nur, wenn sich die VCC immer bis 0V entladen > kann. Richtig. Ist es aber leider auch nicht. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Der Controller initialisiert SP, 2 Timer, Ports, TWI, ein paar Variablen > und das Display (4x40, 2x 44780) und fährt langsam die > Hintergrundbeleuchtung (bis 70mA) mit einer PWM hoch. Normalerweise > passiert danach noch mehr, aber nun startet der Controller an dieser > Stelle neu. Falls du die Software ändern kannst: a) Reihenfolge in der initialisierung ändern. b) Hintergrundbeleuchtung überspringen. Sollte zumindest bei der weiteren Fehlersuche helfen.
Ich bin im übrigen davon überzeugt, dass das Problem auf dem Board sitzt, denn der Controller läuft in anderen Schaltungen. Und: Der neue Controller macht das Selbe wie der alte. Gruß Jobst
Marc V. schrieb: > Falls du die Software ändern kannst: Ja. > a) Reihenfolge in der initialisierung ändern. > b) Hintergrundbeleuchtung überspringen. > > Sollte zumindest bei der weiteren Fehlersuche helfen. Ich habe, wie oben vermutet mal IRQs abgeschaltet - die fingern auf den Ports herum. Nun resetet er nicht mehr. Ich vermute irgendwo einen seichten Schluss. Aber wieso nur nach Powercycle ...? Gruß Jobst
Schaltplan, bitte. Klingt etwas nach: Power-Rampup außerhalb der Spec, Prozessor hängt daher beim Hochfahren der Spannungen irgendwo. BOD Fuse an?
Jobst M. schrieb: > Ich vermute irgendwo einen seichten Schluss. Da ist nichts :-/ Es passiert auf der Reset-Leitung ja auch nichts ... Die SW hat sich nicht geändert - er kann also nicht einfach an eine andere Stelle springen. Ich schaue mal in der SW, an welcher Stelle das genau passiert ... Gruß Jobst
Jobst M. schrieb: > Ich habe, wie oben vermutet mal IRQs abgeschaltet - die fingern auf den > Ports herum. Nun resetet er nicht mehr. Leider falsch. Ich hatte vergessen die Stromzufohr zu unterbrechen :-/ Auch ohne IRQs hängt er sich weg. Jim M. schrieb: > Schaltplan, bitte. Habe ich nicht. Stell Dir einen ATmega168 mit seinen 3 Kondensatoren vor. ISP dazu, das war's. Alles Andere drum herum habe ich schon abgenommen. > Klingt etwas nach: Power-Rampup außerhalb der Spec, An verschiedenen 5V Spannungsquellen, nur mit diesem Board? > Prozessor hängt daher beim Hochfahren der Spannungen irgendwo. Aber nur, wenn er gerade nicht frisch programmiert an der selben Spannungsquelle hängt? > BOD Fuse an? An oder aus - spielt keine Rolle. Steht oben schon. Ich versuche nun gerade heraus zu finden, ob es einen bestimmten Befehl gibt, welcher Theater macht ... Gruß Jobst
Es wäre halt vorteilhaft wenn die Spannung am Resetpin der VCC etwas hinterher läuft. Also erst VCC stabil und danach rennt der uC los. Mit dem Oszi kannst du das prüfen alles andere ist raten. Im Simulator kannst du sehr schön prüfen ob ein Interrupt korrekt angesprungen wird oder das Programm wegen eines fehlenden Resetvektors woanders weiter macht als gedacht. Weiterhin kannst man auch auswerten was den Reset ausgelöst hat. Gibt da ein Register wo die Bits entsprechend gesetzt werden. Hast du vielleicht JTAG aktiviert kann man im Programm per JTAG Disable Bit ausschalten.
:
Bearbeitet durch User
1 | Stell Dir einen ATmega168 mit seinen 3 Kondensatoren |
2 | vor. ISP dazu, das war's. Alles Andere drum herum habe ich schon |
3 | abgenommen. |
wie kein Reset Pullup von 10 kOhm?
:
Bearbeitet durch User
Thomas O. schrieb: > wie kein Reset Pullup von 10 kOhm? Nein. Ich habe oben geschrieben, wo der dran hängt. Ist aber nun auch alles egal, ich habe den Fehler gefunden. So ein blööööder Fehler. Ein SW Fehler. Warum der erst jetzt auftritt, ist mir unklar. Im RAM werden von der SW Schalterzustände abgespeichert. Abhängig von den Werten, werden Daten aus einer Tabelle im ROM ins RAM kopiert, bis eine 0 kommt. Kommt keine 0, wird wild weiter kopiert und evtl. auch SFRs und Stack überschrieben. Die Werte im RAM nach dem Start werden überprüft, wurde aber nicht richtig gemacht. Nach einem Flashvorgang stehen zumindest gültige Werte im RAM, welche kein Tabularasa auslösen. Auch nach einem Reset bleiben die Werte erhalten. Warum das Problem nicht schon viel früher aufgetreten ist und nun durchgängig, ist mir ein Rätsel. Aber es bewahrheitet sich immer wieder: Blöde Fehler sind Softwarefehler. Trotzdem vielen Dank an alle für ihre Mühe! Gruß Jobst
Jobst M. schrieb: > Abhängig von den Werten, werden Daten aus einer Tabelle im ROM ins RAM > kopiert, bis eine 0 kommt. Kommt keine 0, wird wild weiter kopiert und > evtl. auch SFRs und Stack überschrieben. Sowas gehört sich einfach nicht, da macht man einen Guard drumherum, d.h. Schreibzugriffe außerhalb sizeof(array) werden abgewiesen. Will man es gut machen, gibt man noch einen Errorlevel zurück, der dann ausgegeben wird.
Peter D. schrieb: > Sowas gehört sich einfach nicht, da macht man einen Guard drumherum, > d.h. Schreibzugriffe außerhalb sizeof(array) werden abgewiesen. > Will man es gut machen, gibt man noch einen Errorlevel zurück, der dann > ausgegeben wird. ASM unterster Level - was willst Du da abfangen, wenn der Fehler dort drin steckt? Gruß Jobst
Jobst M. schrieb: > ASM unterster Level - was willst Du da abfangen, wenn der Fehler dort > drin steckt? Ach komm, die Befehle CP/CPC kennst Du. Und im .DSEG kann man Label für die unterste und die höchste Arrayadresse vergeben. In meinem Bootloader habe ich z.B. solche Tests drin. Einmal, damit der RAM-Puffer nicht überläuft und einmal, damit der Bootloader sich nicht selber unterm Hintern weglöscht.
Peter D. schrieb: > Ach komm, die Befehle CP/CPC kennst Du. Bei der Grenzabfrage habe ich einen Fehler gemacht, den ich nun beseitigt habe. Welche Softwaretricks hast Du, um Programmierfehler zu verhindern? Vor allem, wenn das, was den Fehler feststellen soll, der Fehler ist? Gruß Jobst
Jobst M. schrieb: > Welche Softwaretricks hast Du, um Programmierfehler zu > verhindern? Ich benutze C, das nimmt einem schon viel monotone Arbeit ab. In Assembler könnte man sich für so einen Guard ein Macro schreiben, dann muß man es nicht jedesmal neu machen.
Hi Was aber auch erst funktioniert, wenn's denn funktioniert :) Verstehe den Verlauf nämlich so, daß die Prüf-Routine fehlerhaft war - und ja, wenn Sie fehlerhaft prüft, kann MIst raus kommen. Wenn das Prüf-Makro Mist ist, dann auch hier. Das Vorhandensein der Prüfung zeigt, daß die Gefahr bekannt war - und ohne Fehler wäre auch Nix passiert. Shit happens - auch in Assembler :) MfG
So sieht's aus ... Was mir aber wirklich Kopfzerbrechen bereitet: Warum ist der Controller über Jahre immer wieder klaglos gestartet und wieso startete er nun (unter selben Bedingungen) zuverlässig nicht mehr? Das Gerät speichert nichts im EEProm. Würde es mal so und mal so sein, hätte ich Verständniss dafür. Das ist, als hätte man einen Würfel und sagt: "Wenn ich 36x würfele, kommt jede Zahl statistisch 6x." Und dann würfelt man. Die ersten 6 Würfe einsen, die zweiten 6 Würfe zweien, etc. Zufall geht anders. Ich verstehe es nicht ... Gruß Jobst
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.