我正在开发一个使用裸机环境的 cortex-m3 CPU 的项目。 由于软件升级需要，CPU 上的可执行映像可能位于闪存中的两个地址之一，这会带来问题。映像的起始地址仅在加载时才知道，而在静态链接期间不知道。 我不太确定，但我认为这并不真正符合动态加载的条件，但我在这里真的可能被误认为，因为我不是这方面的专家。 如果没有操作系统也没有动态加载器，有没有办法编译和链接图像，它的基地址只能在加载时给出？
【问题讨论】：
标签： embedded arm dynamic-loading cortex-m3 gnu-toolchain
对于像您这样的裸机嵌入式系统，这是通过将您的代码编译/链接为可重定位代码（也称为Position Independent Code）来完成的。
如何实现这一点受处理器的影响，而实际方法由您的开发工具集实现，因此您需要查阅有关您的交叉开发工具的文档。它通常是一组编译器和链接器选项（包括您的链接器命令脚本，如果有的话），它们决定了事物的布局方式以及用于访问它们的寄存器。
当您使用支持 MMU（不在 CM3 上，抱歉）的平台（处理器和操作系统）时，事情会变得容易一些 - 然后代码可以位于物理内存中的任何位置，但通过 MMU，它的逻辑地址空间可以不同。因此，在链接时，代码和数据的地址可以固定，然后在加载时，通过 MMU 设置逻辑地址空间，程序就更聪明了。
您可能会发现这个其他 SO 问题 ("Trying to load position independent code on cortex-m3") 也很有帮助。
【讨论】：
您需要某种方式让设备确定何时重置它应该从两个可能位置中的哪一个开始执行。但一般来说，裸机设备在复位时只有一个起始位置（某些控制器可以根据设备上某些引脚的逻辑电平从两个或更多入口点中进行选择）。
我们也有类似的需求，制定了如下方案：
引导加载程序检查固定的已知位置以校验两个可能的图像。
关键是引导加载程序必须简单而愚蠢。它不容易升级，所以你希望它足够愚蠢，不能有错误。
现在设备可以在运行时通过将映像刷新到非运行位置来升级（我们拥有的 Cortex-M3 设备允许这样做 - 如果 LPC1758 不允许这样做，那么您必须有一些可以运行的东西从 RAM 执行闪存更新）。重置，引导加载程序拾取新刷新的映像。
系统需要做一些前期工作才能让引导加载程序运行并坚如磐石，但一旦运行，更新是 100% 可靠的（如果新闪存未完成，则旧映像是唯一的校验和，所以它会在下一次重置时运行 - 没有砖块）。主要的缺点——也是一个很大的缺点——是你基本上失去了一半的主程序的闪存地址空间，因为闪存必须能够保存两个竞争图像。
【讨论】：