Hallo, ich komme hier mit einem ATmega16 und seinem Watchdog nicht ganz klar, vielleicht könnt ihr mir hier ein wenig unter die Arme greifen. Auf dem ATmaga16 läuft ein Bootloader der als erstes beim reboot erkennt ob es sich um einen Watchdog-Reset handelt. Dies erkenne ich durch das WDRF-Flag im MCUCSR wobei ich das Register in einer Variable zwischenspeichere wie es in der Doku avrlib vorgeschlagen wird. Sobald sich ein Fehler im Bootloader befindet und durch den Watchdog resettet wird, wird das korrekt erkannt. Wurde aber vom Bootloader die eigentliche Firmware gestartet und in dieser tritt dann ein Watchdog-Reset auf, wird das nicht erkannt. Ich hoffe ich hab mich verständlich ausgedrückt und ihr könnt mir weiterhelfen. Die bisherigen Threads im Forum sowie der Artikel über den Watchdog haben mich hierbei leider nicht weitergebracht. Vielen Dank im Voraus.
>Die bisherigen Threads im Forum sowie der Artikel über den Watchdog >haben mich hierbei leider nicht weitergebracht. Das wundert nicht, schließlich ist das von dir beschriebene Verhalten so nicht erklärbar. Dem watchdog ist es herzlich egal, wann und wo er zuschlägt, es wird immer mit gesetztem Flag im MCUCSR-Register ein Reset ausgelöst. Bist du sicher, daß der wd nicht in der Firmware deaktiviert ist und gar nicht zuschlägt, bzw. der Reset nicht vom wd kommt, sondern woanders her, und dazu die ISR feht? Oliver
.. zu früh abgeschickt. ...sondern ein Interrupt ausgelöst wird, und dazu die ISR feht? Oliver
Der Watchdog kann nur einem gehören. Entweder dem Bootloader oder der Applikation. Üblicher Weise geht man davon aus, daß ein Bootloader getestet ist, da er sich nicht selber überschreiben kann. Eine Fehlerkorretur ist daher nicht mehr möglich. Also ignoriert der Bootloader den Watchdog und damit gehört er der Applikation. Ist der Watchdog aktiv, wird er vom Bootloader nur getriggert, damit der Download nicht abgebrochen wird. Der Bootloader wertet auch das MCUCSR nicht aus. Ihm ist es egal, ob er durch ein Power-On oder durch die Applikation per Watchdogreset gestartet wurde. Es ist dadurch auch ein Update möglich, ohne das Gerät auszuschalten. Peter
@Oliver Der Watchdog ist in der Firmware aktiviert, das sehe ich da der Bootloader ne Nachricht schickt wenn der ATmega rebootet. Der Bootloader läuft ohne Interrupts und die Testfirmware hat auch keine aktiviert.
Der ATmega ist in den Fusebits so programmiert das er bei einem Reboot automatisch den Bootloader an Adresse 0x3800 startet. Der Bootloader sieht prinzipiell so aus:
1 | uint8_t mcucsr_mirror __attribute__ ((section (".noinit"))); |
2 | |
3 | void get_mcucsr(void) __attribute__((naked)) __attribute__((section(".init3"))); |
4 | |
5 | void get_mcucsr(void) |
6 | {
|
7 | mcucsr_mirror = MCUCSR; |
8 | MCUCSR = 0; |
9 | wdt_disable(); |
10 | }
|
11 | |
12 | int main(void) |
13 | {
|
14 | if bit_is_set(mcucsr_mirror, WDRF) |
15 | {
|
16 | // LED an
|
17 | }
|
18 | wdt_enable(WDTO_2S); |
19 | wdt_reset(); |
20 | ...
|
21 | jmp firmware |
22 | ...
|
23 | return 0; |
24 | }
|
Die Firmware sieht prinzipiell so aus:
1 | int main(void) |
2 | {
|
3 | wdt_enable(WDTO_2S); |
4 | wdt_reset(); |
5 | // LED aus
|
6 | while (1) |
7 | {
|
8 | _delay_ms(10); |
9 | }
|
10 | return 0; |
11 | }
|
Da der Watchdog in der Mainschleife nicht geresettet wird schlägt der Watchdog zu aber wie gesagt das WDRF Flag ist nicht gesetzt. Ändere ich den Bootloader und schicke ihn in ne Endlosschleife statt dem Start der Firmware schlägt der Watchdog auch zu aber hier wird das WDRF Flag gesetzt.
gast schrieb: > Da der Watchdog in der Mainschleife nicht geresettet wird schlägt der > Watchdog zu aber wie gesagt das WDRF Flag ist nicht gesetzt. Darf ja auch nicht, der Bootloader hat es ja gelöscht. Wie gesagt, wenn der Watchdog der Applikation gehören soll, darf der Bootloader das MCUCSR nicht löschen !!! Der Bootloader braucht den Watchdog auch nicht, da er ja getestet sein sollte. Peter
Ich sichere es doch in einem anderen Byte bevor ich es lösche. Oder nicht?
Ich kann mich nur wiederholen, wenn direkt nach einem Reset das WDRF-Bit nicht gesetzt ist, wurde der Reset nicht durch den Watchdog ausgelöst. Egal, ob Bootloader vorhanden, oder nicht. >Der Bootloader läuft ohne Interrupts und die Testfirmware hat auch keine >aktiviert. Wenn überhaupt kein Reset-Flags in MCUCSR gesetzt ist, bleibt ausser einem irrlichternden ínternem Interrupt nicht viel als Ursache übrig. Oliver
Der Bootloader soll praktisch erkennen das die Firmware vom Watchdog geresettet wurde und diese nach x Resetts nicht mehr starten. Die Firmware interessiert es nicht wie oder warum es einen Resett gegeben hat. Danke für euere Mühe.
Hast du denn mal die anderen Reset-Flags überprüft? Oliver
Ja, die anderen Reset-Flags funktionieren und werden korrekt erkannt. Externer Reset und Brown-out habe ich schon getestet. In dem speziellen Fall das die Firmware resettet wird steht allerdings 0 im Register.
gast schrieb: > Der Bootloader soll praktisch erkennen das die Firmware vom Watchdog > geresettet wurde und diese nach x Resetts nicht mehr starten. Dir ist aber klar, dass dieser Schuss nach hinten losgehen kann? Deine Leute in der Produktion werden es dir danken, wenn deine Steuerung nach einem 3/4 Jahr nicht mehr funktioniert, nur weil es in diesem Zeitraum 10 Neustarts wegen Watchdog gegeben hat. Nicht jede auf den ersten Blick gute Idee ist auch wirklich gut.
gast schrieb: > Der Bootloader soll praktisch erkennen das die Firmware vom Watchdog > geresettet wurde und diese nach x Resetts nicht mehr starten. Es ist aus Deinem Schnipselchen aber nicht ersichtlich, wie Du das machst. Und auch, ob die Applikation überhaupt weiß, wo sich das Byte befindet und daß sie es nicht anfassen darf. SW-Fehler lassen sich ohne den Code nunmal nicht lösen. Bei solchen komplexen Sachen ist ein compilierbarer Code als Dateianhang immer besser. Und natürlich auch die speziellen Make-Einstellungen. Peter
Hi, Peter, Du: "Der Watchdog kann nur einem gehören. Entweder dem Bootloader oder der Applikation." Das ist mir unverständlich. Weil Bootloader und Applikation niemals zugleich ablaufen - jedenfalls im AVR. Sondern der Bootloader kann den WD aktivieren, dann wird er rechtzeitig zurückgesetzt oder löst einen Reset aus. Genauso, wenn Bootloader seine Schuldigkeit getan und die Anwendung aufgerufen hat. Ein Wechselspiel, wie es "gast" wohl vorschwebt, habe ich mit einer Zustandsvariablen im EEPROM realisiert. Natürlich so, dass nur in Ausnahmefällen geschrieben wird. Ciao Wolfgang Horn
>In dem speziellen Fall das die Firmware resettet wird steht allerdings 0 >im Register. Kannst du das Testprogramm (Bootloader und Firmware) hier vollständig kompilierbar zeigen? Oliver
Hier die Firmware: Ich habe sie komplett zusammengekürzt, aber mit ihr tritt der Fehler genauso auf.
1 | #include <avr/wdt.h> |
2 | #include <avr/eeprom.h> |
3 | #include <util/delay.h> |
4 | |
5 | int main(void) |
6 | {
|
7 | wdt_enable(WDTO_2S); |
8 | wdt_reset(); |
9 | if (eeprom_read_byte((uint8_t *) 0x0016) != 0x01) |
10 | {
|
11 | eeprom_write_byte((uint8_t *) 0x0016, 0x01); |
12 | }
|
13 | while (1) |
14 | {
|
15 | // wdt_reset();
|
16 | _delay_ms(10); |
17 | }
|
18 | }
|
gast schrieb: > Ich habe sie komplett zusammengekürzt, aber mit ihr tritt der Fehler > genauso auf. Und was ist denn überhaupt der Fehler? Dieses Programm schreibt nur ne 1 an Adresse 22. Völlig egal was der Watchdog oder die Resetquelle macht. Peter P.S.: Es kann sein, daß der Compiler Adresse 0 nicht benutzt und es an Adresse 23 schreibt.
Diese Firmware wird durch den Watchdog rebootet weil in der Schleife wdt_reset() nicht aufgerufen wird. Der ATmega16 rebootet also. Durch den Reboot wird der Bootloader gestartet. Wenn ich im Bootloader das WDRF Flag im MCUCSR Register prüfe, dann ist das nicht gesetzt. Die Frage ist warum ist es nicht gesetzt. Alle anderen Flags werden in dem Register ja gesetzt wenn ein entsprechendes Ereignis aufgetreten ist.
eeprom... Welche WinAVR-Version bzw. avrlibc-Version nutzt du? Es gibt da eine (?) Version mit einem Bug in den eeprom-Routinen, die erzeugen ungewollte Interrupts. (Genaugenommen steckt der Bug im Silikon, die avrlibc umgeht ihn nur nicht. Details stehen in den AVR-errata). Oliver
Ick sach ma, diese endlose Schnipseljagd bringt uns nicht einen Jota weiter. Benutze den Dateianhang und poste zur Abwechslung endlich mal was richtiges. Und wenn das EEPROM-Rumgemache keinen Effekt hat, dann mußt Du uns auch nicht damit verwirren. Also alles unnötige raus! Nicht auskommentieren, sondern löschen! Und natürlich noch die standard Problembeschreibungspunkte: - wie funktioniert das Programm? - was soll wann wie passieren? - was passiert statt dessen? Was macht denn überhaupt das (".noinit") und (".init3")? Was spricht dagegen, es ganz profan im Main auszulesen? Peter
>Durch den Reboot wird der Bootloader gestartet. Wenn ich im Bootloader >das WDRF Flag im MCUCSR Register prüfe, dann ist das nicht gesetzt. >Die Frage ist warum ist es nicht gesetzt. Nein. Das ist nicht die Frage, und war sie auch noch nie. Nach einem WD-Reset ist das WDRF-Flag gesetzt. Immer. Punkt. So kaputt kann der AVR gar nicht sein, daß nur dieses eine Flag komisch rumspinnt. Die Fragen können sein: Wer löst den Reset bzw. den Sprung auf den Reset-Vektor aus, wenn nicht der WD? Wer oder was löscht das MCUCSR-Register, bevor du da dran kommst? Warum klappt das Auslesen des Registers nicht? Oliver
Hallo, Vielen Dank für euere Mithilfe. Ich habe das Problem gefunden und behoben. Aus irgendeinem Grund war der Bootloader nicht mehr in der Bootloadersektion sondern im normalen Firmwarebereich. Somit wurde beim flashen der Firmware ein Teil des Bootloaders überschrieben. Da die Testfirmware sehr klein ist hatte das wohl nur diese doofe Auswirkung.
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.