Watchdog geht anscheinend nach Aktivierung nicht mehr aus

Hallo

ich benötige nochmal eure Hilfe. Ich möchte von außen den Arduino neu starten können, indem ich per serieller Schnittstelle den Befehl 'R' sende. Der Watchdog springt auch an, aber dann blinkt die LED an Pin 13 schnell und nur ein Strom abschalten hilft. Durch google hab ich bisher schon finden können, das mit dem Neustart auch die Zeit für den WD auf den kürzesten Wert gesetzt wird, aber wie erreiche ich einen normalen Start?
wdt_disable(); am Anfang der setup Prozedur hat auch nicht geholfen.

Hier der Code

#include <avr/wdt.h>                                  // für Watchdog
char sKB;                                             // Serial übertragenenr Kennbuchstabe
unsigned long lWatchdogEingang = 0;                   // letzte Nachricht von außen

void setup()
{
  // Aktiviere Watchdog mit 8s Zeitkonstante
  // =======================================
  wdt_enable(WDTO_8S);

  pinMode(LED_BUILTIN, OUTPUT);

  Serial.begin(9600); 
  // Signalisieren, dass der Arduino neu gestartet wurde;
  Serial.println(F("Test-Sketch"));
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  Serial.println(F(";Setup fertig"));
}

// Loop
// ====
void loop()
{
  // internen Watchdog Streicheln
  wdt_reset();

  Serial.println(F("loop"));
  digitalWrite(LED_BUILTIN, HIGH);
  delay(200);
  digitalWrite(LED_BUILTIN, LOW);
  delay(200);
  digitalWrite(LED_BUILTIN, HIGH);
  delay(200);
  digitalWrite(LED_BUILTIN, LOW);
}


void serialEvent() {
  sKB = (char)Serial.read();
  evalSerialData();
}

void evalSerialData()
{
  switch (sKB) {
    case 'R':
      Serial.print(F("SoftwareReset"));
      // nach 8S beisst der Watchdog zu
      delay(9000);
      break;
  }
  sKB = ' ';
}

Vielen Dank für eure Unterstützung und viele Grüße

Frank

Ich sehe 2 fatale Irrtümer!

Der Erste:
Du meinst, es wäre egal, welchem Arduino man das antut!
Das ist falsch.
Aus dem Verhalten kann ich ableiten, dass es ein Nano ist.
Ein alter Nano, oder ein China Nachbau.
Kein neuer original Nano
(stimmt das?)

Der Zweite:
Die Notwendigkeit eines Software gesteuerten Reset.
Denn das ist flüssiger als Wasser.
Überflüssig.

Hallo

combie:
Der Zweite:
Die Notwendigkeit eines Software gesteuerten Reset.
Denn das ist flüssiger als Wasser.
Überflüssig.

prinzipiell stimme ich Dir da zu, wenn man es aber unbedingt will, würde ich einen freien IO über eine Diode an Reset legen, Anode an Reset. Dann eben den Pin als Ausgang/Low setzen und fertig.

Ich weiß nicht, ob er es war, aber jemand wollte man seinen AVR resetten um in den Bootloader zu kommen und den AVR seriell zu flashen. Da könnte ich mir so eine Lösung schon vorstellen um sicher zu sein, daß der Bootloader den AVR im definierten Zustand vorfindet.

Gruß aus Berlin
Michael

Wofür die Diode?

Ich glaube nicht, dass der Start des Bootloaders hier das Ziel ist.

Üblicher weise, ist der Resetwunsch, darauf beruhend, dass ein Programm abgebrochen werden soll.
Also eine Krücke, weil der/ein Automat "unvollständig" Programmiert wurde.
Nicht mehr als ein dirty Hack.

Hallo,

combie:
Wofür die Diode?

naja, man kann sich auch weglassen, nenne sie ruhig "Angstdiode". :wink:
Wenn man dann doch mal hart auf Ausgang und H setzt, kollidiert es wenigstens nicht mit irgend einer Resetbeschaltung.

Gruß aus Berlin
Michael

Hallo,
danke für die Antworten.

Es ist ein Pro Mini mit einem Atmega 168PA 16Mhz 5V.
Bevor jemand fragt, warum ich keinen Atmega 328P genommen habe, ich kannte da die Unterschiede noch nicht.

Ich weiß nicht, ob er es war, aber jemand wollte man seinen AVR resetten um in den Bootloader zu kommen und den AVR seriell zu flashen.

Nein, mein Grund ist, der Pro Mini sitzt an einer Stelle, an die ich nicht gut heran komme, hier wollte ich eine "Rückfallebene" haben. Der PC, mit dem er kommuniziert, steht auch nicht gut erreichbar, den spreche ich per RDP an.

