ARM M0中BOOT到APP跳转方法KEIL工程详解--原创

wangpengcheng

好久没有贡献了，以前有发过飞思卡尔KE02的工程，有网友要求能否详细说明一下，刚好最近玩了一下NV32的国产芯片，就抽空做了一个文档与例程，欢迎转载，但拒绝用来弄什么积分下载，去积分！
我喜欢阿莫，这里什么都能搜到，什么都能下载，不要积分。
文档：

例程：

Eric_Xue

沙发，赞一个。用处很大，谢谢分享。

lncwangfeilnc

谢谢分享     

wangpengcheng

楼主好人！一生平安！

touch_mcu

请加上”阿莫论坛“  ，  直接爱上阿莫有点

greenflyqqq

谢谢楼主的资料！

zuopin

下载下来学习下

kation122

LZ 的烧录器不错，感谢LZ 的分享。

ponder2077

很历害，，，

相由心生

补充解释下：说白了，选option->target就是改这个分散加载文件。这个是文本的方式，那个是IDE方式，一样一样的。

jxchen

赞一个。用处很大，谢谢分享

Gorgon_Meducer

看了一下楼主的帖子，很不错，赞，但是有一个地方是不妥当的：
设置VTOR寄存器应该是 Bootloader 的事情，而不是APP的事情，对APP来说，一个系统是否存在 Bootloader 应该是透明的（不关心的）
简单说，就是有Bootloader，APP可以正常工作；没有 Bootloader，APP也应该可以正常工作。基于这个假设，APP就应该被编译成假设
VTOR就是自己编译的位置——通常是0x00000000。一个好的Bootloader在跳转到 APP 运行之前，应该要做很多清扫环境的工作，比如
关闭 bootloader 自己打开的各类中断资源，根据 APP的 向量表正确配置MSP之类。

lindabell

Gorgon_Meducer 发表于 2017-5-30 23:50
看了一下楼主的帖子，很不错，赞，但是有一个地方是不妥当的：
设置VTOR寄存器应该是 Bootloader 的事情， ...

这能做到吗？APP不用设置中断向量表？

javenreal

Gorgon_Meducer 发表于 2017-5-30 23:50
看了一下楼主的帖子，很不错，赞，但是有一个地方是不妥当的：
设置VTOR寄存器应该是 Bootloader 的事情， ...

我们都是在app一开始设向量表地址的，如果可以不用设，那么调试又会变方便一点。

wangpengcheng

Gorgon_Meducer 发表于 2017-5-30 23:50
看了一下楼主的帖子，很不错，赞，但是有一个地方是不妥当的：
设置VTOR寄存器应该是 Bootloader 的事情， ...

先谢谢版主的回复！试过boot中处理一些中断停止什么的，但太复杂，不如直接RESET来的方便快捷无BUG。考虑了一下不在APP设置VTOR，就得去设置分散加载，开一块RAM做中断，还是麻烦，既然ARM有VTOR这个寄存器，用起来还是方便！另外，DEBUG的时候有没有BOOT都可以直接仿真！

wangpengcheng

lindabell 发表于 2017-5-31 09:05
这能做到吗？APP不用设置中断向量表？

我刚才考虑了一下，应该可以做到，BOOT与APP的中断向量可以指向同一块RAM，只是在加载的时候BOOT加载自己的中断函数，APP加载的也是自己的中断函数，只要用分散加载就可以做到，这个就相当于在编译的时候将指定的函数放到指定的地址位置！

Gorgon_Meducer

首先，这个事情，如果我说你们的做法是错的，你们会说，我们用很多年了。考虑到存在即合理，我
这么说吧，你们的做法只是实现了功能，但是并不是最合理的。最合理的就是APP和Boot loader之间
的透明化——只不过因为你们觉得Bootloader开发会复杂一点，就觉得这是不可行的，你们不觉得这点
很值得商榷么？
然而，实际上，Bootloader在这个问题上的开发并不复杂，我这里放一个参考代码：

1. 
   
2. //! 1. Disable interrupt response.
   
3. __disable_irq();                           
   
