前言

這幾天遇到一個bootloader升級的奇怪問題，分析問題的過程使用了一些常用的分析工具和方法覺得很有普遍性，這里記錄一下Bug分析、復現最后解決的整個過程，希望能給大家帶來一些啟發。

正文

環境描述

ECU使用瑞薩公司的RH850芯片，bootloader支持應用的雙分區刷寫。

測試用例

當前程序處于A分區 --> 開始升級，跳入bootloader --> 升級A分區程序 --> 故障注入，跳過升級的0x34服務，直接開始0x36服務傳輸升級包程序

圖1：Bootloader故障注入測試

圖2：Bootloader升級常用的UDS服務ID

期望結果

Bootloader升級失敗，0x11 01軟件復位后Bootloader校驗A分區失?。J跳到A分區），程序跳到B分區，正常運行B分區程序。

圖3：A分區升級失敗后跳到B分區期望正常通信狀態

實際結果

Bootloader升級失敗，0x11 01軟件復位后Bootloader校驗A分區失?。J跳到A分區），程序跳到B分區，程序的通信都異常（每次重啟后只發出一幀報文，間隔很久又會發出一幀報），但是診斷功能是OK的。

圖4：A分區升級失敗后跳到B分區實際異常通信狀態

問題分析

1）診斷功能OK的，說明程序沒有跑死，上電只發一幀報文很像是應用滿足條件關閉通信了。ECU在以下三個狀態下會關閉通信。

. IGOFF

.低電壓（低于6.5V）

.低功耗模式 && 沒有處于EOL（End Of Line，下線模式）

第一個和第二個條件直接測試外部硬件輸入可以確定不可能滿足。第三個條件需要診斷觸發，理論上是不可能滿足條件。

初步結論1：不是外部硬件輸入狀態導致關閉通信，也不是診斷時間關閉通信。

2）嘗試各種正常情況下的刷寫操作

. 處于A分區，刷A分區

. 處于A分區，刷B分區

. 處于B分區，刷A分區

. 處于B分區，刷B分區

結果，無論最后是在A分區還是B分區，通信都是正常的。

初步結論2：正常情況下的程序刷寫都成功，且通信正常。

3）問題發生后ECU就一直處于故障狀態了，這個時候可以考慮使用調試器的熱插拔功能（Hot Plug-in，不重新Download程序到ECU當中，直接進入調試模式，ECU中運行的還是故障狀態下的程序）。

調試上位機：RH850提供的CS+

調試仿真器：瑞薩專用的E2

圖5：CS+的熱插拔選項

圖6：CS+的調試器E2配置

圖7：程序進入了低功耗狀態下關閉通信的分支

按照1）中的分析，程序不可能進入低功耗狀態下關閉通信的分支，除非是進行分支判斷的全局變量被異常篡改了。

初步結論3：啟動模式的全局變量被異常篡改，導致程序進入到低功耗模式下關閉通信了。

全局變量被異常篡改，一般是數組越界或者是指向全局變量的指針操作異常導致的，但是如果是這樣的話，和升級沒啥關系，無論最后跳到A分區還是B分區都會出現異常，所以應該不是程序本身的問題。

4）讓測試同事在B分區進行故障注入測試。

. 當前處于B分區

. 升級B分區

. 跳過0x34開始傳輸數據服務

最后升級B分區失敗，跳到A分區，A分區的通信是正常的。

初步結論4：B分區升級B分區進行故障注入后跳到A分區是正常的。

5）嘗試自己復現問題。測試同事的測試用例是跳過0x34服務后開始傳輸數據，其實也就是A分區被擦除后升級失敗，跳到了B分區。那么理論上我復現問題的時候，只要滿足以下條件就能復現文：

. 當前處于A分區

. 開始升級程序

. 擦除完A分區數據

. 還沒升級完A分區程序就斷開物理連接，確保A分區升級失敗

最后確實升級A分區失敗，跳到了B分區，但是B分區的通信卻是正常的。為什么自己的測試結果和測試同事的測試結果不一樣了？-- 分析測試同事的測試用例:

. 開始升級

. 跳過0x34服務

. 0x36開始傳輸數據

和上面我的復現步驟對比，測試同學的測試用例因為跳過了0x34服務，所以ECU的A分區是完全被擦除的狀態，我的操作是在程序刷寫了一部分的情況下斷開物理連接，所以A分區被擦除后又被寫入部分數據。

6）模擬測試同事的測試步驟。

擦除完A分區數據后還沒開始傳輸A分區的數據就立馬斷開物理連接。

成功復現問題!!!

分析5）和6）兩種操作，不同點就是擦除完A分區后數據后又往A分區寫入了部分數據。寫入的部分數據影響了A分區程序的運行。

7）使用瑞莎公司提供的RFPV（Renesas Flash Programmer）將5）和6）兩種操作后的程序都讀出來進行對比。

圖8：讀取兩種操作下的Flash中的程序

圖9：使用hexview工具對比B分區通信異常和B分區通信正常下的程序

異常情況下的程序從0x40000開始處數據是被擦除的，正常情況下的程序的0x40000開始的程序是有數據的。

為啥A分區0x40000處開始的數據會影響B分區的程序運行？

8）查看A分區和B分區的鏈接文件

圖10：A分區鏈接文件

圖11：B分區鏈接文件

找到問題，A分區和B分區的標定數據用的是同一塊Flash地址！

9）修改B分區鏈接文件

圖12：修改B分區鏈接文件的標定量起始地址

最后上板驗證通過，問題解決。

10）為啥標定量的數據被擦除后會影響到通信？-- 猜測是標定段數據被擦除后標定相關的協議數據讀寫異常，最后導致進行分支判斷的全局變量被異常篡改了。目前還未想到驗證猜想的辦法。

總結

這個問題分析了足足一天，分析問題的過程很具有代表性：發現問題 --> 推測原因 -->驗證猜想 --> 驗證失敗 -->對比分析推測-->猜測驗證 -->成功解決，逐步抽絲剝繭，層層遞進，最后解決問題。

希望對各位看官有所啟示。中間還用到了調試器的熱插拔功能，編程器的讀取ECU程序的功能，hexview對比Hex文件的功能，這些功能在分析問題中經常用到。

審核編輯：劉清