STM32F0xx在增加IAP后APP为什么在main函数中要重映射SRAM
1 前言在使用F0的片子在增加IAP后,我们经常发现,原来的APP必须增加一段代码,将中断向量表从内部FLASH拷贝到SRAM后再执行REMAP到SRAM,这样操作后APP才能正常运行,这一过程一直困扰着蝶粉们,为什么需要这样呢?本文将针对这一问题为大家解惑。 2 问题详细描述比如F0的下面这部分代码: #define APPLICATION_ADDRESS (uint32_t)0x08004000
/* Private macro -------------------------------------------------------------*/
/* Private variables ---------------------------------------------------------*/
#if (defined ( __CC_ARM ))
__IO uint32_t VectorTable[48] __attribute__((at(0x20000000)));
#elif (defined (__ICCARM__))
#pragma location = 0x20000000
__no_init __IO uint32_t VectorTable[48];
#elif defined ( __GNUC__ )
__IO uint32_t VectorTable[48] __attribute__((section(".RAMVectorTable")));
#endif
int main(void)
{
uint32_t i = 0;
HAL_Init();
/* Configure the system clock to 48 MHz */
SystemClock_Config();
/* Relocate by software the vector table to the internal SRAM at 0x20000000 ***/
/* Copy the vector table from the Flash (mapped at the base of the application load address 0x08004000) to the base address of the SRAM at 0x20000000. */
for(i = 0; i < 48; i++)
{
VectorTable[i] = *(__IO uint32_t*)(APPLICATION_ADDRESS + (i<<2));
}
/* Enable the SYSCFG peripheral clock*/
__HAL_RCC_SYSCFG_CLK_ENABLE();
/* Remap SRAM at 0x00000000 */
__HAL_SYSCFG_REMAPMEMORY_SRAM();
/* Add your own code here... */
//…
}
如上所示,在没有加入IAP之前这部分代码不需要的,而加入IAP后,这部分代码在F0中就必须添加了,不然APP会运行部正常! 从代码中可以看出,增加的代码执行了从内部FLASH中拷贝中断向量表到内存,然后重映射SRAM,可是,蝶粉们不禁要问,为什么要这么操作?这个又是什么原因造成的? 3 原因分析3.1 重映射在搞懂这个问题之前我们首先先来看看什么是重映射。例如F072的参考文档张SYSCFG寄存器的介绍,如下图: MEM_MODE的介绍如下: 从以上内容我们可以得到以下信息: 1. MEM_MODE的值在上电后有BOOT0,BOOT1的状态值决定。 2. MEM_MODE的值决定了哪个内存映射到地址0x0000 0000 也就是说: ? 当MEM_MODE =00/10时,Main Flash映射到地址0x0000 0000,即地址0x0800 0000映射到0x0000 0000. ? 当MEM_MODE =01时,System Flash映射到地址0x0000 0000,也就是芯片自带的Bootloader代码部分会映射到地址0x0000 0000,即0x1FFF C800映射到地址0x0000 0000. ? 当MEM_MODE =11时,Embeded SRAM映射到地址0x0000 0000,也就是内存地址0x2000 0000映射到地址0x0000 0000. 3. 经过映射后,系统访问地址0x0000 0000地址,就相当于直接访问映射的地址,如0x0800 0000. 4. 由BOOT0,BOOT1的状态决定MEM_MODE的值,进而决定哪个地址映射到地址0x0000 0000,这一过程我们称之为映射。默认映射是系统自动完成的,并由BOOT0,BOOT1的状态决定。 5. MEM_MODE位是RW的,也就是说可以修改的,如果修改其中,也就会相应的修改映射到0x0000 0000的地址,这一修改的过程,我们就叫其为重映射。重映射是通过用户代码通过修改MEM_MODE的值来完成的。 3.2 系统启动从STM32F072的参考手册的2.5章,我们可以看到如下内容: 从以上内容我们可以得到以下有用信息: 1. 在复位启动后,系统在系统时钟的第4个上升沿根据BOOT0,BOOT1的配置获取其值,也就是存储到寄存器SYSCFG_CFGR1的MEM_MODE位上,根据前面3.1的信息可知,这里进一步确定了0x0000 0000的映射地址。这一过程是系统自动完成的。 2. 在系统启动后,CPU从地址0x0000 0000获取栈顶地址,然后从0x0000 0004开始执行代码。换句话说,由于0x0000 0000被映射了其他地址,获取栈顶与执行实际上都是从映射的地址上实施的。也就是从映射的地址开始执行代码,比如从地址0x08000 0004开始执行代码(如Mian Flash映射),比如0x1FFF C804(如System Flash映射,即BootLoader启动). 于是,我们简单整理下系统的整个启动流程: -> 系统复位 -> CPU在系统时钟的第4个上升沿根据BOOT0,BOOT1的配置确定寄存器SYSCFG_CFGR1的MEM_MODE的值 -> MEM_MODE进一步决定哪个地址(Main Flash,System Flash,SRAM)映射到地址0x0000 0000. -> CPU从地址0x0000 0000获取栈顶,从0x0000 0004开始执行代码,也就是从映射地址获取栈顶,从映射地址+4的地方开始执行代码。 ->映射地址+4对于着复位中断例程(如0x08000 0004),也就是系统一开始就执行Reset_Handler,进而运行SystemInit然后进入到main函数,就这样,整个代码启动完成。 接下来就是中断产生于中断响应了。 3.3 中断与中断向量表从ARM官网上的信息得知(http://infocenter.arm.com/help/index.jsp ),在Coretext-M3与Coretext-M4核中,在System Control Block中存在一个向量表偏移量寄存器 VTOR(0xE000ED08),系统产生中断后,内核通过这个寄存器的值来找到中断向量表的地址,进而执行中断例程代码,当然,此寄存器的值是可以修改的,它的默认值为0。实际上在大部分的M3和M4的工程中,一般都是在SystemInit函数中对此寄存器的值进行设置,当此之前,它的值为默认值0,由于映射关系,实际上就是指向映射地址,比如0x0800 0000. 如下图所示: 但是,由于STM32F0XX采用的是M0核,它是没有这个VTOR寄存器的,那么它又是怎么找到中断向量表的地址的呢?同样在ARM官网上我们找到如下信息: 也就是说,对于M0来说,中断向量表的地址固定在地址0x0000 0000上! 对此,我们也可以这么理解,将M0理解成M3/M4的特殊情况,M0假设也存在VTOR这么一个虚拟寄存器,只不过它的值不能修改,固定为0罢了,而M3/M4的这个VTOR寄存器一开始时它的值也是为默认值0,只不过在程序运行到SystemInit()函数后,在代码中明确对其进行了修改。 我们整理下STM32F0XX中断的调用过程: 此时,可以回到我们一开始的问题上来了. 3.4 回到问题分析3.4.1 从IAP跳转到APP的过程分析从IAP跳转到APP时到底发生了什么呢?首先我们来看看这个跳转代码: /* Test if user code is programmed starting from address "APPLICATION_ADDRESS" */
if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FFE0000 ) == 0x20000000)
{
/* Jump to user application */
JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);
JumpToApplication = (pFunction) JumpAddress;
/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);
JumpToApplication();
}
如上,首先测试APP地址是否存在用户代码,如果存在,则首先将APPLICATION_ADDRESS + 4,作为跳转地址,然后从APPLICATION_ADDRESS取栈顶并赋值给SP寄存器,最后跳转。 于是我们可以得出结论: 3.4.2 问题分析这里的关键是,如何将中断向量表的寻找位置从0x0800 0000修改到0x0800 3000(假设为APP的地址)? 从之前的分析我们可以得出有两种方法: 通过将SRAM重映射到地址0x0000 0000,那么,M0系统产生中断后,CPU还是从地址0x0000 0000寻找中断入口,但是,实际上不再是寻址0x0800 0000,而是寻址0x2000 0000,这么一来,接下来我们就只需要将中断向量表整个拷贝到SRAM上,也就是0x2000 0000上,就这样,CPU就可以正常寻址中断向量表了。 4 结论在使用STM32F0XX时,若增加IAP,则必须在APP中将中断向量表拷贝到SRAM,并将系统重映射到SRAM,这样才能使中断恢复正常工作。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |