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
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.
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
1
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:
1
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
2
avrdude: AVR device initialized and ready to accept instructions
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.
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.
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.
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).