Warum findet ihr das überflüssig? Sind keine unvorhergesehenen Fälle denkbar, die einen Reset erfordern oder bewirkt der Softwarereset nicht das selbe wie der Hardwarereset? Ich hatte über den Hardwarereset gelesen und dabei den Hinweis gefunden, dass man das auch per Software kann, und das schien mir bequemer.

PS: Interessanter Artikel zum Nano und dass es ein bekannter Fehler ist. Den habe ich leider nicht gefunden.

Vielen Dank und viele Grüße

Frank

Üblicher weise, ist der Resetwunsch, darauf beruhend, dass ein Programm abgebrochen werden soll.
Also eine Krücke, weil der/ein Automat "unvollständig" Programmiert wurde.

Das würde ich vermuten funktioniert doch nicht, da der Arduino dann in einer Schleife hängt und ich den Reset deshalb nicht ausgelöst bekomme oder?
Dann würde doch auch ResetPin per IO-Pin nicht mehr funktionieren, wenn ich das richtig verstanden habe.

Meine Vorstellung es gibt irgendwelche Störungen von Außen und ich benötige mal einen Reset.

Es ist ein Pro Mini mit einem Atmega 168PA 16Mhz 5V.

Dazu kann ich wenig sagen.... habe so ein Teil nicht.
Aber mit einem angepassten/modernen Bootloader sollte das gehen.

Warum findet ihr das überflüssig?

Weil es gegen irrationale Ängste keine technischen Lösungen gibt.

Meine Vorstellung es gibt irgendwelche Störungen von Außen und ich benötige mal einen Reset.

Wie kommst du auf die lustige Idee, dass dein Resetcode dann noch ausgeführt werden wird?

Für solche Zwecke hat man vor langen Jahren schon externe Resetkontroller incl. eigenem Watchdog erfunden.
Kosten nur ein paar Cent.

Bei Atmel hat man den Kontroller dann integriert.

Der PC, mit dem er kommuniziert, steht auch nicht gut erreichbar,

Dann schließe DTR an.
Damit kannst du den Mini jederzeit neu starten.

Um einen Reset korrekt auszuführen muß der RESET-Pin eine gewisse zeit LOW geschaltet werden. Ein Ausgang desselben Controllers tut das nicht da er durch den RESET zurückgesetzt wird.

Ein Hardwareautoreset funktioniert nicht sicher.
Falls Störungen von außen den Kontroller oder Fehler in Sketch den Controller lahmlegen ist die schaltung/Sketch falsch und der Grund muß korrigiert werden und nicht die Auswirkungen.

Grüße Uwe

Hallo,

uwefed:
Um einen Reset korrekt auszuführen muß der RESET-Pin eine gewisse zeit LOW geschaltet werden. Ein Ausgang desselben Controllers tut das nicht da er durch den RESET zurückgesetzt wird.

Ein Hardwareautoreset funktioniert nicht sicher.
Falls Störungen von außen den Kontroller oder Fehler in Sketch den Controller lahmlegen ist die schaltung/Sketch falsch und der Grund muß korrigiert werden und nicht die Auswirkungen.

Grüße Uwe

der Resetcontroller eines AVR macht das ganz ordentlich. Der Pin geht erst wieder auf Input wenn eben die Resetlogik angesprochen hat. In potenziell unsicheren Umgebungen hängt bei mir ohnehin nur ein 100n am Reset gegen GND. Außer bei DebugWire stört da da nicht und verhindert Störimpulse wegen offener Resetleitung (ISP-Anschluß) recht zuverlässig.

Ansonsten stimme ich voll zu, hier laufen zwar 3 AVR in 24/7 und ein paar Tiny-Sensoren werden alle paar Minuten geweckt und schicken per Funk ein paar Daten, aber einen Hardwarereset war bisher nicht nötig.

Gruß aus Berlin
Michael

Ein Ausgang desselben Controllers tut das nicht da er durch den RESET zurückgesetzt wird.

Das halte ich für eine Legende!
Und bekanntlich werden Legenden nicht davon wahrer, wenn sie sie tausend mal erzählt werden.

Es ist wahr, steht auch im Datenblatt, dass die Resetleitung eine kleine Weile auf Low braucht, damit ein Reset erkannt wird. Das ist dem Spike Filter geschuldet.
Es ist auch wahr, dass der interne Resetautomat, als eine der ersten Aktionen, die Pins weg schaltet.
Aber das kann er ja nur, wenn er gestartet wurde.
Und damit ist klar, dass der Reset erkannt wurde.
Wenn der Reset erkannt wurde, wird er auch durchgeführt.
Bis zum bitteren Ende.
Zu halben/angefangene, und dann versagenden Resets, findet sich nichts.
Außer Mundpropaganda.

Oder andersrum:
Bis jetzt habe ich noch keine belastbare Information dazu gefunden, dass ein AVR, bei zu kurzem Reset, in einem undefinierten Zustand landet.
Hast du belastbare Informationen dazu?

Wenn du mich überzeugen kannst, dann werde ich meinen Irrtum gerne eingestehen, und ab dann das Gegenteil behaupten.

