WD aktiv und über Arraygrenzen schreiben/lesen

Hero_123

Mitglied
17. Sep. 2010
183
3
18
Sprachen
  1. ANSI C
Hallo

Ich hab' da eine Frage - wie verhält sich der Controller (ATMega8, Watchdog aktviert), wenn ich ein Array definiert habe und sporadisch (!) über die Bereichsgrenze das Array schreibe oder lese?
Ich vermute, dass dann der Watchdog zuschlägt (zumindest beim beschreiben; lesen evt kein Problem, kommt darauf an, was der gelesene Wert im Programm bewirkt).

AVRStudio 4.18, Build 716
WINAVR20100110
WIN7 32 Bit

mfg

Hero_123
 
Außerhalb von Bereichsgrenzen eines Arrays zu schreiben ist, unabhängig von Controller/Prozessor, Programmiersprache oder Betriebssystem, keine gute Idee, um nicht zu sagen: ein Programmfehler.

Den watchdog interessiert das zwar nicht, aber wenn z.B. eine Rücksprungadresse auf dem Stack verändert wird, stürzt das Programm mit großer Wahrscheinlichkeit ab.

Damit der Controller dann nicht in einer Endlosschleife hängen bleibt, braucht es so etwas wie den watchdog, der den Controller durch einen Reset wieder in einen definierten Zustand versetzt.
lesen evt kein Problem, kommt darauf an, was der gelesene Wert im Programm bewirkt
Gut erkannt.
 
Hallo Mikro23

Vielen Dank für Deine Hilfe :)

Außerhalb von Bereichsgrenzen eines Arrays zu schreiben ist, unabhängig von Controller/Prozessor, Programmiersprache oder Betriebssystem, keine gute Idee, um nicht zu sagen: ein Programmfehler.

Ja, das ist ... :banghead2:

Jedenfalls hast Du meine Vermutung bestätigt

mfg

Hero_123
 
wie verhält sich der Controller (ATMega8, Watchdog aktviert), wenn ich ein Array definiert habe und sporadisch (!) über die Bereichsgrenze das Array schreibe oder lese?
Das kommt darauf an, was Du mit den gelesenen Daten anstellst.
Grundsätzlich ist der Speicher linear - strenggenommen kennt die Hardware ja gar keine Datenstrukturen. Sind (im SRAM) alles Bytes. Die Hochsprache könnte ggf prüfen, ob ein Zugriff innerhalb der definierten Grenzen stattfinden würde oder nicht, und dann bereits beim kompilieren meckern - aber das nicht immer.

Der SRAM ist also linear - irgendwo wird durch die IDE also der Bereich des Arrays festgelegt.
Die Adressen drumrum können entweder durch andere Variablen verwendet werden, oder eben ungenutzt sein. In jedem Falle kann also irgendwas von dort gelesen werden - inwiefern die jetzt allerdings weiterverarbeitet werden, und ob das Sinn macht, und was sich daraus für Folgen ergeben, bestimmt Dein Programm...
Noch komplizierter wird's, wenn Du irgendwas irgendwohin schreiben läßt - die dort eventuell liegenden Variablen erhalten so plötzlich neue (unerwartete) Daten...

Und noch einen Schritt weitergedacht kannst Du möglicherweise auch im Speicherbereich der I/O- (oder gar der Rechenregister) landen (i.A. sind die 32 Rechenregister auf SRAM-Adresse 0x0000..0x001F, danach folgen 64 I/O-Register (0x002F..0x005F), je nach Controller dann noch Extended I/O-Register, und erst danach der eigentliche SRAM.
Schreibzugriffe in den I/O-Bereich manipulieren direkt die periphäre Hardware, klar - aber bei einigen Registern löst bereits das lesen irgendwas aus (beim ADC blockiert das Lesen von ADCL updates des Result-Registers, bis auch ADCH ausgelesen wurde (die beiden Register werden quasi solange eingefroren); bei 16Bit-Registern der Timer gibt's einen ähnlichen Effekt.
 
Hallo LotadaC

Vielen Dank für Deine Hilfe :)

Die Hochsprache könnte ggf prüfen, ob ein Zugriff innerhalb der definierten Grenzen stattfinden würde oder nicht, und dann bereits beim kompilieren meckern - aber das nicht immer.

Ja, in Zukunft werde ich einen Check bezgl Array-Grenzüberschreitungen einbauen ;)

mfg

Hero_123
 
Ist jetzt ja eigentlich schon geklärt, ich würde es aber noch verdeutlichen. Gibt ja auch Googler ;)

Der Watchdog ist eher zu sehen wie eine "Zeitbombe". Einmal aktiviert (per Fuses erzwungen oder per Code) zählt er, unabhängig von der anderen Hardware, x Watchdog Takte, also x ms runter.
Erreicht er 0: Peng. Sonst macht er nichts, er überwacht keine Programmabläufe o.Ä.. Daher liegt es jetzt an dem Programm, dem Watchdog ständig zu sagen, "alles gut". Dadurch wird die Zeit zurück gesetzt und es gibt keinen Knall, zumindest wenn dein Programm schnell genug und nicht eingefroren ist.

Typischerweise knallt es so, dass der Controller / CPU / das gesamte System resettet wird, quasi Power Cycle. Bei den manchen AVRs kann der Hund auch stattdessen einen Interrupt auslösen und somit sogar als (ungenauer) Timer verwendet werden. Zwar nicht ganz im Sinne des Erfinders, geht aber.

Edit dank Hinweis durch @Mikro23: Nicht jeder AVR unterstützt es. Vorher im Datenblatt nachsehen!
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Mikro23
Hallo TommyB

