在使用 OpenOCD 刷新我的 ARM 微控制器之前，我是否需要使用 objcopy？答案

【问题标题】：Do I need to use objcopy before flashing my ARM microcontroller with OpenOCD?在使用 OpenOCD 刷新我的 ARM 微控制器之前，我是否需要使用 objcopy？
【发布时间】：2012-12-01 14:49:00
【问题描述】：

ARM 微控制器的“正常”ARM 交叉编译通常包括三个或四个步骤：

使用汇编器将启动代码（如果是汇编）汇编到目标文件中
使用编译器将任何源代码编译成目标文件
使用链接器将目标文件链接到 .elf 文件中
使用 objcopy 将 .elf 文件转换为 .hex 文件
刷入 .hex 文件

这是我不确定的第 4 步。在 OpenOCD 的 flash write_image 命令的文档中，它指出：

文件 [type] 可以明确指定为 bin（二进制）、ihex（Intel hex）、elf（ELF 文件）、s19（摩托罗拉 s19）。内存或构建器。

很明显OpenOCD支持elf文件，但我不知道这究竟意味着什么。这仅在某些目标上支持吗？ JTAG/SWD 适配器是否必须提供某种类似 objcopy 的功能才能正常工作？这仅仅是 OpenOCD 还不支持 elf 文件的时代的遗留物吗？

【问题讨论】：

标签： arm elf objcopy openocd

【解决方案1】：

包含地址和数据的文件格式，如 elf、ihex、srec 很好用，我主要使用 elf。 .bin 文件不携带地址，因此您 1) 必须指定起始地址 2) objcopy 填充定义区域之间的间隙，这可能会产生问题并需要更多的加载时间等。

使用 .bin 会在地址上留下人为错误的空间。不幸的是，我遇到过 .elf 和 openocd 的组合会加载错误地址或至少在加载时打印错误地址的情况。

我尽可能使用 .elf 文件。如果实用程序不支持 elf 但支持 ihex 或 srec，则为 .hex 或 .srec。和 .bin 例如在使用 x/y/zmodem 加载器时。

我会假设 openocd 是分层的，有一个读取文件的前端，当它到达后端时，jtag 或后端不知道数据来自哪种文件。我不知道事实，但假设...

【讨论】：

swd 与 jtag，我的理解是 swd 是 jtag 的串行形式，如果不是相同的命令，则相同的排序只是使用更少的引脚来回传输。
那么，鉴于 OpenOCD flash write_image 命令明确表示它支持 elf 文件，它应该可以工作吗？它不依赖于微控制器、闪存布局、编译器或......？
当然，您正在加载的二进制文件应该是您真正想要写入设备的内容，当然，不想尝试为错误的处理器加载代码。如果您能够使用该命令加载原始 .bin 文件（一些/许多受支持的设备 openocd 不知道如何写入其闪存），那么 .elf 或 .hex 或任何应该可以正常工作的文件。我自己 99% 的时间使用 load_image（以及 99.9999999% 的时间），并且只偶尔写入闪存（并且在那里也使用 elf 文件）。
现在闪存通常是一个线性的地址空间块，通过使用 .bin 您必须指定地址，但您可以从 .bin 文件的大小轻松看出正在加载多少数据，其中 .elf 文件加载了很多额外的东西并允许多个内存区域，我希望如果闪存失败或者如果 openocd 有可能知道图像的一部分正在运行，闪存 write_image 会发出警告/错误ram 不闪光。
我的经验如此有限，我的项目如此简单以至于证明不了多少......