【RT Thread studio】stm32 使用bootloader跳转后无法启动

最近由于工作需要，在调试STM32的bootloader，中间遇到了很多问题。 之前没有接触过BootLoader,跟着原子哥的IAP来学习的Bootlader原理。写了裸机程序来进行调试，过程还算比较顺利。最后在更新APP（基于RT-Thread的程序）时出现了问题，一直调试了好几天。 裸机bootloader跳转裸机的APP程序没有问题，跳转自身也没有问题。通过JLINK直接读取整个芯片，把APP程序的第二个字（reset_handler的地址）直接写入到0x08000004（默认的reset_hand

STM32 Bootloader跳转到APP程序中无法启动实时系统 一、问题描述： STM32G431 bootloader跳转到APP中执行，能够进入APP的main函数，但main函数里创建实时系统（CMSIS-RTOS2）失败。 二、问题解决过程： 首先明确：APP程序稍作修改（去掉中断向量偏移，flash起始地址改为0x08000000），不用bootloader，直接烧录到单片机里是肯定可以执行的，实时系统也是可以运行的。 以下是bootloader跳转处的程序（bootloader也用的是CMS

STM32 Bootloader跳转后不执行程序的问题解决记录

当前MCU的APP应用程序已经调试OK，为了实现在线升级，需要保留一个存储段添加BootLoader程序实现在线升级和应用程序的跳转； STM32默认代码段起始位置为0x8000000，现在自定义应用程序起始地址为0x8008000，因此BootLoader程序在keil编译的时候起始地址保持默认不变，APP程序编译时需要修改起始地址为0x8008000，将两个bin文件合并后烧录到芯片运行发现BootLoader这边能正常跳转到APP，不过APP应用程序不能正常运行，被看门狗看住反复重启； 通过查阅资料发

本文基本实现STM32F1的Bootloader功能，并通过Ymodem进行程序升级，但这只是从PC端到设备升级，过程中也还存一些小问题，并不算真正意义上的OTA远程升级。当然通过串口通讯也可方便的扩展到其它无线通讯模块实现OTA功能。此外，RT-Thread官方给出的这个Bootloader升级方案确实极大的简化了OTA开发过程，提高了开发效率。

本小节讲述如何使用 RT-Thread OTA 固件打包器对 app 固件进行打包，制作可以被下载到 download 分区的升级固件。进入 Bootloader 生成页面后，根据页面提示填写板卡参数，点击生成固件按钮即可在线自动生成 BootLoader，同时也会将生成的固件发送到用户邮箱中。开发者根据自己使用的芯片，填写相关参数，然后点击生成按钮，即可在线生成 Bootloader。HTTP/HTTPS 固件升级是另外一种固件下载方式，制作下载器时如果开启了系统中的网络驱动，即可使用此种方式下载固件。

W25Q64 是 Winbond（华邦电子）生产的一款串行 NOR Flash 存储器，它通过 SPI 接口与主机通信。这种存储器因其高可靠性、低成本和易于使用而广泛应用于各种嵌入式系统中，包括数据存储、固件程序存储以及字库存储等场景。

本文基于STM32F429VET6单片机，实现了使用片外Flash芯片W25Q128进行RT-Thread的bootloader功能，并使用Ymodem协议进行OTA升级。

使用RT thread Stdio生成STM32L431RCT6工程后，编译下载完成后系统无法启动，无法仿真debug；

Bootloader跳转到APP，APP申明的全局变量未能按照定义初始化

百度了一下可能的原因 有人说是因为PLL不能二次配置倍频 否则会进入void Error_Handler(void)，我就意识到之前的BOOT和APP时钟配置是一致的正常跑，现在的BOOT和APP配置不一致所以跑不了。自己写了个STM32F103RCT6的boot 首先使用boot程序改了下载地址和中断向量表这些代码中的打印作为APP进行验证正常跳转运行。但是将BOOT时钟改为和APP一样或者把APP时钟改为和BOOT一样都不太合适 不通用，既然是PLL导致的问题，那我不用PLL不就可以了？

如题，无法启动的原因已经找到了，是中断向量表偏移没有在没有在合适的地方设置。 正常来说中断向量表偏移在STM32的启动文件的系统时钟初始化：“SystemInit()”函数中有做设置，如图： 所以我的中断向量表设置就这样的： 但是不管怎么样RT-Thread无法跑起来。debug发现bootload是没问题的；注释掉我的向量表偏移设置，把keil5的flash起始地址设置改回0x8000000，APP程序也是可以跑起来的。那到底是什么原因的？ ...

小白一枚，有不对的地方欢迎指教。

解决网络升级问题，其原因就是中断的问题，在bootloader程序中，我打开了systick和ETH中断，但是在APP中是没有的，如果在进入APP前不关闭这个中断（如果APP中没有用到的话），就会在APP中找不到中断入口从而导致死在B. 。之前我采用的用是在跳转前关闭总的中断，然后在APP中在开启总中断，并且要用这个关闭__set_PRIMASK(1); 不能用__disable_irq();这个...

因为芯片首次运行进行了空位检查，此时的empty 标志位(即OBL_LAUNCH)已经置位了1，当使用swd烧写完程序后，无论是软件reset还是芯片的reset管脚复位，都无法把empty标志为清0，芯片会在每次的reset后都进入bootloader状态，而不会进入main flash区。上面3个问题已经研究清楚了，那么如何更改芯片默认的启动方式呢，根据上面的分析，我们应该更改0x1fff 7800处寄存器的nboot_sel bit为0即可使用芯片的boot0管脚来决定芯片如何启动。

Bootloader里面主要是1、设置bootloader和app的空间2、接收编译好的app的bin文件，写入flash3、实现跳转App里面主要修改的地方是1、 ROM起始地址和分配的空间大小2、 重定向中断向量3、 生成bin文件这里就是整个程序执行的流程。

另外，​​栈溢出不一定会死机,比如栈只生长到堆区,或者稍微进入变量区,而且溢出整个过程不对这些区域做写入操作,不对这些区域做取指操作,就可以完美避免hardfault,但溢出还是溢出了,数据还是被修改了.最"直接"的表现是函数调用后,还没看到执行用户代码就发现某些不相干的数据被修改,不过这也足够隐蔽了. 而且,hardfault也不一定是栈溢出的直接结果,只是入栈后数据被修改,出栈时跳转错误(最容易出现),导致指令访问错误,或者数据访问错误。我曾尝试单纯的修改栈或者单纯的修改堆的大小但是程序还都是不运行。