5 参考qboot源码的stm32 boot跳转动作的细节请教

发布于 2022-03-16 17:36:23 浏览：969 订阅该版

单片机升级流程：
![image.png](https://oss-club.rt-thread.org/uploads/20220316/0e6c4b5ab4112cba941d6508a6161469.png.webp)
跳转动作，是实现升级功能的必要步骤。

针对升级过程中的跳转动作，进行实验。
2022.3.13 周日 
升级跳转实验
**步骤1.** 实验了0x08000000地址的boot1(基于qboot的RT-Thread Project) -> 0x08010000地址的boot2(基于qboot的RT-Thread Project) -> 0x08020000地址的app(RT-Thread Project，负责业务逻辑，驱动了所有板载外设)，实验跳转成功，验证了两个boot+一个app，这样连续跳转的基本原理，在实践上是可行的。
另外，也验证了直接由boot1不经过boot2，直接跳转到app，可行。只需要修改boo1工程内的跳转地址，由原来的boot2地址修改为app地址即可。
步骤1实验很**成功**。

不理解处，Boot1内打印的待跳转地址(函数指针app_func的值)， 我填入待跳转地址是0x08010000. 
相关源码：
![image.png](https://oss-club.rt-thread.org/uploads/20220316/8b25b1bde9f87cf3c386542d4fe2ebde.png.webp)

实际boot时，这几句的打印结果如下
qboot.c Jump to application running ...
app_func=0x8011d11 ==
stk_addr=0x20002fc0 ==
这两个是啥地址？

经过百度，解答：
app_func值为程序开始地址(复位地址)， PS：用户代码区第二个字为程序开始地址(复位地址)			
stk_addr值为待初始化的APP的堆栈指针，PS：用户代码区的第一个字用于存放栈顶地址

查看boot2工程的map文件(boot2相对于boot1而言，)，验证上面两个地址
![image.png](https://oss-club.rt-thread.org/uploads/20220316/7760b399897c148ea621fd64838939f8.png.webp)
![image.png](https://oss-club.rt-thread.org/uploads/20220316/4ec66e953c85f7f2c7975ae9d73c5a8f.png.webp)

**步骤2.** 实验0x08000000地址的boot1(裸机工程)-> 0x08010000地址的boot2(基于qboot的RT-Thread Project)， 跳转失败。
 思路1，改变裸机工程的大小，再来试一试？不过本实验的boot1程序所占用的flash资源已经是小于64KB了，为什么还失败呢。
实测，将裸机工程修改得更小，占用flash更小(不到5KB)，还是无法跳转。

本实验内，裸机跳转RTThread工程失败，**打印的这俩地址(app_func、stk_addr)和 步骤1的是一模一样的，为什么会**跳转失败**呢**？

**步骤3. **实验0x08000000地址的boot1(裸机工程)-> 0x08020000地址的app(RT-Thread Project，负责业务逻辑，驱动了所有板载外设)， **跳转成功**。

我的裸机工程内的跳转函数，是直接使用的qboot内复制过来的 qbt_jump_to_app()函数。 为什么可以跳转到我的位于0x08020000的qboot RTT工程，却不能跳转到位于0x08010000的qboot RTT工程？

或者说stm32 boot时有什么注意事项吗？希望大伙能多提供点思路，便于排查问题。感谢。

3 个回答

大话西游2018 2022-03-17

这家伙很懒，什么也没写！

针对的问题：
实验0x08000000地址的boot1(裸机工程，除片内falsh外，只驱动了led)-> 0x08010000地址的boot2(0x08010000这个地址上也是存放了一个boot程序，基于qboot的RT-Thread Project，除片内falsh外，只驱动了led)， 跳转失败。

今天针对这个问题，来打一下断点调试。
跳转失败，跳转前这个裸机boot1工程打印出来的app_func(程序开始地址)、stk_addr(栈顶地址)都是对的啊。
如何知道是对的呢？ 查看本帖子开头介绍的查看boot2工程的map文件那段说明。
所以，我选择在boot2工程内进行仿真调试。

下面介绍下仿真调试的过程：
![image.png](https://oss-club.rt-thread.org/uploads/20220317/4c412a50a67444cca7a3af14298b4ded.png)
断点可以进入到main函数的前置函数int $Sub$$main(void)。这是RTThread的正常启动流程。
说明boot2工程已经跑起来了。这也说明boot1程序的跳转使命已经完成了。

继续打断点
![image.png](https://oss-club.rt-thread.org/uploads/20220317/9d1265e2a4f28fdc4f703afbc3f8427a.png.webp)
又发现可以进入到开启调度器的这块代码，但是在执行开启调度器的这个函数内，代码就跑飞了（点仿真运行、过一会点停止，不知道执行到哪去了，函数没有正常结束）。
**于是进行概念联想，RTOS的调度-》定时器-》中断， 中断要正常使用，要先重定位异常向量表。**
于是在基于qboot的RTThread这个boot2工程内，添加上重定位异常向量表的代码，
![image.png](https://oss-club.rt-thread.org/uploads/20220317/8581a8190d0779ba0ee8cc6a25b0d373.png.webp)
再次烧录。
现在
0x08000000地址的boot1(裸机工程，除片内falsh外，只驱动了led)** --> **0x08010000地址的boot2(0x08010000这个地址上也是存放了一个boot程序，基于qboot的RT-Thread Project，除片内falsh外，只驱动了led) **-->** 0x08020000地址的app(非boot程序，app程序，RT-Thread Project，负责业务逻辑，驱动了所有板载外设，LAN8720A PHY、W25Q32等)， 跳转成功。
问题解决。

那现在也可以解释为什么下面这种情况可以跳转成功，把APP程序跑起来了
实验0x08000000地址的boot1(裸机工程，除片内falsh外，只驱动了led)-> 0x08020000地址的app(非boot程序，app程序，RT-Thread Project，负责业务逻辑，驱动了所有板载外设，LAN8720A PHY、W25Q32等)，跳转成功。
因为我在APP程序里进行了异常向量表的重定位。

现在梳理通了以后，就对本帖子最开始出的步骤1有疑点了。
![image.png](https://oss-club.rt-thread.org/uploads/20220317/d67c86a7e3d471c8bee70474a4bd496c.png)
boot2内没有进行异常向量表的重定位，为什么又可以跑起来呢？boot2是带qboot软件包的基于RTThread的工程，RTOS运行是需要调度器支持的，调度器需要定时器，必须要重定位异常向量表以后才能让定时器中断开始正常工作吧。可实测，boot2工程可以正常跑。

为了保险起见，为了规范操作，我在该boot2工程内添加上重定位异常向量表的代码，再次实验
0x08000000地址的boot1(基于qboot的RT-Thread Project) -> 0x08010000地址的boot2(基于qboot的RT-Thread Project) -> 0x08020000地址的app(RT-Thread Project，负责业务逻辑，驱动了所有板载外设)。实验跳转成功。

**心得体会
看来，不规范操作，有时也能成功。但是就会留下坑，影响自己排查问题。
规范的操作的实验结果，才可以和其他的实验结果进行类比分析。
不规范的操作，实验起来却成功的实验结果，和其他的实验结果进行类比分析，将会一头雾水。**