4. 
   
5. //! 2. Disable all enabled interrupts in NVIC.
   
6. memset((uint32_t *)NVIC->ICER, 0xFF, sizeof(NVIC->ICER));
   
7. 
   
8. /*! Disable all enabled peripherals which might generate interrupt    requests.
   
9.     Clear all pending interrupt flags in those peripherals.
   
10.     This part is device-dependent, and you can write it by referring to device datasheet.
    
11. */
    
12. 
    
13. /*! Clear all pending interrupt requests in NVIC.
    
14. */
    
15. memset((uint32_t *)NVIC->ICPR, 0xFF, sizeof(NVIC->ICPR));
    
16. 
    
17. //! 4. Disable SysTick and clear its exception pending bit.
    
18. SysTick->CTRL = 0;
    
19. SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk;
    
20. 
    
21. //! 5. Load the vector table address of user application code in to VTOR.
    
22. SCB->VTOR = USER_APPLICATION_VECTOR_TABLE_ADDRESS;
    
23. 
    
24. //! 6. Use the MSP as the current SP.
    
25. 
    
26. //! Set the MSP with the value from the vector table used by the application.
    
27. __set_MSP(  ((unsigned int *)(SCB->VTOR))[0] );
    
28. 
    
29. //! In thread mode, enable privileged access and use the MSP as the current SP.
    
30. __set_CONTROL( 0 );
    
31. 
    
32. //! 7. Enable interrupts.
    
33. __enable_irq();
    
34. 
    
35. //! 8. The reset handler address could be found with following expression
    
36. //! ((unsigned int *)(SCB->VTOR))[1]
    
37. 
    

复制代码

这是跳转到APP运行前推荐的要做的事情的伪代码。另外，你们的描述中，中断向量表
需要两块RAM让我觉得很诧异——首先不应该用FLASH来节省空间么？为什么要RAM？
其次，Bootloader理论上是可以不用完整的中断向量表的，你只要保留最基础的部分，
也就是头16个WORD就足够了——我比较激进，我的代码只保留了头4个。另外，很多
芯片可以通过Fuse设置默认的VTOR地址——对于这种芯片，直接把Bootloader的向量
放到Flash的尾部，把启动的VTOR设置成Bootloader的VTOR就行了。另外，即便是不
支持VTOR的M0，也有办法做到APP和Bootloader相互透明，不过时间太短，我就暂时
不在这里介绍了。

huangqi412

Gorgon_Meducer 发表于 2017-5-30 23:50
看了一下楼主的帖子，很不错，赞，但是有一个地方是不妥当的：
设置VTOR寄存器应该是 Bootloader 的事情， ...

没看楼主附件，一路浏览看到你说VTOR，  印象里以前用STM32F0是没有向量偏移量的，只能选择0地址是ROM/RAM，所以APP执行前要复制前面几十个字节到RAM的起头处。貌似当时查了下CM0似乎都没向量偏移值？    看到傻孩子大神你的帖子我错乱了，难道我记错了。

huangqi412

Gorgon_Meducer 发表于 2017-5-31 16:27
首先，这个事情，如果我说你们的做法是错的，你们会说，我们用很多年了。考虑到存在即合理，我
这么说吧， ...

一路继续往下，终于看到你说CM0没有中断向量偏移。
BOOT和APP各有一个向量表， 如果APP的按正常的写， BOOT的每个中断里做个判断，进入中断如果当前是BOOT模式，执行BOOT中断，如果当前是APP模式,加一个固定偏移量跳转到APP的中断去执行也可以。    不过大家肯定毫无疑问会喜欢赋值向量表到RAM简单粗暴，折腾改BOOT中断劳民伤财不爱干。

huangqi412

复制向量表到RAM会引起APP内存缩水了前面几十个字节，跟没有BOOT情况会不同(FLASH缩水对程序没影响 重点一下BUILD而已)，就是你说的APP不透明，要定义一个决定定位数组或者改设置地址范围让编译器知道前面几十个字节不能用。但是简单粗暴方便啊。

yiming988

