mega128 hängt sich auf

[Marcus W (Gast)]

Hallo,

ich hab ein blödes Problem.

Ich versuch ein Display mit einem mega128 anzusteuern, allerdings 
scheint es so, dass sobald das Programm zu lang wird ("lang" ist 
relativ, eigentlich ist es nur ein Paar Zeilen kurz) der Controller sich 
aufhängt oder Resettet oder sowas ähnliches.

Ich hab den Code im Anhang, da wird beim initialisieren eine LED 
angeschalten. Diese sollte normalerweise nach Abschluss des Prozesses 
wieder ausgehen. Das tut sie aber nicht. Kürze ich den Code um ein paar 
Zeilen, nehme z.B. das  PORTA &= ~(1<<RS); raus, dann geht die LED am 
Ende auch aus.
Das ganze begreif ich derzeit nicht so richtig. Im AVR-Studio Simulator 
funktioniert alles wie von mir gedacht, nur in der realen Schaltung 
schaut es ganz anders aus.

Die restlichen Pins vom mc waren zur Testzeit offen, also keine externen 
Faktoren die da reinspielen könnten.

Habt ihr eine Idee?

Gruß Marcus

[abaa (Gast)]

watchdog aktiv?

[Marcus W (Gast)]

Das hatte ich auch schon überlegt, allerdings ist das ein Fabrikneuer 
mc, hab trotzdem die Fuse kontrolliert, WD is default off.
Ich hab derzeit noch die M103C Fuse im Verdacht, allerdings hat das 
Abschalten des Kompatibilitätsmodus auch keinen direkten Erfolg 
gebracht.

[Michael Wilhelm (Gast)]

Wie sieht denn der Stack aus bzw. wie hast du den initialisiert?

MW

[xlomx (Gast)]

hast du den prototypen von

void lcd_send_data(unsigned int TxData)
{
}

auch mit (unsigned int TxData) angelegt?

[Karl H. (kbuchegg)]

Die M103C Fuse muss abgeschaltet werden!
Wenn du das nicht tust und im Compiler einen Meg128
eingestellt hast, dann kann nichts funktionieren!
Der Compiler setzt sonst den Stack falsch auf.


Also: M103C abschalten, im Compiler einen Mege128 einstellen


Dann schiebst du in deinem Source Code mal die main()
ganz nach unten. Dein Compiler müsste jede Menge Warnungen
und Fehler ausgespuckt haben, da du für keine einzige
der restlichen Funktionen einen Prototypen hat. Dadurch
muss der Compiler Standardannahmen treffen, die - wie
könnte es anders sein :-) - in deinem Fall völlig falsch
sind.

Die beste Lösung ist es, wenn du keine Prototypen brauchst.
Das bedeutet aber auch, dass jede Funktion definiert sein
muss, bevor sie verwendet wird. Die einfachste Varianbte dies
zu erreichen besteht darin, main() ganz nach unten zu schieben.
Dadurch kommt im Quelltext jede Funktion vor, bevor sie verwendet
wird.

[Marcus W (Gast)]

Danke für eure Antworten.

Ich glaube langsam, dass es doch an der M103C Fuse liegt. Hatte leider 
nicht mehr die Zeit das genau zu testen und komm leider erst wieder am 
Montag dazu.
Wenns garnicht hinhaut werd ich das ganze mal in Assembler anschaun, da 
sieht man das glaub ich eher.

@MW
Unter C muss ich den Stack doch nicht manuell initialisieren

@Karl Heinz
Die Prototypen existieren in der main.h, die hab ich nur nicht 
angehangen :)
Wird wohl wirklich an der Fuse liegen.

@xlomx
Ja, der Prototyp ist genau so definiert.

Wieso fällt dieser Mega128 nur so aus der Reihe :)

Gruß Marcus

[Karl H. (kbuchegg)]

Marcus W wrote:

> Wieso fällt dieser Mega128 nur so aus der Reihe :)

Weil irgendjemand bei Atmel entschieden hat, dass der Mega128
so ausgeliefert wird, dass er sich wie ein 103 verhält.
Wodurch alle Leute, die leichtsinnig in ihren Entwicklungs-
umgebungen einen 128-er eingestellt haben, auf die Schnauze
fallen.

[Otto Richter (Gast)]

Hi Marcus,
hatte exakt das gleiche Problem mit einer komplexen Schaltung mit einem 
ATMega128. Die Ursache bei mir: zu viele Variablen im Ram (LCD-Texte). 
Habe diese dann ins Flash verbannt, damit waren die Probleme weg.
hoff s hilft,
Otto

[spess53 (Gast)]

Hi

Der ATMega128 ist nicht der einzige, der ein 'compatibility mode'- 
Fusebit besitzt. Beispielsweise kann der ATMega162 als ATMega161 
betrieben werden. Allerdings scheint der 128 der einzige zu sein, bei 
dem das Fusebit werksseitig gesetzt ist.

MfG Spess