Cortex-M Scatter Load, Exception and Boot

Make it to the Right and Larger Audience


Cortex-M Scatter Load, Exception and Boot

Lots of time it is critical for both firmware engineer and SoC hardware engineer to understand how ARM processor code and data are allocated in memory and what processor does when processor is out of reset and when processor sees an interrupt.

ARM provides two ways to specify how code/data is allocated. One is through armlink command line and the other is through scatter load file which armlink calls. The latter is normally used due to obvious reason.  Interested readers can refer to “armlink user guide” for details of both ways. But below example, extracted from this user guide, may be enough to show how scatter load file basically works.

We have two pieces of code, program1 and program2. Program1 can be treated as main() and program2 as a function called by program1. If scatter load file is written as,

here is the memory mapping achieved. Load view refers to how code/data are allocated before processor is out of reset, aka before processor starts execution. Code/data can be in non-volatile memory such as ROM or they can be in volatile memory if bootloader is used to download code/data first. Execution view refers to how code/data are allocated after processor is out of reset or after processor starts execution.

RO is read-only and normally is code. RW is read-write and ZI is zero initialized. Both refers to data variables. This example keeps code of both program1 and program2 in ROM and then “move” data of both RW and ZI into RAM. RAM is needed since data needs to be written and read.


Does above example work on Cortex-M processor? The answer is no. Issue is program1 code will start at addr 0x0. But for Cortex-M processors, addr 0x0-0x400 are pre-defined.

Cortex-M supports up to 240 user defined interrupts, INTISR[239:0]. Location 0 is SP, stack pointer. Location 1 to 15 are pre-defined system interrupts with location 1 as reset vector, 2 as NMI vector, 3 as hard fault vector, and so on. Each location is 4 bytes. In total it is (240+1+15)*4=256*4=0x400 bytes for exception vector table and this is where 0x400 come from.

So we can not allocate user program starting at 0x0 and it will mess up exception vector table.

The following is site premium content.
Use points to gain access. You can either purchase points or contribute content and use contribution points to gain access.
Highlights: 4068 words, 2 images
Author brief is empty


1 Comment

Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.



Forgot your details?