久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

標題: 關于keil 燒錄hex文件問題 [打印本頁]

作者: sylviayy 時間: 2025-2-24 13:46
標題: 關于keil 燒錄hex文件問題
這幾天遇到了一個問題：
同樣的一份hex文件，在keil（j-link）里燒錄，程序能正常運行，但是通過J-flash反讀出來的hex文件，會比原來的hex文件多出一段數據  比如：原來的hex在0x08049444的地址已經結束，反讀出來的hex在此地址之后會多出一段數據。
         通過keil調試，memory窗口定位，在disassembly里對應地址顯示的全是匯編，都是寄存器操作，沒有對應代碼。截取部分如下：
         0x08049477 0000    MOVS       r0,r0
         0x08049479 0000    MOVS       r0,r0
         0x0804947B 0100    LSLS       r0,r0,#4
         0x0804947D 3240    ADDS       r2,r2,#0x40
         0x0804947F 4210    TST          r0,r2
         0x08049481 0301    LSLS       r1,r0,#12
         0x08049483 245D    MOVS       r4,#0x5D
         0x08049485 1AF4    SUBS       r4,r6,r3
         0x08049487 01AA    LSLS       r2,r5,#6
用j-flash燒錄或者上位機（can通訊），程序運行不起來，但是反讀出來的hex與原本的hex一致！！！
想問問大佬是什么原因？keil的編譯器問題還是其他的原因？

附加：單片機是stm32f407VGT6，程序時boot+app，這里運行不起來指的是app

0x08049479 0000    MOVS       r0,r00x0804947B 0100    LSLS       r0,r0,#40x0804947D 3240    ADDS       r2,r2,#0x400x0804947F 4210    TST          r0,r20x08049481 0301    LSLS       r1,r0,#120x08049483 245D    MOVS       r4,#0x5D0x08049485 1AF4    SUBS       r4,r6,r30x08049487 01AA    LSLS       r2,r5,#60x08049489 1401    ASRS       r1,r0,#160x0804948B 7C39    LDRB       r1,[r7,#0x10]0x0804948D 5291    STRH       r1,[r2,r2]0x0804948F 32C8    ADDS       r2,r2,#0xC80x08049491 0206    LSLS       r6,r0,#80x08049493 071B    LSLS       r3,r3,#280x08049495 0332    LSLS       r2,r6,#12

作者: zpwgf 時間: 2025-2-25 09:36
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的有效地址段

作者: polygram2025 時間: 2025-2-25 20:48
有未知格式，建議該換方案

作者: sylviayy 時間: 2025-2-26 09:55

zpwgf 發表于 2025-2-25 09:36
1、keil生成的HEX文件可能僅包含有效代碼段，而J-Flash反讀時會以Flash扇區為單位讀取，導致未使用的扇區尾 ...

謝謝大佬！
按照你的方法調試過程中，發現查找問題點有點偏離，我發現了個現象：
在我的工程里，有一個計算CRC的批處理文件，它生成完CRC之后會自動回填進hex，CRC地址是根據map文件來的，取的是ROM結束地址。
在全編譯工程中，勾選這個bat文件，編譯后hex顯示以crc校驗碼截止；不勾選，編譯后hex在crc之后就會有上述描述的多的一段數據。
（兩次編譯代碼未進行改動，計算的crc的校驗碼一致）左邊勾選編譯，右邊未勾選編譯

作者: sylviayy 時間: 2025-2-26 10:02
批處理代碼如下：

@echo off
ECHO Computing CRC
ECHO -------------------------------------
SET MAP_FILE=1.map
REM::-------------------------------------get CRC address information line
SET TMP_FILE=crc_temp.txt
FINDSTR /R /C:"^ *CHECKSUM" %MAP_FILE%>%TMP_FILE%
SET /p crc_search=<%TMP_FILE%
DEL %TMP_FILE%
REM::-------------------------------------CRC address
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::-------------------------------------CRC32 CRC校驗范圍 0x08020000 %CRC_ADDR%
CRC_BIN\srec_cat.exe 1.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% -fill 0xff %CRCA_START_ADDR% %CRC_ADDR% -stm32-l-e %CRC_ADDR% -o BRMU\BRMU_checked.hex -intel -output_Block_Size 0x10
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% -o 1.hex -intel -output_Block_Size 0x10
CRC_BIN\srec_cat.exe 1.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% -byte_swap 4 -o -hex-dump
del BRMU\BRMU_checked.hex
ECHO -------------------------------------
REM exit

復制代碼

后面臨時解決辦法，不在原本的hex文件上進行填充，而是復制一份hex再修改，這樣最后工程生成兩個hex,如第一張圖

@echo off
ECHO Computing CRC
ECHO -------------------------------------
copy 1.hex 2.hex
SET MAP_FILE=1.map
REM::-------------------------------------get CRC address information line
SET TMP_FILE=crc_temp.txt
FINDSTR /R /C:"^ *CHECKSUM" %MAP_FILE%>%TMP_FILE%
SET /p crc_search=<%TMP_FILE%
DEL %TMP_FILE%
REM::-------------------------------------CRC address
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::-------------------------------------CRC32 CRC校驗范圍 0x08020000 %CRC_ADDR%
CRC_BIN\srec_cat.exe 2.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% -fill 0xff %CRCA_START_ADDR% %CRC_ADDR% -stm32-l-e %CRC_ADDR% -o BRMU\BRMU_checked.hex -intel -output_Block_Size 0x10
CRC_BIN\srec_cat.exe 2.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% BRMU\BRMU_checked.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% -o 2.hex -intel -output_Block_Size 0x10
CRC_BIN\srec_cat.exe 2.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% -byte_swap 4 -o -hex-dump
del BRMU\BRMU_checked.hex
ECHO -------------------------------------
REM exit

