使用微控制器的 DFU 模式現場更新韌體

幾乎所有的嵌入式系統都需要具備在現場更新韌體的能力，以便加入新的功能或修復錯誤。然而，韌體現場更新並不容易，開發人員必須自行編程啟動載入器，或是從第三方元件供應商取得啟動載入器。

但其實有更容易的辦法。本文章將說明如何使用許多微控制器內建，但往往被忽視的裝置韌體更新 (DFU) 功能。

韌體更新選項

從頭開始開發啟動載入器並不容易。開發人員必須解析快閃記憶體的空間，以便多個應用程式共存。接著必須制訂某些方法，在不使用編程工具的情況下，將編譯過的二進位檔案移轉到微控制器中。在此做法下，他們必須開發通訊協定，或是添加外部記憶體以便儲存新映像，因此會增添系統複雜度。也可增加微控制器上的內部記憶體容量。

軟體本身也會變複雜，因為啟動載入器需要設定系統狀態，並判斷是否可安全跳到應用程式碼。

即便使用自訂的啟動載入器，能為開發人員提供應用所需的靈活性，但有一種韌體更新標準，可套用到許多應用，且無需開發人員進行任何作業：USB 標準的內建裝置韌體更新 (DFU) 類別。這項功能可在現場透過 USB 連接埠來更新微控制器的應用程式碼，如此一來，便能大幅縮短韌體更新流程及開發週期。

DFU 已經相當普遍，因此像是 STMicroelectronics 等不少微控制器廠商甚至會將執行更新所必備的軟體直接寫死到 ROM 當中。而不這麼做的廠商，則通常會提供範例程式碼，說明如何支援 DFU。

選擇具有 DFU 功能的微控制器

支援 DFU 最簡單的方式，就是選擇已經在 ROM 當中內建 DFU 的微控制器，像是 STMicroelectronics 的 STM32 微控制器。這些裝置當中會能吸引開發人員興趣進行實驗的產品包括 STM32 IoT 探索節點以及 STM32F429 探索套件。

圖 1：STMicroelectronics 的 STM32 IoT 探索節點是以 ARM^® Cortex^®-M4 核心為基礎，可執行 STM32L475 MCU，其中含有 DFU 模式韌體更新能力。此特定裝置的設計專門當作 IoT 節點使用。(圖片來源：STMicroelectronics)

STM32 IoT 探索節點是低成本的開發板，專門當作 IoT 感測器節點使用。這款開發板包含幾個不同的板連線介面，例如 Wi-Fi 與藍牙等。有趣的是，板載的 STM32L475 能讓開發人員在專門連接網際網路的裝置上測試並使用 DFU 功能。

對於只想在獨立使用的一般裝置上測試 DFU 的開發人員來說，STM32F429 探索套件是相當著名且低成本的 STM32F4 系列微控制器開發套件。現在，我們來探討開發人員如何在這些微控制器上測試 DFU。

圖 2：STMicroelectronics 的 STM32F429 探索套件是以 ARM^® Cortex^®-M4 核心為基礎。這款低成本開發板的 MCU 也包含用於進行韌體更新的 DFU 模式。(圖片來源：STMicroelectronics)

DFU 的簡單範例

在每個微控制器上，DFU 的使用方式都各不相同。舉一個簡單的例子，看看開發人員如何在使用 STM32L475 MCU 的裝置上更新韌體。

就像之前所提到的，STM32 微控制器在 ROM 當中已經內建 DFU 啟動載入器。為了存取此啟動載入器，開發人員必須在 MCU 啟動時，將一支 BOOT 引腳拉到地線。BOOT 引腳能控制 MCU 啟動時所處的模式，像是從快閃記憶體、RAM 啟動，或者我們所偏好的 DFU USB 模式。

開發人員使用 DFU 來準備要下載的應用程式，並不需要進行額外的作業。GNU 編譯器組合 (GCC) 以及其他許多工具鏈，都可支援在應用程式編譯時時產生 DFU 檔案。對開發人員來說，唯一要注意的小技巧是決定檔案的儲存位置：就像任何典型的應用一樣，除錯或物件資料夾即為 .dfu 檔案的所在位置。

DFU 檔案與其他應用程式紀錄格式非常類似，例如二進位、s-record 以及十六進位檔案等。檔案格式內含透過 USB 中繼的位址與數據資訊，在經過處理後會寫入到快閃記憶體中的指定位置。這個流程相當順暢，以致於開發人員鮮少甚至不需要檢查過程中所用的通訊協定。整個過程全部在幕後經過處理，有助於降低韌體更新流程與開發作業的複雜度。