huangqi412 发表于 2017-5-31 17:38
一路继续往下，终于看到你说CM0没有中断向量偏移。
BOOT和APP各有一个向量表， 如果APP的按正常的写， BO ...

这样岂不是boot和app仍然不透明……

Gorgon_Meducer

huangqi412 发表于 2017-5-31 17:38
一路继续往下，终于看到你说CM0没有中断向量偏移。
BOOT和APP各有一个向量表， 如果APP的按正常的写， BO ...

Cortex-M0+ 才有VTOR
对于Cortex-M0没有VTOR其实有两个解决方案，也许你说的方案算是第三个方案，我觉得没有人会在“每一个”中断向量里面做一个判断的……

先简单说说第一个方案（傻孩子原创）：
a. 首先，Bootloader 被放置在 Flash的尾部， 它的向量表只有最小的结构——两个WORD，一个给MSP，一个是Reset_Handler。
b. Bootloader的最小中断向量表放置在0x00000000地址，这点是不会改变的
c. Bootloader的Reset_Handler永远指向Bootloader，这点是不会改变的。所以永远从Bootloader启动。
关键的地方来了：
d. APP的中断向量表“也”保存在0x00000000，这样有没有Bootloader，APP都能运行，这就是“透明”的意义。
   显然，这样处理，APP的中断向量就和Bootloader的最小中断向量冲突了，怎么办呢？
最关键的地方来了：
e. Bootloader 更新 APP的时候，如果接收到 0x00000000开始的两个WORD，则将这部分替换成自己的最小向量表内容，然后再写入FLASH。
   而原来APP向量表的最初两个WORD则被保存到Bootloader自己的某个固定的FLASH空间里。APP向量表的其它内容则原样写入。
f. 当系统从 Bootloader启动时，如果要进入APP运行，则读取先前保存的 APP 向量表中的MSP值，初始化MSP，而用APP的Reset_Handler值
   跳转到APP去执行。这样就解决了启动的问题。

这个方案优点很明显，你甚至可以玩出更多花样；缺点也是很明显的，就是Boot loader不能用中断——这个对我用全状态机开发的bootloader
来说，根本不是问题，要毛中断？！！

第二个方案，类似当年AVR32的 trampoline 方案，这里就不多说了，有兴趣的朋友可以去看我的过去的帖子。

---

总结一下，我这个方案，对几乎一切不支持VTOR的系统都是有借鉴意义的。 还有，年轻人们，不要思路太僵化……咳咳咳

---

huangqi412

Gorgon_Meducer 发表于 2017-6-1 00:16
Cortex-M0+ 才有VTOR
对于Cortex-M0没有VTOR其实有两个解决方案，也许你说的方案算是第三个方案，我觉得 ...

额，F0是CM0 还是CM0+,印象里好像是市面上常见芯片都是CM0+
APP放前面，BOOT放后面，下载APP时候将前面几个字节替换掉这个很久很久前有过讨论，相当于只对RST中断做判断执行。CM3有向量偏移，M0没有，BOOT不好用中断了，我说的就是在这个上面修改的，所有中断 都做判断执行了。 如果真去做，也不会太麻烦，毕竟中断写法一样模板，一个芯片用下去只一个BOOT，N种APP，BOOT只要写一次.   大神说BOOT不用中断，是可以，BOOT用的资源本来就少，不过大家肯定喜欢在BOOT中继续用中断，而且更喜欢简单粗暴的实现功能，拷贝到RAM肯定是大家第一选择，不管他透不透明了，反正我是这样。

huangqi412

yiming988 发表于 2017-5-31 23:11
这样岂不是boot和app仍然不透明……

APP代码跟没有BOOT时候写法没有不同啊，只有BOOT折腾，但BOOT一个芯片只有一次啊。

yiming988

huangqi412 发表于 2017-6-1 09:17
APP代码跟没有BOOT时候写法没有不同啊，只有BOOT折腾，但BOOT一个芯片只有一次啊。 ...

