Atmega128 startet immer neu

[Michael B. (planlessmichi)]

Hallo Profis,

könnte mir bitte jemand ein paar Tipps geben, was ich noch machen kann?
Kurze Erklärung:
Ich baue inzwischen schon seit fast zwei Jahren immer wieder mal an 
meinem ersten "Großprojekt": Einer GSM-Steuerung für eine 
Kfz-Standheizung.
Ich habe dabei immer wieder kleinere Bausteine entwickelt und die 
solange getestet, bis sie wirklich "stabil" liefen.
Seit knapp 3 Wochen sitze ich dran und will aus den vielen kleinen 
Einzelprojekten das fertige Produkt machen. Seit eben habe ich ein 
Problem und habe jetzt keinerlei Idee, wie ich die Fehlersuche 
bewältigen soll.
Als "Hirn" benutze ich einen ATMega128L; an USART0 hängt - über Jumper - 
ein GSM-Modul, an USART1 - auch über Jumper - ein GPS-Modul.
Wenn ich an der einen Baustelle (z.B. GSM) gearbeitet habe, dann habe 
ich über die andere USART-Verbindung immer Debugging-Ausgaben 
geschrieben. Das funktioninert auch ganz gut.
Jetzt ist eine weitere Baustelle (MMC-Karte) dran und wenn ich versuche, 
die Karte zu initialisieren (Code hier aus dem Forum), dann mache ich 
danach eine Ausgabe, ob es geklappt hat, oder nicht.
Nur... Direkt nach dem "mmc_init()" schmiert mir der µC ab und startet 
wieder komplett von vorne.
Wenn ich nur die MMC-Sourcen in ein eigenes Projekt auslagere und das 
auf die gleiche Hardware programmiere, läuft alles einwandfrei: Karte 
erkannt, initialisiert, Datei angelegt, beschrieben, geschlossen. Wie es 
sein sollte...

Jetzt habe ich verschiedene Threads durch und u.a. gelesen, dass einem 
die
MCUCR und / oder MCUCSR Register Auskunft erteilen können...
Also habe ich zu Debug-Zwecken den Code etwas erweitert und direkt im 
main die beiden Register ausgelesen und zwischengespeichert:

