Bootloader启动流程
[color=rgba(0, 0, 0, 0.9)]从启动流程中我们就可以得到Flymcu发送给STM32的特定连接指令为：0x7F。
[color=rgba(0, 0, 0, 0.9)]通过版本信息中红色画线部分可以得知，当 Bootloader[color=rgba(0, 0, 0, 0.9)] 接收到相应的命令之后，就会连续发送两个 response[color=rgba(0, 0, 0, 0.9)]。我们这个时候再看下 Flymcu 中的输出信息，
通过红色画线部分可以看出，Flymcu 接收到两个来自 Bootloader 的信息。此时，接头成功！！！！！接头成功后肯定就可以进行数据交互了！！！因此，我们最初的猜想是正确的：即 STM32 通过某种外设将可执行文件烧写至 FLASH 上（也可以是 SRAM）验证猜想-3博客当中已经多次提及到，STM32 不仅可以从 FLASH 上启动，还可以从 SRAM 上启动。并且在STM32启动配置中有一个小提示：从 SRAM 中启动，需要重新设置中断向量表。中断向量表的设置是用户在用户程序中自己实现的！！！要验证这个猜想，可以从 SRAM 中启动，但是不设置中断向量表，看一下会出现什么情况。
由于正点原子的电路设计（因为我使用的就是正点原子的探索者开发板），使得无法通过串口进行 SRAM 启动，只能通过调试接口下载程序。注意：SRAM是掉电数据就会丢失的存储器介质，因此使用时（前提是已经掉电）要重新下载程序从 SRAM 中启动的最主要的目的是用来调试程序，产品中的用户程序肯定都是存储在 FLASH 上的，不然每次掉电后用户程序都没了！！！ 如何通过调试接口将用户程序下载到 SRAM 处，可以参考一下下面两篇博文：- STM32 内部 SRAM 调试程序
- 在 SRAM 中调试代码
假设你现在已经实现了能够通过调试接口将用户程序下载到 SRAM 处，那么接下来，我们来验证一下。如果没有重新设置中断向量表会出现什么结果。得出结论，总结归纳对于最开始提出的三个猜想，现在可以得出结论：- 指令存储在掉电不丢失的存储介质上
- STM32 通过某种外设将可执行文件烧写至掉电不丢失的存储介质上
- 中断向量表的首地址就是程序的入口地址
注意: 通过串口下载程序，实际上是 Flymcu（上位机）与 STM32 内置的 Bootloader 进行数据交互，但两者直接需要特定的硬件环境（CH340G（USB转串口芯片））注意: 内存图中的 reserved 有些是不使用，有些是不能用(有其他重要的作用：可读写忽略)，不可以修改其值看完这篇博客，你的脑海里必须得有一个流程的框架：- 用户面向单片机编写用户代码（C，C++，ASM）
- 用户代码通过交叉编译工具链生成单片机可以执行的可执行文件（HEX，BIN，AXF）
- 上位机：各种烧写工具（不局限于 Flymcu （因为 Bootloader 与外部设备进行数据交互不仅仅只是通过USART）））与单片机内部的 Bootloader 进行数据交互（目的是将可执行文件下载到指定的存储地址处）
将可执行文件下载到指定存储地址处，然后还会继续等待上位机的 command，可以通过复位或上位机发送跳转到用户代码入口地址的命令执行用户程序。这个流程的框架总结一句话就是：可执行程序 -> cpu执行第一条用户代码的流程至于 cpu 执行第一条用户代码之后的流程后面的博客会详细说明，但毋庸置疑的是，这是一个重要转折点，在这个点之后执行的是你自己编写的代码，你比较熟悉这个过程，但是在这个点之前，对大部分人来说都是都是比较陌生的，但是但你对这个过程了解之后，会对你的知识体系有非常大的提升。**这篇博客对你有所帮助。原文：https://blog.csdn.net/qq_46359697/article/details/114759405 文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
| 
楼主
标题置顶
标题高亮
