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?
liegen die Interruptsprungbefehle auch wirklich im richtigen Bereich?
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.
>>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...
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?
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
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
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
Wie man den Wald vor lauter Bäumen manchmal nicht sehen kann... das wars natürlich, besten dank Erich
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.