|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Timo Sandmann
Datum: Di, 23.10.2007 07:27:30
In-reply-to:
<471D1C68.6050604@xxxxxxx>
References:
<46F96285.8020005@xxxxxx> <2CD3D281-AE62-4FBB-8419-C3EBB7DAFCE9@xxxxxxxxxxxxxxx> <4717C8C2.2030701@xxxxxxx> <0D6C693E-3EAE-4201-9A19-6B321F17EF88@xxxxxxxxxxxxxxx> <471D1C68.6050604@xxxxxxx>
Hallo Thomas,
Am 22.10.2007 um 23:55 schrieb Thomas Kregelin:
der Code kommt nicht von mir. Ich habe das Problem vor einiger Zeit
im Forum gepostet und habe die Modifikation als Antwort bekommen.
Ich habe auch erst gedacht, dass dieser Code eigentlich nichts
anderes tut als die Interrupts zu deaktivieren - doch genau diese
Änderung hat das Problem bei mir behoben.
Man kann aber auch definitiv sagen, dass mit der Operation
GICR=0x00 das IVSEL-Bit auf 0 gesetzt wird. Damit ist dann
sichergestellt, dass die /Interrupt Vectors Start Address/ auf
0x0002 gesetzt wird. Ist das IVSEL-Bit im Register aus
irgendwelchen Gründen auf 1 gesetzt, ruft sich der Bootloader nach
einem Interrupt doch selbst auf, oder habe ich das falsch verstanden?
na ja dann würden wir bei einem Interrupt irgendwo in den Bootloader
springen, je nach Interrupt.
Das GICR ist aber laut Atmel nach dem Booten immer 0 und ich kann mir
weder vorstellen, dass das nicht so ist, noch dass es von ATmega32 zu
ATmega32 verschieden sein kann
.
Welche Compiler-Version benutzt du denn?
Falls dich interessiert, woran das Problem liegt oder liegen könnte,
müsstest du mal in den Compiler-Optionen (Miscellaneous) folgendes
hinzufügen
-save-temps -fverbose-asm
und mir aus dem Debug-MCU-Verzeichnis die Datei bootloader.S
schicken. Vorher Bootloader in ct-Bot.h aktivieren und ohne die von
dir genannten Änderungen (also der Code, der nicht funktioniert),
vielleicht kann ich dir dann sagen, ob und was bei dir anders ist.
Viele Grüße,
Timo
|
|
|