• AVR Freaks

Hot!PIC Bootloader with EZBL. Force your bootloader/app to a certain address

Author
Post
Essentials Only Full Version
hamboy75
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2020/11/06 02:21:56
  • Location: 0
  • Status: offline
2020/11/11 23:47:49 (permalink)
0

PIC Bootloader with EZBL. Force your bootloader/app to a certain address

I'm new to pic but experienced in other microcontrollers
 
I'm doing a project for PIC24F family with a bootloader.
 
I have the bootloader and the code of the app already done, and it works.
Actually what i do with mplab X is import the gld file of the bootloader to the project, in linker files section. This will tell to the linker to add the code of the generated app to the end, after the bootloader (if i'm not wrong).
 
I would like to make this splitted...
 
If the bootloader size is 3kb for example, then o would reserve the first 4 kbs for the bootloader, and the rest of the size for the app. With this i would like abe to update the bootloader and continue being compatible with future and old versions.
 
With the current way (included as file of the app project) if the bootloader changes, then old binaries are not valid, since old app loading address will be part of the new bootloader (usually it will be bigger).
 
I have been thinking about it and I found a way for this... just adding an array with the rest of the size until the limit to make the size of the firmware exactly to the size that i want, but i'm just asking if there is another method.
 
Best regards.
#1

1 Reply Related Threads
    marksullivan
    Super Member
    • Total Posts : 128
    • Reward points : 0
    • Joined: 2010/10/25 16:51:05
    • Location: 0
    • Status: offline
    Re: PIC Bootloader with EZBL. Force your bootloader/app to a certain address 2021/01/21 18:34:30 (permalink)
    0
     
    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 = 0x1FC
    bootloader (axr) : ORIGIN = 0x0200, LENGTH = 0x1800-0x0200
    application (a!xr) : ORIGIN = 0x1800, LENGTH = 0x55800-0x1800
    For the application:
     
    data (a!xr) : ORIGIN = 0x1000, LENGTH = 0x2100-0x1000
    reset : ORIGIN = 0x0, LENGTH = 0x4
    ivt : ORIGIN = 0x4, LENGTH = 0x1FC
    bootloader (a!xr) : ORIGIN = 0x0200, LENGTH = 0x1800-0x0200
    application (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
    #2
    Jump to:
    © 2021 APG vNext Commercial Version 4.5