Moin, ich bin gerade dabei einen ATMEGA644 zu programmieren. Bei diesem wollte ich den watchdog mit 2.7V benutzen. Dies funktioniert leider nicht. Ich habe jetzt nur die Fuse gesetzt. Muss ich noch irgendetwas in Software beachten? Ich hatte das Problem, nachdem ich den watchdog programmiert hatte, lief mein Programm nicht mehr, trotz stabiler 3.3V. Ich hatte den watchdog dann bei den Fuses entfernt, bis ich einmal die Versorgung abgeschaltet hatte war der watchdog aber anscheinend noch aktiv. Was war mein Fehler in diesem Fall? Gruß
Für mich klingt das eher das du die brown out detection setzen wolltest und nicht den Watchdog? Was wolltest du damit erreichen? Kann es sein das du jetzt den Watchdog aktiviert hast und ihn keine passende Zeichenfolge sendest und der Watchdog deswegen noch der eingestellten Zeit deinen Prozessor immer resetet?
Stimmt. Hatte irgendwie beides zusammengeworfen. :( Ist natürlich Quatsch. Trotzdem bräuchte ich neben der BOD auch noch einen Softwarereset. Dafür eignet sich der watchdog ja eigentlich ganz gut. Wie mache ich das am elegantesten? wenn er über die uart einen bestimmten string empfängt geht er in einen programmabschnitt, der solange wartet, bis der watchdog auslöst?
:
Bearbeitet durch User
Marco G. schrieb: > Trotzdem bräuchte ich neben der BOD auch noch einen > Softwarereset. Wofür braucht man bei einem AVR einen "Softwarereset". Ich habe die Frage schon oft gehört, aber noch nie einen echten Grund.
Hallo, wie "bedienst" Du denn den WatchDocTimer während des Programm laufs? Wie schnell springt der WatchDocTimer an und resetet den AVR µC ? Du musst nun strikt nicht blockierend dein Programm gestallten und "lange" Delays sind ab sofort nicht mehr erlaubt. Das gilt an vielen Stellen, (LCD Grafik) Ausgaben, UART RX/TX usw. Man findet sich i.A. in einer Endlosschleife wieder, die ein deterministisches Zeitverhalten hat und haben muss ! Marco G. schrieb: > Wie mache ich das am elegantesten? wenn er über die uart einen > bestimmten string empfängt geht er in einen programmabschnitt, der > solange wartet, bis der watchdog auslöst? Das muss Du bitte noch erklären ? Wieso soll der AVR µC resetten ?
Benutzt du den watchdog denn sonst im "normalen" Programm? Wenn nicht, startest du den dann einfach und schickst das Programm in eine Endlosschleife. Wenn ja nur Endlosschleife (while(1);)
Vielleicht für Dich ein neuer Tipp, wenn man einen AVR µC wirklich einem Hardware Reset aussetzen möchtet, dann verbindet man den /Reset Eingang mit einem GPIO Pin und zieht diesen auf low. Der Rest kommt dann von selbst.
Marco G. schrieb: > Ich hatte den > watchdog dann bei den Fuses entfernt, bis ich einmal die Versorgung > abgeschaltet hatte war der watchdog aber anscheinend noch aktiv. Das ist so gewollt. Wenn du die Watchdog-Aktiv Fuse zuruecksetzt muss du die Versorgungsspannung kurz abschalten sonst bleibt der Aktiv. Kann man so auch im Datenblatt nachlesen.
@Rainer B Danke für den Link. @H.Joachim Seifert Nein, normalerweise wird er im normalen Programm nicht benutzt. Es soll nur die Möglichkeit geben den uC über BT zu reseten, da über diese Schnittstelle auch einige Konfigurationen vorgenommen werden können, bei denen ich es für besser halte einen "vernünftigen" Reset zu benutzen als eine Updatefunktion der entsprechenden Register. Wäre das das so in etwa was du gemeint hattest? (Pseudocode)
1 | if(eingegengener String == erwarteter String) |
2 | {
|
3 | watchdog einschalten |
4 | while(1) |
5 | {
|
6 | }
|
7 | }
|
@ Karl M. Danke für den Tipp, der war mir aber nicht neu ;)
Jo, genauso. Ich benutz das auch, um den Bootlader aus der Applikation zu starten.
Hi, Marco G. schrieb: > wenn er über die uart einen > bestimmten string empfängt geht er in einen programmabschnitt, der > solange wartet, bis der watchdog auslöst? könnte IMHO so gehen. Er initialisiert dann aber die Schnittstelle (UART) wieder neu. (MCU sollte bei .org 0x0000 wieder anfangen.) siehe auch: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_Watchdog ciao gustav
@H.Joachim Seifert Ok, dann werde ich das mal so implementieren. Scheint eine ganz robuste Lösung dafür zu sein. @Karl B. Das ist in Ordnung, dass die Schnittstelle neu initialisiert wird. Das wird auf der Gegenseite berücksichtigt.
Arduino F. schrieb: > Wofür braucht man bei einem AVR einen "Softwarereset". Für dasselbe wie bei jedem anderen Microcontroller auch. Um das System neu zu starten beispielsweise. Typischer Anwendungsfall: Alles auf Werkseinstellungen setzen und dann neu starten. Oder um das System in einen kontrollierten Zustand zu kriegen, wenn die Applikation sich aufhängt. Dafür ist ein Watchdog gedacht.
Netterweise kannst du die Resetquelle am Programmstart auch noch feststellen und unterscheiden, ob es nun ein PowerOn oder der (in deinem Fall gewollte) watchdog der Auslöser ist.
Nop schrieb: > Für dasselbe wie bei jedem anderen Microcontroller auch. Um das System > neu zu starten beispielsweise. Typischer Anwendungsfall: Alles auf > Werkseinstellungen setzen und dann neu starten. > > Oder um das System in einen kontrollierten Zustand zu kriegen, wenn die > Applikation sich aufhängt. Dafür ist ein Watchdog gedacht. Komisch. Beides kriege ich problemlos immer auch ohne Watchdog hin. Oder eigentlich nur Punkt 1. Denn Punkt 2 tritt überhaupt erst garnicht auf, wenn man einfach mal die Bugs in der verschissenen Anwendung sucht und beseitigt, bevor man sie auf die Menschheit losläßt...
c-hater schrieb: > Denn Punkt 2 tritt überhaupt erst garnicht auf, > wenn man einfach mal die Bugs in der verschissenen Anwendung sucht und > beseitigt, bevor man sie auf die Menschheit losläßt... Erstens: Abhängig von der Anwendung und der Umgebung, in der sie läuft, ist "Bugs finden" garnicht so einfach. Ist die Bugsuche teurer als der mögliche Schaden durch den Bug mal der Anzahl des Auftretens, lohnt sie sich zudem nie. Zweitens: Abhängig von den Kosten (Schäden), die ein möglicherweise existierender, aber nicht entdeckter Bug verursachen kann, ist ein Watchdog als Failsafe durchaus sinnvoll. Formale Verifikation ist eine Sache, IoT und TTM eine andere.
Ich mache das auf STM32, aber AVR kann sowas ja auch. Wenn beim Hochfahren die Reset-Analyse ergibt, daß der Watchdog die Ursache ist und nicht vor dem Reset gespeichert wurde, daß ein absichtlicher Watchdog-Reset stattfinden soll, dann wird das im Fehlerspeicher geloggt. Dadurch weiß man überhaupt erst, daß ein Problem vorhanden ist, welches man debuggen muß. Und nein, nicht alle Applikationen sind ein bißchen IO und fertig, wo das mehr oder weniger trivial testbar ist. Mitunter tauchen solche Issues auch erst bei Dauerbetrieb nach ein, zwei Monaten auf. Im Testfeld wird aber, damit die Tests überhaupt reproduzierbar sind, zwischen den Testfällen das Gerät neu gestartet. Das wird dann regelmäßig ein Gehacke zwischen Kunde ("geht nicht"), Entwicklern ("geht im Labor"), Testfeld ("alles bestanden") und Finance ("fürs Rumstochern auf Verdacht gibt's kein Budget"). Klingt häßlich, aber das ist doch die Realität. Gib dem Kunden mit so einem Fehlerlog die Möglichkeit, das zu belegen, dann ist zumindest dieses Pingpong beendet, und es ist klar, da muß was gemacht werden.
Ich habe jetzt versucht den Reset in der Software zu Implementieren. Leider funktioniert es nicht wie gewünscht. Hier mal mein Code:
1 | if (strstr(Received_String, "RST")) |
2 | {
|
3 | wdt_enable(WDTO_15MS); |
4 | |
5 | while(1) |
6 | {
|
7 | |
8 | }
|
9 | }
|
Leider hängt der Controller dann komplett fest und ich muss ihn neu programmieren anstelle eines Resets. Habe ich noch eine Zeile vergessen?
Marco G. schrieb: > Leider hängt der Controller dann komplett fest Wenn man partout nicht ins Datenblatt schauen will, kann man das auch in der <wdt.h> nachlesen: " Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms). It is therefore required to turn off the watchdog early during program startup, the datasheet recommends a sequence like the following: " usw.
Arduino F. schrieb: > Marco G. schrieb: >> Trotzdem bräuchte ich neben der BOD auch noch einen >> Softwarereset. > Wofür braucht man bei einem AVR einen "Softwarereset". > Ich habe die Frage schon oft gehört, aber noch nie einen echten Grund. Ich hatte ein :-D Atmega32u4, Reset des µC zum einfachen Disconnect und Wechsel des USB-Descriptor und Reconnect mit diesem. Und sonst, zum Reset und Wechsel in den Bootloader wird das auch oft genutzt.
Hatte wirklich nur eine Zeile vergessen:
1 | MCUSR = 0; // <-vergessen |
2 | wdt_disable(); // <- vorhanden, vor der eigentlichen Pin-Init |
Draco schrieb: > Ich hatte ein :-D > > Atmega32u4, Reset des µC zum einfachen Disconnect und Wechsel des > USB-Descriptor und Reconnect mit diesem. Ich hätte noch Verständnis dafür, wenn man das mit V-USB (oder einer vergleichbaren Soft-USB-Implementierung) so löst. Wer das hingegen mit einem 32U4 so lösen muss, der kann einfach mal nur nicht programmieren. Oder ist schlicht zu faul dazu, es richtig zu machen... War wohl im per C&P "geschriebenen" "eigenen" Code so nicht vorgesehen...
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.