Forum: Mikrocontroller und Digitale Elektronik Datenbackup bei Watchdog Reset - Atmega


von Hannes J. (hannes_j)


Lesenswert?

Hi,

ich würde gern mal eure Meinung hören, welche Option des Datenbackups im 
Fehlerfall die bessere ist.

Ich habe eine Uhr auf Basis eines Atmega 328p gebaut und programmiert. 
Programmiert habe ich in C++. C++ einfach um das ganze objektorientiert 
machen zu können. Da ich die Uhr auch als Wecker benutzen will und der 
natürlich zuverlässig sein soll, habe ich also einen Watchdog 
aufgesetzt. Alles tip top.

Es soll nun im Falle eines Watchdog-RESET die Uhrzeit, Alarm und eine 
handvoll Einstellungen gesichert und anschließend wiederhergestellt 
werden. Ich sehe hier prinzipiell 2 Möglichkeiten.
1. Ich richte einen Watchdog-Interrupt ein, der alles nötige in den 
EEPROM schreibt. Beim Start wird festgestellt ob ein Watchdog-RESET 
aufgetreten ist und wenn ja laden wir wieder alles aus dem EEPROM
2. Man definiert eine handvoll Backup-Variablen nach dem Schema
1
time_t _timeBackup __attribute__ ((section(".noinit")));
Sollte ein Watchdog-RESET auftreten, bleibt deren Wert erhalten und kann 
anschließend wiederhergestellt werden.

Prinzipiell kommt mir Möglichkeit 2 einfacher vor, allerdings bin ich am 
grübeln, ob es da Probleme bzgl fehlender Initialisierung o. Ä. geben 
könnte. Die Menge der zu sichernden Daten beläuft sich auf ca. 10 Byte. 
Meinungen?

: Bearbeitet durch User
von S. Landolt (Gast)


Lesenswert?

Watchdog bei einer simplen Uhr? Wass nich all gibbt!

Bei meinem Wecker, assemblerprogrammiert, gibt es nur das Problem des 
Netzausfalles (da eben netzgebunden), und da hilft nur Methode 1, aber 
auch die nur bei entsprechender Berücksichtigung in der Hardware.

von Einer K. (Gast)


Lesenswert?

Hannes J. schrieb:
> Sollte ein Watchdog-RESET auftreten, bleibt deren Wert erhalten und kann
> anschließend wiederhergestellt werden.

Machbar!
Aber dann nicht diverse Sicherungsmaßnahmen vergessen...

Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr 
verlassen.

