每一顆量產 ECU 裡都住著兩個軟體：天天工作的應用程式，以及平常隱形、只在更新時登場的 Flash Bootloader。它是 ECU 裡最不起眼也最不能出錯的程式——應用程式壞了可以重刷，Bootloader 壞了，這顆 ECU 就只能上返修台。理解它的運作，就理解了「刷寫斷電也不會變磚」是怎麼做到的。
開機那幾毫秒的決策
上電後 Bootloader 先跑，它要快速回答一個問題：跳去應用程式，還是留在刷寫模式？ 判斷依據通常是三層：
- 有效性旗標（Validity Flag）：上次刷寫有沒有完整結束？旗標是刷寫流程的最後一步才寫入——所以「寫到一半斷電」的應用程式，旗標必然無效
- 完整性檢查：對應用程式區計算校驗（CRC 或雜湊），與儲存的期望值比對
- 外部請求：診斷儀留下的「重開進 Bootloader」請求（跨重啟保存）
三關都過，跳去應用程式；任何一關失敗，留在 Bootloader 等待刷寫——這就是防磚的底層邏輯：無論應用程式多爛，永遠有一條回到「可刷寫狀態」的路。
一次完整的刷寫流程（UDS 視角）
刷寫是一段編排嚴謹的 UDS 對話（服務語意見 UDS 是什麼）：
- 前置：切換延伸會話 → 前置條件檢查（車速為零等）→ 關閉 DTC 記錄與非必要通訊——避免刷寫期間匯流排上其他節點瘋狂報「它怎麼不見了」
- 進入程式更新會話（0x10 programmingSession）＋安全存取（0x27 種子—金鑰）
- 下載 Flash Driver 到 RAM：抹除與寫入快閃的程式碼本身不存在快閃裡，而是刷寫時臨時下載到 RAM 執行。兩個理由：安全（平時 ECU 裡沒有「能自我抹除」的程式碼）與現實（寫快閃的程式碼不能從同一塊快閃執行）
- 逐區塊：抹除 → 傳輸（0x34 請求下載、0x36 連續傳資料、0x37 結束）→ 驗證（校驗與簽章）
- 收尾：寫入有效性旗標 → 重啟 → 新應用程式起跑
安全層面，現代流程在第 4 步的驗證裡包含密碼學簽章驗核——只有正確金鑰簽出的韌體才會被接受，這與 Secure Boot 的開機驗簽（見這篇）構成「寫入時擋一次、每次開機再擋一次」的雙保險。
三種現場，同一套機制的不同壓力
| 場景 | 最在乎 | 工程重點 |
|---|---|---|
| 開發桌 | 迭代速度 | 一鍵刷寫、多 ECU 批次、與 CI 串接 |
| 產線 | 節拍與良率 | 並行刷寫多顆、流程防呆、結果與追溯記錄 |
| 售後／OTA | 絕不變磚 | 斷點續傳、回滾路徑、車況前置條件（OTA 端的機制見這篇） |
同一顆 ECU 的 Bootloader 要同時伺候三種場景——這是為什麼刷寫工具鏈（如 vFlash 之於工作站與產線）的價值不在「能刷」，在把各 OEM 的刷寫規範差異封裝掉：序列、安全演算法、區塊格式各家不同，工具層吸收掉這些差異，工程師面對的是同一個操作介面。
值得放進測試清單的邊界情境
- 刷寫中斷電：每一個階段都斷一次（傳輸中、抹除中、驗證前、旗標寫入前）
- 簽章錯誤、金鑰等級不符、安全存取嘗試超限
- 逾時與重試：0x78（回應等待）處理、傳輸逾時後的恢復
- 相依性：A 模組新版需要 B 模組新版時，順序與失敗回退
- 「刷回舊版」：正常降級與回滾防護的邊界（哪些舊版被安全政策擋掉）
下一步
從 Bootloader 導入、產線刷寫站到售後更新流程，歐特莫夫（Vector Informatik 合作夥伴）協助把「刷寫」建成一條可靠、可追溯的生產能力。