Setting bootloader to the end of the memory

[ferlyn]

Hi,

I'm new to bootloader, hope to get some advise, using loader.c and ex_bootloader.c for testing. I managed to change the bootloader code to the end of the memory by following modification,

in loader.c
#define LOADER_END getenv("PROGRAM_MEMORY")-1
#define LOADER_SIZE 0x5FF
#define LOADER_ADDR LOADER_END-LOADER_SIZE

#ORG LOADER_ADDR, LOADER_END auto=0 default
void real_load_program (void)
:
:
void load_program(void)
{
real_load_program();
}
#ORG default

and remove all the #org in ex_bootloader.c file, looking at the .sym this seems to be working. However this does not "tell" the complier NOT to place code in bootloader area. Thus i tried to add

"#org LOADER_ADDR, LOADER_END {}" to my code and see error as follows;
Executing: "C:\Program files\Picc\CCSC.exe" +FM "ex_bootloader_test.c" +DF +LN +T +A +M +Z +Y=9 +EA
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 00000-007FF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 00800-00FFF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 01000-017FF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 01800-01FFF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 02000-027FF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 02800-02FFF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 03000-037FF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 03800-039FF (0000 used)
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Segment at 03A00-03FFF (0000 used) Priv
--- Info 300 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): More info: Attempted to create: 03A00-03FFF for #org
*** Error 126 "E:\Workarea\16F1939\loader_test.c" Line 56(30,31): Invalid ORG range

1. Can I change the Bootloader code to the end of the memory instead of the begining??

2. How to "tell" complier not to use the memory reserved for bootloader (e.g: 0x3A00- 0x3FFF )

The problem i'm facing now, is complier will place some code into my reserved block (for bootloader) after I added in some test code. My test code takes up 4% of ROM only...

I'm using PIC16F1939, PCM ver4.112
Thanks .....

[Ttelmah]

I have to ask 'why' you want to put the loader at the top of memory?. Historically on some chips there was an advantage to this (ones that had the boot vector, and interrupt vectors at the top of memory), but on the PIC, there isn't.

With a top of memory bootloader, on the PIC, you end up needing three sections to your code. At the base of memory, you need the 'relocater'. The code that vectors the boot to the loader, and possibly vectors interrupts to the loader (if it uses interrupts).
Your main code goes after this, between this and the top of memory loader. Now the first problem then becomes the flash erase size. Your loader when done this way, either _must_ handle reading, and re-writing a 'part' memory page, _or_ the main code cannot start till the second page boundary (or has to include the relocation code internally). Makes the bootloader, or the main more complex, or wastes space....

Finally at the top of memory comes the bootloader itself.

Also on most PICs it is the first few KB of memory that can be separately protected from writing, _for_ the bootloader.

You _need_ the #ORGs in ex_bootloader.c, but they need to position the main above the 'relocater' code, rather than the whole loader. The build needs to put the main above the relocater, and a #ORG, then needs to have as it's 'top' entry the address of the start of the loader-1.

Best Wishes

[ckielstra]

Yes, it is possible to put the bootloader at the end of memory, but why do you want to do this?
Both options, beginning or end of memory, do have pro's and con's. Fact is that most PIC bootloaders use start of memory so there might be a good reason for that...
Long time ago I created a list with pro's and con's. Not utterly complete but gets you started: http://www.ccsinfo.com/forum/viewtopic.php?t=32558

For me the single one reason never to use a bootloader high in memory is that it can brick your device. The bootvector for the PIC is at memory start, so with the bootloader high in memory every new loaded application will overwrite the boottrap in low memory again (the Flash program memory is erased and written in pages). If this fails for some reason your device is bricked.
This can be worked around by creating a third protected section at memory start, but then all the advantages of a bootloader in high memory are gone. Not an option.

[ferlyn]

Thanks for the advice..

I remapped my bootloader to the beginning of the memory. In my application, I'm using #INT_SSP instead of UART for data transfer. Thus I modified the real_load_program routine and add in my SMBUS. Problem arise when i tried to add "#INT_SSP"

Complier error as follows;
Executing: "C:\Program files\Picc\CCSC.exe" +FM "ex_bootloader2.c" +DF +LY +T +A +M -Z +Y=9 +EA
*** Error 159 "ex_bootloader2.c" Line 92(4,5): Invalid interrupt directive Can not mix GLOBAL with non-global

I remember I saw a POST mentioned not advisable to have interrupt but it is possible right? An example will be great. Thanks in advance...

[Ttelmah]

The _bootloader_ code, has to have INT_GLOBAL.
The program code, needs INT_SSP, and needs the build instruction to say 'where' the interrupt handler is to go.
It sounds as if you are trying to compile both together?. This will never work. The bootloader code re-vectors the interrupt to the location defined in the build.
The supplied examples do this correctly.

Best Wishes