ex_bootload example doubt

[m_embedded]

Hi all ,

In the ccs bootload example i seen that the reset and interrupt vector is remapped , my doubt is if we relocate the reset vector to bootloader END address + 1, then at every reset(hardware or software reset) the program may start from bootloader END address + 1 is it correct

[Ttelmah]

Depends what you mean.

The _hardware_ always resets to the first address in memory.
This then runs the bootloader, which (in the case of the example), checks it's 'trigger' pin, and if this is not set, immediately jumps to bootloader end+1. starting the main code.
So a handful of extra instructions in the bootloader are always run, before the main code is executed.
On a chip like the PIC, with a fixed 'reset' address, this is the only way a booloader can work.

Best Wishes

[m_embedded]

[Ttelmah]

In the examples. ex_bootloader.c, is the bootloader. ex_bootload.c is the example application.
When you compile the application, it's reset address _has_ to be after the bootloader (as must it's interrupt address). You place it at the point where the bootloader jumps to, when it completes. This is done by bootloader.h, loaded with the application.
The _bootloader_ sits at the start of memory, and must not be overwritten, so the application has to be located above the bootloader.
The hardware still jumps to the first address in memory, executes the bootloader, which then jumps to the address after itself, if it is not enabled, jumping into the application.

Best Wishes

[m_embedded]

[RF_Developer]

Some high memory bootloaders (for example Microchips AN1310 one) don't require any revectoring in application code. In other words they (generally) don't need the app code to know its being bootloaded. This is because low memory bootloaders, i.e. bootloaders that run at the bottom of program memory must transfer control to the app start vector as it uses the hw start vector, i.e. program memory address 0, for its own start-up. High memory loaders don't cover the restart vector, instead they require the app to be patched, generally at load time as in AN1310, to vector to the loader, which the revectors back to the app.

However, only low memory bootloaders can be protected easily by hardware, making high bootloaders more vulnerable.

RF Developer.

[Ttelmah]

However these will require calling from the application since otherwise they won't ever get executed. So instead of the bootloader jumping to the application, here the application has to jump to the bootloader.

Best Wishes

[m_embedded]

Thank you RF_Developer and Ttelmah. I have completed my bootloader code, now it is under testing. In my application code I will download the hex file from server using ftp and store in eeprom, and from bootloader code the hex file is processed and updated in the program memory. Because of you two I'm able to complete this earlier. Thank you once again (my posts : Functions under same section & ex_bootload example doubt).