【IoT】STM32 分散加载文件 .sct 解析
1、STM32 启动文件与 .sct 文件分析
1) 定义STACK段，{NOINIT，读写}：分配一段内存大小为0.5K;
2) 定义HEAP段， {NOINIT，读写}：分配一段内存大小为1K;
3) 定义RESET段，{DATA，只读}：DCD各种中断向量;
4) 定义|.text|段，{CODE，只读}：Reset_Handler函数，函数中最后加载了__main；
对剩余的中断函数进行了弱定义；
在最后还有一段用户初始化堆栈的代码__user_initial_stackheap。
那这些代码都存放在什么位置呢？
5) 分析 .sct 文件：
分散加载文件（即scatter file，后缀为.scf）。
分散加载文件是一个文本文件，通过编写一个分散加载文件来指定ARM连接器在生成映像文件时如何分配RO,RW,ZI等数据的存放地址。
如果不用SCATTER文件指定，那么ARM连接器会按照默认的方式来生成映像文件，一般情况下我们是不需要使用分散加载文件的。
但在某些场合，我们希望把某些数据放在指定的地址处，那么这时候SCATTER文件就发挥了非常大的作用。
而且SCATTER文件用起来非常简单好用。
举个例子：
比如像LPC2378芯片具有多个不连续的SRAM，通用的RAM是32KB，可是32KB不够用，我想把某个.C中的RW数据放在USB的SRAM中，那么就可以通过SCATTER文件来完成这个功能。
LR_IROM1 0x08000000 0x00080000 { ; load region size_region
ER_IROM1 0x08000000 0x00080000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00010000 { ; RW data
.ANY (+RW +ZI)
}
}STACK段和HEAP段是RW属性，存在RAM（0x20000000-0x20010000）中，具体的地址由编译器在后面链接时决定，并不是一定存在RAM的开头地址。
RESET段存在FLASH（0x08000000-0x08080000）中，而且是FLASH的最开头，再结合CORTEX-M3的特性，其上电后根据启动引脚来决定PC位置，比如启动设置为FLASH启动，则启动后PC跳到0x08000000。
此时CPU会先取2个地址（硬件决定），第一个是栈顶地址，第二个是复位异常地址，这样就跳到Reset_Handler，Reset_Handler执行到将最后跳转到ç库的__main。
|.text |段是CODE属性，也存在FLASH区。
启动代码所做的工作如下：
先是建立了堆栈，之后上电后寻找到中断向量表中的复位函数Reset_Handler执行，之后跳转到__main执行Ç库函数，最后由__main调用main()函数，进入C的世界。
2、__user_initial_stackheap
这段代码位于裸机启动文件的末尾：
IF :DEF:__MICROLIB
EXPORT __initial_sp
EXPORT __heap_base
EXPORT __heap_limit
ELSE
IMPORT __use_two_region_memory
EXPORT __user_initial_stackheap
__user_initial_stackheap
LDR R0, = Heap_Mem
LDR R1, =(Stack_Mem + Stack_Size)
LDR R2, = (Heap_Mem + Heap_Size)
LDR R3, = Stack_Mem
BX LR若是使用了microlib，则只需要将__initial_sp，__ heap_base的，__ heap_limit三个变量定义成全局变量即可（这三个变量也是固定的可被Ç库引用，在库中需要使用到这三个变量对堆栈进行初始化）；
否则，就需要自己定义__user_initial_stackheap。
microlib缺省的情况下使用的是Keil C库。
但是事实上，μVision库里包含了更多__user_initial_stackheap()的函数体，这样编译器可以根据开发人员scatter文件的内容自动选择合适的函数体。
换句话说，针对RVCT v3.x及之后的版本，使用scatter文件的开发人员可以不再重新实现__user_initial_stackheap()的函数体。
也就是说不必再自己写了__user_initial_stackheap，自己在做实验验证时，没有使用microlib库，同时也将这部分函数注释掉，并没有产生任何异常。
所以对__user_initial_stackheap在这里就不再做更多深入的研究了，这一部分太烧脑了，就当作C库已经为我们准备好了这个函数。
3、堆栈的单区模型和双区模型
堆栈分为单区模型和双区模型：
单区模型堆和栈在同一存储器区中互相朝向对方增长
双区模型将堆和栈分别放置在存储器不同的区中，__ user_initial_stackheap()建立的专用堆限制来检查堆，需要设置堆栈的长度。
1）选择使用单区模型，在SCT文件中定义一个特殊的执行域，使用符号：
ARM_LIB_STACKHEAP，并使用EMPTY属性这样库管理器就选择了一个把这个域当作堆和栈合并在一起的__user_initial_stackheap()函数。
在这个函数中使用了“Image$ $ ARM_LIB_STACKHEAP$ $Base”和“Image$ $ARM_LIB_STACKHEAP$ $ZI$ $Limit”符号。
2）选择使用双区模型，在sct文件中定义两个特殊的执行域，使用符号：
ARM_LIB_STACK和ARM_LIB_HEAP，都要使用EMPTY属性。这样库管理器就会选择使用符号：“Image$ $ARM_LIB_HEAP$ $Base” ，“Image$ $ARM_LIB_STACK$ $ZI$ $ limit”，“Image$ $ARM_LIB_STACK$ $Base”，“Image$ $ARM_LIB_STACK$ $ZI$ $Limit”的__user_initial_stackheap()函数。
从裸机的启动文件可以看出，裸机使用的是双区模型。
4、Huawei_LiteOS 启动文件与 sct 文件
启动文件：
LOS_Heap_Min_Size EQU 0x400
AREA LOS_HEAP, NOINIT, READWRITE, ALIGN=3
__los_heap_base
LOS_Heap_Mem SPACE LOS_Heap_Min_Size
AREA LOS_HEAP_INFO, DATA, READONLY, ALIGN=2
IMPORT |Image$$ARM_LIB_STACKHEAP$$ZI$$Base|
EXPORT __LOS_HEAP_ADDR_START__
EXPORT __LOS_HEAP_ADDR_END__
__LOS_HEAP_ADDR_START__
DCD __los_heap_base
__LOS_HEAP_ADDR_END__
DCD |Image$$ARM_LIB_STACKHEAP$$ZI$$Base| - 1
PRESERVE8
AREA RESET, CODE, READONLY
THUMB
IMPORT ||Image$$ARM_LIB_STACKHEAP$$ZI$$Limit||
IMPORT osPendSV
EXPORT _BootVectors
EXPORT Reset_Handler
_BootVectors
DCD ||Image$$ARM_LIB_STACKHEAP$$ZI$$Limit||
DCD Reset_Handler
Reset_Handler
IMPORT SystemInit
IMPORT __main
LDR R0, =SystemInit
BLX R0
LDR R0, =__main
BX R0
ALIGN
END定义LOS_HEAP段，{NOINIT，读写}：分配一段内存大小为1K；
定义LOS_HEAP_INFO段，{DATA，只读}：定义__LOS_HEAP_ADDR_START__和__LOS_HEAP_ADDR_END__这两个全局变量供OS使用；
定义RESET段，{CODE，只读}：启动向量，第一个是栈顶地址，第二个是Reset_Handler；将Reset_Handler主体也写入了RESET段；
首先，可以看出，分配堆栈的方式与裸机不同，使用的是单区模型，从下向上排列
__LOS_HEAP_ADDR_START __ = __ los_heap_base，为堆低地址;
__LOS_HEAP_ADDR_END __ = |Image$ $ARM_LIB_STACKHEAP$ $ZI$ $Base | - 1，为堆顶（不确定的地址）;
|Image$ $ARM_LIB_STACKHEAP$ $ZI$ $Base|，为栈底（不确定的地址）;
|Image$ $ARM_LIB_STACKHEAP$ $ZI$ $Limit|，为栈顶地址;
所以，由上文可知，在sct文件中必然会出现ARM_LIB_STACKHEAP这个执行域：
LR_IROM1 0x08000000 0x00020000 { ; load region size_region
ER_IROM1 0x08000000 0x00020000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
* (LOS_HEAP_INFO)
}
VECTOR 0x20000000 0x400 { ; Vector
* (.data.vector)
}
RW_IRAM1 0x20000400 0x00004800 { ; RW data
;.ANY (+RW +ZI)
* (.data, .bss)
* (LOS_HEAP)
}
ARM_LIB_STACKHEAP 0x20004C00 EMPTY 0x400 { ;LiteOS MSP
}
}那么其他的异常中断向量入口在哪里呢？定义在los_hwi.c文件中被定义成了数组的形式：
#ifdef __ICCARM__
#pragma location = ".data.vector"
#elif defined (__CC_ARM) || defined (__GNUC__)
LITE_OS_SEC_VEC
#endif
HWI_PROC_FUNC m_pstHwiForm[OS_VECTOR_CNT] =
{
(HWI_PROC_FUNC)0, // [0] Top of Stack
(HWI_PROC_FUNC)Reset_Handler, // [1] reset
(HWI_PROC_FUNC)osHwiDefaultHandler, // [2] NMI Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [3] Hard Fault Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [4] MPU Fault Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [5] Bus Fault Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [6] Usage Fault Handler
(HWI_PROC_FUNC)0, // [7] Reserved
(HWI_PROC_FUNC)0, // [8] Reserved
(HWI_PROC_FUNC)0, // [9] Reserved
(HWI_PROC_FUNC)0, // [10] Reserved
(HWI_PROC_FUNC)osHwiDefaultHandler, // [11] SVCall Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [12] Debug Monitor Handler
(HWI_PROC_FUNC)0, // [13] Reserved
(HWI_PROC_FUNC)osPendSV, // [14] PendSV Handler
(HWI_PROC_FUNC)osHwiDefaultHandler, // [15] SysTick Handler
};这一部分代码被分散加载文件加载到了VECTOR段，位于RAM的开头部分。
在内核初始化时会进行中断向量表重映射的工作。
refer：
https://blog.csdn.net/sinat_27066063/article/details/84565308