SRAM initialisieren nach Watchdog-Reset

[Dennis Peters (Gast)]

Hallo Forum,

ich mache gerade meine ersten Erfahrungen mit nem STK600 und den AVR 
XMega Mikrocontrollern. Nach dem Tutorial klappten die ersten kleineren 
Programme schon ganz ordentlich. Leider bin ich jetzt an einem Punkt wo 
ich nicht weiterkomme und weder hier im Forum oder im Datenblatt etwas 
gefunden habe was mir weiterhilft.

Zu meinem Problem, ich möchte nach einem ausgeführten Watchdog-Reset nur 
einen Teil der globalen Variablen wieder zurücksetzen. Sicherlich ist 
eskein Problem diese einzeln mit 0 zu initialisieren. Schöner fände ich 
aber eine Routine, die das SRAM bis auf ein paar Adressen wieder 
zurücksetzt.

Jetzt meine Frage, wie kann ich auf das SRAM zugreifen? Das ist mir 
irgendwie unklar. Und ist es möglich einer Variablen eine bestimmte 
Adresse zuzuweisen, oder einen Adressbereich für bestimmte Variablen zu 
definieren.

Über Hilfe würde ich mich echt freuen.......


Viele Grüße

[Marius W. (mw1987)]

Pack doch die Variablen, die du behalten wollst in die "noinit"-Section. 
Dann bist du allerdings für die korrekte Initialisierung verantwortlich.

Siehe: http://www.nongnu.org/avr-libc/user-manual/mem_sections.html

Gruß
Marius

[Dennis Peters (Gast)]

Ok,

das hört sich gut an. Wo bzw. Wie muss ich dem Linker mitteilen, ab 
welcher Adresse der .noinit Bereich beginnt?

[(prx) A. K. (prx)]

Normalerweise irgends. Wenns sein muss: siehe Link.
Wir reden aber schon von C Programmierung?

[Dennis Peters (Gast)]

Ja, C Programmierung.

Also ich hätte schon gerne einen fest definierten Bereich. Jetzt kann 
ich ja im AVRStudio6 unter Toolchain - AVR/GNU Linker einmal unter 
Memory Settings das SRAM Segment definieren (weiß leider nicht wie)oder 
unter Miscellaneous ein Linker Flag setzen.

Der Befehl -Wl,--section-start=.noinit=0x2000 als Linker Flag scheint 
schon mal zu funktinieren.

Nur wie greife ich jetzt auf das Adresse 0x2010 bis 0xffff zu?

[(prx) A. K. (prx)]

Dennis Peters schrieb:
> Also ich hätte schon gerne einen fest definierten Bereich.

Weshalb? Normalerweise attributierst du die nicht beim Start zu 
initialisierenden Variablen entsprechend dem Link und überlässt die 
Speicherwaltung dem Linker. Der legt diese Variablen automatisch in die 
benannte Sektion und sorgt für die richtigen Adressen.

Wenn du eine komplett eigene Speicherverwaltung des Linkers im Auge 
hast, dann wirds halt etwas komplizierter. Weil du dann erst einmal 
gründlich verstehen solltest, wie die normale Speicherverwaltung 
funktioniert.

[Dennis Peters (Gast)]

Weil ich dann wie oben beschrieben genau den SRAM Bereich löschen kann, 
der keine .nonit Variablen enthält.

[(prx) A. K. (prx)]

Wozu? Das macht der Startup-Code doch sowieso schon von selbst. Alle 
external/static Vars, die nicht explizit in die .noinit Sektion gelegt 
werden, werden beim Start automatisch initialisiert.

[spess53 (Gast)]

Hi

>Weil ich dann wie oben beschrieben genau den SRAM Bereich löschen kann,
>der keine .nonit Variablen enthält.

Und den Stack gleich mit plattmachen?

MfG Spess

[(prx) A. K. (prx)]

spess53 schrieb:
> Und den Stack gleich mit plattmachen?

Nebst der grad eben frisch ins RAM kopierten Strings.

[Thomas (kosmos)]

hier mal ein .asm Beispiel von mir für einen ATMega16 also für 1kByte 
SRAM muss du halt entsprechend anpassen. Ich hatte das ganze direkt vor 
dem Programm gemacht deswegen war mir das mit Zeitaufwand egal, den im 
Programm weiter unten gibt dann keine solchen Verzögerungen.

reset:
ldi temp, low(RAMEND)    ;Stackpointer initialisieren
out SPL, temp
ldi temp, high(RAMEND)
out SPH, temp

