STM32 (F3) CSS immer an?

Basti schrieb:

> Erste erschreckende Erkenntnis für alle die es interessiert:
> Ist der Kondensator am Reset Pin zu groß, in diesem Fall 1 uF, dann kann
> der IWDG mit seinem 20 us Reset-Puls den Mikrocontroller nicht
> resetten...
> Wer baut denn sowas?!

Im Datenblatt findet sich ein Vorschlag(?) 0.1uF. Außerdem die 
(zugegebenermaßen etwas verschämte) Fußnote:

"2. The user must ensure that the level on the NRST pin can go below the 
V IL(NRST) max level specified in Table 55. Otherwise the reset will not 
be taken into account by the device."

Aus den "I/O-Characteristics" kann man auf einen Ausgangswiderstand des 
NRST-Pins (bei Low) von max. 50 bis 65 Ohm schließen. Berechnet man die 
Zeitkonstante, sieht man, dass bei 0.1 uF die 20 us sicher ausreichen, 
während bei 1 uF ...

In Verbindung mit RM, Absch. 7.1.2, "Figure 10. Simplified diagram of 
the reset circuit" ist das beschriebene Verhalten also völlig im Rahmen 
der Spezifikation.

Hätte man sicher etwas deutlicher schreiben können ... Aber da das 
interne RESET-Signal direkt und ausschließlich von der Spannung am 
NRST-Pin abhängt, ist von vornherein klar, dass man an den nicht nach 
Belieben irgendwas ranhängen kann. Ein Push-Pull-Ausgang von einer 
externen Reset-Schaltung ginge auch nicht.

Und so unüblich ist ein "wired-or" im Zshg. mit einem open-drain Ausgang 
ja nun auch wieder nicht.

Hallo Jim,

für Fehlerfälle gibts ein Watchdog... und der wird evtl. ausgehebelt, 
wenn die CPU nur noch mit 8 MHz statt mit erwarteten 72 MHz läuft.

In meinem Reference Manuale steht auf Seite 103 ein Hinweis, dass es 
doch sehr ratsam ist den CSS einzuschalten um HSE Probleme zu umgehen. 
Besonders viele Informationen über das CSS Verhalten oder verhalten ohne 
CSS finde ich aber tatsächlich nicht.

Nenn mir doch mal bitte die Stelle im Datenblatt.

Danke

Basti

Hi A. B.,

danke für den Hinweis, die Schaltung habe ich tatsächlich gesucht. 
Konnte mir dann nur ableiten, dass es so sein muss. Die 
Hardwareschaltung ist nicht von mir, 1 uF habe ich auch noch nie an 
einen Reset gehangen.

Was mir neu ist, ist das der Reset-Pin im Grund auch ein OD-Ausgang 
ist... Sehr nett, dann kann der interen µC-Watchdog auch andere 
Schaltungsteile resetten. Gefällt mir...

VG

Basti

Das Thema (CSS und HSI Wechsel) ist anscheinend gestorben weil einer 
behauptet hat, dass es so im Datenblatt steht... ohne Referenz ohne 
alles...

Sehr schade... würde gern noch dahinter kommen...

Basti schrieb:
> für Fehlerfälle gibts ein Watchdog... und der wird evtl. ausgehebelt,
> wenn die CPU nur noch mit 8 MHz statt mit erwarteten 72 MHz läuft.

Deshalb hat der IWDG doch extra einen eigenen RC-Oszillator.

> In meinem Reference Manuale steht auf Seite 103 ein Hinweis, dass es
> doch sehr ratsam ist den CSS einzuschalten um HSE Probleme zu umgehen.
> Besonders viele Informationen über das CSS Verhalten oder verhalten ohne
> CSS finde ich aber tatsächlich nicht.
>
> Nenn mir doch mal bitte die Stelle im Datenblatt.

