前言

這幾天遇到一個bootloader升級的奇怪問題，分析問題的過程使用了一些常用的分析工具和方法覺得很有普遍性，這里記錄一下Bug分析、復現(xiàn)最后解決的整個過程，希望能給大家?guī)硪恍﹩l(fā)。

正文

環(huán)境描述

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

測試用例

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

圖1：Bootloader故障注入測試

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

期望結(jié)果

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

圖3：A分區(qū)升級失敗后跳到B分區(qū)期望正常通信狀態(tài)

實際結(jié)果

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

圖4：A分區(qū)升級失敗后跳到B分區(qū)實際異常通信狀態(tài)

問題分析

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

. IGOFF

.低電壓（低于6.5V）

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

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

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

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

. 處于A分區(qū)，刷A分區(qū)

. 處于A分區(qū)，刷B分區(qū)

. 處于B分區(qū)，刷A分區(qū)

. 處于B分區(qū)，刷B分區(qū)

結(jié)果，無論最后是在A分區(qū)還是B分區(qū)，通信都是正常的。

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

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

調(diào)試上位機：RH850提供的CS+

調(diào)試仿真器：瑞薩專用的E2

圖5：CS+的熱插拔選項

圖6：CS+的調(diào)試器E2配置

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

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

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

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

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

. 當前處于B分區(qū)

. 升級B分區(qū)

. 跳過0x34開始傳輸數(shù)據(jù)服務

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

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

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

. 當前處于A分區(qū)

. 開始升級程序

. 擦除完A分區(qū)數(shù)據(jù)

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

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

. 開始升級

. 跳過0x34服務

. 0x36開始傳輸數(shù)據(jù)

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

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

擦除完A分區(qū)數(shù)據(jù)后還沒開始傳輸A分區(qū)的數(shù)據(jù)就立馬斷開物理連接。

成功復現(xiàn)問題!!!

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

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

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

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

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

為啥A分區(qū)0x40000處開始的數(shù)據(jù)會影響B(tài)分區(qū)的程序運行？

8）查看A分區(qū)和B分區(qū)的鏈接文件

圖10：A分區(qū)鏈接文件

圖11：B分區(qū)鏈接文件

找到問題，A分區(qū)和B分區(qū)的標定數(shù)據(jù)用的是同一塊Flash地址！

9）修改B分區(qū)鏈接文件

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

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

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

總結(jié)

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

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

審核編輯：劉清