I think you're asking how to make the application always start in the same place even if the bootloader changes size.
You simply write your own GLD file with explicit memory regions for the boot loader and the application. Something like this:
For the bootloader:
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0x2100-0x1000 reset : ORIGIN = 0x0, LENGTH = 0x4 ivt : ORIGIN = 0x4, LENGTH = 0x1FCbootloader (axr) : ORIGIN = 0x0200, LENGTH = 0x1800-0x0200 application (a!xr) : ORIGIN = 0x1800, LENGTH = 0x55800-0x1800For the application:
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0x2100-0x1000reset : ORIGIN = 0x0, LENGTH = 0x4ivt : ORIGIN = 0x4, LENGTH = 0x1FCbootloader (a!xr) : ORIGIN = 0x0200, LENGTH = 0x1800-0x0200application (axr) : ORIGIN = 0x1800, LENGTH = 0x55800-0x1800 Note that the attribute (axr) tells the linker it can put code in this block and (a!xr) tells it not to.
With the above allocation, as long as the bootloader never gets bigger than 5K, there's no problem.
You can make the boot section as large as you want as long as you're careful about the granularity
of erasable blocks. Some PICs (and other brands) can write-protect a bootloader area while
leaving the application area writable.
I haven't addressed the IVT problem. If the IVT is within the bootloader, then rebuilding the application can't
change the vectors. On some pics, the bootloader can change the base address of the IVT. If not, you may have to include a jump table in the app so the vectors (within the bootloader area) can be fixed.
post edited by marksullivan - 2021/01/21 18:39:58