Software-Reset ohne Watchdog und JumpToZero

[Philippp (Gast)]

Hi,
ich habe einen Mega644 und möchte nach einem "echten" Watchdog Reset 
darüber informiert werden. Klappt auch sehr gut mit WDRF im MCUSR 
Register.
Problem bei der Sache ist jedoch, dass anwendungsbedingt hinundwieder 
Software-Resets notwendig sind. Diese funktionieren im Moment per 
Watchdog-Timeout. JumpToZero ist wegen der Komplexität des Programmes 
nicht möglich. Unglücklicherweise wird so auch das WDRF Flag gesetzt und 
ich kann nicht unterscheiden ob es ein "böser" Watchdog-Reset war.
Kennt jemand eine Lösung für dieses Problem?
Fanke im Vorraus,
Grüße

[Nils S. (kruemeltee)]

IO Pin auf Reset legen.

[Klaus (Gast)]

Philippp schrieb:
> Unglücklicherweise wird so auch das WDRF Flag gesetzt und
> ich kann nicht unterscheiden ob es ein "böser" Watchdog-Reset war.

Eine Speicherstelle oder ein Bit suchen, das einen Watchdog-Reset 
überlebt, und dort ein Flag setzen.

MfG Klaus

[Philippp (Gast)]

Danke für die Antworten.
Lösung mit dem Pin ist nicht möglich, da die Hardware vorgegeben ist.

Habe es nun mittels noinit-section im Speicher gelöst

static uint8_t isSoftwareReset _attribute_ ((section (".noinit")));

[Klaus W. (mfgkw)]

Hatten wir nicht heute schon das Thema GPIOR0/1/2?
Vielleicht geht es mit denen.

[Jörg W. (dl8dtl) (Moderator)]

Klaus Wachtler schrieb:
> Hatten wir nicht heute schon das Thema GPIOR0/1/2?
> Vielleicht geht es mit denen.

Nö, die werden doch bei einem Reset gelöscht.

[Peter D. (peda)]

Philippp schrieb:
> Problem bei der Sache ist jedoch, dass anwendungsbedingt hinundwieder
> Software-Resets notwendig sind.

Das ist ungewöhnlich.
Eigentlich sollte es reichen, wenn man die relevanten Initialisierungen 
nochmal aufruft.
Diese müssen dann so geschrieben sein, daß der Zustand aller IO-Register 
egal ist (zu setzende Bits verodern, zu löschende Bits verunden, Timer 
anhalten, gegebenenfalls Interruptsperre während der Initialisierung).


Philippp schrieb:
> JumpToZero ist wegen der Komplexität des Programmes
> nicht möglich.

Du hast also komplett den Überblick verloren, was Du wo initialisierst.
Dann solltest Du daran arbeiten.

Alle anderen Ansätze bekämpfen nur die Wirkung und nicht die Ursache.


Peter

[Wolfgang H. (Gast)]

Hi, Philippp,

> Problem bei der Sache ist jedoch, dass anwendungsbedingt hinundwieder
> Software-Resets notwendig sind.

Diese scheinbare Notwendigkeit werte ich als Symptom für Pfusch des 
Programmierers.
Meine Lernstunde in dieser Sache war, als ich eine einfache I2C-Funktion 
mit Timeout-Sicherungen versehen musste, weil
a) nicht ausgeschlossen werden konnte, dass der Kunde eine Baugruppe 
außer Betrieb setzte, weil er sie gerade nicht brauchte.
b) Deswegen aber durfte die Initialisierung der I2C-Bausteine nicht 
verzögert werden durch Wartezeiten auf Antworten oder gar Stillstand der 
I2C-Funktion.
Das war eine bittere Lernstunde, weil ich diesen Aufwand nicht 
kalkuliert hatte und mein Versuch "Mehraufwand" abgeschmettert wurde: 
"Das hätten sie kalkulieren müssen!"
Sauber wäre eine Überwachung notwendig gewesen, welche nach 
Power-Down-Reset prüft, ob alle Baugruppen gesteckt sind.

Sauberkeit im Programmieren macht ähnlich viel lästige Mühe wie 
Sauberkeit in der Küche. Aber warten, bis die Kakerlaken das Kommando 
übernehmen oder die "Software-Resets", das ist Pfusch.

Gerade im Embedded-Bereich muss ein Programmablauf immer unter Kontrolle 
sein, ähnlich einem Auto auf der Straße.
"Meister, machen sie mein blutig zerbeultes Auto wieder heile" darf für 
Autos nicht vorkommen, wie auch nicht "wir haben uns verirrt, alles 
Reset".

Sondern wir Autolenker haben Kollisionen zu vermeiden und wir 
Programmier unkontrollierte Zustände.

Sorry, aber eine bittere Wahrheit ist hilfreicher als hundert gefällige 
Lügen.

Ciao
Wolfgang Horn

[Klaus D. (kolisson)]

So ähnlich kommt es mir auch in den Sinn.
Mein erster Gedanke war statt GOTO 0 ein GOTO Init zu setzen.
Im Init wird ja dann alles Initialiesiert.

)Irgendwie scheint mit mir Anforderung einer Eigenschaft
wie TO sie anfragt im (sagen wir mal) vernünftigen Leben
eigentlich nicht vorzukommen.

Vielleicht liegt der Wurm im Konzept.

Gruss
klaus de lisson

[kxr (Gast)]

* ich setze in SoftBoot() einfach alle (in Setup()) vorkommenden 
interrupt enable bits zurück
* dann wdt_disable()
* dann jump auf 0 bzw. bootloader-start