STM32F0 WWDG fehlerhaft?

Zusatzinfo: auffällig ist, dass ich beim ersten Brakepoint (unmittelbar 
nach Beschreiben des CR-Registers) in CT->T[6:0] kein 0x7F, sondern 
immer unterschiedliche Werte (in einem Versuch 0x39, in einem weiteren 
0x34, 0x2b, 0x6c, 0x7b, 0x48, ...) beobachte

Ich habe bei einem STM32F030K6 scheinbar das gleiche verhalten...hast Du 
mittlerweile was herausgefunden?

Danke an Paul für den Hinweis!

Vllt hilft das Oliver auch weiter? Habe es noch nicht (wieder) 
ausprobiert, da ich damals dann auf den Independent Watchdog (IWDG) 
ausgewichen bin...

Offenbar verstehe ich die Funktion der Bits 0-6 im CFR nicht richtig: 
nach meinem Verständnis bedeutet ein Wert von 0, dass ich den WD 
jederzeit refreshen darf - die "Window"-Funktion also faktisch nicht 
aktiv ist. So verstehe ich Figure 206 des Reference Manual. 
Interpretiere ich das falsch?

Hm, habe das wohl genau falsch herum gelesen: refresh ist nur erlaubt, 
wenn der Counterwert kleiner ist als der im von W[6:0] im CFR. W[6:0] = 
0 bedeutet (genau wie von Paul dargestellt), dass ich nie refreshen 
darf...

Ans Laufen bekomme ich den WD so leider auch nicht...

in den paar Zeilen vom Aktivieren des APB1-Clocks für den WD bis zu 
meinem ersten nop zählt der Counter von 0x7f auf 0x3f (manchmal auch 
0x3b, 0x33, 0x36, ...) runter.

Wirkt auf mich vollkommen undeterministisch und unplausibel. Ich gebs 
vorerst auf und arbeite mit dem IWDG weiter.

Falls jemand den WWDG im STM32F0... mal erfolgreich benutzt hat, möge er 
sich melden - ich wäre zumindest dran interessiert, wo mein Fehler lag. 
Kann ich mit meinen Takteinstellungen irgendwas derartig vergeigt haben, 
dass ich hier so ein seltsames Verhalten beobachte?

Dass er prinzipiell dann schon runterläuft ist mir bewusst - dass er 
aber innerhalb weniger Codezeilen um soviele Takte runterzählt, finde 
ich unplausibel:

diese 4 Codezeilen müssten ja ziemlich viele CPU-Zyklen zur Abarbeitung 
benötigen, damit der WD-Counter (der aus einem langsameren Takt, der 
zudem noch um 8 heruntergeteilt wird, gespeist wird) um 64 (von 0x7f auf 
0x3f) dekrementiert wird.

Wobei ich gerade net genau präsent habe, welcher Takt den WD treibt und 
wie der sich zum CPU-Takt verhält. Werde ich Montag nochmal 
nachvollziehen...

Selbst wenn es plausibel wäre, dass der WD-Counter während der 
Abarbeitung von 4 Codezeilen soweit runterläuft, hieße das ja, dass der 
WD faktisch unbrauchbar ist, da er alle paar Codezeilen retriggert 
werden müsste, um den uC nicht zu reseten! Ich strebe ein "Füttern" des 
WDs alle paar (d.h. irgendwas zwischen 1 und ~25) ms an und kann mir 
gerade schwer vorstellen, dass ein interner WD sinnvoll einsetzbar ist, 
der innerhalb weniger us neu gefüttert werden muss - oder fehlt mir da 
gerade schlicht die Fantasie für eine sinnvolle Anwendung?

Ich bin nun auch auf den IWDG ausgewichen, da ich den WWDG auch mit 0x7f 
als Limit und 0x7e als Counter auch nicht läuft.
Ich habe die gleiche Initialisierung auf einem STM32F4xx (laut Reference 
Manual technisch gleich) problemlos laufen und vermute deshalb ein 
Hardwarefehler. Bei ST oder im Netz habe ich dazu jedoch noch nichts 
gefunden.