復制代碼

我猜這個批處理對hex進行處理的時候，去掉了后面那一段數據，但是不知道這個批處理代碼該怎么修改？
但我還是很奇怪，map里顯示0x080406C4已經結束，后面那一段的數據從哪里來的

？

麻煩您看看,xiexie！

作者: sylviayy 時間: 2025-2-26 15:01
批處理代碼如下：

@echo off
ECHO Computing CRC
ECHO -------------------------------------
SET MAP_FILE=1.map
REM::-------------------------------------get CRC address information line
SET TMP_FILE=crc_temp.txt
FINDSTR /R /C:"^ *CHECKSUM" %MAP_FILE%>%TMP_FILE%
SET /p crc_search=<%TMP_FILE%
DEL %TMP_FILE%
REM::-------------------------------------CRC address
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::-------------------------------------CRC32 CRC校驗范圍 0x08020000 %CRC_ADDR%
CRC_BIN\srec_cat.exe 1.hex -intel -crop %CRCA_START_ADDR% %CRC_ADDR% -fill 0xff %CRCA_START_ADDR% %CRC_ADDR% -stm32-l-e %CRC_ADDR% -o BRMU\BRMU_checked.hex -intel -output_Block_Size 0x10
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% -o 1.hex -intel -output_Block_Size 0x10
CRC_BIN\srec_cat.exe 1.hex -intel -crop %CRC_ADDR% %CRC_ADDR_END% -byte_swap 4 -o -hex-dump
del BRMU\BRMU_checked.hex
ECHO -------------------------------------
REM exit

復制代碼

后面臨時解決辦法，不在原本的hex文件上進行填充，而是復制一份hex再修改，這樣最后工程生成兩個hex,如第一張圖

@echo off
ECHO Computing CRC
ECHO -------------------------------------

復制代碼

我猜這個批處理對hex進行處理的時候，去掉了后面那一段數據，但是不知道這個批處理代碼該怎么修改？
但我還是很奇怪，map里顯示0x080406C4已經結束，后面那一段的數據從哪里來的？

51hei圖片_20250226100256.png (80.07 KB, 下載次數: 0)

下載附件

2025-2-26 15:00 上傳

麻煩您看看,xiexie！

作者: cedtek 時間: 2025-2-27 02:54

以下內容由 DeepSeek R1 生成根據你提供的批處理腳本和現象分析，問題的核心在于 srec_cat工具對HEX文件的裁剪邏輯不完整，導致未勾選批處理時HEX文件中殘留了編譯器生成的填充數據，而勾選批處理時意外截斷了這些數據。以下是詳細分析和解決方案：

問題根源

編譯器填充行為 Keil編譯器在生成HEX文件時，默認會根據Flash扇區大小（如STM32F407的16KB/128KB）對代碼段進行填充，填充內容通常為0xFF或未定義值。這些填充數據在MAP文件中不會顯示，但實際會存在于HEX文件中。
批處理腳本的裁剪缺陷 你的批處理腳本通過srec_cat裁剪HEX文件時，僅保留了0x08020000到CRC_ADDR之間的數據，忽略了CRC_ADDR之后可能存在的填充數據。這導致：
- 勾選批處理：生成的HEX文件僅包含有效代碼和CRC，裁剪掉了填充數據。
- 未勾選批處理：HEX文件保留編譯器生成的填充數據，J-Flash反讀時讀取整個扇區，包含這些殘留值。
Flash擦除差異 Keil燒錄時可能僅擦除代碼占用的扇區，而J-Flash默認擦除整個扇區，導致未初始化區域被填充為隨機值（如0x00），覆蓋了中斷向量表或其他關鍵數據。

解決方案

修改批處理腳本，確保在計算CRC后，保留原HEX文件中CRC_ADDR之后的所有填充數據。以下是修正后的腳本關鍵步驟：

1. 修改srec_cat命令

將第二個srec_cat命令改為合并三部分數據：

原HEX的CRC地址前部分 (0x08020000到CRC_ADDR)
新生成的CRC部分 (CRC_ADDR到CRC_ADDR_END)
原HEX的CRC地址后部分 (CRC_ADDR_END到Flash末尾)

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 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 -------------------------------------

關鍵改進點

保留填充數據 通過-crop %CRC_ADDR_END% 0x08080000顯式保留原HEX文件中CRC地址后的所有數據，避免截斷編譯器生成的填充。
統一填充值 使用-fill 0xFF ...確保未使用的Flash區域被初始化為0xFF，避免J-Flash讀取到隨機值。
完整Flash覆蓋 指定Flash的完整地址范圍（0x08080000為STM32F407VGT6的Flash末尾地址），確保操作覆蓋整個空間。

驗證方法

HEX文件對比 使用二進制工具（如HexCompare）對比Keil生成的原始HEX和批處理后的HEX，確認CRC地址后的數據是否一致。
Flash內容檢查 在Keil調試模式下，通過Memory窗口查看CRC_ADDR之后的Flash內容，確認是否為0xFF或有效數據。
J-Flash燒錄測試 使用修正后的HEX文件通過J-Flash燒錄，驗證App是否能正常啟動。

通過上述修正，批處理腳本將正確保留編譯器生成的填充數據，同時確保CRC校驗碼的完整性，解決J-Flash反讀多余數據導致程序無法運行的問題。

作者: rundstedt 時間: 2025-3-8 11:11
讀flash的軟件又不知道哪里結束當然把全部內容讀出來了。

歡迎光臨 (http://www.zg4o1577.cn/bbs/)