int main()
{
  uint8_t cResetData1 = MCUCR;
  uint8_t cResetData2 = MCUCSR;
  char caResetReason[10];
  ...
  // DEBUG
  uart_puts("Reset-Daten: 0x");
  uart_puts(itoa(cResetData1, caResetReason, 16));
  uart_puts(" und 0x");
  uart_puts(itoa(cResetData2, caResetReason, 16));
  uart_puts("\r\n");
  ...

Etwas später im Programm, wenn dann die Hardware fertig initialisiert 
wurde, habe ich die beiden Werte ausgeben lassen: MCUCR ist immer 0x00, 
MCUCSR immer 0x03; sowohl beim ersten Einschalten, wenn die Spannung 
angelegt wird, als auch dann, wenn ich die MMC-Karte initialisieren will 
und sich das Teil verabschiedet.

Kann ich als Hobby-Bastler da irgendetwas machen, oder muss ich mir 
jetzt irgendwelche Hardware zulegen, um dann vermutlich monatelang zu 
debuggen (wenn das überhaupt geht)? :-(

Da mir jetzt wirklich komplett ein Ansatz fehlt, hoffe ich sehr auf Eure 
Erfahrungen und Tipps.

Ich weiß jetzt nicht, ob es etwas bringt, den SourceCode zu posten; der 
ist doch schon ziemlich groß und nur Auszüge würden wohl auch nichts 
bringen, weil die Einzelbaustellen ja funktionieren.... Und ohne diese 
spezielle Hardware... Aber wenn's ist: Bitte kurz Bescheid geben, dann 
mache ich das natürlich: Ist ein AVR Studio 6 Projekt...

Ach und übrigens: Die Fuses habe ich mit angehängt. Den wohl häufigen 
Grund für Resets (M103-Kompatibilitätsmodus) habe ich wohl nicht; sollte 
deaktiviert sein.


Viele Grüße,
Michael

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Michael B. schrieb:
> Nur... Direkt nach dem "mmc_init()" schmiert mir der µC ab und startet
> wieder komplett von vorne.

Es wäre schön, wenn du wenigstens einen Verweis auf die benutzte SD/MMC 
Software mitgeliefert hättest. So kann ich nur raten, ob du evtl. 
versuchst, einen nicht initialisierten Interrupt (z.B. den SPI IRQ) zu 
feuern.

[Pete K. (pete77)]

Ein Neustart hängt oft mit der Spannungsversorgung zusammen.
Hast Du alles nach Datenblatt aufgebaut (Abblockkondensatoren) und 
liefert Dein Netzteil genügend Strom?

GPS-Modul und SD-Karte hört sich für mich nach >300mA an.

Poste bitte mal den Hardware-Aufbau.

[Michael B. (planlessmichi)]

Also der SourceCode von der MMC-Ansteuerung ist der hier:
http://www.mikrocontroller.net/attachment/116369/AVR-mmc-0.6.4.zip

Den Schaltplan habe ich angehängt...

Stromaufnahme, denke ich  jetzt fast nicht.... Selbst beim Senden einer 
SMS blieb die ziemlich konstant... bei 4.0V und BODLEVEL ist 2.7V...

[g457 (Gast)]

> MCUCR ist immer 0x00, MCUCSR immer 0x03

Löschst Du die auch gelegentlich?

Und wie siehts mit dem verfügbaren freien Speicher aus?

[Michael B. (planlessmichi)]

Nee, also mit diesen beiden Registern habe ich selbst aktiv gar nichts 
gemacht.... Ich habe jetzt allerdings keine Ahnung, ob irgendeine 
benutzte Lib (UART, DS1820, MMC) die Reister verwendet.

Vom Speicher sieht es so aus:
text     data      bss      dec      hex  filename
20504     1610     2642    24756     60b4  GSMParkHeatingControl.elf

[g457 (Gast)]

> Nee, also mit diesen beiden Registern habe ich selbst aktiv gar nichts
> gemacht

Nach dem Auslesen löschen, die werden nicht (alle) automatisch genullt. 
Details stehen im Datenplatt.

> Vom Speicher sieht es so aus:

Das ist ja schon statisch total überfüllt. Mach da mal ordentlich was 
frei. Ich vermute jetzt einfach mal wild drauf los dass Du den Speicher 
mit einem Überlauf korrumpierst.

[Michael B. (planlessmichi)]

Sorry, habe gerade gesehen, dass ich den alten Schaltplan gepostet habe 
:-(
Anbei also der aktuelle. Was hat sich geändert: Ansteuerung der MMC 
jetzt über HW-SPI; Ansteuerung der Transistoren im Anschluß-Panel 
(werden aber aktuell noch nicht angesteuert)

[Michael B. (planlessmichi)]

g457 schrieb:
> Das ist ja schon statisch total überfüllt.

??? O.k., jetzt stehe ich auf dem Schlauch... Wieso ist der überfüllt???
Welcher Wert sieht da denn jetzt kritisch aus?

[Spess53 (Gast)]

Hi

>Das ist ja schon statisch total überfüllt.

Der ATMega128 hat 4k.

MfG Spess

[g457 (Gast)]

>>Das ist ja schon statisch total überfüllt.
>
>Der ATMega128 hat 4k.

Da fehlt ein 'nur'. Mit über 3k2 statisch belegt stehen die Chancen gut, 
dass man zur Laufzeit mehr Speicher belgt als wie da ist. Insbesondere 
wenn man nicht aufpasst.

Muss nicht die Fehlerursache sein, ist aber sicher ein guter Kandidat. 
Und sehr leicht händisch zu debuggen.

[Michael B. (planlessmichi)]

Hallo zusammen,

also anscheinend hat es wirklich am Speicher gelegen...
Ich wollte eigentlich sicherheitshalber - bis auf wenige Loop-Counter 
innerhalb einer Funktion etc. - komplett alles statisch machen, da ich 
dachte, so das Risiko zu minimieren, dass das Teil nach ein paar Wochen 
sich plötzlich ganz komisch verhält. Wenn ich zur Laufzeit keinen 
einzigen Speicher dynamisch anlege, dann sollten irgendwelche 
Speicherüberschreibungen auch eher nicht vorkommen...
Bin halt doch leider nur ein Hobby-Bastler...

Wie auch immer; ich habe beim SRAM eigentlich immer nur die Zahlen bei 
dieser "bss"-Spalte betrachtet und dachte, dass ich mit grob 2,6k noch 
dicke unter den erlaubten 4k bin und dass dann genug freie Resourcen für 
den Stack da sein sollten....

Ich habe daraufhin den ATMega128L jetzt durch einen ATMega2561V 
ausgetauscht (8kByte SRAM) und siehe da: Jetzt funktioniert es wohl 
wieder...

Jetzt mal echt blöd gefragt:
Wofür stehen denn diese "text", "data", "bss" und "dec/hex" Zahlen und 
was genau befindet sich darin?

So, wie ich das jetzt verstanden habe:
"text" ist die Sektion im Flash, in dem die Funktionen meines 
eigentlichen Programmcodes stehen.

"data" ist der Teil im SRAM, der alle fixen und bekannten Variablen 
enthält (z.B. Strings etc.); also Daten, die schon beim Compilieren 
einen Wert haben.

"bss" ist der Teil - auch im SRAM - , bei dem zwar die Größe, nicht aber 
der Inhalt fest steht (also z.B. arrays, die z.B. für einen 
Datenaustausch gedacht sind, aber nur mit z.B. char test[256] angelegt 
wurden.

"dec" bzw. "hex" ist die Summer aller drei Werte (wofür auch immer man 
diese Zahl benötigen sollte)

Ist das soweit richtig oder sehe ich das falsch? Gibt es eigentlich 
"Faustformeln", wieviel SRAM nach dem Linken frei bleiben sollte?

[Josef D. (jogedua)]

Beitrag "AVR Studio5 AVR Memory Usage"
http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch

[Michael B. (planlessmichi)]

Cool; Danke! Wusste gar nicht, dass es eine Möglichkeit gibt, etwas 
"manuell" noch vor der main() zu tun :-)

Also dieses "data" ist also ein Zwitter... Das beinhaltet sowohl Daten 
aus dem Flash, als auch Daten aus dem SRAM.... Das werde ich mir wohl 
noch genauer anschauen müssen...

Irgendwie schon immer wieder faszinierend, wenn man vor dem PC sitzt und 
einem durch solche "Basics" wieder vor Augen geführt wird, wie extrem 
viel Zeug da in so einer Kiste abgehen muss...

[Spess53 (Gast)]

Hi

>"data" ist der Teil im SRAM, der alle fixen und bekannten Variablen
>enthält (z.B. Strings etc.); also Daten, die schon beim Compilieren
>einen Wert haben.

Wieso müssen Strings im RAM stehen?

MfG Spess

[Michael B. (planlessmichi)]

Gut, 'MÜSSEN' müssen sie natürlich nicht ;-)
Aber für mich war es jetzt erstmal einfacher, weil ich gelesen habe, 
dass ich diese EEMEM Makros nicht verwenden darf, wenn ich auch manuell 
an gewisse Stellen im EEPROM etwas abspeichern und wieder einlesen will. 
Und da ich nicht jeden String mit read und write handeln wollte, sind 
einige jetzt auch direkt so im Code gelandet. Deswegen sind die mir mit 
als erstes eingefallen :-)

[Spess53 (Gast)]

Hi

>Aber für mich war es jetzt erstmal einfacher, weil ich gelesen habe,
>dass ich diese EEMEM Makros nicht verwenden darf,...

Ich lese hier immer etwas von 'progmem'. Da wird das im Flash abgelegt 
und nicht noch mal in den RAM kopiert.

MfG Spess

[Michael B. (planlessmichi)]

Spess53 schrieb:
> Ich lese hier immer etwas von 'progmem'. Da wird das im Flash abgelegt
> und nicht noch mal in den RAM kopiert.

??? Wie darf ich denn das verstehen?

[Spess53 (Gast)]

Hi

>??? Wie darf ich denn das verstehen?

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#progmem_und_pgm_read_xxx

MfG Spess