von Dr. Sommer (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr
> verlassen.

Insbesondere nicht, ob die Daten nicht genau im Moment des 
Watchdog-Resets bearbeitet wurden und somit inkonsistent sind. Wenn der 
Watchdog ein derartiges Problem darstellt, sollte man vielleicht lieber 
den Code korrigieren sodass der Watchdog nicht auslöst.

von Hannes J. (hannes_j)


Lesenswert?

Dr. Sommer schrieb:
> Arduino Fanboy D. schrieb:
>> Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr
>> verlassen.
>
> Insbesondere nicht, ob die Daten nicht genau im Moment des
> Watchdog-Resets bearbeitet wurden und somit inkonsistent sind. Wenn der
> Watchdog ein derartiges Problem darstellt, sollte man vielleicht lieber
> den Code korrigieren sodass der Watchdog nicht auslöst.

Ich gehe schon davon aus, dass der Watchdog nicht auslöst, keine Sorge. 
Er ist ganz watchdog like dazu da um im besten Fall niemals gebraucht zu 
werden, im Fall der Fälle aber da zu sein. Und da die Uhr schon einige 
Features hat, begonnen bei der Helligkeitsregelung der 
7-Segment-Anzeigen entsprechend der Umgebungs-Helligkeit bis hin zum 
Zeitempfang über WLAN mittels I2C-Kommunikation mit einem ESP8266, sowie 
Sommer- / Winterzeit-Management kann man eben nie ausschließen, dass es 
nicht im Laufe der nächsten Jahre eben doch mal irgendwo hängt.

Okay das schreiben während eines RESET ist ein wichtiger Punkt. Also 
sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben 
werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde. Beim 
Start werden die Daten natürlich nur angerührt wenn im MCUSR das WDR 
Flag gesetzt ist. Außerdem würde ich ein Flag setzen um sicherzugehen, 
dass überhaupt Daten gespeichert wurden. Sollte dann passen oder?

von Einer K. (Gast)


Lesenswert?

Hannes J. schrieb:
> Also
> sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben
> werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde.

Du weißt nie, wann er zuschlägt.
Da irgend welche Annahmen zu treffen, ist unsinnig.


Hannes J. schrieb:
> Sollte dann passen oder?

Hmmm ....

Stopfe alle Daten in eine Struktur
Berechne eine Prüfsumme(oder vergleichbares) und schreibe diese auch.

Vor dem nutzen der Daten, dann die Merkmale prüfen.
Das gilt übrigens auch fürs EEPROM.

von Jacko (Gast)


Lesenswert?

Bei einer Weck-Uhr die aktuelle Uhrzeit zum Watchdog-Reset zu
speichern ist doch Quatsch.

Die Einstellungen, wie Weckzeit - und was auch immer - speichert
man vernünftigerweise sofort in's EEPROM. Das kannst du 100.000
mal machen, also über 27 Jahre 10 mal am Tag.

Die Zeit kannst du aber nur über DCF, GPS, oder Handeingabe wieder
auf den aktuellen Wert bringen.

Einen Wecker würde ich dann lieber (auch nachts) wild alarmieren
lassen, dass er nach einem Stromausfall-, oder Watchdog-Reset
keine aktuelle Zeit mehr hat.

Sonst verpasst du sicher den Start zu deiner sündhaft teuren
Traumreise...

von Chlorophor (Gast)


Lesenswert?

Ein Watchdog Reset fuer eine Uhr bringt gar nicht. Denn der besagt, dass 
der Reset kam. Was du willst ist ein Interrupr bevor der Power weggeht. 
Und in diesem schreibst du dein Zeug ins EEPROM. Bei einem Powerup liest 
du die Daten vom EEPROM. Ohne zu wissen, was dazwischen war.
Am Sinnvollsten nimmst du einen Uhrenbaustein mit einer kleinen 
Batterie. Die hat auch vielleicht 64 byte Speicher. Der Vorteil .. sie 
laeuft ab Batterie durch einen Powerunterbruch weiter.

von Thorsten S. (thosch)


Lesenswert?

Jacko schrieb:
> Die Einstellungen, wie Weckzeit - und was auch immer - speichert
> man vernünftigerweise sofort in's EEPROM. Das kannst du 100.000
> mal machen, also über 27 Jahre 10 mal am Tag.
Full ACK.
In meinen Designs verwende ich dafür meist ein per SPI angeschlossenes 
FRAM oder MRAM, dann muss man nicht auf Schreibvorgänge eines lahmen 
EEPROMs warten und hat auch bei häufigerem Schreiben keine 
Lebensdauer-Problematik.

> Die Zeit kannst du aber nur über DCF, GPS, oder Handeingabe wieder
> auf den aktuellen Wert bringen.
Die naheliegendste und einfachste Möglichkeit hast du nicht erwähnt:
Ein RTC-Chip, gepuffert mit Batterie  Akku  SuperCap, je nach 
Anforderungen an die überbrückbare Stromausfalldauer.

Manche RTCs haben sogar einen Alarmkomparator, der einen Ausgang 
ansteuern kann. Wenn der μC den jeweils nächsten Alarm da reinlädt, kann 
man über diesen Ausgang sogar einen Notfall-Alarm z.B.über einen 
batteriegespeisten Piezoheuler auslösen, ohne dass der μC zur Alarmzeit 
laufen muss...

Wenn der Watchdog den Controller resettet hat, ist irgendwas im Argen, 
da würde ich auch eher einen Alarm auslösen, bzw. einen Zähler im FRAM, 
EEPROM oder im CMOS-RAM der RTC inkrementieren und bei Überschreiten 
eines Schwellwertes Alarm schlagen, der dem Benutzer den Fehler meldet.
Wenn man z.B. mit jedem Tag Uptime des Controllers den Zähler 
dekrementiert (nur bis 0), kann man den Alarm auch nur bei mehr als 
einem Watchdog-Event pro Tag auslösen...

von Stefan F. (Gast)


Lesenswert?

Ich würde auch sagen, dass eine Erkennung von Stromausfall eher Sinn 
macht. Der Watchdog triggert dann aber schon zu spät. Den Stromausfall 
musst du erkennen, bevor die Pufferkondensatoren erschöpft sind und die 
Spannungsversorgung absackt. Also vor dem Spannungsregler, besser noch 
sogar vor dem Gleichrichter.

Wenn mein µC ohne Watchdog nicht dauerhaft funktioniert, ist entweder 
das Programm oder die Hardware fehlerhaft. Als Entwickler möchte ich das 
mitbekommen, der µC soll nicht klamm-heimlich einfach neu starten.

Normalerweise laufen Mikrocontroller ohne Ausfall durch - jahrelang. 
Dass sie sich unerwartet zwischendurch aufhängen ist eher eine seltene 
Ausnahme.

von Hannes J. (hannes_j)


Lesenswert?

Arduino Fanboy D. schrieb:
> Hannes J. schrieb:
>> Also
>> sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben
>> werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde.
>
> Du weißt nie, wann er zuschlägt.
> Da irgend welche Annahmen zu treffen, ist unsinnig.
>
>
> Hannes J. schrieb:
>> Sollte dann passen oder?
>
> Hmmm ....
>
> Stopfe alle Daten in eine Struktur
> Berechne eine Prüfsumme(oder vergleichbares) und schreibe diese auch.
>
> Vor dem nutzen der Daten, dann die Merkmale prüfen.
> Das gilt übrigens auch fürs EEPROM.

Perfekto, so mache ich das.


Zu allen Kommentaren die später noch kamen kann ich nur sagen, ihr habt 
entweder nicht alles komplett gelesen was ich geschrieben habe, es nicht 
verstanden oder ihr stellt irgendwelche Aussagen auf Grund von 
Vermutungen über mein Design an, von dem ihr letztlich nicht die 
geringste Ahnung habt. Aber das gehört wohl zu mikrocontroller.net, dass 
jeder Thread iwann in sinnlosem Kluggescheiße endet.

von Stefan F. (Gast)


Lesenswert?

> ihr habt entweder nicht alles komplett gelesen was ich geschrieben
> habe, es nicht verstanden oder ihr stellt irgendwelche Aussagen auf
> Grund von Vermutungen über mein Design an, von dem ihr letztlich nicht
> die geringste Ahnung habt.

Wir helfen gerne. Punkt.

Wenn der Fragende (also du) zu wenig Infos über sein Projekt verrät, 
erzählen Leute aus ihrem Erfahrungsschatz Sachen, die sie für eventuell 
hilfreich halten. Ja, manchmal artet das dann zu einer regelrechten 
Rate-Orgie aus, die am Ende nur Verwirrung stiftet.

Deswegen: Lerne, deine Fragen vernünftig zu stellen, dann bekommst du 
auch vernünftige Antworten.

Im übrigens ist es in diesem Thread beinahe vorbildlich abgelaufen. Alle 
Antworten waren zum Thema passend, sind auf deine Angaben eingegangen 
und enthalten gut gemeinte Ratschläge.

von Max M. (max_m250)


Lesenswert?

Stefanus F. schrieb:
>> ihr habt entweder nicht alles komplett gelesen was ich geschrieben
>> habe, es nicht verstanden oder ihr stellt irgendwelche Aussagen auf
>> Grund von Vermutungen über mein Design an, von dem ihr letztlich nicht
>> die geringste Ahnung habt.
>
> Wir helfen gerne. Punkt.
>
> Wenn der Fragende (also du) zu wenig Infos über sein Projekt verrät,
> erzählen Leute aus ihrem Erfahrungsschatz Sachen, die sie für eventuell
> hilfreich halten. Ja, manchmal artet das dann zu einer regelrechten
> Rate-Orgie aus, die am Ende nur Verwirrung stiftet.
>
> Deswegen: Lerne, deine Fragen vernünftig zu stellen, dann bekommst du
> auch vernünftige Antworten.
>
> Im übrigens ist es in diesem Thread beinahe vorbildlich abgelaufen. Alle
> Antworten waren zum Thema passend, sind auf deine Angaben eingegangen
> und enthalten gut gemeinte Ratschläge.

Es sind doch alle notwendigen Infos da und die gestellte Frage wurde 
zufriedenstellend beantwortet.

Dann fingen plötzlich ein paar an den watchdog ansich infrage zu stellen 
und schrieben etwas von eeprom generell benutzen, was wiederum in 
Anbetracht der wenigen Infos zum gesamten Design (wohl aber ausreichend 
um die eigentliche Frage zu beantworten) ziemlich fragwürdig scheint.

Am besten ist der Kommentar von Chlorophor. Man versteht hauptsächlich 
Bahnhof, weil kein einziger halbwegs fehlerfreier Satz zu finden ist, 
aber iwas steht da von wegen man wüsste ja nicht was zwischen power off 
und power on passiert sei. Er hat offensichtlich nicht im geringsten 
verstanden worum es geht oder was ein watchdog ist.

Und als nächstes kam noch eine Fraktion die etwas von Stromausfall 
faselte, was nun wirklich völlig am Thema vorbei geht. Was hat ein 
watchdog mit fehlendem Strom zu tun? Nullum! Dann noch dein Hinweis ein 
Programm sollte ohne watchdog laufen, sonst habe man etwas falsch 
gemacht. Ja, genau das hat der TO in seinem ersten Kommentar ja selbst 
geschrieben. Es geht um eine Absicherung gegen Programmierfehler. Also 
genau das wofür das Konzept watchdog existiert.

Also so wie ich das sehe ist der TO zum Schluss etwas zickig geworden, 
aber durchaus nachvollziehbar. Alles nach Arduino Fanboy war sinnloses 
Geschwurble.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.