Bootloader and common code space for application code

[Hans Wedemeyer]

My current project should have a bootloader, however the circuit does not use Serial or USB. Just a SD memory card.

From what I've read most people are jumping through hoops to make the bootlloader as small as possible because it eats memory space and for the greater part of the time it's code that is never used.

this idea seems OK but is an awfaull waste of code space.

I my case the greatest amount of bootloader code space would be for the SD memory card fuctions.
Because I'm running short on code space I'd like to call these memory card functions from the application space.

How can I make the application code aware of the memory card functions that the bootloader uses ?

Pointers to functions come to mind!
I'm not sure if the compiler can be made to use the bootloader code so that it can get the addresses of the SD memory card functions!

I have a few not so nice ideas for workarounds that would require hard coding the addresses of the memory card functions of the bootloader for the application code to use.
I would like to be free of having to always check addresses etc, especially during the development phase when the bootloader code will change.

May be this there is a simple solution to this ? (I hope)

Any suggestions would be appreciated.

Bootloader code:
int foo() // in the bootloader code space
{
return 1;
}


Application code:

a = foo(); // call function in bootloader code space

[Guest]

Hi Hans,
If your PIC has enough ROM space (at least the double of the final code size) then you can use something like this (I use similar method to upload new PIC code over a GPRS-based socket communication):
1. Divide the ROM space to two partitions. The lower part contains the active code and the upper part is reserved for the new code.
2. If you have the new firmware stored on the MMC (e.g. "upgrade.hex" or "firmware.bin" exists) then:
3. Copy the file from the MMC to the upper ROM space and then delete the file from the MMC. Additionally set a data EEPROM byte to 0xFF. After this restart the PIC by a RESET command.
4. At the reset, test the data EEPROM byte. If it is not NULL, copy the upper half to the lower and RESET again. If it is NULL, jump to the user code.

Steps 2-3 are executed in early main() of the user code when MMC is just inited.
To upgrade your code turn off the target card, remove the MMC, copy the new firmware, insert the card and turn on your target card.

In this case the bootloader code itself could be very short (Read_program_memory() and Write_program_memory() cycles) because all of MMC operations done at the user code.

In one of my projects when I don't have enough ROM space (>80% ROM usage) but I have an external 32K EEPROM like 24LC256 I use that EEPROM for temporary store.

Brg,
Tomi

[Ttelmah]

It is perfectly posible to have 'common' code. I do this on a bootloader, where there is a fairly complex set of I/O functions. The solution for me, was to split the bootloder, into two components. The first was entirely parts not to be 'shared'. This is relatively small, and is declared as normal for a bootloader. The second is the shared I/O functions. These are delcared using a #org statement, and sit just after the 'bootloader only' code. The _same_ declarations, are then present in the 'main', which has this set of declarations, and then the 'main' components placed just after this. The bootloader itself, is written to not start actually loading code, till the area _after_ the shared functions. The 'downside', is that the .hex file is therefore larger than it needs to be (it would be possible to strip the extra stuff), and I must use the same compiler for the running code, as the bootloader (so that the code declarations remain the same size...). It would obviously be possible to declare this stuff using separate #org statements, but the 'downside' then would be that some space would have to be left between the functions, resulting in a little wastage.

Best Wishes

[Hans Wedemeyer]

Thanks to you both for the handy tips.
It gives me a basis to get started.

Hans W

[Foppie]

Hello,

I am trying exactly the same as described above. Now I cannot recreate an easy version.

What I try to do is make common functions in one file and include this file with the bootloader. This is working properly. But when I include this file with my main application, I get the message: invalid ORG range.

When I don't include the bootloader.h file, the main application work.

I suspect that the error comes forth out of the fact that the functions are placed in the ROM in front of the main().

How should I resolve this? Must I place the functions at the end of the ROM or is there an easier solution?

I used the CCS bootloader as base. The target device is a PIC18F6722 A code example of a common function: