汽車軟件Boot程序的主要作用是刷新App程序。在在一個具體客戶項目中,Boot也是客戶需求的一部分,跟隨項目也有軟件開發計劃(有的為了和其它Boot區分,把項目上的Boot稱作CB, Customer Boot)。對于已經下線盒蓋的控制器,無論是在供應商或者客戶手里測試,只能通過CB刷新App。如果需要CB自刷新,就需要額外的方法。
規范:
整車廠只有對App程序刷新的規范,沒有對Boot自刷新的規范。因為規范是針對量產車的,售后只負責App程序的升級,不對Boot升級(也不允許Boot升級)。所以,Boot的自刷新只存在于項目開發階段,且由供應商自行提供方案。本文分析五種Boot自更新方式的優缺點。
方式一,SB更新CB:
如圖1-a,有的軟件架構是兩級Boot:SB+CB,Start Boot只檢查CPU最小系統,與具體項目的外圍電路無關,它獨立于客戶需求,由供應商自行維護,在Pilot項目早期就應開發完成。因為程序啟動順序是SB->CB->App,這樣在SB里增加刷新邏輯可以更新CB。通常情況下運行CB更新App程序,特殊情況下程序啟動后一直停留在SB里,更新CB。
優點:
1.邏輯結構簡單清晰,軟件分工明確。
2.一次刷新,操作簡易。
缺點:
1.需要較大的Flash空間在SB里存放刷新邏輯,項目SOP后又要禁止這種刷新方式,造成額外的浪費。
2.軟件分三級啟動,結構復雜,開發和維護成本較高。對于不需要SB的控制器是一種負擔。
3.萬一SB也需要更新怎么辦?按照這種策略,還得做個SSB?顯然不現實。
方式二、RAM+Flash Reboot更新
如圖2-a,不存在SB情況下,程序啟動順序是CB->App。需要刷新Boot時,首先把Reboot程序下載到不用的RAM里(圖2-b),然后在RAM環境下運行ReBoot,下載新的CB(圖2-c)
優點:
1. 不需要額外的Flash空間,Boot程序運行只需要少量的RAM,因此為App設計的RAM臨時可以保存Reboot程序。
2. RAM擦寫速度很快,則下載ReBoot的速度會很快。
缺點:
在CB更新過程中萬一CPU掉電,重新上電后Reboot內容全無,CB已經破損,程序不能正常啟動,控制器癱瘓,只能開蓋用JTAG燒寫程序。
方式三、RAM+RAM ReBoot更新(對方式二的改進)
首先把ReBoot(藍色)+NewCB(紫色)一起都下載到RAM里(圖3-a),然后運行ReBoot,擦除CB Flash區域,將RAM中NewCB復制到CB Flash區域(這一步內部完成)。最后,重新上電復位,RAM中的ReBoot和NewCB自動丟失,程序從新的CB開始運行。
優點:
1.相比方式二少了一步刷新(因為ReBoot和CB是綁在一起的)。
2.相比方式二CB更新全部在CPU內部執行,不受外界干擾,耗時更短。
缺點:
1. 相比方式二需要更大的RAM空間存儲ReBoot+NewCB。
2. 和方式二一樣存在CB更新階段掉電后控制器癱瘓的風險 。
方式四、借助App程序Flash空間
刷新分三步:1.圖4-b運行CB,擦除App,把ReBoot下載到App區域。2.圖4-c運行ReBoot,擦除舊CB,刷入新CB。3.圖4-d運行新CB,刷回App。
優點:
1.不需要額外的Flash和RAM資源。
2.穩定可靠,通過優化設計,可以保證在任何一個步驟突然掉電,上電后可以繼續操作,控制器不會刷死。(詳細設計方法請看附錄)
3.對CB做稍微改造就可以成為Reboot程序,開發快速。
缺點:
1.步驟繁多,為了更新CB必須要先擦除App,最后恢復App,至少三次刷新。對不熟悉步驟的操作者容易搞混亂。
2.整體刷新時間會較長,兩次Boot+一次App
方式五、借助額外Flash空間
相比方式四,需要一塊和CB一樣大小的額外Flash空間,刷新分三步:
圖5-b,運行CB,刷入ReBoot到額外Flash。
圖5-c,運行ReBoot,更新CB。
運行新的CB,破壞ReBoot(全部擦除,或只擦除ReBoot有效性標志)
優點:相比方式四,不需要破壞App程序,也省去了這部分更新時間。
缺點:相比方式四,需要額外的Flash空間,且必須是獨立的Block。
小結:
本質上只有三種:
依賴啟動程序SB(方式一),當CPU的Flash資源很富余且項目需要兩級Boot時,用該方法最節省時間。
借助RAM(方式二、三)3.借助Flash(方式四、五)。只需要單級Boot(CB)時,可以容忍因Boot刷新癱瘓必須要給控制器開蓋帶來時間,人力,物力的成本損耗的情況下用方式二,三較方便。
只需要單級Boot(CB)時,不允許或不方便控制器開蓋,但可以容忍Boot更新步驟繁多時間較長的情況下用方式四、五最可靠。
綜上,工程師需要根據整體軟件架構,CPU資源,時間人力物料等成本因素綜合考慮一種適合自己產品及項目的Boot自刷新方法。
附錄:
《Boot自刷新方式四(借助Flash)的具體實現方法》
背景:
對于方式四借助Flash刷新【不存在刷死風險,在任何一個步驟中控制器突然掉電,上電后可以繼續操作。】的結論,是有條件的。筆者給出這個結論是從最理想的前提思考的,即只要控制器中至少有一個Boot存在(即使一個是壞的),程序就可以從任何一正常的Boot啟動運行。這里就有一個問題,CPU怎么判斷哪個Boot是好的,哪個是壞的?現在分析一下存在控制器刷死這種風險的情況和幾種對策方案。
兩級啟動地址介紹:
如下圖示,CPU上電后程序按地址順序,檢查BootSector的有效性,如果BOOT_ID合法則從指定的地址開始執行,否則檢查下一個BootSector。
考慮CPU至少具備兩個啟動地址的情況,如圖1-a,當且僅當啟動地址1有效時(App為空),程序啟動后自動進入Boot。如圖1-b,當且僅當啟動地址2有效時(不帶Boot測試),程序啟動后自動進入App。如圖1-c,當啟動地址1,2都有效勢,程序優先從地址1啟動,在Boot里檢查App程序有效時,再靠跳轉指令Jump到啟動地址2,開始運行App。
方式四控制器刷死情況分析:
如圖 2-a,運行Reboot更新CB途中斷電。重新上電后,如圖2-b,由于啟動地址1的內容是在刷新開始就被更新了是有效的,程序會進入CB運行,但是CB不完整,必然運行出錯,程序不會跳入ReBoot里,從而不能再刷新(即刷死)。假設從擦除完舊CB開始到刷入新CB完成的時間有10S,在此期間掉電的可能性也不能忽略。
對策一、Boot有效性標志與啟動地址重合
考慮最普遍情況,CPU只能整塊(Block)的擦出(16K,32K,64K...),可以最少4字節單位寫,沒有順序限制,現在CB只用了一個Block。現在調整刷新順序:擦出成功后,先刷新橙色區域,最后一步刷新啟動地址1有效性標志(灰色區域)。這樣,即使在更新橙色區域過程中掉電。重新上電后,程序依然從啟動地址2開始運行,即重新運行Reboot繼續等待刷新CB指令,如圖3-a所示。具體操作時也不需要更改下載流程,使用$34,36服務按順序從上位機傳輸數據到CPU中,先把啟動地址1的有效性標志放到RAM里,當把橙色區域都下載到Flash后,再從RAM里把啟動地址1的有效性標志寫到Flash里(這一步10ms以內即可完成,完全可以忽略在此時間內掉電的可能性)
如果最后一步啟動地址1刷新成功,再重新上電后,程序從啟動地址1開始運行新的Boot。即啟動地址1起了Boot有效性標志的作用(最先擦,最后寫),如圖3-b所示。
對策二、Boot有效性標志獨立置尾,增加Boot有效性檢查邏輯
如圖4-a,把Boot分成2個段,Sec1里僅存放少量的啟動自檢查邏輯,當它檢測到置于Sec2末尾的CB_ValidFlg無效時,即認為Boot是不完整的,則程序控制跳轉到啟動地址2繼續運行ReBoot,重新刷新Boot。
如圖4-b,當Sec1的邏輯檢測到CB_ValidFlg有效時,即認為Boot刷新完成,則程序控制跳轉入Sec2里,此時由于App(ReBoot)末尾的App_ValidFlg是無效的,程序并不會跳轉入ReBoot里,接下來就可以刷入新的App了。
這種方法只需要對CB的邏輯和段分配做一下調整,不需要更改刷新順序。Sec1里的啟動自檢查邏輯可以做的盡量小,則只要保證刷新Sec1段的過程中不掉電,控制器就不會刷死,大大降低風險。但是對量產軟件,檢查CB_ValidFlg無效就直接跳轉入App是不合理的,所以當Boot最終定型后,應該把這個跳轉邏輯關閉。
小結:
對策一簡單可靠,經過實際測試驗證,完全可以滿足穩定刷新ECU的要求。
審核編輯:劉清
-
控制器
+關注
關注
112文章
16339瀏覽量
177829 -
FlaSh
+關注
關注
10文章
1633瀏覽量
147951 -
RAM
+關注
關注
8文章
1368瀏覽量
114649 -
bootloader
+關注
關注
2文章
235瀏覽量
45614 -
SOP封裝
+關注
關注
0文章
56瀏覽量
15364
原文標題:實現BootLoader自更新的五種方式
文章出處:【微信號:嵌入式情報局,微信公眾號:嵌入式情報局】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論