Die Beschreibung im RM ist tatsächlich etwas mißverständlich. Das 
Einschalten des CSS bewirkt offenbar nur ZUSÄTZLICH zum Umschalten auf 
HSI den Interrupt etc., während das Umschalten unabhängig davon immer 
bei Ausfall des HSE erfolgt, wenn HSE direkt oder indirekt als 
Taktquelle dient, s. Datenblatt:

"3.8 Clocks and startup
System clock selection is performed on startup, however the internal RC 
8 MHz oscillator is selected as default CPU clock on reset. An external 
4-32 MHz clock can be selected, in which case it is monitored for 
failure. If failure is detected, the system automatically switches back 
to the internal RC oscillator."

Und im RM unter 7.2.7: "If the HSE oscillator is used directly or 
indirectly as the system clock (indirectly means: it is used as PLL 
input clock, and the PLL clock is used as system clock), a detected 
failure
causes a switch of the system clock to the HSI oscillator and the 
disabling of the HSE oscillator."

Bei dem Absatz ist nicht ganz klar, ob das generell gilt, oder nur wenn 
CSS eingeschaltet ist. Da es aber nach "Note: ..." steht, würde ich das 
schon so lesen, dass diese Funktion immer gegeben ist.

Aber letzlich ist das doch egal. Wenn ich Wert auf Sicherheit lege (und 
dazu den IWDG nutze), muss ich mir doch ein Gesamtkonzept überlegen. 
Also auch den Oszillatorausfall einkalkulieren und eine entsprechende 
Reaktion einplanen. Nur ein Reset reicht da vielleicht nicht, also muss 
die CPU noch etwas sinnvolles machen können, und dazu braucht's halt 
einen Takt, 72 Mhz hin oder 8 Mhz her ...

@A. B.

Die Info aus 7.2.7 steht ja schon unter der Überschrift CSS... nur weils 
ne Note ist... ich weiß nicht... erwartet hätte ich eine "Note" oder 
eher noch  "Caution" im HSE Part des Reference Manuels. Da es doch sehr 
relevant für alle STM32 Benutzer ist... gerade wenns auch Richtung Serie 
geht.
Wirklich deutlich steht es tatsächlich nur im Datenblatt im von dir 
zitierten 3.8. Dort habe ich es übersehen.

Wenn ich ein 8 MHz Quarz einsetze und es durch einen Produktionsfehler 
auf den HSI zurückfällt, unbemerkt!, da CSS nicht aktiviert ist, 
vermurks ich mir mein Timing. Die Software loopt fröhlich weiter und 
triggert auch ein window watchdog wie gewohnt. Die (z.B.) nötige 
Präzession am Timerausgang ist jedoch dahin.
Ich stelle mal die Behauptung auf, dass über zwei drittel der 
µC-Programme nicht mehr wie gefordert funktionieren, wenn der Clock mal 
eben halbiert oder verdoppelt wird. Bei vielen poppt der Fehler 
vielleicht viel zu spät auf. Da hilft auch ein Watchdog nur noch 
bedingt.

Fazit ist für mich: CSS immer an, kann gern in den default Vector in der 
Endless loop fallen und wird dann vom Watchdog abgefangen oder in der 
Serienproduktion gleich erkannt. Wenn ich keinen HSE brauchen würde, 
würde ich ja keinen drauf bauen. Ich versteh den Gedanken, das immer 
aktiv zu haben, von STM leider nicht. Beim XMega (als Gegenbeispiel) ist 
die Funktion KOMPLETT optional.

Die Hardware sollte so ausgelegt sein, dass im Reset des µC der sichere 
Zustand eingenommen wird. Da kann ich nicht vom Mikrocontroller noch 
irgendwelche "Rettungsroutinen" erwarten (siehe Kommentar Jim M.). Ist 
natürlich auch Einsatzabhängig... aber in den meisten Fällen...

Danke A.B. für die Referenzen.

Ich ärger mich gerade, dass wir schon ewig mit STM32 arbeiten und keiner 
diese Funktion kannte...

Viele Grüße

Basti