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?
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(eingegengenerString==erwarteterString)
2
{
3
watchdogeinschalten
4
while(1)
5
{
6
}
7
}
@ Karl M.
Danke für den Tipp, der war mir aber nicht neu ;)
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.
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.
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...
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang