|
发布时间: 2025-2-24 13:46
正文摘要:这几天遇到了一个问题： 同样的一份hex文件，在keil（j-link）里烧录，程序能正常运行，但是通过J-flash反读出来的hex文件，会比原来的hex文件多出一段数据 比如：原来的hex在0x08049444的地址已经结束 ... |
| 读flash的软件又不知道哪里结束当然把全部内容读出来了。 |
|
以下内容由 DeepSeek R1 生成根据你提供的批处理脚本和现象分析，问题的核心在于 srec_cat工具对HEX文件的裁剪逻辑不完整，导致未勾选批处理时HEX文件中残留了编译器生成的填充数据，而勾选批处理时意外截断了这些数据。以下是详细分析和解决方案： 问题根源
解决方案 修改批处理脚本，确保在计算CRC后，保留原HEX文件中CRC_ADDR之后的所有填充数据。以下是修正后的脚本关键步骤： 1. 修改srec_cat命令将第二个srec_cat命令改为合并三部分数据：
CRC_BIN\srec_cat.exe ^ 1.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% ^ BRMU\BRMU_checked.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% ^ 1.hex -intel -crop %CRC_ADDR_END% 0x08080000 ^ -o 1.hex -intel -output_Block_Size 0x102. 添加Flash范围参数 明确指定Flash的完整地址范围（如0x08000000到0x08080000），确保填充未使用的区域为0xFF： REM 生成临时CRC文件时填充未使用区域CRC_BIN\srec_cat.exe ^ 1.hex -intel ^ -crop %CRCA_START_ADDR% %CRC_ADDR% ^ -fill 0xFF %CRCA_START_ADDR% 0x08080000 ^ -stm32-l-e %CRC_ADDR% ^ -o BRMU\BRMU_checked.hex -intel 完整修正脚本 @echo off ECHO Computing CRC ECHO ------------------------------------- SET MAP_FILE=1.map SET TMP_FILE=crc_temp.txt REM 提取CRC地址 FINDSTR /R /C:"^ *CHECKSUM" %MAP_FILE% > %TMP_FILE% SET /p crc_search=<%TMP_FILE% DEL %TMP_FILE% FOR /F "tokens=1 delims=(" %%a IN ("%crc_search%") DO SET crc_search=%%a SET crc_search=%crc_search:CHECKSUM=% FOR /F "tokens=1 delims= " %%a IN ("%crc_search%") DO SET CRC_ADDR=%%a SET /a CRC_ADDR_END=%CRC_ADDR% + 4 SET CRCA_START_ADDR=0x08020000 REM 生成包含CRC的临时文件，并填充未使用区域为0xFF CRC_BIN\srec_cat.exe ^ 1.hex -intel ^ -crop %CRCA_START_ADDR% %CRC_ADDR% ^ -fill 0xFF %CRCA_START_ADDR% 0x08080000 ^ -stm32-l-e %CRC_ADDR% ^ -o BRMU\BRMU_checked.hex -intel REM 合并原HEX的CRC前部分、新CRC部分、原HEX的CRC后部分 CRC_BIN\srec_cat.exe ^ 1.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% ^ BRMU\BRMU_checked.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% ^ 1.hex -intel -crop %CRC_ADDR_END% 0x08080000 ^ -o 1.hex -intel -output_Block_Size 0x10 REM 清理临时文件 DEL BRMU\BRMU_checked.hex ECHO ------------------------------------- 关键改进点
验证方法
通过上述修正，批处理脚本将正确保留编译器生成的填充数据，同时确保CRC校验码的完整性，解决J-Flash反读多余数据导致程序无法运行的问题。 |
| 有未知格式，建议该换方案 |
|
1、keil生成的HEX文件可能仅包含有效代码段，而J-Flash反读时会以Flash扇区为单位读取，导致未使用的扇区尾部数据被包含进来，例如，STM32F407的Flash扇区大小为16KB或128KB，若原HEX文件结束地址在扇区中间，反读时会读取整个扇区，包含未写入的随机残留数据； 2、keil烧录时可能采用仅擦除代码占用的扇区，且不处理后续未使用的区域。J-Flash默认可能擦除整个扇区，导致未初始化的Flash区域被填充为随机值 3、在Boot+App架构中，App的中断向量表需要重映射到其起始地址，若反读的HEX文件在App区域后包含额外数据，可能导致中断向量表被覆盖或偏移错误，使得App无法响应中断 验证与解决 1、使用J-Link配合J-Flash的Memory Read功能，直接读取Flash中App区域的原始数据，与Keil生成的HEX文件逐字节对比，定位异常数据点 2、Keil调试模式下，单步执行App的启动代码（如Reset_Handler），确认栈指针（SP）和中断向量表地址（VTOR）是否正确加载。若SP指向无效地址，程序会立即崩溃 3、使用二进制工具（如HexView）对比Keil生成的HEX和J-Flash反读的HEX，确认多余数据的地址范围。手动裁剪反读的HEX文件，仅保留原HEX的有效地址段 |
组图打开中，请稍候......
收藏
顶
踩
