汽車軟件Boot程序的主要作用是刷新App程序。在在一個(gè)具體客戶項(xiàng)目中，Boot也是客戶需求的一部分，跟隨項(xiàng)目也有軟件開發(fā)計(jì)劃（有的為了和其它Boot區(qū)分，把項(xiàng)目上的Boot稱作CB, Customer Boot）。

對(duì)于已經(jīng)下線盒蓋的控制器，無論是在供應(yīng)商或者客戶手里測試，只能通過CB刷新App。如果需要CB自刷新，就需要額外的方法。

規(guī)范：

整車廠只有對(duì)App程序刷新的規(guī)范，沒有對(duì)Boot自刷新的規(guī)范。因?yàn)橐?guī)范是針對(duì)量產(chǎn)車的，售后只負(fù)責(zé)App程序的升級(jí)，不對(duì)Boot升級(jí)（也不允許Boot升級(jí)）。

所以，Boot的自刷新只存在于項(xiàng)目開發(fā)階段，且由供應(yīng)商自行提供方案。本文分析五種Boot自更新方式的優(yōu)缺點(diǎn)。

方式一，SB更新CB：

如圖1-a，有的軟件架構(gòu)是兩級(jí)Boot：SB+CB，Start Boot只檢查CPU最小系統(tǒng)，與具體項(xiàng)目的外圍電路無關(guān)，它獨(dú)立于客戶需求，由供應(yīng)商自行維護(hù)，在Pilot項(xiàng)目早期就應(yīng)開發(fā)完成。因?yàn)槌绦騿?dòng)順序是SB->CB->App,這樣在SB里增加刷新邏輯可以更新CB。通常情況下運(yùn)行CB更新App程序，特殊情況下程序啟動(dòng)后一直停留在SB里，更新CB。

優(yōu)點(diǎn)：

1.邏輯結(jié)構(gòu)簡單清晰，軟件分工明確。

2.一次刷新，操作簡易。

缺點(diǎn)：

1.需要較大的Flash空間在SB里存放刷新邏輯，項(xiàng)目SOP后又要禁止這種刷新方式，造成額外的浪費(fèi)。

2.軟件分三級(jí)啟動(dòng)，結(jié)構(gòu)復(fù)雜，開發(fā)和維護(hù)成本較高。對(duì)于不需要SB的控制器是一種負(fù)擔(dān)。

3.萬一SB也需要更新怎么辦？按照這種策略，還得做個(gè)SSB？顯然不現(xiàn)實(shí)。

方式二、RAM+Flash Reboot更新

如圖2-a，不存在SB情況下，程序啟動(dòng)順序是CB->App。需要刷新Boot時(shí)，首先把Reboot程序下載到不用的RAM里（圖2-b），然后在RAM環(huán)境下運(yùn)行ReBoot,下載新的CB（圖2-c）

優(yōu)點(diǎn)：

1. 不需要額外的Flash空間，Boot程序運(yùn)行只需要少量的RAM，因此為App設(shè)計(jì)的RAM臨時(shí)可以保存Reboot程序。

2. RAM擦寫速度很快，則下載ReBoot的速度會(huì)很快。

缺點(diǎn)：

在CB更新過程中萬一CPU掉電，重新上電后Reboot內(nèi)容全無，CB已經(jīng)破損，程序不能正常啟動(dòng)，控制器癱瘓，只能開蓋用JTAG燒寫程序。

方式三、RAM+RAM ReBoot更新（對(duì)方式二的改進(jìn)）

首先把ReBoot（藍(lán)色）+NewCB（紫色）一起都下載到RAM里（圖3-a），然后運(yùn)行ReBoot,擦除CB Flash區(qū)域，將RAM中NewCB復(fù)制到CB Flash區(qū)域（這一步內(nèi)部完成）。最后，重新上電復(fù)位，RAM中的ReBoot和NewCB自動(dòng)丟失，程序從新的CB開始運(yùn)行。

優(yōu)點(diǎn)：

1.相比方式二少了一步刷新（因?yàn)镽eBoot和CB是綁在一起的）。

2.相比方式二CB更新全部在CPU內(nèi)部執(zhí)行，不受外界干擾，耗時(shí)更短。

缺點(diǎn)：

1. 相比方式二需要更大的RAM空間存儲(chǔ)ReBoot+NewCB。

