Problem mit Interrupt im Bootloader

[Erich (Gast)]

Habe eine Problem mit dem Interrupt im selbst geschriebenen 
Bootloader...

Es sieht so aus, also ob der ATMega640 resetet sobald ein interrupt 
auslösst...

Wenn ich den Bootloader auf Startadresse 0 ins Flash schreibe 
funktioniert alles mit den interrupts. Schreibe ich den Bootloader aber 
in den defür vorgehenen Bereich im Flash (mit 
-Wl,--section-start=.text=0x7000) auf die adresse 0x7000, resetet er 
sich immer...

gemäss Datanblatt hab ich die rücksprungadresse der interrupts in den 
Bootloaderbereich verschoben mit:
MCUCR = SpeichereMCUCRL |(1<<IVCE);
MCUCR = SpeichereMCUCRL |(1<<IVSEL);

Um timingfehler beim setzen von IVSEL Auszuschliessen habe ich die 
Optimierung im Compiler ausgeschaltet...


wenn ich versuchsweise eine endlosschleife im interrupt mache, resetet 
der ATMega trotzdem... sprich es sieht so aus, als ob dieser die ISR nie 
durchläuft... (BOOTRST Bit ist entsrpchende gesetzt)


Jemand eine Idee was ich falsch mache?

[nicht "Gast" (Gast)]

liegen die Interruptsprungbefehle auch wirklich im richtigen Bereich?

[Purzel H. (hacky)]

Soweit ich mich erinnere, ist der Boot Loader immer auf Null. Die 
Interrupts muessen natuerlich auch auf Null sein. Der andere Bereich ist 
ja ueberschreibbar.

[Erich (Gast)]

>>nicht "Gast" (Gast)
>>liegen die Interruptsprungbefehle auch wirklich im richtigen Bereich?

Wie kann ich das überprüfen? meine das legt ja der compiler fest nicht 
ich selbst...

@Dürrer Zitterknilch
ne stimmt nicht, bei 0 begint die application selection, die 
bootloaderselection beginnt nach fuse einstellungen an einer 
entsprechende Adresse...

[Peter D. (peda)]

Erich schrieb:
> Wie kann ich das überprüfen?

Ins Assembler-Listing schauen (*.lss).


Peter

[Erich (Gast)]

Habe mal das *.lss file angeschaut und meine abscheu gegen simulatoren 
überwunden und das ganze kurz simuliert...

ganz klar ist mir das ganze jedoch trotzdem noch nicht...

meine vorherige feststellung, dass der interrupt gar nicht druflaufen 
wird hat sich als richtig erwiesen. sobald ein interrupt ausgelöst wird, 
spricht das programm auf die adresse 0x7000.

Der Simulator gibt die Warnung: "invalide oppcode at adress 0x007002" 
heraus.

Im Simulator ist mir aufgefallen, dass mein Code zwar im *.hex file wie 
gewünscht bei der startadresse 0x7000 beginnt, im dissasmbler file im 
simulator jedoch bei der adresse 0x0000...

wenn ich im *.lss file schaue steht da
00007000 <__vectors>:
    7000:  0c 94 72 38   jmp  0x70e4  ; 0x70e4 <__ctors_end>
    7004:  0c 94 a3 39   jmp  0x7346  ; 0x7346 <__vector_1>
    7008:  0c 94 8f 38   jmp  0x711e  ; 0x711e <__bad_interrupt>
    700c:  0c 94 8f 38   jmp  0x711e  ; 0x711e <__bad_interrupt>
    7010:  0c 94 8f 38   jmp  0x711e  ; 0x711e <__bad_interrupt>

wenn ich mit dem datenblatt vergleiche, fällt mir auf, dass der INT0 den 
ich verwende hier oben auf adresse 0x7004 ist, im datenblatt aber auf 
0x7002 (Ausschnitt aus dem Datenblatt Seite 105) "2 $0002 INT0 External 
Interrupt Request 0")

Hat jemand eine idee was genau ich falsch mache?

[Erich (Gast)]

woran liegt dass, dass mein programm im simulator bei 0x3800 beginnnt, 
obwohl es laut *.lss und *.hex bei 0x7000 beginnt (wie gewollt). 0x3800 
wäre genau die hälfte... bei einem interrupt der siulator jedoch auf die 
eigentilch richtige adresse von über 0x7000 hmmm

[Sascha W. (sascha-w)]

im .lss und .hex File steht die Byteadresse, da der Speicher aber zu 
16Bit organisiert ist, zeigt der Dissassembler des Simulators die 
entsprechende Wordadresse an. Damit erklärt sich auch die 'verschiebung' 
des INT0 0x0002(Word)=0x0004(Byte)

Sascha

[frank (Gast)]

Sascha Weber schrieb:
> ... da der Speicher aber zu
> 16Bit organisiert ist, zeigt der Dissassembler des Simulators die
> entsprechende Wordadresse an.

Das ist die richtige Fährte. Der Bootloader muss bei BOOTSZ1 = 0 und 
BOOTSZ0 = 0 an die "Wordadresse" 0x7000.
frank

[Erich (Gast)]

Wie man den Wald vor lauter Bäumen manchmal nicht sehen kann...
das wars natürlich, besten dank Erich