First let's take a look how each of the memory regions are defined. The address ranges for each of the regions seen in the diagram below must be defined in either the application linker file or the boot loader linker files.
Below is an excerpt from one of the HID boot loader linker files. This is from the linker script for the boot loader itself so this will be covering sections (1), (2), (3), and (4).
/* ** Memory Regions */ MEMORY { data (a!xr) : ORIGIN = 0x800, LENGTH = 0x4000 reset : ORIGIN = 0x0, LENGTH = 0x4 ivt : ORIGIN = 0x4, LENGTH = 0xFC aivt : ORIGIN = 0x104, LENGTH = 0xFC program (xr) : ORIGIN = 0x400, LENGTH = 0x1000 config4 : ORIGIN = 0x2ABF8, LENGTH = 0x2 config3 : ORIGIN = 0x2ABFA, LENGTH = 0x2 config2 : ORIGIN = 0x2ABFC, LENGTH = 0x2 config1 : ORIGIN = 0x2ABFE, LENGTH = 0x2 }
The region named "reset" is defined to start at address 0x0 and has a length of 0x4. This means that the first two instructions of the device are used for the reset vector. This is just enough for one 'goto' instruction. This corresponds to hardware implementation and should not be changed. This defines section (1).
Section (2) is the IVT table. This is defined with the "ivt" memory entry. It starts at address 0x4 and is 0xFC bytes long. This corresponds to hardware implementation and should not be changed.
Section (3) is the AIVT table. This is defined with the "aivt" memory entry. It starts at address 0x104 and is 0xFC bytes long. This corresponds to hardware implementation and should not be changed.
Section (4) is the section for the boot loader code. This section is covered by the "program" entry in the memory table. This section starts at address 0x400 and is 0x1000 bytes long in this example (ends at 0x1400). As you can see with this section it has been decreased from the total size of the device to limit the boot loader code to this specific area. This is how the linker knows where the boot loader code is allowed to reside.
Looking in the corresponding application linker file will result in a similar table.
/* ** Memory Regions */ MEMORY { data (a!xr) : ORIGIN = 0x800, LENGTH = 0x4000 reset : ORIGIN = 0x0, LENGTH = 0x4 ivt : ORIGIN = 0x4, LENGTH = 0xFC aivt : ORIGIN = 0x104, LENGTH = 0xFC app_ivt : ORIGIN = 0x1400, LENGTH = 0x10C program (xr) : ORIGIN = 0x1510, LENGTH = 0x296E8 config4 : ORIGIN = 0x2ABF8, LENGTH = 0x2 config3 : ORIGIN = 0x2ABFA, LENGTH = 0x2 config2 : ORIGIN = 0x2ABFC, LENGTH = 0x2 config1 : ORIGIN = 0x2ABFE, LENGTH = 0x2 }
Note that the "reset", "ivt", and "aivt" sections are all still present in the application linker script. These sections remain here so that applications compiled with the boot loader can be programmed with or without the boot loader. This aids in the development of the application without having to use the boot loader while maintaining identical interrupt latency and memory positioning.
Sections (5) and (6) are created in the special "app_ivt" section. The following discussion topic describes how the content of this section is created. This entry in the memory table is how the space for that area is allocated. Note that the "app_ivt" section starts at address 0x1400 (the same address that the boot loader ended at). Since different parts have different number of interrupts, the size of the "app_ivt" section may change.
The "program" memory section has changed for the application space. It starts at address 0x1510 in this example. This will vary from part to part based on the size of the "app_ivt" section. The "program" memory section corresponds to the user application code (section (7)). Note that it takes up the rest of the memory of the device that is available to load.
MLA - USB Library Help Version : 2.16
![]() |