我是说boot中断里做判断再跳转到app的中断 这种方法不透明，太麻烦，因为还要跳到app的中断去。cm0里在app开始把向量表写到ram里（ram是从0地址开始的话）倒是不影响中断了，但app就必须知道当前芯片是“ram从0开始的m0”还是其他。
不是不可以，是在想是否有更完美的方法。

huangqi412

yiming988 发表于 2017-6-1 15:23
我是说boot中断里做判断再跳转到app的中断 这种方法不透明，太麻烦，因为还要跳到app的中断去。cm0里在ap ...

麻烦和不透明的只是BOOT，APP没多一毛钱事。一系列芯片BOOT只有一次，而所有中断都一个模板。 SO,工作量就是一系列芯片一上午，你打算一年换多少种系列？  这是对APP放前面BOOT放后面方式的补丁。 傻孩子大神也说了可以直接BOOT不用中断，就是不要这个补丁。   

yiming988

huangqi412 发表于 2017-6-1 15:43
麻烦和不透明的只是BOOT，APP没多一毛钱事。一系列芯片BOOT只有一次，而所有中断都一个模板。 SO,工作量 ...

从boot中断里再跳到app中断里，肯定影响中断实时性能力
so  还是把boot放后面好一点。

Ray______

只是多了出入一下栈耗不了多少时间吧

armstrong

Gorgon_Meducer 发表于 2017-5-31 16:27
首先，这个事情，如果我说你们的做法是错的，你们会说，我们用很多年了。考虑到存在即合理，我
这么说吧， ...

版主，你用memset来做M0的内核寄存器清除和设置操作不是很妥当吧！你应该知道M0内核很多寄存器只能接受WORD访问，不支持BYTE和HALFWORD读写。
如果你用memset，就很依赖编译器使用的C库了！这样恐怕换个编译器自己都拿不准好不好用了吧？

Gorgon_Meducer

armstrong 发表于 2017-6-15 18:21
版主，你用memset来做M0的内核寄存器清除和设置操作不是很妥当吧！你应该知道M0内核很多寄存器只能接受WO ...

你说的有道理。但这个代码我在主流ARM编译器上都测试过，而且ARM官方有文档解释
这个问题。既然是操作ARM处理器的核，那么本身就是针对ARM环境，在这个情况下，
我确认这个代码是安全的。

这个代码属于编译器依赖的典型例子。你批评的很好，我接受。我特此声明一下，以上代码
对以下编译器合法，可靠有效：
ARM Compiler 5
ARM Compiler 6
IAR
GCC （Cortex-M，Cortex-R）
GCC linaro （Cortex-A）

不知道这个解释你是否满意？

另外，补充说明一下，不光是Cortex-M0，实际上所有Cortex-M的内核，0xExxx xxxx 地址的
寄存器，都只支持WORD操作，且必须在特权模式下（privilege access）。也就是大家熟悉
的NVIC，SysTick，MPU，SCB，都在这个范畴内。

eliterxzgxu

感谢楼主分享

ckhf

我用的IAP升级，也有bootloader

armstrong

Gorgon_Meducer 发表于 2017-6-16 00:46
你说的有道理。但这个代码我在主流ARM编译器上都测试过，而且ARM官方有文档解释
这个问题。既然是操作ARM ...

谢谢版主的答复，我对你的回复满意。
版主的答复质量很高，可见你技术功底之厚、研究态度之专是令人赞叹的！
不过Cortex-M3和Cortex-M4的NVIC寄存器有点例外，它的优先级配置寄存器IPR组（从0xE000E400地址开始）可以字节读写。

Gorgon_Meducer

armstrong 发表于 2017-6-16 10:06
谢谢版主的答复，我对你的回复满意。
版主的答复质量很高，可见你技术功底之厚、研究态度之专是令人赞叹 ...

这都被你发现了，你很细心哈。不过，这几个寄存器允许字节访问也是功能的需要
因为实际上每个字节对应一个Interrupt的优先级，所以，以字节为单位提供访问是
合理的——不提供字节访问反而显得不太方便了。这类寄存器应该还有一些吧，但
记住总的来说System Control Space（SCS）地址空间里，大部分地址都是WORD
的特权访问是没有坏处的。