• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 21 subscribers
  • Views 4683 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Making relocatable binaries for firmware updates

iron hide

We have a multi-app bootloader. The application starts with bootloader.uvprojx and then switches to one of the two applications namely: fw2000 and fw3000. So we have 3 binaries/executables on our controller at following addresses of the flash program/code memory space: bootloader at 0x0, fw2000 at 0x2000 and fw3000 at 0x3000 .
fw2000 and fw3000 are the same code but these two app firmwares here are compiled using absolute ROM addresses to create fw2000.bin and fw3000.bin. This is done in Keil by setting the address in "Options for target"->"Target"->"IROM1:" -> "Start" address to respective start address .

We have this architecture to update firmware. For that creating bin/hex specific to absolute address is not desirable.

Is there a way to compile a fwXXXX which can be relocatable at both the addresses? Such that, fwXXXX is compiled and the .bin ot .hex can be written at any address (in this case 0x2000 or 0x3000).

Parents
  • 0 in reply to iron hide

    The interrupt vector table relocation feature is quite common.

    All it does, is to make a piece of flash be mapped to the address range where the actual hardware expects to find it.

    But it doesn't take care of how the processor - when activating an interrupt - will be able to jump from the vector and into the relocated service routine.

    The normal way this is done is that the build tools knows the interrupt vector table will be mapped on top of address zero - but also knows about the exact address where the ISR code is. So the linker produces code that correctly jumps to the ISR. But if you load your code to some other address than what the linker prepared the code for, then this jump will fail.

    So the vector remapping fixes the jump into the table but not the jump out of the table and into the ISR. That's something your boot loader needs to fix. If the processor architecture uses absolute or relative jumps, affects how the boot loader needs to modify the interrupt vector table content.

Reply
  • 0 in reply to iron hide

    The interrupt vector table relocation feature is quite common.

    All it does, is to make a piece of flash be mapped to the address range where the actual hardware expects to find it.

    But it doesn't take care of how the processor - when activating an interrupt - will be able to jump from the vector and into the relocated service routine.

    The normal way this is done is that the build tools knows the interrupt vector table will be mapped on top of address zero - but also knows about the exact address where the ISR code is. So the linker produces code that correctly jumps to the ISR. But if you load your code to some other address than what the linker prepared the code for, then this jump will fail.

    So the vector remapping fixes the jump into the table but not the jump out of the table and into the ISR. That's something your boot loader needs to fix. If the processor architecture uses absolute or relative jumps, affects how the boot loader needs to modify the interrupt vector table content.

Children
No data