Daten über Atmega Neustart retten

Hallo,

ich versuche ein paar Daten (wenige int) über einen Neustart eines Atmega8 zu retten (speziell bei Neustart durch Watchdog ).

Programmiert wird mit ICCAVR, der als ordentlicher C-Compiler natürlich den gesamten RAM am Anfang löscht. Dort geht es also nicht.

Im Netz fand ich den Tip, die Daten an das Ende des Stack zu legen:

########################################### I'm wondering if anyone has some good idea on debugging a sporadic watchdog reset I get (about once a day)?

I thought I could set a variable to different values in different parts of the program and then at reboot store it in another, but if I understod correctly even unitialized variables gets initialized to 0, so that wouldn't work.

EEPROM is to slow for storing it in.

From richard-lists at imagecraft.com Wed Jul 20 23:23:32 2005 From: richard-lists at imagecraft.com (Richard) Date: Wed Jul 20 23:24:25 2005 Subject: [Icc-avr] Debugging watchdog reset In-Reply-To: References: Message-ID:

First, see the Help on "Stacks" and Stack Checking Functions, it explains why you can't use &_bss_end+1. Anyway, you can do something like this:

extern char _bss_end; char *p = &_bss_end+2;

.... *p = ...;

As long as you are not using the heap or that the stacks are running into that part of SRAM, then you can use the space after bss_end.

########################################### Etwas besseres fiel mir bisher nicht ein, ich habe das nun etwas abgewandelt:

extern int _bss_end; int *a = &_bss_end+3; int *b = &_bss_end+5;

Mit den Variablen kann ich arbeiten, a und b sind nach Neustart aber immer wieder 0. Ich kann aber auch in den Bibliotheken nichts finden, wo der ICCAVR den Stack mit 0 beschreibt.

Hat irgendwer eine Idee oder einen besseren Lösungsvorschlag für das eigentliche Problem? Nutzung des EEPROM ist aufgrund der beschränkten Zyklen leider keine Alternative, zusätzliche Hardware wollte ich eigentlich möglichst vermeiden.

Lutz

Lutz Schulze schrieb:

Kannst Du den Startup-Code nicht so modifizieren, dass ein Teil des RAMs ungelöscht bleibt und die Variablen explizit dorthin legen? (Ich kenne den ICC nicht.)

CU Christian

Lutz Schulze schrieb:

ga8

den

Den ICCAVR kenne ich nur vom H=F6rensagen. Beim AVR-GCC, den ich verwende, ist die nicht zu initialisierende Variable in einem "noinit"- Abschnitt anzulegen. - Kurzes Googeln nach "ICCAVR noinit" brachte folgendes Beispiel (ohne Garantie, da ich das nicht testen kann):

#pragma data:noinit int i, j, k; #pragma data:data

Gru=DF Thorsten

Am 8 Feb 2007 15:09:36 -0800 schrieb Thorsten Wahn:

Danke für den Denkanstoss.

Das Problem saß wieder mal vor dem Rechner:

Ich hatte mich ja schon gewundert, warum die (zugegeben nicht ganz saubere) Ablage auf dem Stack scheinbar nicht funktionierte.

Habe dann nach deinem Hinweis nochmal gesucht und in der FAQ vom ICCAVR einen Hinweis ähnlich deinem gefunden:

Die Syntax dort ist nicht ganz korrekt, richtig muss das dann so aussehen:

.area data(ram) __data_start:: .area uninit_vars(ram) __uninit_vars_start:: .area bss(ram) __bss_start::

Dann das Startupfile und das Programm neu compiliert - und es ging trotzdem nicht :-(

Nach einigem überlegen kam ich dann drauf, das ich zu Beginn der Tests temporär den Namen des C-Files geändert hatte, aber in den Flash immer noch die alte Datei geschrieben wurde. Oh Mann ....

Jetzt klappt aber alles, danke für die Tips.

Lutz

Hallo,

ein ganz ordentlicher C-Compiler lässt sich schon sagen wo z.B. batteriegepuffertes RAM liegt bei dem solche Löscherei zu unterlassen ist.

Bye

Am Mon, 12 Feb 2007 11:24:51 +0100 schrieb Uwe Hercksen:

Stimmt.

Habe vor Jahren mal mit dem ICCAVR angefangen, vielleicht sollte ich wirklich mal umsteigen.

So schlecht ist der ansonsten IMHO aber nicht.

Lutz