I am developing a USB bootloader for Infineon XMC 4400 micro . I have modified linker_Script.ld file and have allocated 32K for flash.


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 = DEFINED(stack_size) ? stack_size : 2048; no_init_size = 64; SECTIONS { /* TEXT section */

.Boot_text :
    sText = .;
    . = ALIGN(4);        
} > BOOT_FL_cached AT > BOOT_FL_uncached

.text :
    sText = .;
    *(.text .text.* .gnu.linkonce.t.*);

    /* C++ Support */

    /* .ctors */
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)

    /* .dtors */
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)

    *(.rodata .rodata.*)


    . = ALIGN(4);        
} > FLASH_1_cached AT > FLASH_1_uncached

The problem is when i try to debug the code , and open disassembly , I don't see anything at address 0x08000000(which is the start of the BOOT FLASH). My vector table for application is pointing at 0x08008000 which is where it should be as expected. So DO I NEED TO have a separate VECTORTABLE for BOOTLOADER ? Also I am using a separate function JumpToApplication(Jump_address) to jump to the application .

  • \$\begingroup\$ Please paste the complete linker script. \$\endgroup\$
    – filo
    Mar 12 '19 at 22:16

It's not fully clear what all you are asking here, but to address one of your aquestions, No, Cortex M4 cannot boot without a vector table (or at least the first two words of one) at the address where the hardware or ROM boot decider expects it. It is possible to write a bootloader which works entirely by polling with interrupts (at least the recoverable ones) disabled, but the startup process still requires the initial stack pointer and entry point from the start of the vector table.

So typically yes, your bootloader requires its own vector table.

If the application's vector table were at the expected hardware address and the bootloader kept interrupts dissabled, that might sort of work but would be risky because the boot process (even to the bootloader) would be broken by erasing the target memory area.

Note that something being in memory and the debugger making sense of it are distinct things. Symbolic disassembly would depend on you informing the debugger about what it is examining, typically by loading the appropriate .elf file into the debugger. In the usual case where the bootloader and application are distinct builds, you need to load the .elf of the project you are wanting to examine, even though execution might momentarily pass through the other.

And of course you also need to make sure that you have loaded both the bootloader and the application into flash itself, and not accidentally done something like a full chip erase before loading the second.

  • \$\begingroup\$ Thank you Sir, You pretty much answered my main question about whether to develop a separate Vector Table for Bootloader or not. \$\endgroup\$ Mar 13 '19 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.