Ich entwickle einen USB-Bootloader für Infineon XMC 4400 micro. Ich habe die Datei linker_Script.ld geändert und 32 KB für Flash zugewiesen.
SPEICHER {
BOOT_FL_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x8000
BOOT_FL_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x8000
FLASH_1_cached(RX) : ORIGIN = 0x08008000, LENGTH = 0x00078000
FLASH_1_uncached(RX) : ORIGIN = 0x0C008000, LENGTH = 0x00078000
PSRAM_1(!RX) : ORIGIN = 0x1FFFC000, LENGTH = 0x4000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x8000
DSRAM_2_comm(!RX) : ORIGIN = 0x20008000, LENGTH = 0x8000
SRAM_combined(!RX) : ORIGIN = 0x1FFFC000, LENGTH = 0x14000
}
stack_size = DEFINIERT (stack_size) ? Stapelgröße: 2048; no_init_size = 64; ABSCHNITTE { /* TEXT-Abschnitt */
.Boot_text :
{
sText = .;
KEEP(*(.Boot_section));
. = ALIGN(4);
} > BOOT_FL_cached AT > BOOT_FL_uncached
.text :
{
sText = .;
KEEP(*(.reset));
*(.text .text.* .gnu.linkonce.t.*);
/* C++ Support */
KEEP(*(.init))
KEEP(*(.fini))
/* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)
/* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)
*(.rodata .rodata.*)
*(.gnu.linkonce.r*)
*(vtable)
. = ALIGN(4);
} > FLASH_1_cached AT > FLASH_1_uncached
Das Problem ist, wenn ich versuche, den Code zu debuggen und die Disassemblierung zu öffnen, sehe ich nichts an der Adresse 0x08000000 (was der Beginn des BOOT FLASH ist). Meine Vektortabelle für die Anwendung zeigt auf 0x08008000, wo sie wie erwartet sein sollte. MUSS ICH also eine separate VECTORTABLE für BOOTLOADER haben? Außerdem verwende ich eine separate Funktion JumpToApplication(Jump_address), um zur Anwendung zu springen.
Es ist nicht ganz klar, was Sie hier alles fragen, aber um eine Ihrer Fragen zu beantworten: Nein, Cortex M4 kann nicht ohne eine Vektortabelle (oder zumindest die ersten beiden Wörter davon) an der Adresse booten, an der die Hardware- oder ROM- Boot - Entscheidung erfolgt erwartet es. Es ist möglich, einen Bootloader zu schreiben, der vollständig durch Abfragen mit deaktivierten Interrupts (zumindest den wiederherstellbaren) funktioniert, aber der Startvorgang erfordert immer noch den anfänglichen Stapelzeiger und den Einstiegspunkt vom Beginn der Vektortabelle.
Normalerweise benötigt Ihr Bootloader also eine eigene Vektortabelle.
Wenn sich die Vektortabelle der Anwendung an der erwarteten Hardwareadresse befindet und der Bootloader Interrupts deaktiviert hält, könnte das funktionieren, wäre aber riskant, da der Bootvorgang (sogar zum Bootloader) durch Löschen des Zielspeicherbereichs unterbrochen würde.
Beachten Sie, dass etwas, das sich im Speicher befindet, und der Debugger, der daraus einen Sinn ergibt, unterschiedliche Dinge sind. Die symbolische Disassemblierung würde davon abhängen, dass Sie den Debugger darüber informieren, was er untersucht, normalerweise durch Laden der entsprechenden .elf-Datei in den Debugger. In dem üblichen Fall, in dem Bootloader und Anwendung unterschiedliche Builds sind, müssen Sie die .elf-Datei des Projekts laden, das Sie untersuchen möchten, auch wenn die Ausführung vorübergehend die andere durchlaufen könnte.
Und natürlich müssen Sie auch sicherstellen, dass Sie sowohl den Bootloader als auch die Anwendung in das Flash selbst geladen haben und nicht versehentlich so etwas wie eine vollständige Chip-Löschung durchgeführt haben, bevor Sie die zweite geladen haben.
Filo