Estoy desarrollando un gestor de arranque USB para Infineon XMC 4400 micro. He modificado el archivo linker_Script.ld y he asignado 32K para flash.
MEMORIA {
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
}
tamaño_pila = DEFINIDO(tamaño_pila) ? tamaño_pila: 2048; no_init_size = 64; SECCIONES { /* sección TEXTO */
.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
El problema es que cuando trato de depurar el código y abrir el desensamblado, no veo nada en la dirección 0x08000000 (que es el inicio de BOOT FLASH). Mi tabla de vectores para la aplicación apunta a 0x08008000, que es donde debería estar como se esperaba. Entonces, ¿NECESITO tener una VECTORTABLE separada para BOOTLOADER? También estoy usando una función separada JumpToApplication(Jump_address) para saltar a la aplicación.
No está del todo claro lo que está preguntando aquí, pero para abordar una de sus preguntas, no, Cortex M4 no puede arrancar sin una tabla de vectores (o al menos las dos primeras palabras de una) en la dirección donde el hardware o la ROM de arranque deciden lo espera Es posible escribir un gestor de arranque que funcione completamente sondeando con interrupciones (al menos las recuperables) deshabilitadas, pero el proceso de inicio aún requiere el puntero de pila inicial y el punto de entrada desde el inicio de la tabla de vectores.
Por lo general, sí, su cargador de arranque requiere su propia tabla de vectores.
Si la tabla de vectores de la aplicación estuviera en la dirección de hardware esperada y el cargador de arranque mantuviera las interrupciones desactivadas, eso podría funcionar pero sería arriesgado porque el proceso de arranque (incluso para el cargador de arranque) se interrumpiría al borrar el área de memoria de destino.
Tenga en cuenta que algo que está en la memoria y que el depurador le da sentido son cosas distintas. El desensamblado simbólico dependería de que informe al depurador sobre lo que está examinando, normalmente cargando el archivo .elf apropiado en el depurador. En el caso habitual en el que el cargador de arranque y la aplicación son compilaciones distintas, debe cargar el .elf del proyecto que desea examinar, aunque la ejecución pueda pasar momentáneamente a través del otro.
Y, por supuesto, también debe asegurarse de haber cargado tanto el cargador de arranque como la aplicación en la memoria flash y no haber hecho accidentalmente algo como un borrado completo del chip antes de cargar el segundo.
filo