Problem mit ATmega32

[Dennis (Gast)]

Hallo zusammen. Ich habe ein Problem mit einem ATmega32 der bei mir 
schon länger rumliegt. Folgende Infos habe ich:

* Eigentlich würde ich gerne das Programm AVR_test.c (angehängt) laufen 
lassen, dieses funktioniert jedoch nur wenn ich solange Dinge 
auskommentiere bis es <= 88 Bytes gross ist.
* Wenn ich ein neues Programm rauflade (d.h. ein anderes als vorher im 
ROM war, ein anderes als AVR_test.c) läuft das neue Programm einmal 
durch, jedoch mit fehlern, und hängt sich dann auf. Ebenso läuft 
AVR_test.c einmal durch (auch mit fehlern) wenn ich es wieder 
zurückwechsle.
* Wenn ich dasselbe Programm nochmals rauflade, das schon im ROM ist, 
passiert und ändert sich rein gar nichts. LEDs bleiben schwarz. Nichts 
passiert.
* Die vom ROM zurückgelesene Datei AVR_test_read.hex ist byte-weise 
identisch mit AVR_test.hex, dem original file. Am Programm scheint es 
also irgendwie nicht zu liegen.

Hat irgendwer irgendwelche ideen Wo da ein problem liegen könnte. 
Vielleicht eher bei der Hardware? Dass eine Lötstelle nicht mehr stimmt 
oder so? Oder können ATmega intern so kaputt gehen - eher nicht, oder? 
Hoffe jemand hat ein paar Ideen.

Grüsse, Dennis

[Joe S. (bubblejoe)]

Dennis schrieb:
> (d.h. ein anderes als vorher im
> ROM war, ein anderes als AVR_test.c)

Das Programm liegt im Flashspeicher.

[Dennis (Gast)]

Ja klar :). Sorry mein Fehler! Man ersetze "ROM" mit "flash" in meinem 
ganzen post.

[Spess53 (Gast)]

Hi

1. Löscht du den ATMega vor dem Programmieren?
2. Machst du nach dem Programmieren ein Verify?

MfG Spess

[amateur (Gast)]

Wenn auch Dein Programmierstiel preiswürdig in der Rubrik: "Mit großem 
Aufwand, maximal unlesbaren Code schreiben", ist, sollte er eigentlich 
laufen.

Keine Ahnung welcher Compiler.
Keine Ahnung welche Programmierumgebung.
Keine Ahnung welche Bratpfanne.
Keine Ahnung welche Fehlermeldungen.

Schätze aber mal, dass es an Punkt 2 oder 3 bzw. deren Einstellungen 
liegt.

Nur ein Tipp: Egal welcher Blödsinn in einem Hex-File steht. Hält es die 
Bedingungen an das Format ein und überschreitet der Code nicht den 
erlaubten Bereich, so muss es sich auch in den Prozessor schreiben 
lassen. Ob es auch funktioniert ist eine ganz andere Sache.

Es geht ja scheinbar keinen etwas an, aber wie kommst Du darauf dass 
dein Programm nicht im Flash landet? Manche Fehlermeldung ist 
interessanter als der gesamte Quellcode.

[Pete K. (pete77)]

Willst Du sieben Segmente je 20mA mit dem µC treiben? Gibt mal bitte 
Infos über den Hardware-Aufbau.

[Magnus M. (magnetus)]

Habe mir den Quellcode noch nicht angesehen, aber bist du dir sicher, 
dass du den Code auch für den Mega32 übersetzt hast?

[Dennis (Gast)]

Spess53 schrieb:
> Hi
>
> 1. Löscht du den ATMega vor dem Programmieren?
> 2. Machst du nach dem Programmieren ein Verify?
>
> MfG Spess

1. Ich programmiere mit

 avrdude -p m32 -c usbasp -U flash:w:AVR_test.hex -P usb

Das macht vor dem programmieren einen automatischen Löschvorgang.
2. Ein verify macht es glaube ich auch automatisch

avrdude gibt keinen Fehler, scheint alles zu funktionieren, jedoch ein 
warning, dass ich jedoch als nicht relevant einschätze. Der ganze 
output:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "AVR_test.hex"
avrdude: input file AVR_test.hex auto detected as Intel Hex
avrdude: writing flash (296 bytes):

Writing | ################################################## | 100% 0.92s



avrdude: 296 bytes of flash written
avrdude: verifying flash memory against AVR_test.hex:
avrdude: load data flash data from input file AVR_test.hex:
avrdude: input file AVR_test.hex auto detected as Intel Hex
avrdude: input file AVR_test.hex contains 296 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.86s



avrdude: verifying ...
avrdude: 296 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

amateur schrieb:
> Keine Ahnung welcher Compiler.
> Keine Ahnung welche Programmierumgebung.
> Keine Ahnung welche Bratpfanne.
> Keine Ahnung welche Fehlermeldungen.

* Compiler benutze ich avr-gcc
* Programmierumgebung keine / Linux
* Bratpfanne?
* Fehlermeldung keine / siehe oben. Probleme gibt es erst beim laufen 
des Programms auf dem Mikrokontroller selbst.

Pete K. schrieb:
> Willst Du sieben Segmente je 20mA mit dem µC treiben? Gibt mal bitte
> Infos über den Hardware-Aufbau.

Habe das Layout angehängt, daran sollte jedoch alles stimmen. Ist nicht 
von mir und wurde schon 100x benutzt.

[Dennis (Gast)]

Magnus M. schrieb:
> Habe mir den Quellcode noch nicht angesehen, aber bist du dir sicher,
> dass du den Code auch für den Mega32 übersetzt hast?

Eigentlich schon, aber siehe selbst, ich habe noch das Makefile 
angehängt.

Es hat auch vorher schonmal funktioniert (vor ca. 1 Jahr), meine 
Vermutung ist daher je länger je mehr, dass einfach ein Detail an der 
Hardware (z.B. eine Lötstelle) kaputt ist, aber dann verstehe ich nicht 
was und auch nicht warum das so komische Auswirkungen hat und nicht nur 
einfach 1 LED spinnt z.B. sondern gleich das ganze zeug.

[Hans Peter B. (Gast)]

Zu deinem AVR_test.c:
Schau dir mal unter
http://www.mikrocontroller.net/articles/Bitmanipulation
die Abschnitte "Bit setzen unter C" und "Bit löschen unter C" an, denn 
ein Bit mit 0 oderverknüpfen lässt einen µC äüsserst kalt
H. P.

[Joe S. (bubblejoe)]

Dennis schrieb:
> Es hat auch vorher schonmal funktioniert (vor ca. 1 Jahr), meine
> Vermutung ist daher je länger je mehr, dass einfach ein Detail an der
> Hardware (z.B. eine Lötstelle) kaputt ist, aber dann verstehe ich nicht
> was und auch nicht warum das so komische Auswirkungen hat und nicht nur
> einfach 1 LED spinnt z.B. sondern gleich das ganze zeug.

Dann teste deine Hardware einzeln durch, LED für LED, dauert zwar, aber 
so suchst du dir den Wolf, wenn am Ende noch mehrere Fehler im gesamten 
System stecken, deswegen immer Einzelbausteine testen, niemals das 
gesamte!
(In ganz blöden Fällen können sich Fehler auch mehr oder weniger 
gegenseitig "aufheben", sodass man sie kaum bemerkt bzw. erst sehr 
spät).