详解蓝牙空中升级(BLE OTA)原理与步骤
如何實現BLE OTA？什么叫DFU？如何通過UART實現固件升級？又如何通過USB實現固件升級？怎么保證升級的安全性？什么叫雙區（dual bank）DFU？什么叫單區（single bank）DFU？什么叫后臺式（background）DFU？本文將對上述問題進行探討。
DFU過程中涉及的所有操作步驟所對應的腳本都放在百度云盤上，云盤鏈接如下所示：
鏈接:https://pan.baidu.com/s/1FKTfY3Q_zBVvviO7KC7Gyg密碼: 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根目錄examplesdfusecure_bootloader，然后在該目錄下選擇你對應的板子和工程。Application對應的目錄：SDK根目錄examplesle_peripheralle_app_buttonless_dfu，而softdevice所在目錄：SDK根目錄componentssoftdevice。
下面我們以nRF52832/PCA10040和S132為例闡述無按鍵式藍牙空中升級實現步驟：
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根目錄examplesdfu下的同名文件，然后使用Keil編譯如下目錄中的工程：
SDK根目錄examplesdfusecure_bootloaderpca10040_blearm5_no_packs，或者nRF5SDK160098a08e2examplesdfusecure_bootloaderpca10040_s132_blearm5_no_packs
，將生成的hex文件改名為：bootloader.hex（注：本文所有項目都會采用Keil工程來講解，如果你使用其他IDE，請選擇其對應的工程文件進行編譯，不管是Keil還是其他IDE，除了編譯時候選擇的工程文件不一樣，其余都大同小異，大家可以舉一反三完成其他IDE的相應工作）
6) 編譯application代碼。請編譯工程：
SDK根目錄 examplesle_peripheralle_app_buttonless_dfupca10040s132arm5_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根目錄examplesdfu下的同名文件，確保sdk_config.h中的NRF_BL_DFU_ENTER_METHOD_BUTTON為1，然后使用Keil編譯如下目錄中的工程：
SDK根目錄 examplesdfusecure_bootloaderpca10040e_uartarm5_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根目錄examplesle_peripheralle_app_blinkypca10040es112arm5_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根目錄 examplesdfusecure_bootloaderpca10056_usbarm5_no_packs
通過USB口進行安全式固件升級示例腳本已打包并上傳到百度網盤，請去網盤下載文件：
secure_usb_app_SDK160_nRF52840.rar，這個文件已經過我的測試，大家可以直接使用。
3.5 通過USB口進行開放式固件升級示例腳本
我們還是以nRF52840為例來講述如何通過USB進行開放式固件升級，其升級步驟與3.3節的操作幾乎一模一樣，唯一不同的是，選擇如下目錄的BootLoader工程進行編譯：
SDK根目錄 examplesdfuopen_bootloaderpca10056_usbarm5_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_89a8197examplesdfuootloaderpca10040dual_bank_ble_s132arm5_no_packs”中的工程，將生成的hex文件改名為bootloader.hex
2) 編譯application代碼，請編譯目錄“nRF5_SDK_11.0.0_89a8197examplesle_peripheralble_app_hrspca10040s132_with_dfuarm5_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
RFgo 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根目錄examplesle_peripheralle_app_uartpca10040s132arm5_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根目錄examplesle_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軟件界面如下所示：
總結
以上是生活随笔為你收集整理的详解蓝牙空中升级(BLE OTA)原理与步骤的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 临床基本概念 | 单臂双臂三臂临床试验
- 下一篇： excel SUBTOTAL函数使用详解