記錄一下bootloader升級(jí)Bug分析及復(fù)現(xiàn)最后解決的整個(gè)過(guò)程

前言

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

正文

環(huán)境描述

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

測(cè)試用例

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

圖1：Bootloader故障注入測(cè)試

圖2：Bootloader升級(jí)常用的UDS服務(wù)ID

期望結(jié)果

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

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

實(shí)際結(jié)果

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

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

問題分析

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

. IGOFF

.低電壓（低于6.5V）

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5：CS+的熱插拔選項(xiàng)

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

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

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

初步結(jié)論3：?jiǎn)?dòng)模式的全局變量被異常篡改，導(dǎo)致程序進(jìn)入到低功耗模式下關(guān)閉通信了。

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

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

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

. 升級(jí)B分區(qū)

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

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

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

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

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

. 開始升級(jí)程序

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

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

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

. 開始升級(jí)

. 跳過(guò)0x34服務(wù)

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

和上面我的復(fù)現(xiàn)步驟對(duì)比，測(cè)試同學(xué)的測(cè)試用例因?yàn)樘^(guò)了0x34服務(wù)，所以ECU的A分區(qū)是完全被擦除的狀態(tài)，我的操作是在程序刷寫了一部分的情況下斷開物理連接，所以A分區(qū)被擦除后又被寫入部分?jǐn)?shù)據(jù)。

6）模擬測(cè)試同事的測(cè)試步驟。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后上板驗(yàn)證通過(guò)，問題解決。

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

總結(jié)

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

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

審核編輯：劉清