STM32F0 WWDG fehlerhaft?

[Tom W. (nericoh)]

Hallo zusammen,

ich beiße mir gerade an der Inbetriebnahme des System window watchdog 
(WWDG) eines STM32F0 die Zähne aus: sobald ich den WD aktiviere (Bit7 im 
CR-Register setze), generiert der WD mir einen Reset - auch dann, wenn 
ich unmittelbar vorher T[6:0] im CR Register mit 0x7F beschreibe.

Hat jemand Ähnliches beobachtet und weiß Rat?

Gruß,
Tom

Beitrag "STM32F4 Watchdog"
-> der TO hatte möglicherweise das gleiche Problem, hat aber nie wieder 
in dem Thread geantwortet...

Hier mein Code dazu:

void WDint_onInit(void)
{
  /* enable clk for WWDG */
  RCC->APB1ENR |= RCC_APB1ENR_WWDGEN;

  /* divide PCLK by 8 */
  WWDG->CFR |=  (WWDG_CFR_WDGTB0 | WWDG_CFR_WDGTB1);

  /* enable early wakeup IR */
  WWDG->CFR |=  (WWDG_CFR_EWI);

  /* clear early wakeup interrupt flag */
  WWDG->SR  &= ~WWDG_SR_EWIF;

  /* set Counter value for WWDF -> setting all bits results in cycletime of xx ms */
    WWDG->CR |= ( WWDG_CR_T6 | WWDG_CR_T5 | WWDG_CR_T4 | WWDG_CR_T3 | WWDG_CR_T2 | WWDG_CR_T1 | WWDG_CR_T0);

  __asm("nop"); //nur fuer den Breakpoint

  /* enable WD */
  WWDG->CR |= WWDG_CR_WDGA;

  __asm("nop"); //nur fuer den Breakpoint; wird nie erreicht :(
}

[Tom W. (nericoh)]

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

[Oliver R. (2a17)]

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

[Paul (Gast)]

Dein Wert für das high limit in CFR ist 0, d.h. du bist beim enablen des 
WWDG automatisch außerhalb des erlaubten Bereichs und es gibt einen 
Reset. Probier mal 0x7f als high Limit und 0x7e als Wert für CR.

[Tom W. (nericoh)]

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...

[Tom W. (nericoh)]

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?

[Tom W. (nericoh)]

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...

[Tom W. (nericoh)]

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?

[Paul (Gast)]

Das ist schon richtig so: "This downcounter is free-running: It counts 
down even if the watchdog is disabled."

Der WWDG läuft also auch wenn nicht WDGA gesetzt. Nur macht er dann 
keinen Reset.

[Tom W. (nericoh)]

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?

[Paul (Gast)]

Bei 8MHz PCLK und AHB/APB prescaler jeweils 1 ist der WWDG-Takt maximal 
~2kHz, minimal 244Hz. Das Fenster ist bei minimalem Takt bis zu 262ms 
gross. Je nachdem welchen Takt du für die APB-peripherals maximal 
brauchst, kannst du den WWDG-Takt per AHB/APB-prescaler noch weiter 
verringern.

[Oliver R. (2a17)]

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.