我正在尝试将部分二进制文件的 md5 哈希值插入到二进制文件中,以跟踪 MCU 固件版本。
我是这样处理的: 在链接脚本中,我将 Flash 分成两部分
MEMORY
{
FLASH0 (rx) : ORIGIN = 0x8000000, LENGTH = 64K - 16
FLASH1 (r) : ORIGIN = 0x800FFF0, LENGTH = 16
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K
}
然后我指定了一个输出部分,如下所示:
.fw_version :
{
KEEP(*(.fw_version))
} >FLASH1
接下来我的firmware_version.c 文件仅包含:
#define FW_VERSION_SIZE 16
const unsigned char FW_VERSION[FW_VERSION_SIZE]
__attribute__((section(".fw_version"), used)) = {0};
然后在编译二进制文件并使用 objcopy 创建 .bin 文件后,我有一个 65536 B 大文件,我将该文件分割为 65520 字节,对第一部分进行 md5 校验和并将其插入到第二部分部分(16B)。最后我做cat parta partb > final.bin
.
当我使用 hexdump 检查这个二进制文件时,我可以看到 md5 校验和确实位于末尾。
使用objdump -h
我得到:
...
8 .fw_version 00000010 0800fff0 0800fff0 00017ff0 2**2
...
和objdump -t
给出:
...
0800fff0 g O .fw_version 00000010 FW_VERSION
...
我认为这意味着我可以使用 FW_VERSION[i]
从 MCU 固件中获取 md5 校验和的第一部分,但是当我检查 gdb 中的内存时,我发现它全部清零,就像从未更改过一样。
我在这里缺少什么?
[edit]该设备是一个通过gdb编程的stm32f030c8t6 arm cortex m0。
最佳答案
就像我在问题下评论的那样,我发现它不起作用的(一个)原因是当我在使用 gdb 编程时加载 .elf 文件时操作 .bin 文件。 如果我使用编程器或引导加载程序将 .bin 文件下载到目标,它应该可以工作。
不过,我找到了更好的(我认为)方法。
- 将项目中的所有源代码编译为 .o 文件。
- cat *.o >/tmp/tmp.something_unique。我在 Makefile 中使用了 $(shell mktemp)
- openssl dgst -md5 -binary/tmp/tmp.something_unique > 版本文件
- objcopy -I 二进制 -O elf32-littlearm -B arm version_file v_file.o
- linkscript 有一个部分
.fw_version : { KEEP(v_file.o(.data)) } >FLASH1
- 链接申请
- 在应用程序中通过执行
extern unsigned char _binary_version_file_start获取版本号的地址; uint8_t *FW_VERSION = &_binary_version_file_start; const size_t FW_VERSION_SIZE = (size_t) &_binary_version_file_size;
。请注意,&
的使用是正确的。
这将导致校验和接管从源代码编译的所有对象,然后将该校验和链接到目标中闪存的二进制文件中。
关于c - 如何将数据插入到 MCU 编译的二进制文件中,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30119354/