如何實作BLE OTA？什麼叫DFU？如何通過UART實作固件更新？又如何通過USB實作固件更新？怎麼保證更新的安全性？什麼叫雙區（dual bank）DFU？什麼叫單區（single bank）DFU？什麼叫背景式（background）DFU？本文将對上述問題進行探讨。
DFU過程中涉及的所有操作步驟所對應的腳本都放在百度雲盤上，雲盤連結如下所示：
- 連結: https://pan.baidu.com/s/1FKTfY3Q_zBVvviO7KC7Gyg#list/path=%2Fblog 密碼: y8fb
腳本是按照SDK版本進行分類的，建議大家把自己SDK版本對應的腳本下載下傳下來，然後跟着第3章的操作步驟一步一步去實作自己的DFU。
1.概述
所謂DFU（Device Firmware Update），就是裝置固件更新的意思，而OTA（Over The Air）是實作DFU的一種方式而已，準确說，OTA的全稱應該是OTA DFU，即通過空中無線方式實作裝置固件更新。隻不過大家為了友善起見，直接用OTA來指代固件空中更新（有時候大家也将OTA稱為FOTA，即Firmware OTA，這種稱呼意思更明了一些）。隻要是通過無線通信方式實作DFU的，都可以叫OTA，比如2G/3G/4G/WiFi/藍牙/NFC/Zigbee，他們都支援OTA。DFU除了可以通過無線方式（OTA）進行更新，也可以通過有線方式進行更新，比如通過UART，USB或者SPI通信接口來更新裝置固件。
不管采用OTA方式還是有線通信方式，DFU包括背景式（background）和非背景式兩種模式。背景式DFU，又稱靜默式DFU（Silent DFU），在更新的時候，新固件在背景悄悄下載下傳，即新固件下載下傳屬于應用程式功能的一部分，在新固件下載下傳過程中，應用可以正常使用，也就是說整個下載下傳過程對使用者來說是無感的，下載下傳完成後，系統再跳到BootLoader模式，由BootLoader完成新固件覆寫老固件的操作，至此整個更新過程結束。比如智能手機更新Android或者iOS系統都是采用背景式DFU方式，新系統下載下傳過程中，手機可以正常使用哦。非背景式DFU，在更新的時候，系統需要先從應用模式跳入到BootLoader模式，由BootLoader進行新固件下載下傳工作，下載下傳完成後BootLoader繼續完成新固件覆寫老固件的操作，至此更新結束。早先的功能機就是采用非背景式 DFU來更新作業系統的，即使用者需要先長按某些按鍵進入bootloader模式，然後再進行更新，整個更新過程中手機正常功能都無法使用。
下面再講雙區DFU（dual bank）和單區DFU（single bank），雙區或者單區DFU是新固件和老固件覆寫的兩種方式。背景式DFU必須采用雙區模式進行更新，即老系統（老固件）和新系統（新固件）各占一塊bank（存儲區），假設老固件放在bank0中，新固件放在bank1中，更新的時候，應用程式先把新固件下載下傳到bank1中，隻有當新固件下載下傳完成并校驗成功後，系統才會跳入BootLoader模式，然後擦除老固件所在的bank0區，并把新固件拷貝到bank0中。非背景式DFU可以采用雙區也可以采用單區模式，與背景式DFU相似，雙區模式下新老固件各占一塊bank（老固件為bank0，新固件為bank1），更新時，系統先跳入BootLoader模式，然後BootLoader程式把新固件下載下傳到bank1中，隻有新固件下載下傳完成并校驗成功後，才會去擦除老固件所在的bank0區，并把新固件拷貝到bank0區。單區模式的非背景式DFU隻有一個bank0，老固件和新固件分享這一個bank0，更新的時候，進入bootloader模式後立馬擦除老固件，然後直接把新固件下載下傳到同一個bank中，下載下傳完成後校驗新固件的有效性，新固件有效更新完成，否則要求重來。跟非背景式DFU雙區模式相比，單區模式節省了一個bank的Flash空間，在系統資源比較緊張的時候，單區模式是一個不錯的選擇。不管是雙區模式還是單區模式，更新過程出現問題後，都可以進行二次更新，都不會出現“變磚”情況。不過雙區模式有一個好處，如果更新過程中出現問題或者新固件有問題，它還可以選擇之前的老固件老系統繼續執行而不受其影響。而單區模式碰到這種情況就隻能一直待在bootloader中，然後等待二次或者多次更新嘗試，此時裝置的正常功能已無法使用，從使用者使用這個角度來說，你的确可以說此時裝置已經“變磚”了。是以說，雖然雙區模式犧牲了很多存儲空間，但是換來了更好的更新體驗。
可參考下面三個圖來了解上述過程。
如果你是第一次接觸Nordic nRF5 SDK，那麼建議你先看一下這篇文章：開發你的第一個BLE應用程式—Blinky，或者看一下這一篇文章：手把手教你開發BLE資料透傳應用程式，以建立Nordic nRF5 SDK的一些基本知識，然後再往下看以下章節。
2. Nordic nRF5 SDK DFU工作原理
如文章“nRF5 SDK軟體架構及softdevice工作原理”所述，Nordic nRF5 SDK軟體架構跟其他家有點不一樣，程式存儲區最開始部分放得不是Bootloader，而是藍牙協定棧Softdevice，應用程式則緊挨着Softdevice，Bootloader則被nRF5 SDK放在程式存儲區的最上面，整個存儲區結構圖如下所示。如果使用者還有Flash資料需要存放，那麼這些資料緊挨着BootLoader下面。
目前Nordic SDK預設隻提供非背景式DFU開箱即用的例子（SDK16.0開始也支援背景式DFU架構），即系統必須先跳到BootLoader中，然後才能通過BLE/UART/USB去接收新的固件。如上所示，如果采用雙區模式DFU，那麼Bank0放的是應用程式，即老固件，Bank1放的是新固件。平時，Bank1為空或者忽略，系統隻跑Bank0裡面的應用程式；更新的時候，先跳到BootLoader，然後接收新固件并把它放在Bank1中，最後把Bank1裡面的固件拷貝到Bank0中。如果采用單區模式，則沒有Bank1這個區。平時，系統隻跑Bank0裡面的代碼；更新的時候，跳到BootLoader，先擦除Bank0裡面的老程式，并把新固件直接放在Bank0中。
根據更新時如何跳轉到Bootloader，Nordic SDK又将DFU分為按鍵式DFU和非按鍵式（Buttonless）DFU，所謂按鍵式DFU，就是上電時長按某個按鍵以進入bootloader模式，而非按鍵式DFU，就是整個DFU過程中裝置端無任何人工幹預，通過BLE/UART/USB接口給應用程式發送一條指令，應用程式收到指令後再自動跳入bootloader模式。不管是按鍵式DFU還是非按鍵式DFU，兩者隻是進入BootLoader的方式不一樣，其餘基本一樣，尤其是BootLoader工作過程基本上是一模一樣的。後面隻會闡述非按鍵式DFU的過程，按鍵式DFU以此類似，就不再贅述。
程式跳到BootLoader後，根據BootLoader需不需要對新固件進行驗簽，Nordic SDK又把DFU分為開放式DFU和安全式DFU（又稱簽名DFU）。開放式DFU，BootLoader不做任何驗證，直接把新固件接收下來。安全式DFU，BootLoader存有一把公鑰，BootLoader會先用這把公鑰驗證新固件的簽名，隻有驗簽通過，才允許後續的工作：比如把新固件接收下來；如果驗簽失敗，BootLoader将拒絕更新，重新跳回應用程式。
BootLoader可以通過不同的通信接口來接收新的固件，目前Nordic SDK支援BLE，UART和USB三種接口，是以大家可以在Nordic SDK中看到如下三種工程目錄：
其中pca0056表示nRF52840對應的開發闆編号，S140對應Softdevice的型号，然後ble有兩個目錄：無debug和有debug，uart和usb也包含同樣的兩個目錄。有debug和無debug兩者功能是一樣的，兩者的差別是：debug版本BootLoader支援日志列印（大家可以通過列印出的日志去了解BootLoader的工作過程），并可以忽略各種校驗，debug版本占據的代碼空間要大很多；無debug版本 BootLoader不支援日志列印功能并且版本和有效性校驗是強制的。正式量産的時候推薦使用無debug版本以節省代碼空間。這裡要強調一下，不管是debug版本還是無debug版本，兩者都可以用Keil進行單步和斷點調試。
BLE，UART和USB隻是通信方式不一樣，他們遵守的DFU流程是一模一樣的，這裡會以BLE通信接口為例，詳細闡述DFU過程，UART和USB與之類似，就不再贅述。
講述DFU更新之前，先講一下nRF52的啟動流程，上電後，系統先執行softdevice，softdevice通過讀取UICR一個寄存器的值，來判斷目前系統是否有BootLoader，如果沒有BootLoader，系統直接跳到application；如果有BootLoader，系統先跳到BootLoader，BootLoader再根據目前的情況來決定是進入更新模式還是跳往application，BootLoader主要判斷如下幾種情況：
- 按鍵是否按下
- 保持寄存器GPREGRET1是否為0xB1
- 上次DFU過程是否還在進行中
- 應用程式校驗是否通過
如果按鍵沒有按下，GPREGRET1不為0xB1，本次複位不是上次DFU的繼續，并且應用程式校驗通過，那麼BootLoader就會直接跳到application，去執行application應用程式。那怎麼去校驗應用程式的有效性呢？為此BootLoader引入了一個放在Flash的結構體參數：m_dfu_settings_buffer（資料類型：nrf_dfu_settings_t），這個結構體參數雖然隻有896位元組，但由于Flash隻能按頁擦除，是以這個參數實際占用了一個Flash page，這個page稱為settings page，settings page放在Flash的最後一個頁面，settings page目前有2個版本：版本1（SDK15.2及以前版本）和版本2（SDK15.3及以後版本），版本2可以相容版本1，前面所述的896位元組是指settings page版本2的大小。Settings page包含的資訊比較多，大家用得比較多的是：
- 各種版本資訊
- DFU更新過程資訊
- Application image的CRC值和大小
- 應用程式的bonding資訊
- Init command内容
- application/softdevice的啟動校驗資訊（版本2才有）
版本1的settings page隻校驗application image的CRC值，如果CRC比對，則認為application有效。版本2的settings page不僅可以校驗application image的CRC值，還可以校驗application/softdevice的CRC值或者hash值或者簽名，你可以選擇你自己想要的校驗方式，隻有CRC值或者hash值或者簽名校驗通過（三選其一），應用程式才算有效，這時BootLoader才會跳到application去執行。為了保證settings page在發生意外時，比如寫settings page過程中發生了複位或者掉電，系統也能正确恢複，SDK15及以後版本引入了一個backup page，backup page也占用一個Flash page，内容和settings page一模一樣。
上面是沒有觸發更新的情況下nRF52的正常啟動流程，那如果要執行DFU更新，流程又是怎麼樣的呢？下面詳細講一下無按鍵式BLE OTA的工作流程。
1) 正常啟動後，系統運作在應用程式中，此時手機通過app發送一條開始DFU的指令給裝置，裝置收到指令後，将GPREGRET1指派0xB1，并觸發軟複位
2) 複位後，系統再次進入BootLoader，因為GPREGRET1等于0xB1，BootLoader進入DFU模式，等待新固件接收
3) 手機先将init packet發送給裝置，裝置先做前期檢驗prevalidation，主要是各種版本校驗以及簽名驗簽，校驗通過後，更新settings page并準備開始資料接收
4) 接收新固件。每接收4kB資料，回複一次CRC校驗值，直至整個新固件image接收完畢，如果新固件校驗通過（版本1校驗CRC值，版本2校驗hash值），就會去invalidate（無效化） bank0裡面的老固件，更新settings page，并再次觸發軟複位
5) BootLoader啟動後發現有新固件需要activate（激活），此時會去擦掉bank0裡面的固件，并把bank1裡面的固件拷貝到bank0，然後更新settings page，并再次觸發軟複位。注：上面講的是dual bank的流程，single bank與之相似，隻不過在第3）步的時候就會去擦除老固件
6) BootLoader再次啟動後，檢查新image的有效性，校驗通過後，跳到新的application去執行代碼
從上面流程可以看出，DFU過程中，系統需要跑兩段完全獨立的代碼：Application和BootLoader，Application和BootLoader都支援藍牙功能，也就是說，兩者都有自己的藍牙廣播和藍牙連接配接。這裡面有一個問題：當系統從Application跳到BootLoader後，手機怎麼辨識兩者為同一個裝置？很多人會說，可以讓BootLoader和Application兩者的廣播名字一樣，根據廣播名字的一緻性，來判斷二者來自同一個裝置。這種方法存在兩個問題：一大部分手機都支援GATT cache（緩存）功能，當application跟手機相連後，手機會把application的GATT資料緩存下來以加快下次連接配接的速度（這個現象在蘋果手機最明顯），之後如果系統跳到BootLoader，然後再跟手機相連，如果兩者的藍牙裝置位址一樣，手機會認為是同一個裝置，進而跳過服務發現的過程而直接使用之前緩存下來的GATT資料，這樣會導緻BootLoader的服務無法被手機發現，進而出現更新失敗。二如果多個裝置同時在更新，而我們僅僅依靠廣播名字來決定兩者屬不屬于同一個裝置，這會導緻裝置A application有可能跟裝置B的BootLoader進行錯配。為了解決這個問題，Nordic提出了兩套方案。方案一，假設application的藍牙裝置位址為x，跳到BootLoader後藍牙裝置位址會變成x+1，這樣手機就可以通過這種位址+1的方式來辨識兩者屬不屬于同一個裝置，由于application和BootLoader使用不同的藍牙裝置位址，前面的GATT緩存問題也就不存在。關于方案一，有一個問題需要特别注意：如果你想修改例子預設的藍牙裝置位址（比如使用IEEE的public藍牙MAC位址），此時一定要記得同時更改application和BootLoader的藍牙裝置位址，使他們滿足+1的條件，否則Nordic手機DFU庫無法辨識兩者是否屬于同一個裝置，以緻于無法完成OTA過程。方案二，application和BootLoader的藍牙裝置位址一模一樣，但裝置跟手機執行配對和bonding操作，裝置跟手機bonding後，就可以支援service changed indicate操作，這樣跳到BootLoader後可以讓手機主動再執行一次服務發現過程，進而解決GATT緩存問題。
很多人對簽名驗簽不是很了解，這裡詳細說一下它的工作原理。首先，你需要一對公私鑰，其中私鑰用來生成新固件的簽名，公鑰用來驗證簽名的有效性，大家可以用nrfutil來生成自己需要的公私鑰對，公私鑰制作成功後，私鑰一定要妥善保管（一般放在雲端），千萬不能丢，否則你自己也無法更新自己的裝置；也不能被第三方知道，否則更新的安全性就不能保證了。公鑰可以變成一個.c檔案，并覆寫DFU工程下的同名檔案：dfu_public_key.c 。其次，BootLoader要支援簽名驗簽密碼算法，這個DFU代碼已經有了，并且有四種後端可選：micro-ecc，cc310_bl，Oberon和mbedtls，四選其一即可（這4種後端，隻有cc310是硬體實作，其餘都是軟體實作），nRF52840推薦選擇cc310作為算法後端，其他nRF52晶片推薦選擇micro-ecc作為算法後端。micro-ecc效率高，占用的代碼空間最小，但它的版權是CPOL，隻要你能接受CPOL，那麼推薦使用micro-ecc；反之，如果接受不了CPOL版權，而且硬體又不支援cc310，那麼推薦使用Oberon，不過Oberon占用的代碼空間比micro-ecc要大一些，這個大家注意一下。再次，手機端要生成新固件的簽名，并把新固件的簽名傳給裝置端。大家還是可以用nrfutil去生成新固件的簽名。最後，BootLoader接收到新固件hash值和簽名，并使用自己的公鑰對該簽名進行驗簽。這裡說一下，由于nrfutil是PC端應用程式，是以它可以內建各種加密算法庫，并完成上面提及的公私鑰對，hash和簽名的生成工作。
3. DFU更新步驟詳解
3.1 安全式藍牙空中更新步驟
如前所述，Nordic SDK已經提供了DFU例子，下面我們一步一步給大家講解如何通過Nordic SDK來實作無按鍵式藍牙空中更新。欲實作空中更新，裝置需要同時下載下傳softdevice，應用程式，BootLoader程式，以及BootLoader settings page。其中BootLoader代碼位于目錄：SDK根目錄\examples\dfu\secure_bootloader，然後在該目錄下選擇你對應的闆子和工程。Application對應的目錄：SDK根目錄\examples\ble_peripheral\ble_app_buttonless_dfu，而softdevice所在目錄：SDK根目錄\components\softdevice。
下面我們以nRF52832/PCA10040和S132/SDK16為例闡述無按鍵式藍牙空中更新實作步驟，其他晶片/softdevice/SDK原理與之類似，這裡就不再贅述。當然，不同晶片不同softdevice不同SDK，他們的實作腳本還是會有一些細微差别，是以強烈建議大家去百度網盤下載下傳跟大家相比對的腳本，百度網盤裡面各個腳本的命名規則請參考3.2節。
1) 安裝PC版nrfutil。nrfutil安裝有兩種方式，一種是直接下載下傳exe檔案，一種是以Python的方式進行安裝。nrfutil.exe直接下載下傳連結為：https://github.com/NordicSemiconductor/pc-nrfutil/releases，記得把nrfutil.exe所在目錄放在Windows環境變量中。Python方式安裝nrfutil步驟如下所示：
- 安裝Python2.7或者Python3.7，下載下傳位址：https://www.python.org/downloads/，安裝成功後請確定Windows環境變量包含Python目錄
- 通過pip安裝最新版的nrfutil，即打開Windows指令行工具CMD（管理者權限），輸入如下指令：pip install nrfutil，即可以完成nrfutil的安裝。
- 安裝完成後，在Windows指令行工具輸入：nrfutil version，如果可以正确顯示版本資訊，說明安裝已經成功
對于Windows使用者，nrfutil運作需要幾個特殊的DLL庫，而這幾個庫有些Windows機器是沒有的，如此，可往：https://www.microsoft.com/en-us/download/details.aspx?id=40784下載下傳
2) 通過nrfutil生成公私鑰對。
- 私鑰生成指令：nrfutil keys generate priv.pem （priv.pem就是私鑰）
- 公鑰生成指令：nrfutil keys display --key pk --format code priv.pem --out_file dfu_public_key.c （dfu_public_key.c就是公鑰）
- 大家務必要儲存好私鑰priv.pem，以後每次更新新固件時，都會通過這個私鑰對它進行簽名，一旦priv.pem丢失或者被暴露，DFU将無法進行或者變得不安全
3) 請確定已按照“Nordic nRF51/nRF52開發環境搭建”把Nordic nRF5 SDK開發環境搭建成功
4) 生成micro-ecc算法庫。由于micro-ecc是第三方算法庫，需要使用者自己去安裝（這個是版權的要求，沒辦法直接編譯放在SDK中）。請先確定電腦已安裝了git和GCC編譯器，然後直接點選SDK如下目錄的build_all腳本，就可以自動完成micro-ecc算法庫的安裝。為了友善一些開發者評估，我這裡在自己電腦上生成了micro-ecc算法庫，micro-ecc目錄編排結構有兩種：SDK14及以後版本是一種目錄結構（百度雲盤壓縮包名稱：micro_ecc_new.rar），SDK13和SDK12又是一種目錄結構（百度雲盤壓縮包名稱：micro_ecc_old.rar），這兩個壓縮包隻是目錄不一樣，裡面的算法庫内容其實是一樣的，這兩個壓縮包大家都可以在前面的百度雲盤中找到，以供大家評估使用。大家下載下傳下來後，直接覆寫同名目錄即可。注意：百度雲盤裡面的micro-ecc庫僅供大家評估使用，如要商用，請大家按照上面步驟去生成。
5) 編譯bootloader代碼。将剛才的dfu_public_key.c取代SDK根目錄\examples\dfu下的同名檔案，然後使用Keil編譯如下目錄中的工程：
SDK根目錄\examples\dfu\secure_bootloader\pca10040_ble\arm5_no_packs，或者nRF5SDK160098a08e2\examples\dfu\secure_bootloader\pca10040_s132_ble\arm5_no_packs
，将生成的hex檔案改名為：bootloader.hex（注：本文所有項目都會采用Keil工程來講解，如果你使用其他IDE，請選擇其對應的工程檔案進行編譯，不管是Keil還是其他IDE，除了編譯時候選擇的工程檔案不一樣，其餘都大同小異，大家可以舉一反三完成其他IDE的相應工作）
6) 編譯application代碼。請編譯工程：
SDK根目錄 \examples\ble_peripheral\ble_app_buttonless_dfu\pca10040\s132\arm5_no_packs，将生成的hex檔案改名為：app.hex
7) 生成BootLoader settings page。Bootloader settings page存儲在Flash最後一個page，如前所述，BootLoader settings page有2個版本，他們的生成腳本指令如下所示：
- 版本2生成指令：
nrfutil settings generate --family NRF52 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex - 版本1生成指令：
nrfutil settings generate --family NRF52 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex
8) 燒寫固件。将上文生成的3個hex檔案和softdevice hex檔案merge成一個檔案，然後通過nrfjprog或者nRF Connect桌面版進行燒寫，相關指令如下所示：
- 合并hex檔案指令：
mergehex --merge bootloader.hex settings.hex --output bl_temp.hex mergehex --merge bl_temp.hex app.hex s132_nrf52_7.0.1_softdevice.hex --output whole.hex - 燒寫hex檔案指令（以nrfjprog為例）：
nrfjprog --eraseall -f NRF52 nrfjprog --program whole.hex --verify -f NRF52 nrfjprog --reset -f NRF52
9) 通過nrfutil生成新固件對應的zip包：new_app.zip。zip包包含新固件（新固件廣播名改為：Nordic_New，其餘跟老固件一模一樣）和init包，zip包一般通過雲端下發到手機app，手機app再通過藍牙下載下傳到裝置中。生成zip包的指令如下所示：
nrfutil pkg generate --application app_new.hex --application-version 2 --hw-version 52 --sd-req 0xCB --key-file priv.pem SDK160_app_s132.zip 其中，--application表示新固件hex檔案。--hw-version表示闆子版本，隻要BootLoader裡面的hw version和這裡的hw version對應起來，大家可以改成任何自己想要的值。--key-file 表示簽名用的私鑰檔案。--sd-req表示老固件運作在哪個版本softdevice上，這個值一定要跟自己的softdevice相比對，否則無法更新，各個softdevice版本ID資訊可以通過指令“nrfutil pkg generate --help”獲得，如下為目前所有softdevice ID清單：
10) 将“new_app.zip”拷貝到手機上。安卓和蘋果手機都可以通過微信的‘檔案傳輸助手’拷過去，非常友善。請注意，手機nRF Connect和nRF Toolbox都支援DFU功能，蘋果手機拷貝的時候可以随便選擇其中一個app。
11) 通過手機版nRF Connect或者nRF Toolbox進行藍牙空中更新，這裡以nRF Connect為例闡述更新詳細步驟，nRF Toolbox與此類似，就不再贅述
-
- 第8）步完成後，開發闆就可以正常跑起來，并廣播為Nordic_Buttonless
-
- 連接配接該裝置，使能CCCD（這一步可選），然後選擇“DFU”，如下所示：
-
- 選擇“DFU”後，将跳出一個對話框，讓你選擇新固件對應的zip包。由于zip包放在了微信下面的download目錄下，我們需要通過檔案浏覽器找到這個zip包，大家可以先用系統自帶的檔案浏覽器打開這個zip包（如果打開失敗，那麼大家就要去下載下傳一些第三方的檔案浏覽器了，比如es explorer），相關操作界面如下所示：
-
- 一旦zip包打開成功，更新過程開始，界面如下所示：
-
- 更新成功後，裝置将運作新固件，即廣播名字将變成：Nordic_New，如下所示：
如上以nRF52832/S132為例闡述了Nordic SDK實作無按鍵式簽名式藍牙空中更新的詳細步驟，Nordic SDK有多個版本，從SDK13.0.0到現在SDK16.0.0，他們的更新步驟基本上一模一樣，大家完全可以參考上述步驟來做。SDK12更新步驟也與上述步驟基本一樣，唯一如下地方需要注意一下：
- 編譯application代碼的時候，把如下語句注掉，否則會造成BootLoader和application兩者的hex檔案相沖突
3.2節會按照上述步驟，對一些經典的安全式BLE OTA例子進行測試，并生成可直接運作的腳本，以供大家參考。
3.2 各種安全式藍牙空中更新例子
3.1節是以更新nRF52832 application為例，詳細闡述了安全式BLE OTA步驟。除了更新application，有的人還需要更新softdevice和BootLoader；除了52832，有的人還會用52840/52833/52811/52810/51822等；除了SDK16.0.0，有的人還會用SDK15.3/15.2/14.2/12.3等。為此我選了一些經典組合，将他們DFU用得的所有腳本都做好了，并進行了實際測試，有需要的可以去百度網盤下載下傳。這些腳本在百度網盤的命名規則為：安全模式_固件傳輸接口_更新哪一部分固件_SDK版本号_晶片型号.rar，比如secure_ble_S132_app_SDK160_nRF52832.rar表示采用安全簽名，固件通過BLE傳輸，BLE使用S132協定棧，更新的時候隻更新application而不更新BootLoader和SoftDevice，基于SDK16.0.0和nRF52832。
目前百度網盤上傳了如下安全式BLE OTA示例腳本（注：這些腳本都經過我的測試，全都可以直接運作）：
- secure_ble_S132_app_SDK160_nRF52832.rar
- secure_ble_S140_app_sd_bl_SDK160_nRF52840.rar
- secure_ble_S132_app_SDK153_nRF52832.rar
- secure_ble_S132_app_SDK152_nRF52832.rar
- secure_ble_S132_app_SDK150_nRF52832.rar
- secure_ble_S140_app_SDK150_nRF52840.rar
- secure_ble_S132_app_SDK142_nRF52832.rar
- secure_ble_S132_app_SDK123_nRF52832.rar
- secure_ble_S130_app_SDK123_nRF51.rar
3.3 通過UART口進行安全式固件更新示例腳本
我們以nRF52810為例來闡述如何通過UART進行安全式固件更新步驟：
1) 請參考3.1節第1）到第4）步，完成nrfutil安裝，mico-ecc算法庫生成，以及公私鑰生成
2) 編譯bootloader代碼。将剛才的dfu_public_key.c取代SDK根目錄\examples\dfu下的同名檔案，確定sdk_config.h中的NRF_BL_DFU_ENTER_METHOD_BUTTON為1，然後使用Keil編譯如下目錄中的工程：
SDK根目錄\ examples\dfu\secure_bootloader\pca10040e_uart\arm5_no_packs
，将生成的hex檔案改名為：bootloader.hex
3) 編譯application代碼。3.1節講述OTA的時候，我們選擇的例子是ble_app_buttonless_dfu，因為我們是通過藍牙給裝置發送一條指令，進而讓裝置進入DFU模式。通過序列槽更新固件，如何進入DFU模式，取決于你的應用設計，你可以采用通過發送藍牙指令讓其進入DFU模式，也可以通過上電檢測按鍵是否按下以決定是否進入DFU模式。如果想采用ble_app_buttonless_dfu作為application，那麼你需要把該工程中的main函數如下語句删掉（這些語句是為藍牙版BootLoader設計的，我們現在是UART版BootLoader，不支援這些語句）：
err_code = ble_dfu_buttonless_async_svci_init();
APP_ERROR_CHECK(err_code); 這裡我們選擇以上電檢測按鍵的方式來決定是否進入DFU模式，并以ble_app_blinky作為應用例子，請直接編譯如下工程：
SDK根目錄\examples\ble_peripheral\ble_app_blinky\pca10040e\s112\arm5_no_packs，将生成的hex檔案改名為：app.hex
4) 生成BootLoader settings page并同時燒寫老固件，輕按兩下“program.bat”即可完成，這個腳本是使用nrfjprog來完成固件燒寫的。
5) 生成新固件zip包并進行UART DFU，輕按兩下“dfu.bat”即可完成，這個腳本是使用nrfutil作為UART主機，并将新固件通過電腦COM口傳給裝置的。請記得一定要修改腳本中的UART對應的電腦COM口，否則更新無法完成。
注：所有bat腳本都可通過右鍵選擇Notepad++打開，然後檢視裡面包含的具體指令，并按照自己的需求進行修改。如需進一步了解腳本中的指令，請參考3.1節的說明。
上述所有操作步驟已打包并上傳到百度網盤，請去網盤下載下傳檔案：secure_uart_app_SDK160_nRF52810.rar，這個檔案已經過我的測試，大家可以直接使用。
3.4 通過USB口進行安全式固件更新示例腳本
我們以nRF52840為例來講述如何通過USB進行安全式固件更新，其實通過USB口更新固件步驟與3.3節的操作幾乎一模一樣，唯一不同的是，選擇如下目錄的BootLoader工程進行編譯：
SDK根目錄\ examples\dfu\secure_bootloader\pca10056_usb\arm5_no_packs
通過USB口進行安全式固件更新示例腳本已打包并上傳到百度網盤，請去網盤下載下傳檔案：
secure_usb_app_SDK160_nRF52840.rar，這個檔案已經過我的測試，大家可以直接使用。
3.5 通過USB口進行開放式固件更新示例腳本
我們還是以nRF52840為例來講述如何通過USB進行開放式固件更新，其更新步驟與3.3節的操作幾乎一模一樣，唯一不同的是，選擇如下目錄的BootLoader工程進行編譯：
SDK根目錄\ examples\dfu\open_bootloader\pca10056_usb\arm5_no_packs
相關腳本已上傳百度網盤，請下載下傳：
open_usb_app_SDK160_nRF52840.rar，這個檔案已經過我的測試，大家可以直接使用。
3.6 開放式藍牙空中更新（Legacy DFU）步驟
所謂開放式OTA，是指OTA過程中，不需要檢驗新固件的簽名，也就是說BootLoader代碼裡面不包含公鑰及相關密碼算法庫，更新的時候，隻校驗版本資訊，版本校驗通過，就可以開始更新流程。Nordic SDK目前支援兩套開放式OTA方案，一套是SDK15和SDK16提供的，一套是SDK9/SDK10/SDK11提供的。SDK15/16提供的開放式OTA工作原理和流程，與安全式OTA基本上一樣，隻不過删掉了簽名驗簽部分。SDK9/SDK10/SDK11提供的開放式OTA也叫legacy OTA DFU，它的工作流程與SDK15/16略有不同，下面将以nRF52832/S132為例，闡述如何在SDK11中實作無按鍵式開放式藍牙空中更新，詳細步驟如下所示：
1) 編譯bootloader代碼，請使用Keil編譯目錄“nRF5_SDK_11.0.0_89a8197\examples\dfu\bootloader\pca10040\dual_bank_ble_s132\arm5_no_packs”中的工程，将生成的hex檔案改名為bootloader.hex
2) 編譯application代碼，請編譯目錄“nRF5_SDK_11.0.0_89a8197\examples\ble_peripheral\ble_app_hrs\pca10040\s132_with_dfu\arm5_no_packs”中的工程，将生成的hex檔案改名為app.hex
3) 将softdevice，bootloader和app三個hex檔案合成一個檔案，指令如下所示：
mergehex --merge s132_nrf52_2.0.1_softdevice.hex app.hex bootloader.hex –output whole.hex 4) 燒寫固件到裝置中，大家可以用nRF Connect桌面版燒寫，也可以通過nrfjprog燒寫，nrfjprog燒寫指令如下所示：
nrfjprog.exe --eraseall -f NRF52
nrfjprog --program whole.hex --verify -f NRF52 5) 另外我們還需要在Flash中寫一個application有效标志位，進而上電後程式直接跑到application中去執行，而不是停留在bootloader中不出來，其對應的指令如下所示：
nrfjprog --memwr 0x0007F000 --val 0x01 --verify -f NRF52 6) 用老版本的nrfutil生成新固件對應的zip包。該zip包除了包含新固件image，還包含一些配置資訊。更新時，zip包會通過雲端下發到手機端app，手機端app再把zip包傳給藍牙裝置以進行固件更新。請使用老版本nrfutil（版本号0.3.0）來生成該zip包，老版本nrfutil跟随nRFgo studio一起安裝的，隻要你安裝了nRFgo studio，老版本nrfutil就會自動安裝好，并放在目錄“C:\Program Files (x86)\Nordic Semiconductor\nRFgo Studio”中。生成zip包對應的指令如下所示：
nrfutil dfu genpkg --application app_new.hex --application-version 1 SDK110_app_s132.zip 7) 把上述的‘SDK110_app_s132.zip’拷到手機中，安卓和蘋果手機都可以通過微信的‘檔案傳輸助手’拷過去，非常友善。注：手機nRF Connect和nRF Toolbox都支援DFU功能，蘋果手機拷貝的時候可以随便選擇其中一個app。
8) 使用nRF Connect或者nRF Toolbox來完成DFU過程。這裡以nRF Connect為例來闡述整個更新過程。
- 成功執行完第5）步後，如果開發闆運作正常，那麼它将進行廣播，廣播名字為：Nordic_HRM
- 連接配接該裝置，并使能CCCD，然後選擇“DFU”
- 選擇“DFU”後，将跳出一個對話框，讓你選擇新固件對應的zip包。由于zip包放在了微信下面的download目錄下，我們需要通過檔案浏覽器找到這個zip包，大家可以先用系統自帶的檔案浏覽器打開這個zip包（如果打開失敗，那麼大家就要去下載下傳一些第三方的檔案浏覽器了，比如es explorer），相關操作界面如下所示：
- 一旦zip包打開成功，更新過程開始，界面如下所示：
- 更新成功，裝置将自動啟動，此時你會看到新固件已經在運作，廣播名字也變成了：Nordic_HRM_new，如下所示：
目前百度網盤上傳了如下開放式BLE OTA示例腳本（注：這些腳本都經過我的測試，全都可以直接運作）：
- open_ble_S132_app_SDK110_nRF52832.rar
- open_ble_S130_app_SDK110_nRF51.rar
如果你的應用是基于SDK11開發的，并且需要內建DFU功能，請參考上述例子ble_app_hrs來移植DFU功能，主要工作包括兩部分：一把BLE_DFU_APP_SUPPORT這個宏包括的所有代碼拷到你的工程中，二如果你的裝置支援bonding的話，還需把Device manager相關代碼也拷到你的工程中，如此即可完成DFU功能的移植。
4. 詳解如何移植DFU功能到ble_app_uart
為了讓SDK14及以後版本的ble_app_uart具有DFU功能，有2種做法，一是把NUS服務移植到ble_app_buttonless_dfu中，這種方法相對來說更簡單，大家可以自己去實踐一下；二是把DFU服務移植到ble_app_uart中，這種移植方式挑戰更大，但更有利于我們了解DFU的工作原理，我們現在就來闡述如何給ble_app_uart加上OTA功能。如前所述，OTA過程中，手機跟裝置可以進行配對和bonding，也可以用明文進行藍牙通信。配對bonding的時候，我們可以讓BootLoader和application共享bonding資訊，也可以隻讓application進行配對bonding，而BootLoader還是以明文方式進行藍牙通信。
Nordic已經把DFU服務做成了一個子產品，大家隻要把這個子產品加到自己的應用中，然後完成一些必須的配置，初始化以及回調函數的撰寫，再加上把SVCI子產品（SVCI子產品主要用來修改BootLoader的一些配置參數）加入到應用中移植即可大功告成。在SDK中，DFU服務的名字是：BLE_DFU_SERVICE，這個服務放在檔案ble_dfu.c中，而ble_dfu.c又有兩個後端實作：ble_dfu_unbonded.c和ble_dfu_bonded.c，分别對應無bonding明文藍牙連接配接和有bonding的藍牙連接配接，下面也将分這兩種情況詳細闡述移植過程。
4.1 明文正常連接配接OTA（無bonding）
1) 用Keil打開如下工程：SDK根目錄\examples\ble_peripheral\ble_app_uart\pca10040\s132\arm5_no_packs
2) 添加DFU服務有關的檔案，目錄和宏定義。首先添加如下DFU目錄及相關檔案：
在define中添加這些宏：DEBUG DFU_SUPPORT BL_SETTINGS_ACCESS_ONLY NRF_DFU_SVCI_ENABLED NRF_DFU_TRANSPORT_BLE=1，其中DEBUG宏隻是為了調試友善而設定的，跟DFU本身無關。DFU_SUPPORT是我用來控制我添加的DFU代碼的，删掉DFU_SUPPORT，将不編譯所有DFU有關代碼。其餘的宏都是系統自帶的，如果要支援DFU，就必須要添加。
然後包含如下目錄：
3) 修改sdk_config.h檔案。首先我們需要使能BLE_DFU子產品，及選擇OTA藍牙連接配接方式，如下為使用明文進行藍牙通信的配置：
#define BLE_DFU_ENABLED 1
#define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 0 同時我們還需要修改softdevice配置。現在整個應用包括2個供應商自定義UUID：NUS和DFU（其實這兩個UUID可以合成一個，但由于曆史原因，DFU和NUS分别使用了兩個不同的vs UUID），相應地ATT table size也要變大，然後應用程式RAM起始位址也需要跟着變，如下（注：這裡的NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 設定得稍稍偏大）：
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1600
#define NRF_SDH_BLE_VS_UUID_COUNT 2 修改應用程式RAM起始位址，如下：
4) 修改main.c檔案。首先添加如下頭檔案：
#include "ble_dfu.h"
#include "nrf_bootloader_info.h"
#include "nrf_power.h" 然後在main函數的開始處，添加修改BootLoader廣播名字的代碼，這一行代碼是可選的，如果想改掉BootLoader預設的廣播名字，就需要它；反之就不需要：
err_code = ble_dfu_buttonless_async_svci_init();
APP_ERROR_CHECK(err_code); 然後在services_init()中添加ble dfu服務
dfus_init.evt_handler = ble_dfu_evt_handler;
err_code = ble_dfu_buttonless_init(&dfus_init);
APP_ERROR_CHECK(err_code); ble_dfu_evt_handler回調函數的撰寫，大家隻要按照要求來，就沒問題，如果應用隻支援一個連接配接，那麼ble_dfu_evt_handler可以直接為空。如果應用支援多個連接配接，可以參考ble_app_buttonless_dfu做法，這裡就不貼代碼了。
5) 在跳轉到bootloader之前，如果你想做一些專門的代碼處理，比如完成pending的Flash操作，比如關閉某些子產品，那麼你可以注冊一個app_shutdown_handler來做這些工作。（注：這一步不是必須的，是可選的！）
NRF_PWR_MGMT_HANDLER_REGISTER(app_shutdown_handler, 0); 6) （這一步可選）之前的ble_app_uart是沒有BootLoader的，是以啟動起來非常快。現在加了BootLoader代碼，為了加快system off喚醒的速度，可以定義如下語句，
nrf_power_gpregret2_set(BOOTLOADER_DFU_SKIP_CRC); 然後先disable softdevice，然後再進入system off模式。這一步本身跟DFU沒有什麼關系，主要是為了加快程式啟動速度而另加的。
7) 編譯工程，并将生成的hex檔案改名為“app.hex”
8) 然後按照3.1節的步驟一步一步完成後續的DFU過程。
4.2 bonding連接配接OTA
4.1節的工程已經移植了DFU功能，現在我們再把bonding功能移植到4.1節工程上，就可以讓我們的應用同時支援DFU和bonding。Bonding功能是通過peer_manager子產品來實作的，大家隻要把peer_manager有關的檔案添加進來，就可以實作bonding的目标。
1) 打開4.1節的工程
2) 添加如下檔案：
3) 修改sdk_config.h檔案，需要修改多個地方，如下：
#define PEER_MANAGER_ENABLED 1
#define FDS_ENABLED 1
#define NRF_SDH_BLE_SERVICE_CHANGED 1
#define NRF_FSTORAGE_ENABLED 1
#define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 1 當NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS設為1時，表示application将與主機進行bonding，同時該bonding資訊将共享給BootLoader，也就是說，進入bootloader模式後，主機将使用以前的bonding資訊與裝置進行加密連接配接。
4) 在main.c檔案開頭，包含如下頭檔案：
#include "peer_manager.h" 5) 在main函數中添加peer_manager_init()，其定義如下所示：
static void peer_manager_init()
{
ble_gap_sec_params_t sec_param;
ret_code_t err_code;
err_code = pm_init();
APP_ERROR_CHECK(err_code);
memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));
// Security parameters to be used for all security procedures.
sec_param.bond = SEC_PARAM_BOND;
sec_param.mitm = SEC_PARAM_MITM;
sec_param.lesc = SEC_PARAM_LESC;
sec_param.keypress = SEC_PARAM_KEYPRESS;
sec_param.io_caps = SEC_PARAM_IO_CAPABILITIES;
sec_param.oob = SEC_PARAM_OOB;
sec_param.min_key_size = SEC_PARAM_MIN_KEY_SIZE;
sec_param.max_key_size = SEC_PARAM_MAX_KEY_SIZE;
sec_param.kdist_own.enc = 1;
sec_param.kdist_own.id = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id = 1;
err_code = pm_sec_params_set(&sec_param);
APP_ERROR_CHECK(err_code);
err_code = pm_register(pm_evt_handler);
APP_ERROR_CHECK(err_code);
} 添加pm_evt_handler定義，代碼如下所示：
static void pm_evt_handler(pm_evt_t const * p_evt)
{
pm_handler_on_pm_evt(p_evt);
pm_handler_flash_clean(p_evt);
} 6) 在ble_evt_handler中删除BLE_GAP_EVT_SEC_PARAMS_REQUEST分支，因為這個分支在peer_manager子產品中已經進行處理了，這裡再處理一次，會産生異常：
// case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
// // Pairing not supported
// err_code = sd_ble_gap_sec_params_reply(m_conn_handle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
// APP_ERROR_CHECK(err_code);
// break; 7) 修改advertising_start定義，增加删除bonding資訊功能（如果你不需要這個功能，也可以不改）
8) （此步可選）一般來說，如果使用者在手機端把配對資訊删掉了，為了安全起見，裝置端也需要把相關配對資訊清掉，然後才可以允許手機和裝置再次進行配對和bonding。如何觸發裝置端bonding資訊的删除操作？可以通過按鍵檢測的方式來做，比如目前我們這個例子的做法。但是有很多裝置沒有按鍵，而且很多人希望這種二次配對的操作對使用者來說無感，即哪怕使用者删掉了手機端配對資訊，如果使用者想發起第二次配對請求，裝置也能接受，而且操作過程跟使用者第一次發起配對請求的過程一模一樣。Nordic SDK其實是相容這種操作的，使用者隻需在pm_evt_handler()中添加如下代碼即可：
if (p_evt->evt_id == PM_EVT_CONN_SEC_CONFIG_REQ)
{
pm_conn_sec_config_t cfg;
cfg.allow_repairing = true;
pm_conn_sec_config_reply(p_evt->conn_handle, &cfg);
} 9) 上述所有代碼都包括在“BONDING_SUPPORT”宏中。
10) 編譯工程，将生成的hex檔案改名為app.hex
11) 然後按照3.1節步驟來執行OTA過程，不過如下幾點需要注意：
-
- 如果你在應用中把NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS設為1，那麼bootloader代碼就不能采用預設配置，請修改bootloader工程中的sdk_config.h檔案中的如下宏定義，然後重新編譯生成新的bootloader.hex。
#define NRF_DFU_BLE_REQUIRES_BONDS 1
#define NRF_SDH_BLE_SERVICE_CHANGED 1 -
- 在nRF Connect中勾選“keep bond information”選項，如下：
-
- 手機連接配接裝置成功後，請手動使能CCCD，以讓手機自動發起bonding請求
-
- DFU更新成功後，裝置将會與手機自動重連，此時需點選“Refresh services”，以獲得裝置最新服務清單，如下：
上述代碼工程我已打包成：ble_app_uart_ota_SDK16_0_0.rar，并上傳到百度網盤，大家下載下傳下來解壓縮到：SDK根目錄\examples\ble_peripheral這個目錄下，就可以直接編譯和運作。DFU過程中用到的所有腳本我也幫大家做好了，大家可以直接下載下傳下來使用，其中secure_ble_S132_uart_SDK160_nRF52832_Nobonding.rar對應明文藍牙傳輸，secure_ble_S132_uart_SDK160_nRF52832_bonding.rar對應bonding藍牙傳輸。
5 手機端DFU參考代碼
Nordic不僅提供DFU裝置端的參考代碼，同時提供手機端的參考代碼。Nordic分别開發了Android版和iOS版的DFU庫，大家可以直接拿過來使用，內建到自己的移動端app中，這兩個庫都放在github上，連結如下所示：
- Android版DFU庫：https://github.com/NordicSemiconductor/Android-DFU-Library
- iOS版DFU庫：https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library
Nordic還提供了一個移動端app：nRF Toolbox，nRF Toolbox是代碼開源的，裡面也內建了上面提到的DFU庫，大家可以參考nRF Toolbox來開發自己的移動端app。nRF Toolbox源碼也可以在github上找到：
- Android版nRF Toolbox源代碼及開發說明請參考：https://github.com/NordicSemiconductor/Android-nRF-Toolbox
- iOS版nRF Toolbox源代碼及開發說明請參考：https://github.com/NordicSemiconductor/IOS-nRF-Toolbox
nRF Toolbox軟體界面如下所示：