The linker is probably the least talked about tool available to embedded software developers. For many, the linker is ignored for most if not the entire development cycle. Yet, the linker allows a developer to do very powerful things such as splitting up flash memory into multiple sections. Let’s look at a quick example how the linker can be used to partition flash.
Above is an example memory partitioning for an embedded system. In this example, flash is broken up into multiple sections. First, we have a section for the bootloader that contains the interrupt vector table and the bootloaders application code. The second memory partition contains the primary application code along with its interrupt vector tables. We also include a checksum region following the application code so that on start-up we can verify that the application flash space is complete and not empty or corrupted.
A developer working on the application code will use the linker to exclude the bootloader memory region so that the application code doesn’t accidentally get placed into the bootloader region. One could use a compiler intrinsic to place code regions but that clutters the code and is not’ very elegant. Instead, excluding the memory region from the linker will make the linker believe that memory location is unavailable. Developers working on the bootloader would then also exclude the application memory region from their linker file.
Finally, we can use the linker to reserve memory regions that we want to save for calibration data or to store lookup tables such as geometric tables. Using the linker in this way we can finely tune how the flash space on the microcontroller is broken up and used. Below is an example for how we might modify the linker to include a checksum and boot_config section:
Before you even start coding, make sure that you review your linker and start to think about how you want it to be partitioned. There is nothing like getting to the end of a project with full memory usage and discover that a bootloader won’t fit!