clear_sram:       ;Setze alle 1024 SRAM-Zellen auf 0
clr temp          ;320,75 µSek bei 16 MHz
ldi temp2, 0      ;256
ldi temp3, 4      ;4      4x256=1024
clr R27           ;Startadresse SRAM $0060
ldi R26, $60

Schleife1:
st X+, temp
dec temp2
brne Schleife1
dec temp3
brne Schleife1

[(prx) A. K. (prx)]

Thomas O. schrieb:
> hier mal ein .asm Beispiel

Drum fragte ich nach Assembler vs. C. Ein Assembler-Beispiel ist in 
dieser Frage bei C Programmierung zu 100% nutzlos.

[Dennis Peters (Gast)]

>Wozu? Das macht der Startup-Code doch sowieso schon von selbst. Alle
>external/static Vars, die nicht explizit in die .noinit Sektion gelegt
>werden, werden beim Start automatisch initialisiert.

Aber nicht nach einem Watchdog_Reset. Das ist mein Problem, denn sonst 
könnte ich die Variable auch im EEPROM speichern.

>Und den Stack gleich mit plattmachen?
Ich frag jetzt mal ganz dumm, wäre das kritisch wenn ich den Bereich 
einhalte?

[Thomas (kosmos)]

du wirst es doch in C hinbekommen eine Schleife z.B. 1024mal 
abzuarbeiten und eine Adresse bei jedem Schreiben um 1 zu erhöhen? Da 
ich mit C nichts am Hut habe mache ich mir den Aufwand nicht aber ein 
.asm Beispiel ist doch besser als garkeins. Vielleicht kann jemand 
anderes das Beispiel oben nach C umwürfeln.

[(prx) A. K. (prx)]

Dennis Peters schrieb:
> Aber nicht nach einem Watchdog_Reset.

Doch, meines Wissens ist es dem Startup-Code völlig schnurz, wodurch ein 
Reset ausgelöst wurde. Anders wärs beim Watchdog-Interrupt.

[(prx) A. K. (prx)]

Thomas O. schrieb:
> du wirst es doch in C hinbekommen eine Schleife z.B. 1024mal
> abzuarbeiten und eine Adresse bei jedem Schreiben um 1 zu erhöhen?

Sein Problem ist nicht das Löschen selbst, sondern die Frage der 
Speicherorganisation. Also welche Variable an welcher Stelle landet und 
welcher Bereich wann gelöscht werden muss/kann/darf.

[spess53 (Gast)]

Hi

>Ich frag jetzt mal ganz dumm, wäre das kritisch wenn ich den Bereich
>einhalte?

Welchen Bereich? Der Stack ist dynamisch. Wie weit er in den RAM 
hineinreicht, ist einfach ausgedrückt, von der Stelle im Programm 
abhängig, die gerade abgearbeitet wird.

>ich mache gerade meine ersten Erfahrungen mit nem STK600 und den AVR
>XMega Mikrocontrollern.

Dann ist der Watchdog das allerletzte was du brauchst. Ergo hast du kein 
Problem mit den Variablen.

MfG Spess

[Thomas M. (thomaswm)]

Ich habe etwas ähliches gemacht:

Es handelt sich hier zwar um einen V850-Automotive Controller, aber bei 
den AVRs sollte das gleich sein.
Zu meinem Projekt habe ich das .ld-File angepasst. Darin steht der 
Aufbau des SRAMs. Bei meinem Controller beginnt der SRAM an der Adresse 
0xFFFF0000 und genau dort hin habe ich die .noinit-Section gelegt.
Die Größe wird automatisch angepasst, was für meine Zwecke ok ist. Man 
kann aber auch feste Werte eintragen.

/************************************************************************/
/*                          DF3441.ld                                   */
/*                                                                      */
/*  NEC V850 microcontroller device uPD70F3441                          */
/*                                                                      */
/*  Template of linker directive file for the                           */
/*  Green Hills Multi 2000 environment                                  */
/*  Usage:  ccv850e file1.o file2.o ... fileN.o -o a.out DF3441.ld      */
/*                                                                      */
/*  Copyright (C) NEC Corporation 2006                                  */
/*  This file was created from device file DF3441.800       [E1.00d]    */
/*  by DeFiX V1.24                                                      */
/*                                                                      */
/*  This file is only intended as a sample supplement to NEC tools.     */
/*  Feel free to adapt it to your own needs.                            */
/*  This File is provided 'as is' without warranty of any kind.         */
/*  Neither NEC nor their sales representatives can be held liable      */
/*  of any inconvenience or problem caused by its contents.             */
/************************************************************************/

