Under normal circumstances I would not try to share functions between the boot loader and the application program. Keeping them separate simplifies the application to a great degree and makes the app code code testable and verifiable independant of the boot loader. Sharing code actually increases the chance that the boot loader would need to change during a product life cycle.

The main legacy reason for shared code was twofold. One was the really small size of code memory available on older MCUs. That is a thing of the past as cheap MCUs are easily available with full capacity code memory. The other reason is that Monitors used to be used as the debugger of the application. Shared code for the debug interface was essential, particularly the UART support, and so led to the idea of sharing a lot of other things too. It was not uncommon for monitors on old type development systems to consume as much as half the code space on small memory foot print MCUs. These days trying to do application debug via a monitor is a silly thing to do in view of the fact that many MCUs of choice support wonderful in system hardware assisted debugging via JTAG.

Keep your loader simple to its function, independent of the application from a code sharing standpoint and you will then have a robust solution where the initial loader is highly likely to stay the same throughout the life of the product.

If you really really have to have a shared code / shared data scheme then what I would do is equip the loader with a function entry point branch table at its beginning. Function sharing is a whole lot easier if the functions are written in assembler and not in C using C constructs. In the "application" if written in C for example manage the function entry points through function pointer type code instead of trying to "link" calls in the boot loader for direct calls from the C object code.

Michael Karas