2. 和方式二一樣存在CB更新階段掉電后控制器癱瘓的風(fēng)險(xiǎn) 。

方式四、借助App程序Flash空間

刷新分三步：1.圖4-b運(yùn)行CB，擦除App，把ReBoot下載到App區(qū)域。2.圖4-c運(yùn)行ReBoot,擦除舊CB，刷入新CB。3.圖4-d運(yùn)行新CB，刷回App。

優(yōu)點(diǎn)：

1.不需要額外的Flash和RAM資源。

2.穩(wěn)定可靠，通過優(yōu)化設(shè)計(jì)，可以保證在任何一個(gè)步驟突然掉電，上電后可以繼續(xù)操作，控制器不會(huì)刷死。（詳細(xì)設(shè)計(jì)方法請看附錄）

3.對(duì)CB做稍微改造就可以成為Reboot程序，開發(fā)快速。

缺點(diǎn)：

1.步驟繁多，為了更新CB必須要先擦除App，最后恢復(fù)App，至少三次刷新。對(duì)不熟悉步驟的操作者容易搞混亂。

2.整體刷新時(shí)間會(huì)較長，兩次Boot+一次App

方式五、借助額外Flash空間

相比方式四，需要一塊和CB一樣大小的額外Flash空間，刷新分三步：

圖5-b,運(yùn)行CB，刷入ReBoot到額外Flash。

圖5-c,運(yùn)行ReBoot，更新CB。

運(yùn)行新的CB，破壞ReBoot（全部擦除，或只擦除ReBoot有效性標(biāo)志）

優(yōu)點(diǎn)：相比方式四，不需要破壞App程序，也省去了這部分更新時(shí)間。

缺點(diǎn)：相比方式四，需要額外的Flash空間，且必須是獨(dú)立的Block。

小結(jié)：

本質(zhì)上只有三種：

依賴啟動(dòng)程序SB（方式一），當(dāng)CPU的Flash資源很富余且項(xiàng)目需要兩級(jí)Boot時(shí)，用該方法最節(jié)省時(shí)間。

借助RAM（方式二、三）3.借助Flash（方式四、五）。只需要單級(jí)Boot（CB）時(shí)，可以容忍因Boot刷新癱瘓必須要給控制器開蓋帶來時(shí)間，人力，物力的成本損耗的情況下用方式二，三較方便。

只需要單級(jí)Boot（CB）時(shí)，不允許或不方便控制器開蓋，但可以容忍Boot更新步驟繁多時(shí)間較長的情況下用方式四、五最可靠。

綜上，工程師需要根據(jù)整體軟件架構(gòu)，CPU資源，時(shí)間人力物料等成本因素綜合考慮一種適合自己產(chǎn)品及項(xiàng)目的Boot自刷新方法。

附錄：

《Boot自刷新方式四（借助Flash）的具體實(shí)現(xiàn)方法》

背景：

對(duì)于方式四借助Flash刷新【不存在刷死風(fēng)險(xiǎn)，在任何一個(gè)步驟中控制器突然掉電，上電后可以繼續(xù)操作。】的結(jié)論，是有條件的。筆者給出這個(gè)結(jié)論是從最理想的前提思考的，即只要控制器中至少有一個(gè)Boot存在（即使一個(gè)是壞的），程序就可以從任何一正常的Boot啟動(dòng)運(yùn)行。這里就有一個(gè)問題，CPU怎么判斷哪個(gè)Boot是好的，哪個(gè)是壞的？現(xiàn)在分析一下存在控制器刷死這種風(fēng)險(xiǎn)的情況和幾種對(duì)策方案。

兩級(jí)啟動(dòng)地址介紹：

如下圖示，CPU上電后程序按地址順序，檢查BootSector的有效性，如果BOOT_ID合法則從指定的地址開始執(zhí)行，否則檢查下一個(gè)BootSector。

考慮CPU至少具備兩個(gè)啟動(dòng)地址的情況，如圖1-a,當(dāng)且僅當(dāng)啟動(dòng)地址1有效時(shí)（App為空），程序啟動(dòng)后自動(dòng)進(jìn)入Boot。如圖1-b,當(dāng)且僅當(dāng)啟動(dòng)地址2有效時(shí)（不帶Boot測試），程序啟動(dòng)后自動(dòng)進(jìn)入App。如圖1-c，當(dāng)啟動(dòng)地址1，2都有效勢，程序優(yōu)先從地址1啟動(dòng)，在Boot里檢查App程序有效時(shí)，再靠跳轉(zhuǎn)指令Jump到啟動(dòng)地址2，開始運(yùn)行App。

