问题标签 [hex-file]

我想为AVR制作引导加载程序代码，它可以通过无线方式更新固件。

现在我可以使用一些固定数据写入应用程序区域。我有一个要更新的新固件的十六进制文件。如何将该十六进制文件转换为原始数据，以便可以使用该原始数据更新应用程序？

我一直在为我的 C 源代码使用 TortoiseGit。对于版本 V1.0，我已将输出 project.hex 文件添加到存储库中，以便我保留/存档确切的文件。

我只想为固件版本保留 *.hex 文件，而不是中间提交。如何忽略 *.hex 文件更改并仅选择在特定情况下提交？

我想将十六进制文件转换为 bin 文件。我知道这个问题已经被问过好几次了，但我的问题是，没有工具可以给我 hex 文件的绝对起始地址。

例如，如果我使用“hex2bin”-Tool ( http://hex2bin.sourceforge.net/ ) 将 .bin 中的 .hex 转换，该工具不会返回绝对的“起始地址”/“偏移地址” hex 文件，最后我在 .bin 文件中找不到给定的绝对地址。

我希望有人可以建议我解决这个问题的解决方案。

我之前已经解析了十六进制文件以进行引导加载。这是我第一次使用 Microchip 的 XC32 工具链生成 hex 文件。我立刻注意到十六进制文件和反汇编文件之间似乎存在差异。

hex 文件的前 3 行：

从列表文件中：

请注意，地址 9d000008 看起来应该在列表文件中包含 0x06。但是，十六进制文件似乎在此位置指示 0x40。以下 3 个字节也不是预期的顺序。

:10 0000 00 03 00 00 10 00 00 00 00 40 f3 06 00 00 00 00 00 a4

当我查看文件时，其他记录与预期的一样，但与该jalx指令字有关的字节似乎是乱序的。有人可以让我直截了当吗？

谢谢！

更新： 另一个令人困惑的数据点。如果我使用调试器（不使用我的引导加载程序）将十六进制文件闪存到部件中。然后，如果我查看执行内存和反汇编列表，我会看到以下内容：

当 IDE 重新解释它编写的代码时，它现在显示一条SLL指令而不是JALX. 这是编译器生成的启动代码，所以我不能确定它应该是什么。字节顺序匹配十六进制文件而不是列表文件，因此 Microchip 工具会像我一样解释十六进制文件，但这与列表文件不匹配。

我正在尝试使用 python 3.6 的 Intelhex 包从 intelhex 文件中读取部分十六进制数据。使用以下代码打开文件并尝试转换为字典（如果有帮助）。

现在我有地址了

我想读取从 $startAddress 分隔到零值的存储数据。执行此操作的最佳方法是什么？

我需要一个编译器来在命令行中将 .c 文件转换为 .hex 文件，我需要有关其工作原理的信息，非常感谢

我一直在研究一个嵌入式软件项目，该项目使用 FATFS 模块将传感器数据写入 SD 卡。数据的数据类型为 uint32_t（4 字节），输出为二进制文件。

我正在尝试编写一个 python 脚本来读取二进制文件（并将数据解析为 int 并写入一个新文件）。我当前的代码，

这给了我一大块十六进制的价值，

打印每4个字节时，有些数字甚至丢失，

给出结果

但是当我在十六进制编辑器中读取二进制文件时，所有二进制文件似乎都是正确的？！

如果我想一次读取 4 个字节，然后写入一个新文件（int 类型），我该如何实现呢？

谢谢，

亨利

我正在尝试为 ARM Cortex M3 编写模拟器。如何读取二进制文件然后对其进行解码？我想使用二进制文件作为我的模拟器的资源。我用 Atmel Studio 创建了一个项目并编译了它。现在，我有一个 .hex 文件。我还可以使用 hex2bin 将此文件转换为二进制文件。之后，如何使用该二进制文件来获取和解码指令？我正在使用 C/C++ 开发 Visual Studio。

我有一个 STM32F427 的十六进制文件，它是使用具有连续内存地址的 GCC(gcc-arm-none-eabi) 4.6 版构建的。我编写了用于加载该 hex 文件的引导加载程序，还添加了校验和功能，以在启动应用程序之前确保 Hex 文件正确。十六进制文件的片段：

:10 05C8 0018460AF02FFE07F5A64202F1D00207F5F9 :10 05D8 008E4303F1A803104640F6C821C2F2000179 :10 05E8 001A460BF053F907F5A64303F1D003184652 :10 05F8 000BF068F907F5A64303F1E80340F6FC1091 :10 0608 00C2F2000019463BF087FF07F5A64303F145 :10 0618 00E80318464FF47A710EF092FC07F5A643EA :10 0628 0003F1E80318460EF03DFC034607F5A64221 :10 0638 0002F1E0021046194601F0F2FC07F56A5390

如您所见，所有地址都是连续的。然后我们将编译器更改为 4.8 版本，我得到了相同类型的 Hex 文件。

但是现在我们使用了 6.2 版本的编译器，生成的 Hex 文件不是连续的。有点像这样：

正如您在 0188 之后看到的那样，它从 0190 开始意味着其余 8 个字节（0189 到 018F）是 0xFF，因为它们没有被刷新。

现在引导加载程序有点愚蠢，我们只传递起始地址和字节数来计算校验和。

有没有办法像编译器 4.6 和编译器 4.8 一样以连续的方式制作 hex 文件？代码在所有三个时间都是相同的。

我目前正在 STM32 上编写一个程序，该程序使用一个简单的引导加载程序和两个子应用程序。子应用程序位于闪存中，引导加载程序将其中一个（代码和数据）加载到 RAM 内存中，然后开始执行。复制只需遍历闪存中的地址并将数据从这些地址复制到 RAM 即可完成。

最近我遇到了一些奇怪的错误。我试图从全局定义的数组中读取一些数据。我得到了错误的值，例如，当我试图阅读时，array[0]我得到了array[1].

我对 .elf 和 .hex 文件进行了一些调试和反汇编，我想我已经找到了这个错误的原因。原来.ARM这个项目的.elf文件的部分之间有一个空格。
令人惊讶的是，.hex 文件中不存在这个空白空间（我用它来刷新 STM32 板）。
这就是我所说的：

• .elf 文件：

• .hex 文件：

显然，地址是不同的，因为.elf文件中的地址是VMA，而.hex文件中的地址是LMA。
我在这里注意到的是，在.ARM节之后，下一个内存地址应该是2000ee7C但由于未知原因，.data节开始于2000ee80. 所以他们之间只有一个无法解释的空话。但是 .hex 文件中不存在这个空字。00000001紧随其后的是00000000。
所以基本上，我认为.hex文件的反汇编应该输出以下结果：

由于这个在 .hex 文件中消失的空内存空间，当我的引导加载程序将数据加载到 RAM 时，array[0]LMA2000eec8最终位于 address 2000eec4。

这是我使用的链接器脚本的令人不安的片段：

我使用以下命令将 .o 文件链接到一个 .elf 文件中：

我使用以下命令将 .elf 文件转换为 .hex 文件：

我试图尝试使用我给的参数arm-none-eabi-objcopy并arm-none-eabi-gcc摆脱这种填充，例如--file-alignment，--gap-fill但到目前为止没有成功。

有谁知道这个空白空间来自哪里以及如何摆脱它（或将其包含在 .hex 文件中）？

编辑：根据前两条评论的建议，我尝试过：
*使用最新版本的arm-none-eabi-gcc和arm-none-eabi-objcopy在我的工具链中，
*ALIGN(4)该.ARM部分，
*不将该部分复制.ARM到 RAM。
不幸的是，这些解决方案都没有解决这个问题。

我最近注意到的是，有时.elf文件中的数据是正确对齐的（.data节的第一个地址是紧跟.ARM节末尾的地址）。这取决于该.ARM部分恰好结束的地址。我可以通过在代码中添加一些额外的函数调用来操纵它（导致更大的.text区域），例如：

这样，我已经确定：
* 当.ARM部分在地址结束时0x*******0，.data部分错误地开始于0x*******8（应该是0x*******4）
* 当.ARM部分在地址结束时0x*******8，.data部分错误地开始于0x*******0（应该是0x*******C）
* 当.ARM部分在地址结束时0x*******4，.data部分正确地开始于0x*******8
* 当.ARM部分在地址结束时0x*******C，.data部分正确地开始于0x*******0