Field-upgradeable code modules and ROM libraries...

[ElfShottheFood]

I'm working on an application that will be remotely installed and needs the ability to download firmware images over a cell modem.  The current design works well (and uses two project files: one for the bootloader, which resides in a protected region of flash, and one for the upgradeable application code).  However, code space is getting tight, and there's a fair amount of cell modem and associated network code that's in both programs, so I'd like to share as much code as possible between the two programs.

I could put the common code in a ROM library, but then I run into linker issues with compiler helper routines (_ICMP, _LCMP_RC, etc.).  I could duplicate the library source code for the few routines needed, but the compiler still controls the names of the helper routines and so I'd end up with several symbols defined twice when I tried to link the ROM library into the bootloader or app.

Another idea is to create a single project that encompasses the bootloader and the application, and use pragmas to place application code, strings, and constants in the unprotected region of flash.  That would make debugging easier too, since I'd have a single set of debug symbols.  But then I'd have to do all variable initialization "manually" since the compiler doesn't give the user much control over the .copy and .startData sections.

Any recommendations?  I'm leaning toward the single project, but I'd appreciate any input on this. 

[CompilerGuru · Accepted solution]

The single project is fragile, for example if the app good picks up an additional runtime routine not used before then that routine would be allocated in between the existing routines and therefore change the order of routines.

I see the problem with the runtime support, as far as I know the linker checks that there are no symbols defined twice. So

the app should only define the symbols which are not already defined in the rom library.

Technically this probably means that the app needs to have its own copy of the runtime support with all the symbols linked into the rom library excluded (similarly for all other files).

You could also check if you want to include all possibly used methods into the ROM library, even if the ROM lib does itself not use them. Not sure how much additional code that would be in your case.

BTW: Instead of linking the ROM library into the bootloader, the bootloader could also be the ROM Library.

Unless you want some parts of the bootloader not to be shared with the app, there is no need for a splitup.

Daniel

[kef]

Two project files, one for main application and another for bootloader is the best. Compiler could be updated many times, you even can switch to another compiler vendor - but you still will be able to bootload new FW.

• I'd end up with several symbols defined twice when I tried to link the ROM library into the bootloader or app.

That's not the big issue. You only need to check your ROM lib has linking priority over standard libs, and may need to move lib files up or down in project Link Order tab. When done, you may disable annoying linker warning.

• Another idea is to create a single project that encompasses the bootloader and the application, and use pragmas to place application code, strings, and constants in the unprotected region of flash.  

Suppose you have _LCMP linked at address X in bootloader protected area. Do you think after some modifications _LCMP will be still linked to address X? It may be so, but there are no guarantees for that.