Vielen Dank für Deine Hilfe :good2:

mfg

Hero_123
 
Der Watchdog ist eher zu sehen wie eine "Zeitbombe".
Gut ausgedrückt. ;)

Wie Du ganz richtig sagst
Ist jetzt ja eigentlich schon geklärt, ich würde es aber noch verdeutlichen. Gibt ja auch Googler ;)
Daher kann man das
Bei den AVRs kann der Hund auch stattdessen einen Interrupt auslösen
nicht so stehen lassen.

Ich kenne bei weitem nicht alle AVRs, also kann ich nicht mal sagen, ob das auf alle alten zutrifft oder nur auf einen Teil.
Auf die xmegas jedenfalls trifft es nicht zu, da löst der watchdog, wenn aktiviert, immer einen Reset aus. Die Interrupt-Option gibt es nicht.
Für die neueren AVRs, also die xcore-tinies und -megas, die ich mir bisher angesehen habe, sieht es genauso aus, wie bei den xmegas.
 
Meiner Erinnerung nach ist der WD bei vielen neueren konventionellen (SPI-programmierbaren) AVR interruptfähig (ich nenne sie die new-generation-SPI-AVR zB der genannte Mega88, Tiny261 usw), ebenso bei den TPI-Tinies, aber offensichtlich nicht mehr bei den X-Core-AVR.

Soweit ich das recht in Erinnerung hab, gabs doch inzwischen auch neue ATmega ähnlichh den XTinies, die aber keine ATXmegas sind (also X-Core-ähnliche Peripherie aber - wie bei den XTinies - zB 5V Betriebsspannung usw...) Deren WD ist dann auch nicht mehr IRQ-fähig?

P.S.: neben IRQ oder Reset ist auch eine Kombination wählbar - beim ersten Überlauf des WDT triggert der IRQ, beim nächsten der Reset...
 
P.S.: neben IRQ oder Reset ist auch eine Kombination wählbar - beim ersten Überlauf des WDT triggert der IRQ, beim nächsten der Reset...
Da bin ich mir jetzt nicht ganz sicher. So wie ich es verstanden hatte wird dann erst der Interrupt und direkt danach der Reset, nicht mit 2 Überläufen. Stellt sich dann auch die Frage, muss es der Nächste Überlauf sein oder setzt ein WDR wieder alles zurück? Irgendwie ist das Datenblatt etwas schwammig, oder ich finde es nicht. Naja, Worst-Case: Ausprobieren :)
 
Soweit ich das recht in Erinnerung hab, gabs doch inzwischen auch neue ATmega ähnlichh den XTinies, die aber keine ATXmegas sind (also X-Core-ähnliche Peripherie aber - wie bei den XTinies - zB 5V Betriebsspannung usw...) Deren WD ist dann auch nicht mehr IRQ-fähig?
Für die neueren AVRs, also die xcore-tinies und -megas, die ich mir bisher angesehen habe, sieht es genauso aus, wie bei den xmegas.
Gilt anscheinend für alle xcores
 
Da bin ich mir jetzt nicht ganz sicher. So wie ich es verstanden hatte wird dann erst der Interrupt und direkt danach der Reset, nicht mit 2 Überläufen. Stellt sich dann auch die Frage, muss es der Nächste Überlauf sein oder setzt ein WDR wieder alles zurück? Irgendwie ist das Datenblatt etwas schwammig, oder ich finde es nicht.
Bit 6 – WDIE: Watchdog Interrupt Enable
When this bit is written to '1' and the I-bit in the Status Register is set, the Watchdog Interrupt is enabled.
If WDE is cleared in combination with this setting, the Watchdog Timer is in Interrupt Mode, and the
corresponding interrupt is executed if timeout in the Watchdog Timer occurs. If WDE is set, the Watchdog
Timer is in Interrupt and System Reset Mode.
The first timeout in the Watchdog Timer will set WDIF.
Executing the corresponding interrupt vector will clear WDIE and WDIF automatically by hardware (the
Watchdog goes to System Reset Mode).

This is useful for keeping the Watchdog Timer security while using the interrupt. To stay in Interrupt and
System Reset Mode, WDIE must be set after each interrupt.
This should however not be done within the
interrupt service routine itself, as this might compromise the safety function of the Watchdog System
Reset mode.
If the interrupt is not executed before the next timeout, a System Reset will be applied.
Finde ich schon eindeutig...
 
Ach ja, einer der alten megas, der mega8515 (noch früher hieß er auch 90S8515) kennt auch keinen watchdog-interrupt. Und das gilt auch für den nahen Verwandten mega8535.
 
Müsste ich jetzt mal schaun welches Datenblatt (und welcher Chip, muss aber Tiny13, Tiny2313, Mega48 Serie gewesen sein) ich damals hatte. Das war auf jeden Fall noch eins zu Atmel Zeiten gewesen als ich dahingehend mal geschaut hatte.
 
Das Zitat ist aus dem Datenblatt:
Atmel-2545W-ATmega48/V / 88/V / 168/V_Datasheet_Complete-11/2016
(auch noch aus Atmel-Zeiten;))
 
ja, einer der alten megas, der mega8515
Wie gesagt: bei den alten SPI-AVR nicht, bei den noch älteren AT90S nicht (und eben auch bei den X-Cores nicht), aber bei den neueren SPI-ATtinies/megas und den TPI-Tinies...

Mal am Beispiel der "Mega8-Serie":
  • AT90S2333/AT90S4433 - nein
  • ATmega8 - nein
  • ATmega48/88/168/328 - ja
  • ATmega48/88/168/328 P/A/PA/PB meiner Meinung nach auch
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)