MEMORY
 {
  iROM    : ORIGIN = 0x00000000,  LENGTH = 992k
  iRAM    : ORIGIN = 0xFFFF0000,  LENGTH = 60k
 }

SECTIONS
 {

/* Start of internal ROM area (iROM) */

  .intvect                         :>iROM   /* start of interrupt vector */
  .intvect_end  0x07CF             :>.      /* end   of interrupt vector */
  .rozdata                         :>.      /* constant datas in ZDA area */
  .robase   align(4)               :>.      /* initialize textpointer TP for SDA addressing */
  .rosdata  align(4)               :>.      /* constant datas in SDA area */
  .rodata   align(4)               :>.      /* constant datas in normal area */

  .text     align(4)               :>.      /* program code area */

  .fixaddr  align(4)               :>.      /* ghs internal (compiler) */
  .fixtype  align(4)               :>.      /* ghs internal (compiler) */
  .secinfo  align(4)               :>.      /* ghs internal (runtime library) */
  .syscall  align(4)               :>.      /* ghs internal (linker) */

  .romdata  ROM(.data)             :>.      /* constant data to initialize variables (copied to RAM at startup)*/
  .romzdata ROM(.zdata)            :>.      /* constant data to initialize variables in ZDA area (copied to RAM at startup)*/
  .romsdata ROM(.sdata)            :>.      /* constant data to initialize variables in SDA area (copied to RAM at startup)*/
  .romtdata ROM(.tdata)            :>.      /* constant data to initialize variables in TDA area (copied to RAM at startup)*/

/* Start of internal RAM area (iRAM) */

  .noinit   align(4)               :>iRAM   /* not initialized data */
  .data                            :>.      /* initialized data */
  .bss      align(4)               :>.      /* zero initialized data*/

  .sdabase  align(4)               :>.      /* initialize globalpointer GP for SDA addressing */
  .sdata    align(4)               :>.      /* initialized data in SDA area*/
  .sbss      align(4)               :>.      /* zero initialized data in SDA area*/

  .zdata    align(4)               :>.      /* initialized data in ZDA area*/
  .zbss     align(4)               :>.      /* zero initialized data in ZDA area*/

  .tdata    align(4) MAX_SIZE(256) :>.      /* initialized and zero-initialized data in TDA area */

  .stack    align(4) pad(0x200)    :>.      /* definition of stack size */

//  .heap     align(4) pad(0x800)    :>.      /* definition of heap size (enable if needed) */

 }

/************************************************************************/
/*      End of File                                                     */
/************************************************************************/

hier noch etwas Theorie:

http://www.math.utah.edu/docs/info/ld_3.html

[Thomas (kosmos)]

nach einem Reset würde ich mich auf nichts mehr (Variablen/SRAM) 
verlassen. Wenn ich sichergehen will das nichts verloren geht, würde ich 
den µC ausreichend Puffern, mit einem Analogeingang die Spannung vor dem 
Spannungsregler messen und wenn diese Abfällt sofort alles wichtige ins 
EEPROM schreiben. Damit ich nach dem folgendem Reset damit 
weiterarbeiten kann.

[(prx) A. K. (prx)]

Thomas O. schrieb:
> nach einem Reset würde ich mich auf nichts mehr (Variablen/SRAM)
> verlassen.

Die Quelle des Reset geht aus einem Statusregister hervor. Das kann man 
also schon differenzieren. Bei Watchdog/Pin ist die Situation anders als 
bei Powerup/Brownout.

[Thomas (kosmos)]

sorry habe das mit dem Brown Out verwechselt.

[Marian (phiarc)]

Ich habe das mal ein bissl getestet und der Mega8 verhält sich da wie 
erwartet (BOD an, Watchdog an), wenn der BOD resettet, zählt das als 
quasi-POR, nur eben mit dem BOD-Reset-Bit gesetzt. Ein eventuell vorher 
gesetztes WD-Reset-Bit wird also auch zurückgesetzt => kein Problem.


Ich weiß nicht so ganz, wo OPs Problem noch liegt.
-Seine Variablen, die er behalten will, packt er ins .noinit (attribute)
-In main() oder auch below-main, wie er mag, prüft er aufs WD-Reset-Bit 
und wenn es nicht gesetzt ist, initialisiert er die .noinit-Variablen
-Fertig.