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

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

下面介绍下仿真调试的过程：

断点可以进入到main函数的前置函数int $Sub$$main(void)。这是RTThread的正常启动流程。
说明boot2工程已经跑起来了。这也说明boot1程序的跳转使命已经完成了。

继续打断点

又发现可以进入到开启调度器的这块代码，但是在执行开启调度器的这个函数内，代码就跑飞了（点仿真运行、过一会点停止，不知道执行到哪去了，函数没有正常结束）。
于是进行概念联想，RTOS的调度-》定时器-》中断， 中断要正常使用，要先重定位异常向量表。
于是在基于qboot的RTThread这个boot2工程内，添加上重定位异常向量表的代码，

再次烧录。
现在
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有疑点了。

boot2内没有进行异常向量表的重定位，为什么又可以跑起来呢？boot2是带qboot软件包的基于RTThread的工程，RTOS运行是需要调度器支持的，调度器需要定时器，必须要重定位异常向量表以后才能让定时器中断开始正常工作吧。可实测，boot2工程可以正常跑。

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

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

.

粗略概括：不同大小的升级包文件，有低概率会升级失败
详细描述：大部分的升级包文件，在不同的服务器上每次都可以成功升级，无论是RTThread软件包内的MyWebServe、JAVA同事搭建的各种http服务器， 还是阿里云。
而我手头恰好有一个306638字节大小的升级包文件，使用RTThread软件包内的MyWebServer作为局域网服务器，也每次都可以被成功升级。但是使用JAVA同事那边搭建的某个服务器，以及公司某个阿里云服务器，每次都不能正常升级。

1.验证写入到stm32 flash内的字节包，确实缺失了462字节。
如何验证缺失了462字节，我们查看一下stm32片内falsh上的数据，来证明缺失了这462个。
上分区表截图：

我的bootloader占据了0x08000000-0x08020000之间的部分(不含0x08020000这个地址)。
我的download分区的起始地址： 0x08000000(十六进制)+512*1024(十进制) = 0x080a0000.
我的该升级失败的升级包文件大小是306638字节。
从我们刚才的分析来判断，除去后面的462字节，前面的(306638-462)=306176字节应该是被正确写入了stm32片内flash内的download分区了。
0x080a0000 + 306176 -1 (注意，这里需要减去1) = 0x080E ABFF. 即到这个地址为止(包含0x080E ABFF这个地址)，都正确存储了升级包的数据。
从0x080E ABFF+1=0x080EAC00,这个地址开始，就应该没被写入正确的rbl数据了。

查看rbl升级包的二进制，
十进制的306176，对应的十六进制是0x4AC00, 即从rbl升级包的这个偏移地址开始(包含这个地址)，数据就没有被写入到stm32的download分区了。

2.http下载数据包，这最后一帧数据有没有被正确下载呢？ 我们在webclient软件包内添加打印来证实一下。
关键的函数是int webclient_shard_position_function(struct webclient_session session, const char URI, int start, int length, int mem_size)

有必要先大致介绍下http get流程，和代码。
http get流程：



代码修改：

.

前后两次代码的区别，只是多定义了一个4K的数组而已。前后两次代码跑到相同的位置。 但是最大的历史申请内存高水位线，maximum allocated memory值，却不一样，而且相差有点大，差不多近3K了。

请问，修改启动文件这段代码应该加在哪里？可以截图展示下？

解决方案：
把数据的收发都做到一个线程内，

参考资料：
socket为send和recv设置超时时间
https://www.cnblogs.com/lidabo/p/3804245.html

.

新理解。

假设个场景：如果某个线程内系统延时100ms间隔时间执行一次某个动作，rtthread没有满足，假设偶偶会变成120ms才过来执行，因为中途有更高优先级的任务消耗了大块的时间，那么rtthread后续将如何处理？ 这块需要查看下rtos的实现源码。
我初步认为应该是没后续处理了，时间过了就过了呗，还能咋处理？
而且从我们的用户软件设计上，如果希望保证某个线程100ms执行一次，可以这样做：1.不应该让高优先级的任务占用大块的时间，可以把要做的事情分成一小段一小段来做，不要一次性全做完，这样就可以把CPU腾出去，从而兼顾其他的低优先级线程。 2. 将我们希望的精准100ms间隔执行一次的这个线程的优先级设高。 3.关于如何提高主芯片的办事效率，=》可以借助DMA. 网络、串口、SPI等大量数据收发的场景，都可以使用DMA.

使用strlen=>

不支持，源码里有依据：

我看别人博客都没遇到我这种情况 https://blog.csdn.net/sundm75/article/details/106454833/

就是宏 RT_SERIAL_RB_BUFSZ 。

对应STM32-HAL库-设备驱动框架内的源码如下图：

先赞一个 udp 发送 广播

赞一个 udp 广播 接收

下一步有多个选项： 1.精读生成的keil工程代码
2.可在此基础上去使用文件系统，参考文章：**https://www.rt-thread.org/document/site/application-note/components/dfs/an0012-dfs/**