STM32F103这样类单片机，用bootloader升级时，boot没有把app区域全部擦除，只是擦除了本次app的Bin文件大小的区域，前一次的bin文件在app区域的末尾残留了几百个字节，请问这样会造成什么影响（理论上的）。

当前我这里看到的现象是，在串口发送某一项指定的数据时，hardfault了。如果擦除了那一段残留的代码，就不会有hardfault的问题。

如上图所示，图中左侧是由问题的flash，因为bootloader设计有bug，没有在升级APP时，把整个app区域擦除，而是按照本次升级的bin文件大小来擦除，导致了hardfault问题的出现。（回溯hardfault，发现是freertos的运行崩了，与堆栈有关，与哪一个具体变量有关没有看到）。

左图绿色框框起来的代码，就是残留的代码，就是没有被bootloader擦掉的。从图中可以看到，这段残留代码，与本次升级后的代码是连接在一起。

右图为正常的flash中的代码。

所以想请教一下，左图中的那种flash，从理论上来讲，连接在正常代码后面的异常代码，会造成那些影响，或者隐患。

备注：图中边条里，其它位置的红色是数据区的数据不同，不是代码。

另上传一张有残留代码的keil时的debug截图。图中0x8050000就是残留代码开始的地址。因为本人对汇编不熟悉，看不出来BLE是一个什么指令。

交流下，供参考：


如果残留的代码里有旧全局变量或静态变量数据可能会导致数据混乱、内存越界方面的问题。


比方那些 未初始化的全局变量或静态变量等，这些变量在新的应用程序中可能会被错误地读取或使用。


如果新的APP没有显式地初始化某些全局变量或静态变量，这些变量可能会保留旧的值。这些旧值可能与新的APP逻辑又不匹配，导致程序行为异常。
你可以尝试在新APP里将所有变量都显示地初始化一遍，不使用默认值。
当然，也不排除还有其它原因，比方堆栈越界之类的。


这里的BLE 就是一个条件判断跳转指令，其它DCD都是定义的一些常量。

xmshao 发表于 2024-12-3 11:53
交流下，供参考：</p>
<p>

感谢您的回答。

我在测试中，到hardfault这一步的时候，反查LR寄存器和PC寄存器，发现这两处都指向了FreeRTOS自己的两个函数。经过推敲，认为是跟堆栈有关，才会导致程序从FreeRTOS的这2个函数进入到hardfault中。

而后我把一个占用堆栈最大的任务屏蔽掉，再做导致死机的操作，测试后没有出现死机的问题。所以我认为你的回答是有道理的。

补充3张图，它们就是hardfault时，LR寄存器和PC寄存器，指向的FreeRTOS自己的两个函数。

进入hardfault时，xPortStartScheduler函数执行到return 0;这里了，所以系统崩了。

备注：我不明白的是为何是xPortStartScheduler函数之后出现崩了，这是FreeRTOS启动任务调度的函数。