方式四控制器刷死情況分析：

如圖 2-a，運(yùn)行Reboot更新CB途中斷電。重新上電后，如圖2-b，由于啟動(dòng)地址1的內(nèi)容是在刷新開始就被更新了是有效的，程序會(huì)進(jìn)入CB運(yùn)行，但是CB不完整，必然運(yùn)行出錯(cuò)，程序不會(huì)跳入ReBoot里，從而不能再刷新（即刷死）。假設(shè)從擦除完舊CB開始到刷入新CB完成的時(shí)間有10S，在此期間掉電的可能性也不能忽略。

對(duì)策一、Boot有效性標(biāo)志與啟動(dòng)地址重合

考慮最普遍情況，CPU只能整塊（Block）的擦出（16K,32K,64K...），可以最少4字節(jié)單位寫，沒有順序限制，現(xiàn)在CB只用了一個(gè)Block。現(xiàn)在調(diào)整刷新順序：擦出成功后，先刷新橙色區(qū)域，最后一步刷新啟動(dòng)地址1有效性標(biāo)志（灰色區(qū)域）。這樣，即使在更新橙色區(qū)域過程中掉電。

重新上電后，程序依然從啟動(dòng)地址2開始運(yùn)行，即重新運(yùn)行Reboot繼續(xù)等待刷新CB指令，如圖3-a所示。具體操作時(shí)也不需要更改下載流程，使用$34,36服務(wù)按順序從上位機(jī)傳輸數(shù)據(jù)到CPU中，先把啟動(dòng)地址1的有效性標(biāo)志放到RAM里，當(dāng)把橙色區(qū)域都下載到Flash后，再從RAM里把啟動(dòng)地址1的有效性標(biāo)志寫到Flash里（這一步10ms以內(nèi)即可完成，完全可以忽略在此時(shí)間內(nèi)掉電的可能性）

如果最后一步啟動(dòng)地址1刷新成功，再重新上電后，程序從啟動(dòng)地址1開始運(yùn)行新的Boot。即啟動(dòng)地址1起了Boot有效性標(biāo)志的作用（最先擦，最后寫），如圖3-b所示。

對(duì)策二、Boot有效性標(biāo)志獨(dú)立置尾，增加Boot有效性檢查邏輯

如圖4-a,把Boot分成2個(gè)段，Sec1里僅存放少量的啟動(dòng)自檢查邏輯，當(dāng)它檢測到置于Sec2末尾的CB_ValidFlg無效時(shí)，即認(rèn)為Boot是不完整的，則程序控制跳轉(zhuǎn)到啟動(dòng)地址2繼續(xù)運(yùn)行ReBoot，重新刷新Boot。

如圖4-b,當(dāng)Sec1的邏輯檢測到CB_ValidFlg有效時(shí)，即認(rèn)為Boot刷新完成，則程序控制跳轉(zhuǎn)入Sec2里，此時(shí)由于App(ReBoot)末尾的App_ValidFlg是無效的，程序并不會(huì)跳轉(zhuǎn)入ReBoot里，接下來就可以刷入新的App了。

這種方法只需要對(duì)CB的邏輯和段分配做一下調(diào)整，不需要更改刷新順序。Sec1里的啟動(dòng)自檢查邏輯可以做的盡量小，則只要保證刷新Sec1段的過程中不掉電，控制器就不會(huì)刷死，大大降低風(fēng)險(xiǎn)。但是對(duì)量產(chǎn)軟件，檢查CB_ValidFlg無效就直接跳轉(zhuǎn)入App是不合理的，所以當(dāng)Boot最終定型后，應(yīng)該把這個(gè)跳轉(zhuǎn)邏輯關(guān)閉。

小結(jié)：

對(duì)策一簡單可靠，經(jīng)過實(shí)際測試驗(yàn)證，完全可以滿足穩(wěn)定刷新ECU的要求。

原文標(biāo)題：單片機(jī)固件自更新，可靠實(shí)用的一個(gè)方法

文章出處：【微信公眾號(hào)：硬件攻城獅】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

審核編輯：湯梓紅