Bootloader Newbie Question

[ralpok]

I am working on attempting to make homegrown bootloader. I have begun to dig into the CCS example bootloader and found something I don't understand and would really appreciate some help.

In their loader.c file they define the variable LOADER_END. As far as I can tell this #define is used to determine the overall size of the program memory for following #org statements. Then I find in ex_bootloader.c statements that use this LOADER_END+20 in one of the #org statements. This seems to me like it would be indexing beyond the given memory space for program memory.

This seems wrong to me, so if somebody can explain what is really happening or why it is done I would very much appreciate it.

Thanks in advance.

[ckielstra]

In bootloaders for the PIC there are two possible concepts:
1) locate the bootloader at the start of memory.
2) locate the bootloader at the end of memory.
Both concepts have their strong and weak points and it depends on your application which is the best choice.

It looks like CCS first decided to locate the bootloader at the end of memory but later decided to move it to start of memory. What you see in loader.c are the remainders of the old choice and should be ignored (check bootloader.h for the actual used defines).

[Ken Johnson]

This is a topic that has long interested and puzzled me.

Microchip has protect fuses for a boot block in low memory, but this requires re-locating interrupt vectors.

Can some of you knowledgeable folks expound more on the pros/cons of locating bootloader in low vs high memory? Or point to a discussion?

Thanks,
Ken

[ralpok]

Thanks ckielstra, it makes more sense when you are looking at the correct #Defines.

[ckielstra]

Ken,
Here a first attempt to list the (dis)advantages for locating the bootloader high or low in memory. Additions to the list are welcome.

Low in memory
Advantages

- Possible to use the memory protection flag (but on older PIC models only a very small memory region),
- Does not conflict with the program memory reserved for the ICD.
- Stable; loading a new application does not require changes to the bootloader program.

Disadvantages

- The user application has to be relocated to a new start address. This means the User program has to be aware of a bootloader being present and the size of the bootloader.
- A new bootloader version with increased size requires a new compilation of the user application.
- Interrupts have to be relocated.
- Because of relocation about 2 instructions extra overhead in every interrupt call.
- The interrupt relocation occupies 20 bytes (PIC18). A waste of memory space when the user application has no interrupts.

High in memory
Advantages

- No User's program relocation required. A bootloader being present or not, the User's program is the same.
- A new bootloader version with changed size does not require a recompilation of the User's program.
- No extra bootloader introduced delays in the interrupt handler.
- No memory waste when interrupts are not used (20 bytes, PIC18)

Disadvantages

- Not possible to use the bootloader memory protection flags.
- Is in the same program address range as the resources reserved for the ICD. This can be worked around by reserving that memory, but is a waste of program memory.
- The Power-on reset vector must be set to the bootloader on every new program load. Many bootloaders do this on-the-fly. There is a (very) small risk that writing the reset vector fails (power failure, etc) leaving a disfunctional bootloader.

[ralpok]

Thanks again for the awesome information ckielstra. One thing that struck me as unexpected was the part about the ICD having a reserved memory block.

Where could I find out more information about this?
How big is it and where? Is it always the last N-bytes of memory?


Thanks!!

[ckielstra]

The resources used by the ICD are different for every processor, something between 0 to 500 bytes at the end of ROM, a few bytes RAM and 1 or 2 stack levels. Information about the exact resources is sometimes mentioned in the processor's datasheet but best place to look is in the ICD help file for the MPLAB version you are using:

In MPLAB, go to Help / Topics / Debuggers - MPLAB ICD2
Select the Index tab
search for 'Resources' and it will come up with 'Reserved Resources'
Find your processor in the list.

[Ken Johnson]

ckielstra, I do appreciate the pro/con info - many thanks!

re: icd/mplab memory use - I assume this applies only when debugging, correct ?

what about the ccs icd without mplab ?\

Thanks again,
Ken

[ckielstra]

[oxo]

[temtronic]

comment.

Just because the bootblock size is 1K, doesn't mean the loader is that big.
Think of your bank account being allowed 1,000 euros.But you only have 600 euros in it. Trying to withdraw 722 euros will cause a problem !! You're now 'overdrawn' and in trouble.

Same holds true with the PIC..if you try loading code beyond the end of the loader, you'll get 'garbage' and crash the program.

hth
jay

[Ttelmah]

However if you have turned on the protection, then your actual loadable code will always have to start after the end of the bootblock, or it can't be written by the bootloader. So the build location would have to use the bootblock size, not the size of the bootloader (assuming the former is larger than the latter).

Best Wishes