Hi

Worin besteht denn jetzt akut das Problem?

Nein, ich meine nicht, daß der AVR, nachdem der Wachhund gebissen hat, doch ganz gerne wieder 'normal' zu nutzen wäre.
DAS verlange ich sogar von einem µC - hier geht es ab Start nur darum, wie ich den Wachhund AUS bekomme, bevor Dieser wieder bissig wird.

Ob oder Wer Das jemals gebraucht hat, oder Wer Das niemalsnicht und auch Dann nur eher selten machen würde - Alles rein subjektiver Schwurbelkram.

Könnt Ihr den Wachhund beim Neustart AUS-schalten, oder nicht?

Ja -> Hier bitte den dazu notwenigen Vorgang dateiliert aufzeigen
Nein -> Macht Nichts, man muß nicht Alles wissen - man muß aber auch nicht Alles verteufeln :wink:

... und ja, wenn der Wachhund zubeißt, wird's irgendwo im Sketch nicht passen, der Grund des Fehlers wohl den Ursprung VORM Monitor haben - ja jesses - genau dafür habe ich den Wachhund, daß Der mir die Karre wieder auf die Straße bringt.

Danke für's Lesen - noch mehr Dank für's Verstehen / Einsehen.

MfG

Worin besteht denn jetzt akut das Problem?

Der Wachund wird (absichtlich) ausgelöst.
while(!stromausfall)
{
 Der Bootloader handelt das nicht ab.
 Wärend der Bootloader Bereitschaft wird wieder der Wachhund ausgelöst
}

Abhilfe:

  • Anderer Bootloader
  • Bootloader töten

HVprogramming wenns über ISP nicht geht weil der Wachdog schneller zubeißt als der Upload beginnt.

Grüße Uwe

Hallo,

uwefed:
HVprogramming wenns über ISP nicht geht weil der Wachdog schneller zubeißt als der Upload beginnt.

Bei ISP greift kein Watchdog weil ISP mit Reset = Low läuft.

Ich muß direkt mal testen, was bei einem Arduino mit Bootloader und aktiviertem Watchdog passiert.

Gruß aus Berlin
Michael

Ich muß direkt mal testen, was bei einem Arduino mit Bootloader und aktiviertem Watchdog passiert.

Gute Idee!
Das muss man selber mal "gefühlt" haben.

Ich kann in die Zukunft schauen:
Der UNO steckt das weg.
Die alten Nano versagen daran.

Bei den anderen wäre ich selber an dem Ergebnis interessiert!

Dieser Beitrag scheint mir relevant zu sein. Probier mal Optiboot aus.

Wow, ich hätte nicht gedacht, hier eine solche Diskussion zu starten. Ist aber sehr lehrreich, deshalb vielen Dank.

Da ich noch nie einen Bootloader gebrannt habe, habe ich mir zuerst ein paar Infos angelesen, aber jetzt komme ich nicht weiter. Evtl. habe ich zuviele verschiedene Informationen gelesen.
Ich habe mich an dieser Anleitung orientiert: Pro-Mini-Klone: Bootloader flashen | Hausautomation mit Arduino
Der ArduinoISP-Sketch ist auf dem Uno.

Welche Einstellungen zum Bootloader brennen brauche ich?

Programmer: Arduino as ISP ist klar

Was wähle ich als Board für den China-Pro Mini mit ATMEGA168PA?

Pro Mini, wäre doch der vorhandene oder?

Wähle ich nach der Empfehlung mancher Seiten "Arduino/Genuino Uno"

erhalte ich folgende Fehlermeldung:

Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Uno"

avrdude: Expected signature for ATmega328P is 1E 95 0F
Double check chip, or use -F to override this check.
Fehler beim Brennen des Bootloaders.

Heißt doch, dass ein ATmega328P erwartet wird und ich den nicht für einen ATmega168 verwenden kann oder?

Dann findet sich die Empfehlung, Optiboot auszuprobieren. Bei der Suche, wie das geht, findet man aber auch den Hinweis, dass an Version 1.6.20 der AVR Boards auf Optiboot umgestellt worden sei.
Da bei mir die Version 1.6.21 installiert ist, hätte ich die schon?

Könnt ihr mir bitte aus dem Informationschaos helfen und mir sagen, was richtig/falsch ist und mir sagen, wie ich weiter komme?

Vielen Dank und viele Grüße

Frank

Hat niemand Zeit oder habe ich zu viele Fragen gestellt? :frowning:

F200:
Hat niemand Zeit oder habe ich zu viele Fragen gestellt? :frowning:

Was mich angeht: Ich habe diesen Thread erst jetzt entdeckt.

Kannst Du nochmal kurz beschreiben, was genau Du für Hardware hast und was Du erreichen möchtest? Evtl. hilft Dir mein Geschreibsel hier.

Gruß

Gregor