finde den fehler nicht!

Hallo Sascha!
Ich darf den Code leider nicht online Stellen und er beträgt jetzt 
mindestens auch an die 30 Seiten!

<Glaskugel-Mode ON> klingt nach Pufferüberlauf - an 0-Terminierung von 
Strings usw. gedacht?<Glaskugel-Mode OFF>

>Ich darf den Code leider nicht online Stellen und er beträgt jetzt
>mindestens auch an die 30 Seiten!

Das, und die Fehlerbeschreibung, deuten auf einen Stack-Overflow hin.

Oliver

Hallo Karl
Ich benutze viele Variablen! Wenn das der Fehler wäre, was könnte man 
dagegen tuen?

Hallo egberto
Ich habe eigentlich immer darauf geachtet! Aber vielleicht hab ich mal 
was übersehen, werde gleich mal auf die Suche gehen!

wenn ich z.B. diese Zeile einfüge fangen probleme an!
while((mmc_write_daten(biom,archiv))!=0);

Was sagt denn deine Entwicklungsumgebung dazu, wieviel Ram belegt ist?

Und falls das nicht auch geheim ist: Welcher Prozessor wird verwendet?

Oliver

Ich benutze einen Atmega162! Und es ist noch ein drittel des 
Speicherbereichs frei! Laut AVR Studio

Wenn da steht: data xx byte (66% full), dann bedeutet das, daß 66% des 
Rams schon mit globalen oder statischen Variablen belegt sind, bevor 
dein Programm auch nur eine Zeile ausgeführt hat. Wenn da jetzt noch 
größere lokale arrays oder tief geschachtelte Funktionsaufrufe 
hinzukommen, wird es halt eng.

Oliver

Bei mir steht folgendes
Program:   12050 bytes (73.5% Full)
Data:        234 bytes (22.9% Full)
aber vielleicht habe ich schon eine Lösung gefunden! werde es morgen 
ausprobieren. vielen dank für die hilfe!

hast du
deine variablien global oder lokal definiert

hab sie alle unter int main() angelegt!
mache morgen weiter muss jetzt leider aufhören!

ich packe die daten in eine string und diesen lege ich auf die mmc 
karte.
die größe des array ist somit uint8_t array[512].

Entwicklungsumgebung (Compiler?)

Beim ICC-AVR Compiler gibt es so eine unscheinbare Einstellung für den
"Return" Stack. Der Compiler verwaltet zwei Stacks (macht gcc und Co 
glaub auch so). Auf dem "Return" Stack werden nur die Rücksprungadressen 
abgelegt und Variablen auf dem "Datenstack". Wenn du Funktionen benutzt 
wie printf(), die viele Unterprogrammaufrufe oder evtl. sogar rekursiv 
sind, dann muss die
Größe des Return-Stacks angepasst werden!

Tut man das nicht, dann rennt einem das Programm ins Nirvana....

Beim ICC gibt es auch eine Stack-Check Funktion. Ist zwar nicht absolut 
sicher, aber es hilft manchmal das Problem einzugrenzen.

Ein anderer Fehlertyp, der einem passieren kann ist z.B.

1

funtionX()

2

{

3

  CLI(); // Interrupts sperren

4

  [...]

5

  SEI(); // Interrupts freigeben

6

7

}

8

9

ISR()

10

{

11

 funktionX();

12

}

So genug Arbeit für die Glaskugel für heut ;-)

Hallo!

Ich hatte vor gewisser Zeit ein änhliches Problem:

Ab einer gewissen Grösse funktionierte mein Code nicht mehr. Sobald ich 
also eine Zeile hinzufügte ging nichts, aber auch garnichts mehr. (Nicht 
mal LED Sign of Life). Die Zeile konnte wie bei dir beliebig sein.

Das Problem lag dann beim meinem Eeprom Emulator. Der war auf ne zu 
kleine Grösse eingestellt und sobald ich diese überschritten hatte ging 
nichts mehr.

Ich würde bei dir auf ein ähnlich geartetes Speicherproblem schliessen. 
Da es ja egal ist, welche Zeile du einfügst, muss es zwangläufig 
irgendetwas mit der Codegrösse zu tun haben.

Grüsse

Hallo Karl
Hab die Variablen mal globalisiert und es sind 90.8% belegt. Ist das zu 
viel?

Hallo Matthias
Wie kann ich denn den Stack vergrößern?

>Hab die Variablen mal globalisiert und es sind 90.8% belegt. Ist das zu
viel?

Jaaaaaa :-)

>Wie kann ich denn den Stack vergrößern?

Gar nicht. Beim avr-gcc nimmt der sowieso schon allen Platz ein, der 
verfügbar ist.

Oliver

okay dann fang ich mal an zu optimieren!

Ich wollte mich noch mal bei allen bedanken! Der Fehler ist gefunden! Es 
war so wie ihr gesagt habt. Habe die Variablen optimiert und jetzt 
funktioniert es
ohne probleme! Bis jetzt zumindestens
vielen dank noch mal