提供多種不同的工具，能讓開發人員利用 DFU 將應用程式移轉到微控制器。可使用一個常見的命令列工具 dfu-util。Linux 和 Windows^® 都有提供此開放原始碼軟體套裝。若開發人員使用 STM 工具鏈，則可以享有 STMicroelectronics 的 DfuSe 應用程式所帶來的優勢 (圖 3)。

圖 3：STMicroelectronics 的 DfuSe 工具能用來設定由 GCC 等編譯器所產生的 DFU 檔案，並載入到具有 DFU 功能的微控制器中。(圖片來源：Beningo Embedded Group)

DfuSe 是一種 Windows GUI 公用程式，能偵測任何以 DFU 模式啟動，並透過 USB 連接到電腦的 STM32 裝置。開發人員能取得的資訊像是進行編程的廠商以及產品 ID 等。若快閃記憶體空間並未進行適當保護，開發人員甚至可用 Upload Action (上傳動作) 方塊複製 MCU 的記憶體內容，並將其儲存在電腦中。

使用 DfuSe 時，開發人員通常只需使用 Upgrade or Verify Action (升級或驗證動作) 區塊。在這個區塊中，開發人員可以選擇 DFU 應用檔案，然後選擇 Upgrade (升級) 按鈕。接著，DfuSe 會自動協調韌體更新流程的進行，直到整個檔案成功載入到 MCU 為止。之後開發人員可以選擇驗證映像檔是否已成功接收。驗證完成後，就可以將 BOOT 引腳設定回預設的配置 (像是啟動至快閃記憶體)，然後就可選擇「Leave DFU」(離開 DFU) 模式，以載入並執行更新的韌體。

在不支援 DFU 的元件上使用 DFU

微控制器的 ROM 當中未內建 DFU 啟動載入器，並不表示開發人員就無法利用 DFU 功能。DFU 是一種 USB 類別，並受到許多 USB 堆疊支援。也就是說，開發人員可以輕鬆將 DFU 功能加到應用框架，並且仍能執行 DFU 更新。

舉例來說，Microchip Technology 的 AT32UC3A3 就未內建 DFU 模式 (圖 4)。開發人員能參考簡單的應用說明，瞭解 DFU 的運作方式，以及開發人員該如何設定微控制器以便正確支援 DFU。

圖 4：AT32UC3A3 UC3-A3 XPLD AVR®32 MCU 32 位元 AVR 嵌入式評估板並未在晶片上內建 DFU，但能在框架中加入 USB 程式碼，進而達到 DFU 韌體更新功能。(圖片來源：Microchip Technology)

進行韌體更新的秘訣和技巧

在現場更新韌體的能力，並非只能由具備 DFU 功能的微控制器提供。開發人員可以自行判斷，韌體更新的替代方法是否有必要，或者是更為實際的作法。在這些情況下，開發人員應該記住幾個關於韌體更新流程的秘訣。包括：

• 使用核對和或雜湊來驗證將寫入到微控制器記憶體的應用程式。
• 選擇記憶體容量足夠儲存韌體備份檔的微控制器，這麼一來，即便不小心出錯，也能還原韌體版本。
• 確認微控制器是否內建快閃載入器，且最終用戶無法意外觸發。
• 確保任何軟體啟動載入器皆已經過編譯，並且具有最佳化大小。
• 鎖定快閃記憶體周邊裝置，讓應用程式無法讀取記憶體與進行反向工程。
• 務必確定堆疊指標、向量表以及程式計數器暫存器皆設定為適當的應用值。
• 考慮使用替代的更新方法，像是使用 USB MSD 進行拖放式更新，如同 KL46Z Freedom 板 (圖 5) 展示的一樣。

圖 5：NXP Semiconductor 的 KL46Z Freedom 板是低成本的開發板，預設不支援 DFU。開發人員能夠使用 USB MSD 等替代更新方法，將新的韌體映像拖放到內建記憶體中。(圖片來源：NXP Semiconductor)

結論

幾乎所有的嵌入式系統都需要可在現場更新應用程式碼的方法，以避免產品召回。從頭開始建立啟動載入器或是修改現有的啟動載入器，可能會在開發週期中產生複雜度與整合問題。