wenn während des Flashens die Stromversorgung zusammenbricht? Folgendes Szenario: Ein Arduino Nano bedient eine Peripherie, die ~ 2 A bei 5 V zieht – deswegen habe ich die Schottky-Diode auf dem Nano entfernt, die das Board über den USB-Anschluss versorgt. Als Spannungsversorgung hatte ich eine Powerbank an die +5V angeschlossen – die natürlich nach einer gewissen Zeit den Saft abstellt, wenn nicht genügend Last vorhanden ist. Das ist mir während des Flashens per Bootlader passiert und anschließend hat avrdude das Teil nicht mehr erkannt. Ein weiterer merkwürdiger Effekt: Wenn ich das Board per USB an den PC anstecke, stürzt die Anwendung auf dem Nano sofort ab und bootet wieder. Die in die SW eingebaute Watchdog-Ereigniserkennung zeigt mehr als 50 Watchdog-Interrupts an und für das jeweils letzte auch die Adresse, auf der es auftrat: in letzter Zeit ist das häufig 0, manchmal aber auch irgend was, das zuweilen mitten in einem Befehl liegt. Auch auffällig: die Fuses lassen sich per ISP nicht mehr programmieren. Ansonsten läuft der Controller so, wie man es erwartet. Kann sich bei dem Spannungsausfall der Bootlader selbst abgeschossen haben?
> Kann der Bootlader schaden nehmen > wenn während des Flashens die Stromversorgung zusammenbricht? Definitiv ja. Deswegen wird bei Consumer Elektronik immer dick und fett darauf hingewiesen, dass man beim Firmware-Upgrade für eine zuverlässige Stromversorgung sorgen soll. Per ISP Programmieradapter müsstest du den Bootloader aber wieder reparieren können. > die Fuses lassen sich per ISP nicht mehr programmieren. Zeige mal die Fehlermeldung von avrdude, den Schaltplan und Fotos vom Aufbau. Ich vermute, deine Stromversorgung ist mangelhaft. > Kann sich bei dem Spannungsausfall der Bootlader selbst abgeschossen > haben? Ja, das hat aber nichts mit deinem Fuses-Problem zu tun.
Stefan ⛄ F. schrieb: > Definitiv ja. Beim Nano ist BOD enabled. Es "sollte" also nichts passieren. Klar, der Flash Vorgang bricht ab. Das Anwender Programm ist dann kaputt. Aber doch nicht der Bootloader. (?) Ich vermute eher, dass da der alte Bootloader drauf ist, und der bei aktiviertem WDT in einen Dauer Resetloop verfällt. Das war wohl der Hauptgrund für Arduino, beim Nano den Bootloader auszutauschen. alles im Kristallkugelmodus
Arduino Fanboy D. schrieb: > Ich vermute eher, dass da der alte Bootloader drauf ist Ja, es ist definitv der alte Bootlader drauf.
Stefan ⛄ F. schrieb: > Zeige mal die Fehlermeldung von avrdude, den Schaltplan und Fotos vom > Aufbau. Ich vermute, deine Stromversorgung ist mangelhaft. avrdude versucht die Fuses zu schreiben und liest was anderes zurück. Aufbau: ist relativ uninteressant – das ist der Nano auf einem Stück Lochraster. Die schwach Signaleitungen sind aus Fädeldraht, alles, worüber mehr Strom fließen kann, ist aus abisoliertem Klingeldraht. Das Gerät als Ganzes funktioniert so, wie es soll. Nur der Bootlader will nicht und ich kann mich bei laufendem Gerät nicht per USB in die Userschnittstelle einhängen, um Daten anzusehen – beim Einstecken stürzt der 328 ab, bootet und überschreibt die Daten.
Taucher schrieb: > Ja, es ist definitv der alte Bootlader drauf. Dann wird das das Problem sein. Der geht nicht mit dem WDT zusammen! Auch das deutet darauf hin. Taucher schrieb: > Die in die SW eingebaute Watchdog-Ereigniserkennung zeigt mehr als 50 > Watchdog-Interrupts an
Taucher schrieb: > Das Gerät als Ganzes funktioniert so, wie es soll. Nur der Bootlader > will nicht Deshalb hast du schon den Tipp bekommen, per ISP den 328 neu zu flashen. Dann aber gleich mit dem neuen Bootloader.
Taucher schrieb: > die natürlich nach einer gewissen Zeit den Saft abstellt, wenn nicht > genügend Last vorhanden ist. https://www.ramser-elektro.at/powerbank-schaltet-sich-aus-die-loesung/
Erwin D. schrieb: > Deshalb hast du schon den Tipp bekommen, per ISP den 328 neu zu flashen. Wow, das hätte ich jetzt nicht gedacht…
Den 47Ω Widerstand in Reihe zur 5V Versorgung des Arduino Nano Moduls finde ich sehr merkwürdig. Das könnte die Ursache für viele Fehlfunktionen sein.
SoEiner schrieb: > https://www.ramser-elektro.at/powerbank-schaltet-sich-aus-die-loesung/ Ja, den Thread kenne ich. Das hilft nur beim Flashen nicht. In der SW ist eine Funktion vorgesehen, mit der das Gerät auf eine andere Powerbank trainiert werden kann – ist aber noch nicht fertig. Deswegen die BAT43, der 100 mF Kondensator und D2 an +.
Taucher schrieb: > Erwin D. schrieb: >> Deshalb hast du schon den Tipp bekommen, per ISP den 328 neu zu flashen. > > Wow, das hätte ich jetzt nicht gedacht… Was hättest du nicht gedacht? Dass du den Tipp bereits bekommen hast?
Stefan ⛄ F. schrieb: > Den 47Ω Widerstand in Reihe zur 5V Versorgung des Arduino Nano Moduls > finde ich sehr merkwürdig. Das könnte die Ursache für viele > Fehlfunktionen sein. Würdest du die 100 mF einfach so an + hängen?
Taucher schrieb: > Würdest du die 100 mF einfach so an + hängen? Kommt auf das Netzteil an. Deine Bedenken sind sicher angebracht, aber du brauchst trotzdem eine stabile Versorgungsspannung - vor allem beim Flashen und wenn du auf das EEPROM zugreifst. Wenn schon, würde ich da höchstens 1Ω oder eine aktive Strombegrenzung verwenden.
Dann müsste auch noch eine richtig fette Schottky-Diode dazu, denn die BAT43 würde sich beim ersten Versuch in Rauch auflösen… Stefan ⛄ F. schrieb: > Kommt auf das Netzteil an. Deine Bedenken sind sicher angebracht, aber > du brauchst trotzdem eine stabile Versorgungsspannung - vor allem beim > Flashen und wenn du auf das EEPROM zugreifst. Netzteil ist eine Powerbank… Im Betrieb ist das alles kein Problem, weil die SW – vorläufig, s.o. – alle 30 sec für 1 Sekunde einen der FETs auf macht. Die beiden Powerbänke, die ich dafür habe, spielen da prima mit. Problematisch ist nur das Flashen und das will ich ja auch nicht dauernd machen. Ich hatte nur vergessen, beim Flashen rechtzeitig den "Totermann-Knopf an der PB zu drücken und dann wars auch schon passiert…
Die 47 Ω können sich auch nur beim Kaltstart störend auswirken – anschließend wird sein Effekt ja vom C ausgebügelt. Da der Arduino ja schon (per großem USB-Stecker) an die Powerbank angeschlossen sein muss, wenn man eine Verbindung per µ-USB herstellen will, und die Schottky-Diode auf dem Arduino, die ihn mit Strom vom µ-USB versorgen könnte, entfernt ist, kann der Widerstand eigentlich keinen Effekt mehr haben, wenn die serielle Verbindung aufgebaut wird.
Was sagt eigentlich die Powerbank bzw. dein PC zu dem dicken Elko auf der 5V Schiene? Und: Brennt dabei nicht die Diode unter der USB Buchse des Arduino Nanos ab? Laut USB Spezifikation darf die 5V Schiene nur mit maximal 10µF belastet werden.
Stefan ⛄ F. schrieb: > Brennt dabei nicht die Diode unter der USB Buchse > des Arduino Nanos ab? Wo keine Diode ist, kann keine abbrennen. Wie oben schon mehrfach geschrieben, hab ich sie ausgelötet.
Taucher schrieb: > Wo keine Diode ist, kann keine abbrennen. Wie oben schon mehrfach > geschrieben, hab ich sie ausgelötet. Ach so, das habe ich übersehen.
OK, Frage bzgl. Bootlader beantwortet, vielen Dank dafür.
Arduino Fanboy D. schrieb: > Beim Nano ist BOD enabled. > Es "sollte" also nichts passieren. Kann der BOD-Reset eine laufende Flash-Programmierung sauber abbrechen? Ich glaube ja auch, dass der Flash-Speicher dann zwar eine nur teilweise geschriebene Seite enthält, aber sonst nichts überschrieben wird. Aber ist im Datenblatt wirklich garantiert dass sich beim Fall von VCC und BOD-Reset nicht eventuell auch völlig falsche Schreibadressen ergeben können, die dann evtl. auch den Bootloader selbst betreffen können? LG, Sebastian
:
Bearbeitet durch User
Meines bescheidenen Wissens nach: Ja! Das Datenblatt hält sich da bedeckt. bzw. empfiehlt es BOD zu aktiveren um Fehlfunktionen zu verhindern. Aber ganz konkret auf den Punkt geht es nicht ein. Zumindest habe ich das noch nicht gelesen. Stefanus behauptet das Gegenteil, also dass die Gefahr besteht, trotz BOD. Heute nicht zum ersten mal. Denn er kennt einen Dr. X, dem das schon passiert ist. Dem hats bei unsauberer Versorgung den Flash Inhalt zerstört, einfach so im laufenden Betrieb. Natürlich nicht mit einem ATMega328P, sondern mit einem anderen. (ich kann das nicht glauben und den Dr. kann ich auch nicht fragen) Wer jetzt recht hat, darfst du dir selber aussuchen.
Na immerhin geht der BL auf dem Nano nach dem Zusammenbruch der Versorgungsspannung nicht mehr. Das ist doch immerhin ein Hinweis…
Taucher schrieb: > Na immerhin geht der BL auf dem Nano nach dem Zusammenbruch der > Versorgungsspannung nicht mehr. Das ist doch immerhin ein Hinweis… Der alte Bootloader kann mit dem WDT nicht. -- das ist auch ein Hinweis --- Sogar einer, welcher im praktischen Experiment jederzeit bewiesen werden kann. Du könntest den Nano mal auslesen, dann siehst du (oder dein diff) ob der Bootloader kaputt ist. Das wäre dann keine Vermutung mehr. So kann man Realität mit Fantasie abgleichen. Merke: Nicht immer ist die einfachste/offensichtlichste Ursache --> Wirkung Kette auch die echte. Der Mensch sucht gerne nach "einfachen" Dingen, um sich die Welt zurecht zu pinseln. Einfach, steht oft höher auf der Prioritätenliste, als die Wahrheit.
Arduino Fanboy D. schrieb: > Nicht immer ist die einfachste/offensichtlichste Ursache --> Wirkung > Kette auch die echte. Dass der BL nicht mehr funktioniert, ist offensichtlich und dass er vor dem Unfall mit der Betriebsspannung klaglos tat, auch. Dass er sich nach dem Auslesen als unbeschädigt erweist, wäre doch sehr verwunderlich – deshalb meine Frage, ob der BL durch Spannungszusammenbruch beim Flashen Schaden nehmen kann.
Nur der Vergleich, kann dir die Antwort liefern! Dass der Bootloader, nicht mit dem WDT funktioniert scheint ja irgendwie kein Argument für dich zu sein.... Warum nicht?
Arduino Fanboy D. schrieb: > Warum nicht? Weil bisher er immer funktioniert hat. Auch mit WD. (Den Code hatte ich mir vor längerer Zeit auch mal genauer unter die Lupe genommen und das Teil so zurecht gebogen, dass es über Bluetooth flashen kann. Allerdings nicht die Version, die auf besagtem Exemplar läuft.) Aber denk doch einmal logisch: Der Controller funktioniert, abgesehen vom BL, problemlos. Wäre es ein echter Hardware-Defekt, dann würde ich zumindest auch mit anderen Problemen rechnen. Bei einem 14-stündigen Praxis-Test des Gerätes habe ich keinerlei Probleme gefunden, alles läuft genau so, wie vorgesehen. Ich hatte zuerst ja auch gewisse Zweifel, ob da nicht irgend was am 328 kaputt ist, was mich zu meiner Frage hier veranlasst hat.
Taucher schrieb: > Aber denk doch einmal logisch: OK! 1. Du hast einen Nano 2. Mit dem alten Arduino Bootloader 3. Den WDT aktiviert Das kann nicht funktionieren! Fertig mit logisch denken. Tut mir leid, das sagen zu müssen, aber wer gegenteiliges behauptet, liegt falsch. Irgendwas stimmt an deinen Aussagen nicht. Was, kann ich dir nicht sagen. Und damit endet es hier und jetzt auch für mich, denn gegen Windmühlen habe ich keine Lust anzukämpfen. Der Ball liegt bei dir im Feld. Du kannst den Nano auslesen und so den Bootloader prüfen. Du könntest die 3 Punkte Logik mit einem anderen Nano/ATMega328P gegentesten.
Arduino Fanboy D. schrieb: > 1. Du hast einen Nano > 2. Mit dem alten Arduino Bootloader > 3. Den WDT aktiviert > > Das kann nicht funktionieren! Es hat aber funktioniert. Wenn du dir den Code des BL ansiehst, wirst du feststellen, dass er den WD benutzt, um dem Controller nach dem Fashen einen Reset machen zu lassen – er muss also aktiviert sein. In den BL kommt der Nano nur, wenn er einen Reset bekommen hat – der wird mit einem Trick über eine der Steuerleitungen (DTR?) über den USB ausgelöst. Ohne Reset kein Bootlader.
Taucher schrieb: > Wenn du dir den Code des BL ansiehst, wirst du feststellen, dass er den > WD benutzt, um dem Controller nach dem Fashen einen Reset machen zu > lassen – er muss also aktiviert sein. Iss klar... Keine Fragen mehr! Der neue Bootloader
1 | void appStart() { |
2 | watchdogConfig(WATCHDOG_OFF); |
3 | __asm__ __volatile__ ( |
4 | #ifdef VIRTUAL_BOOT_PARTITION
|
5 | // Jump to WDT vector
|
6 | "ldi r30,4\n" |
7 | "clr r31\n" |
8 | #else
|
9 | // Jump to RST vector
|
10 | "clr r30\n" |
11 | "clr r31\n" |
12 | #endif
|
13 | "ijmp\n" |
14 | );
|
15 | }
|
Der alte Bootloader (gekürzt)
1 | void (*app_start)(void) = 0x0000; |
2 | // --schnipp --
|
3 | app_start(); |
Ich sehe da einen Jump/Call. Du siehst da einen WDT Reset. Alles klar! Keine Fragen mehr.... --------------------- Vorsicht Logik: Wenn der Bootloader einen WDT Reset machen würde, dann würde wieder der Bootloader dran kommen. Und nie und nimmer die Anwendung. Da aber die Anwendung im Normalfall gestartet wird, ist es unbezweifelbar, dass der Bootloader keinen WDT Reset machen darf. ------------ Taucher schrieb: > In den BL kommt der Nano nur, wenn > er einen Reset bekommen hat – der wird mit einem Trick über eine der > Steuerleitungen (DTR?) über den USB ausgelöst. > > Ohne Reset kein Bootlader. Also, natürlich darfst du mich für böld halten. Ich kann dir ja auch in Grenzen zustimmen, denn alles weiß ich auch nicht.
Taucher schrieb: >> Das kann nicht funktionieren! > Es hat aber funktioniert. Es funktioniert nur solange, bis der WDT einen Neustart auslöst. Dann läuft erstmal der Bootloader, welche der WDT nicht zufrieden stellt, und deswegen bricht der WDT den Bootloader ab und startet wieder neu. Es kommt zu einer Endlosschleife von Neustarts, bis man das Ding Stromlos macht und dann wieder einschaltet. Der Knackpunkt ist, dass ein einmal aktivierter WDT durch einen Reset nicht automatisch wieder deaktiviert wird, wohl aber durch eine Power-Cycle. Im Datenblatt steht: "If the Watchdog is accidentally enabled, for example by a runaway pointer orbrown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If the code is not set up to handle the Watchdog, this might lead to an eternal loop of time-out resets. To avoid this situation, the application software should always clear the Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialization routine, even if the Watchdog is not in use." Die Initialisierungs-Routine ist beim Arduino Nano sein Bootloader und der schaltet den Watchdog eben nicht aus, weil er davon ausgeht, dass der Watchdog nicht verwendet wird. Deswegen ist jede Aktivierung im Sinne dieses Textes "accidentally". Wohl gemerkt gilt das alles nur für den alten Botoloader.
Stefan ⛄ F. schrieb: > Es funktioniert nur solange, bis der WDT einen Neustart auslöst. Dann > läuft erstmal der Bootloader, welche der WDT nicht zufrieden stellt, und > deswegen bricht der WDT den Bootloader ab und startet wieder neu. > > Es kommt zu einer Endlosschleife von Neustarts, bis man das Ding > Stromlos macht und dann wieder einschaltet. Das deckt sich mit meiner Beobachtung, dass der Watchdogzähler meiner SW nach dem Kaltstart irgendwo über 50 steht. > Der Knackpunkt ist, dass ein einmal aktivierter WDT durch einen Reset > nicht automatisch wieder deaktiviert wird, wohl aber durch eine > Power-Cycle. Bei mir lief er immer auch ohne Stromunterbrechung an. Offenbar ist das Timing irgendwo im kritischen Bereich. Ich habe den WDT auf 2 sec eingestellt – es ist also reichlich Luft vorhanden, durch die der Controller irgendwann mal ein Loch finden kann, um in den App-Code zu kommen. Die zeitlichen Variationen dürften durch den USB und unterschiedliche Latenzen des Linux-Systems am anderen Ende zustande kommen. > Die Initialisierungs-Routine ist beim Arduino Nano sein Bootloader und > der schaltet den Watchdog eben nicht aus, weil er davon ausgeht, dass > der Watchdog nicht verwendet wird. Ich benutze nicht die Arduino-Umgebung, sondern programmiere das Ding vollständig in C. Außerdem fange ich den Watchdog-IR ab und führe dort ein wdt_disable() aus – damit ist das Problem aus der Welt und das Verhalten erklärt.
Taucher schrieb: > Ich habe den WDT auf 2 sec eingestellt – es ist also reichlich Luft > vorhanden, durch die der Controller irgendwann mal ein Loch finden kann, > um in den App-Code zu kommen. Das ist ebenso nicht wahr. Der WDT wird bei einem Reset NICHT abgeschaltet. Aber der Teiler des WDT auf den kleinsten möglichen Faktor gestellt. Es ist also völlig wurscht egal, welche Zeit du da einstellst.
Arduino Fanboy D. schrieb: > Das ist ebenso nicht wahr. Na du weißt alles besser… Nur dumm, dass sich deine Sicht einfach nicht mit dem Verhalten des Gerätes decken will. Was machen wir da? Die Realität korrigieren? So nach dem Motto, ist der Hocker nicht nahe genug am Flügel, dann schieben wir eben den Flügel an den Hocker ran?
Taucher schrieb: > Na du weißt alles besser… Klar! Habe ja schließlich auch das Datenblatt des ATMega328P auswendig gelernt. (für irgendwas muss das ja gut gewesen sein) Von daher: Ja! 1. Ich weiß das. 2. Kann es im Experiment belegen, dass dem so ist.
Arduino Fanboy D. schrieb: > 2. Kann es im Experiment belegen, dass dem so ist. Und was hat des jetzt mit meiner Implementierung zu tun? Verschwindet mein Kistchen durch dein Experiment einfach aus der Welt? Natürlich nicht, denn es liegt nach wie vor hinter mir im Regal und dass es jetzt durch geisterhafte Wirkung plötzlich sein Verhalten ändert?
> Das ist mir während des Flashens per Bootlader passiert > und anschließend hat avrdude das Teil nicht mehr erkannt. Dumm wie immer.
@ Taucher: Möchtest du wirklich nur diskutieren oder machst du schon? Schieb den neuen Bootloader auf den Nano und wiederhole dein Experiment mit der Versorgungsspannung. Ziehe daraus die richtigen Schlüsse.
Der Ork schrieb: > Möchtest du wirklich nur diskutieren oder machst du schon? Damit war der Thread für mich eigentlich erledigt: Beitrag "Re: Arduino Nano: Kann der Bootlader schaden nehmen…" Du musst die Frage also an Arduino Fanboy stellen. oerks schrieb: > Dumm wie immer. Danke, klüger bist DU aber auch nicht.
Taucher schrieb: > Der Ork schrieb: >> Möchtest du wirklich nur diskutieren oder machst du schon? > > Damit war der Thread für mich eigentlich erledigt: > Beitrag "Re: Arduino Nano: Kann der Bootlader schaden nehmen…" > > Du musst die Frage also an Arduino Fanboy stellen. Nö nö, dass war schon gezielt an dich addressiert. Hast du denn nun schon den neuen Bootloader drauf oder nicht? Wie lautet dein Testergebnis?
Wie schon vorher angedeutet: Kausalketten sind kein Wunschkonzert!
Hi
>Aber der Teiler des WDT auf den kleinsten möglichen Faktor gestellt.
An welcher Stelle des Datenblatts kann man das nachlesen?
So weit mir bekannt muss dazu erst das WDCE-Bit in WDTCSR und danach
die Prescaler-Bits gesetzt werden.
Aber aus eigener Erfahrung weis ich, das der Watchdog total überbewertet
wird. Kann natürlich sein, das das im Arduino Universum anders gesehen
wird. Ist aber nicht mein Baustelle.
MfG spess
Spess53 schrieb: > Kann natürlich sein, das das im Arduino Universum anders gesehen > wird. Ist mir Peng! Spess53 schrieb: > An welcher Stelle des Datenblatts kann man das nachlesen? Default Wert nach Reset. Steht da wo die Register erklärt werden.....
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.