如何實(shí)現(xiàn)BLE OTA？什么叫DFU？如何通過UART實(shí)現(xiàn)固件升級(jí)？又如何通過USB實(shí)現(xiàn)固件升級(jí)？怎么保證升級(jí)的安全性？什么叫雙區(qū)（dual bank）DFU？什么叫單區(qū)（single bank）DFU？什么叫后臺(tái)式（background）DFU？本文將對上述問題進(jìn)行探討。

腳本是按照SDK版本進(jìn)行分類的，建議大家把自己SDK版本對應(yīng)的腳本下載下來，然后跟著第3章的操作步驟一步一步去實(shí)現(xiàn)自己的DFU。

1. 概述

所謂DFU（Device Firmware Update），就是設(shè)備固件升級(jí)的意思，而OTA（Over The Air）是實(shí)現(xiàn)DFU的一種方式而已，準(zhǔn)確說，OTA的全稱應(yīng)該是OTA DFU，即通過空中無線方式實(shí)現(xiàn)設(shè)備固件升級(jí)。只不過大家為了方便起見，直接用OTA來指代固件空中升級(jí)（有時(shí)候大家也將OTA稱為FOTA，即Firmware OTA，這種稱呼意思更明了一些）。只要是通過無線通信方式實(shí)現(xiàn)DFU的，都可以叫OTA，比如2G/3G/4G/WiFi/藍(lán)牙/NFC/Zigbee，他們都支持OTA。DFU除了可以通過無線方式（OTA）進(jìn)行升級(jí)，也可以通過有線方式進(jìn)行升級(jí)，比如通過UART，USB或者SPI通信接口來升級(jí)設(shè)備固件。
不管采用OTA方式還是有線通信方式，DFU包括后臺(tái)式（background）和非后臺(tái)式兩種模式。

后臺(tái)式DFU，又稱靜默式DFU（Silent DFU），在升級(jí)的時(shí)候，新固件在后臺(tái)悄悄下載，即新固件下載屬于應(yīng)用程序功能的一部分，在新固件下載過程中，應(yīng)用可以正常使用，也就是說整個(gè)下載過程對用戶來說是無感的，下載完成后，系統(tǒng)再跳到BootLoader模式，由BootLoader完成新固件覆蓋老固件的操作，至此整個(gè)升級(jí)過程結(jié)束。比如智能手機(jī)升級(jí)Android或者iOS系統(tǒng)都是采用后臺(tái)式DFU方式，新系統(tǒng)下載過程中，手機(jī)可以正常使用哦。非后臺(tái)式DFU，在升級(jí)的時(shí)候，系統(tǒng)需要先從應(yīng)用模式跳入到BootLoader模式，由BootLoader進(jìn)行新固件下載工作，下載完成后BootLoader繼續(xù)完成新固件覆蓋老固件的操作，至此升級(jí)結(jié)束。早先的功能機(jī)就是采用非后臺(tái)式DFU來升級(jí)操作系統(tǒng)的，即用戶需要先長按某些按鍵進(jìn)入bootloader模式，然后再進(jìn)行升級(jí)，整個(gè)升級(jí)過程中手機(jī)正常功能都無法使用。 下面再講雙區(qū)DFU（dual bank）和單區(qū)DFU（single bank），雙區(qū)或者單區(qū)DFU是新固件和老固件覆蓋的兩種方式。后臺(tái)式DFU必須采用雙區(qū)模式進(jìn)行升級(jí)，即老系統(tǒng)（老固件）和新系統(tǒng)（新固件）各占一塊bank（存儲(chǔ)區(qū)），假設(shè)老固件放在bank0中，新固件放在bank1中，升級(jí)的時(shí)候，應(yīng)用程序先把新固件下載到bank1中，只有當(dāng)新固件下載完成并校驗(yàn)成功后，系統(tǒng)才會(huì)跳入BootLoader模式，然后擦除老固件所在的bank0區(qū)，并把新固件拷貝到bank0中。非后臺(tái)式DFU可以采用雙區(qū)也可以采用單區(qū)模式，與后臺(tái)式DFU相似，雙區(qū)模式下新老固件各占一塊bank（老固件為bank0，新固件為bank1），升級(jí)時(shí)，系統(tǒng)先跳入BootLoader模式，然后BootLoader程序把新固件下載到bank1中，只有新固件下載完成并校驗(yàn)成功后，才會(huì)去擦除老固件所在的bank0區(qū)，并把新固件拷貝到bank0區(qū)。單區(qū)模式的非后臺(tái)式DFU只有一個(gè)bank0，老固件和新固件分享這一個(gè)bank0，升級(jí)的時(shí)候，進(jìn)入bootloader模式后立馬擦除老固件，然后直接把新固件下載到同一個(gè)bank中，下載完成后校驗(yàn)新固件的有效性，新固件有效升級(jí)完成，否則要求重來。跟非后臺(tái)式DFU雙區(qū)模式相比，單區(qū)模式節(jié)省了一個(gè)bank的Flash空間，在系統(tǒng)資源比較緊張的時(shí)候，單區(qū)模式是一個(gè)不錯(cuò)的選擇。不管是雙區(qū)模式還是單區(qū)模式，升級(jí)過程出現(xiàn)問題后，都可以進(jìn)行二次升級(jí)，都不會(huì)出現(xiàn)“變磚”情況。不過雙區(qū)模式有一個(gè)好處，如果升級(jí)過程中出現(xiàn)問題或者新固件有問題，它還可以選擇之前的老固件老系統(tǒng)繼續(xù)執(zhí)行而不受其影響。而單區(qū)模式碰到這種情況就只能一直待在bootloader中，然后等待二次或者多次升級(jí)嘗試，此時(shí)設(shè)備的正常功能已無法使用，從用戶使用這個(gè)角度來說，你的確可以說此時(shí)設(shè)備已經(jīng)“變磚”了。所以說，雖然雙區(qū)模式犧牲了很多存儲(chǔ)空間，但是換來了更好的升級(jí)體驗(yàn)。

可參考下面三個(gè)圖來理解上述過程

如果你是第一次接觸Nordic nRF5 SDK，那么建議你先看一下這篇文章：開發(fā)你的第一個(gè)BLE應(yīng)用程序—Blinky (https://www.cnblogs.com/iini/p/8996025.html)，或者看一下這一篇文章：手把手教你開發(fā)BLE數(shù)據(jù)透傳應(yīng)用程序，以建立Nordic nRF5 SDK的一些基本知識(shí)，然后再往下看以下章節(jié)。

2. Nordic nRF5 SDK DFU工作原理

如文章“nRF5 SDK軟件架構(gòu)及softdevice工作原理” 所述，Nordic nRF5 SDK軟件架構(gòu)跟其他家有點(diǎn)不一樣，程序存儲(chǔ)區(qū)最開始部分放得不是Bootloader，而是藍(lán)牙協(xié)議棧Softdevice，應(yīng)用程序則緊挨著Softdevice，Bootloader則被nRF5 SDK放在程序存儲(chǔ)區(qū)的最上面，整個(gè)存儲(chǔ)區(qū)結(jié)構(gòu)圖如下所示。如果用戶還有Flash數(shù)據(jù)需要存放，那么這些數(shù)據(jù)緊挨著BootLoader下面。

目前Nordic SDK默認(rèn)只提供非后臺(tái)式DFU開箱即用的例子（SDK16.0開始也支持后臺(tái)式DFU框架），即系統(tǒng)必須先跳到BootLoader中，然后才能通過BLE/UART/USB去接收新的固件。如上所示，如果采用雙區(qū)模式DFU，那么Bank0放的是應(yīng)用程序，即老固件，Bank1放的是新固件。平時(shí)，Bank1為空或者忽略，系統(tǒng)只跑Bank0里面的應(yīng)用程序；升級(jí)的時(shí)候，先跳到BootLoader，然后接收新固件并把它放在Bank1中，最后把Bank1里面的固件拷貝到Bank0中。如果采用單區(qū)模式，則沒有Bank1這個(gè)區(qū)。平時(shí)，系統(tǒng)只跑Bank0里面的代碼；升級(jí)的時(shí)候，跳到BootLoader，先擦除Bank0里面的老程序，并把新固件直接放在Bank0中。 根據(jù)升級(jí)時(shí)如何跳轉(zhuǎn)到Bootloader，Nordic SDK又將DFU分為按鍵式DFU和非按鍵式（Buttonless）DFU，所謂按鍵式DFU，就是上電時(shí)長按某個(gè)按鍵以進(jìn)入bootloader模式，而非按鍵式DFU，就是整個(gè)DFU過程中設(shè)備端無任何人工干預(yù)，通過BLE/UART/USB接口給應(yīng)用程序發(fā)送一條指令，應(yīng)用程序收到指令后再自動(dòng)跳入bootloader模式。不管是按鍵式DFU還是非按鍵式DFU，兩者只是進(jìn)入BootLoader的方式不一樣，其余基本一樣，尤其是BootLoader工作過程基本上是一模一樣的。后面只會(huì)闡述非按鍵式DFU的過程，按鍵式DFU以此類似，就不再贅述。 程序跳到BootLoader后，根據(jù)BootLoader需不需要對新固件進(jìn)行驗(yàn)簽，Nordic SDK又把DFU分為開放式DFU和安全式DFU（又稱簽名DFU）。開放式DFU，BootLoader不做任何驗(yàn)證，直接把新固件接收下來。安全式DFU，BootLoader存有一把公鑰，BootLoader會(huì)先用這把公鑰驗(yàn)證新固件的簽名，只有驗(yàn)簽通過，才允許后續(xù)的工作：比如把新固件接收下來；如果驗(yàn)簽失敗，BootLoader將拒絕升級(jí)，重新跳回應(yīng)用程序。 BootLoader可以通過不同的通信接口來接收新的固件，目前Nordic SDK支持BLE，UART和USB三種接口，所以大家可以在Nordic SDK中看到如下三種工程目錄：

其中pca0056表示nRF52840對應(yīng)的開發(fā)板編號(hào)，S140對應(yīng)Softdevice的型號(hào)，然后ble有兩個(gè)目錄：無debug和有debug，uart和usb也包含同樣的兩個(gè)目錄。有debug和無debug兩者功能是一樣的，兩者的區(qū)別是：debug版本BootLoader支持日志打印（大家可以通過打印出的日志去理解BootLoader的工作過程），并可以忽略各種校驗(yàn)，debug版本占據(jù)的代碼空間要大很多；無debug版本BootLoader不支持日志打印功能并且版本和有效性校驗(yàn)是強(qiáng)制的。正式量產(chǎn)的時(shí)候推薦使用無debug版本以節(jié)省代碼空間。這里要強(qiáng)調(diào)一下，不管是debug版本還是無debug版本，兩者都可以用Keil進(jìn)行單步和斷點(diǎn)調(diào)試。 BLE，UART和USB只是通信方式不一樣，他們遵守的DFU流程是一模一樣的，這里會(huì)以BLE通信接口為例，詳細(xì)闡述DFU過程，UART和USB與之類似，就不再贅述。 講述DFU升級(jí)之前，先講一下nRF52的啟動(dòng)流程，上電后，系統(tǒng)先執(zhí)行softdevice，softdevice通過讀取UICR一個(gè)寄存器的值，來判斷目前系統(tǒng)是否有BootLoader，如果沒有BootLoader，系統(tǒng)直接跳到application；如果有BootLoader，系統(tǒng)先跳到BootLoader，BootLoader再根據(jù)目前的情況來決定是進(jìn)入升級(jí)模式還是跳往application，BootLoader主要判斷如下幾種情況：

如果按鍵沒有按下，GPREGRET1不為0xB1，本次復(fù)位不是上次DFU的繼續(xù)，并且應(yīng)用程序校驗(yàn)通過，那么BootLoader就會(huì)直接跳到application，去執(zhí)行application應(yīng)用程序。那怎么去校驗(yàn)應(yīng)用程序的有效性呢？為此BootLoader引入了一個(gè)放在Flash的結(jié)構(gòu)體參數(shù)：m_dfu_settings_buffer（數(shù)據(jù)類型：nrf_dfu_settings_t），這個(gè)結(jié)構(gòu)體參數(shù)雖然只有896字節(jié)，但由于Flash只能按頁擦除，所以這個(gè)參數(shù)實(shí)際占用了一個(gè)Flash page，這個(gè)page稱為settings page，settings page目前有2個(gè)版本：版本1（SDK15.2及以前版本）和版本2（SDK15.3及以后版本），版本2可以兼容版本1，前面所述的896字節(jié)是指settings page版本2的大小。Settings page包含的信息比較多，大家用得比較多的是：

版本1的settings page只校驗(yàn)application image的CRC值，如果CRC匹配，則認(rèn)為application有效。版本2的settings page不僅可以校驗(yàn)application image的CRC值，還可以校驗(yàn)application/softdevice的CRC值或者h(yuǎn)ash值或者簽名，你可以選擇你自己想要的校驗(yàn)方式，只有CRC值或者h(yuǎn)ash值或者簽名校驗(yàn)通過（三選其一），應(yīng)用程序才算有效，這時(shí)BootLoader才會(huì)跳到application去執(zhí)行。為了保證settings page在發(fā)生意外時(shí)，比如寫settings page過程中發(fā)生了復(fù)位或者掉電，系統(tǒng)也能正確恢復(fù)，SDK15及以后版本引入了一個(gè)backup page，backup page也占用一個(gè)Flash page，內(nèi)容和settings page一模一樣。 上面是沒有觸發(fā)升級(jí)的情況下nRF52的正常啟動(dòng)流程，那如果要執(zhí)行DFU升級(jí)，流程又是怎么樣的呢？下面詳細(xì)講一下無按鍵式BLE OTA的工作流程。

正常啟動(dòng)后，系統(tǒng)運(yùn)行在應(yīng)用程序中，此時(shí)手機(jī)通過app發(fā)送一條開始DFU的指令給設(shè)備，設(shè)備收到指令后，將GPREGRET1賦值0xB1，并觸發(fā)軟復(fù)位

復(fù)位后，系統(tǒng)再次進(jìn)入BootLoader，因?yàn)镚PREGRET1等于0xB1，BootLoader進(jìn)入DFU模式，等待新固件接收

手機(jī)先將init packet發(fā)送給設(shè)備，設(shè)備先做前期檢驗(yàn)prevalidation，主要是各種版本校驗(yàn)以及簽名驗(yàn)簽，校驗(yàn)通過后，更新settings page并準(zhǔn)備開始數(shù)據(jù)接收

接收新固件。每接收4kB數(shù)據(jù)，回復(fù)一次CRC校驗(yàn)值，直至整個(gè)新固件image接收完畢，如果新固件校驗(yàn)通過（版本1校驗(yàn)CRC值，版本2校驗(yàn)hash值），就會(huì)去invalidate（無效化）bank0里面的老固件，更新settings page，并再次觸發(fā)軟復(fù)位

BootLoader啟動(dòng)后發(fā)現(xiàn)有新固件需要activate（激活），此時(shí)會(huì)去擦掉bank0里面的固件，并把bank1里面的固件拷貝到bank0，然后更新settings page，并再次觸發(fā)軟復(fù)位。注：上面講的是dualbank的流程，single bank與之相似，只不過在第3）步的時(shí)候就會(huì)去擦除老固件

BootLoader再次啟動(dòng)后，檢查新image的有效性，校驗(yàn)通過后，跳到新的application去執(zhí)行代碼

從上面流程可以看出，DFU過程中，系統(tǒng)需要跑兩段完全獨(dú)立的代碼：Application和BootLoader，Application和BootLoader都支持藍(lán)牙功能，也就是說，兩者都有自己的藍(lán)牙廣播和藍(lán)牙連接。這里面有一個(gè)問題：當(dāng)系統(tǒng)從Application跳到BootLoader后，手機(jī)怎么辨別兩者為同一個(gè)設(shè)備？很多人會(huì)說，可以讓BootLoader和Application兩者的廣播名字一樣，根據(jù)廣播名字的一致性，來判斷二者來自同一個(gè)設(shè)備。這種方法存在兩個(gè)問題：一大部分手機(jī)都支持GATT cache（緩存）功能，當(dāng)application跟手機(jī)相連后，手機(jī)會(huì)把a(bǔ)pplication的GATT數(shù)據(jù)緩存下來以加快下次連接的速度（這個(gè)現(xiàn)象在蘋果手機(jī)最明顯），之后如果系統(tǒng)跳到BootLoader，然后再跟手機(jī)相連，如果兩者的藍(lán)牙設(shè)備地址一樣，手機(jī)會(huì)認(rèn)為是同一個(gè)設(shè)備，從而跳過服務(wù)發(fā)現(xiàn)的過程而直接使用之前緩存下來的GATT數(shù)據(jù)，這樣會(huì)導(dǎo)致BootLoader的服務(wù)無法被手機(jī)發(fā)現(xiàn)，從而出現(xiàn)升級(jí)失敗。二如果多個(gè)設(shè)備同時(shí)在升級(jí)，而我們僅僅依靠廣播名字來決定兩者屬不屬于同一個(gè)設(shè)備，這會(huì)導(dǎo)致設(shè)備A application有可能跟設(shè)備B的BootLoader進(jìn)行錯(cuò)配。為了解決這個(gè)問題，Nordic提出了兩套方案。方案一，假設(shè)application的藍(lán)牙設(shè)備地址為x，跳到BootLoader后藍(lán)牙設(shè)備地址會(huì)變成x+1，這樣手機(jī)就可以通過這種地址+1的方式來辨別兩者屬不屬于同一個(gè)設(shè)備，由于application和BootLoader使用不同的藍(lán)牙設(shè)備地址，前面的GATT緩存問題也就不存在。關(guān)于方案一，有一個(gè)問題需要特別注意：如果你想修改例子默認(rèn)的藍(lán)牙設(shè)備地址（比如使用IEEE的public藍(lán)牙MAC地址），此時(shí)一定要記得同時(shí)更改application和BootLoader的藍(lán)牙設(shè)備地址，使他們滿足+1的條件，否則Nordic手機(jī)DFU庫無法辨別兩者是否屬于同一個(gè)設(shè)備，以致于無法完成OTA過程。方案二，application和BootLoader的藍(lán)牙設(shè)備地址一模一樣，但設(shè)備跟手機(jī)執(zhí)行配對和bonding操作，設(shè)備跟手機(jī)bonding后，就可以支持service changed indicate操作，這樣跳到BootLoader后可以讓手機(jī)主動(dòng)再執(zhí)行一次服務(wù)發(fā)現(xiàn)過程，從而解決GATT緩存問題。 很多人對簽名驗(yàn)簽不是很理解，這里詳細(xì)說一下它的工作原理。首先，你需要一對公私鑰，其中私鑰用來生成新固件的簽名，公鑰用來驗(yàn)證簽名的有效性，大家可以用nrfutil來生成自己需要的公私鑰對，公私鑰制作成功后，私鑰一定要妥善保管（一般放在云端），千萬不能丟，否則你自己也無法升級(jí)自己的設(shè)備；也不能被第三方知道，否則升級(jí)的安全性就不能保證了。公鑰可以變成一個(gè).c文件，并覆蓋DFU工程下的同名文件：dfu_public_key.c 。其次，BootLoader要支持簽名驗(yàn)簽密碼算法，這個(gè)DFU代碼已經(jīng)有了，并且有四種后端可選：micro-ecc，cc310_bl，Oberon和mbedtls，四選其一即可（這4種后端，只有cc310是硬件實(shí)現(xiàn)，其余都是軟件實(shí)現(xiàn)），nRF52840推薦選擇cc310作為算法后端，其他nRF52芯片推薦選擇micro-ecc作為算法后端。micro-ecc效率高，占用的代碼空間最小，但它的版權(quán)是CPOL，只要你能接受CPOL，那么推薦使用micro-ecc；反之，如果接受不了CPOL版權(quán)，而且硬件又不支持cc310，那么推薦使用Oberon，不過Oberon占用的代碼空間比micro-ecc要大一些，這個(gè)大家注意一下。再次，手機(jī)端要生成新固件的簽名，并把新固件的簽名傳給設(shè)備端。大家還是可以用nrfutil去生成新固件的簽名。最后，BootLoader接收到新固件hash值和簽名，并使用自己的公鑰對該簽名進(jìn)行驗(yàn)簽。這里說一下，由于nrfutil是PC端應(yīng)用程序，所以它可以集成各種密碼算法庫，并完成上面提及的公私鑰對，hash和簽名的生成工作。

3. DFU升級(jí)步驟詳解

3.1 安全式藍(lán)牙空中升級(jí)步驟

如前所述，Nordic SDK已經(jīng)提供了DFU例子，下面我們一步一步給大家講解如何通過Nordic SDK來實(shí)現(xiàn)無按鍵式藍(lán)牙空中升級(jí)。欲實(shí)現(xiàn)空中升級(jí)，設(shè)備需要同時(shí)下載softdevice，應(yīng)用程序，BootLoader程序，以及BootLoader settings page。其中BootLoader代碼位于目錄：SDK根目錄examplesdfusecure_bootloader，然后在該目錄下選擇你對應(yīng)的板子和工程。Application對應(yīng)的目錄：SDK根目錄examplesle_peripheralle_app_buttonless_dfu，而softdevice所在目錄：SDK根目錄componentssoftdevice。

下面我們以nRF52832/PCA10040和S132為例闡述無按鍵式藍(lán)牙空中升級(jí)實(shí)現(xiàn)步驟： 1)安裝PC版nrfutil。nrfutil安裝有兩種方式，一種是直接下載exe文件，一種是以Python的方式進(jìn)行安裝。nrfutil.exe直接下載鏈接為：https://github.com/NordicSemiconductor/pc-nrfutil/releases，記得把nrfutil.exe所在目錄放在Windows環(huán)境變量中。Python方式安裝nrfutil步驟如下所示：

安裝Python2.7或者Python3.7，下載地址：https://www.python.org/downloads/，安裝成功后請確保Windows環(huán)境變量包含Python目錄

通過pip安裝最新版的nrfutil，即打開Windows命令行工具CMD，輸入如下命令：pip install nrfutil，即可以完成nrfutil的安裝。

安裝完成后，在Windows命令行工具輸入：nrfutil version，如果可以正確顯示版本信息，說明安裝已經(jīng)成功

對于Windows用戶，nrfutil運(yùn)行需要幾個(gè)特殊的DLL庫，而這幾個(gè)庫有些Windows機(jī)器是沒有的，如此，可往：https://www.microsoft.com/en-us/download/details.aspx?id=40784下載 2) 通過nrfutil生成公私鑰對。

私鑰生成命令：nrfutil keysgenerate priv.pem （priv.pem就是私鑰）

公鑰生成命令：nrfutil keysdisplay --key pk --format code priv.pem --out_file dfu_public_key.c （dfu_public_key.c就是公鑰）

大家務(wù)必要保存好私鑰priv.pem，以后每次升級(jí)新固件時(shí)，都會(huì)通過這個(gè)私鑰對它進(jìn)行簽名，一旦priv.pem丟失或者被暴露，DFU將無法進(jìn)行或者變得不安全

3) 請確保已按照 “Nordic nRF51/nRF52開發(fā)環(huán)境搭建” 把Nordic nRF5 SDK開發(fā)環(huán)境搭建成功 4) 生成micro-ecc算法庫。由于micro-ecc是第三方算法庫，需要用戶自己去安裝（這個(gè)是版權(quán)的要求，沒辦法直接編譯放在SDK中）。請先確保電腦已安裝了git和GCC編譯器，然后直接點(diǎn)擊SDK如下目錄的build_all腳本，就可以自動(dòng)完成micro-ecc算法庫的安裝。為了方便一些開發(fā)者評(píng)估，我這里在自己電腦上生成了micro-ecc算法庫，micro-ecc目錄編排結(jié)構(gòu)有兩種：SDK14及以后版本是一種目錄結(jié)構(gòu)（百度云盤壓縮包名稱：micro_ecc_new.rar），SDK13和SDK12又是一種目錄結(jié)構(gòu)（百度云盤壓縮包名稱：micro_ecc_old.rar），這兩個(gè)壓縮包只是目錄不一樣，里面的算法庫內(nèi)容其實(shí)是一樣的，這兩個(gè)壓縮包大家都可以在前面的百度云盤中找到，以供大家評(píng)估使用。大家下載下來后，直接覆蓋同名目錄即可。注意：百度云盤里面的micro-ecc庫僅供大家評(píng)估使用，如要商用，請大家按照上面步驟去生成。

5)編譯bootloader代碼。將剛才的dfu_public_key.c取代SDK根目錄examplesdfu下的同名文件，然后使用Keil編譯如下目錄中的工程： SDK根目錄examplesdfusecure_bootloaderpca10040_blearm5_no_packs，或者 nRF5SDK160098a08e2examplesdfusecure_bootloaderpca10040_s132_blearm5_no_packs 將生成的hex文件改名為：bootloader.hex（注：本文所有項(xiàng)目都會(huì)采用Keil工程來講解，如果你使用其他IDE，請選擇其對應(yīng)的工程文件進(jìn)行編譯，不管是Keil還是其他IDE，除了編譯時(shí)候選擇的工程文件不一樣，其余都大同小異，大家可以舉一反三完成其他IDE的相應(yīng)工作） 6) 編譯application代碼。請編譯工程： SDK根目錄examplesle_peripheralle_app_buttonless_dfupca10040s132arm5_no_packs，將生成的hex文件改名為：app.hex 7) 生成BootLoader settingspage。Bootloader settings page存儲(chǔ)在Flash最后一個(gè)page，如前所述，BootLoader settings page有2個(gè)版本，他們的生成腳本命令如下所示： 版本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個(gè)hex文件和softdevice hex文件merge成一個(gè)文件，然后通過nrfjprog或者nRF Connect桌面版進(jìn)行燒寫，相關(guān)命令如下所示： 合并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 -fNRF52 nrfjprog --programwhole.hex --verify -fNRF52 nrfjprog --reset -f NRF52 9)通過nrfutil生成新固件對應(yīng)的zip包：new_app.zip。zip包包含新固件（新固件廣播名改為：Nordic_New，其余跟老固件一模一樣）和init包，zip包一般通過云端下發(fā)到手機(jī)app，手機(jī)app再通過藍(lán)牙下載到設(shè)備中。生成zip包的命令如下所示： nrfutil pkg generate--application app_new.hex --application-version 2 --hw-version 52 --sd-req 0xCB--key-file priv.pem SDK160_app_s132.zi 其中，--application表示新固件hex文件。--hw-version表示板子版本，只要BootLoader里面的hw version和這里的hw version對應(yīng)起來，大家可以改成任何自己想要的值。--key-file 表示簽名用的私鑰文件。--sd-req表示老固件運(yùn)行在哪個(gè)版本softdevice上，這個(gè)值一定要跟自己的softdevice相匹配，否則無法升級(jí)，各個(gè)softdevice版本ID信息可以通過命令“nrfutil pkg generate --help”獲得，如下為當(dāng)前所有softdevice ID列表：

10) 將“new_app.zip”拷貝到手機(jī)上。安卓和蘋果手機(jī)都可以通過微信的‘文件傳輸助手’拷過去，非常方便。請注意，手機(jī)nRF Connect和nRF Toolbox都支持DFU功能，蘋果手機(jī)拷貝的時(shí)候可以隨便選擇其中一個(gè)app。 11) 通過手機(jī)版nRF Connect或者nRF Toolbox進(jìn)行藍(lán)牙空中升級(jí)，這里以nRF Connect為例闡述升級(jí)詳細(xì)步驟，nRF Toolbox與此類似，就不再贅述

第8）步完成后，開發(fā)板就可以正常跑起來，并廣播為Nordic_Buttonless

連接該設(shè)備，使能CCCD（這一步可選），然后選擇“DFU”，如下所示：

選擇“DFU”后，將跳出一個(gè)對話框，讓你選擇新固件對應(yīng)的zip包。由于zip包放在了微信下面的download目錄下，我們需要通過文件瀏覽器找到這個(gè)zip包，大家可以先用系統(tǒng)自帶的文件瀏覽器打開這個(gè)zip包（如果打開失敗，那么大家就要去下載一些第三方的文件瀏覽器了，比如es explorer），相關(guān)操作界面如下所示：

一旦zip包打開成功，升級(jí)過程開始，界面如下所示：

升級(jí)成功后，設(shè)備將運(yùn)行新固件，即廣播名字將變成：Nordic_New，如下所示：

如上以nRF52832/S132為例闡述了Nordic SDK實(shí)現(xiàn)無按鍵式簽名式藍(lán)牙空中升級(jí)的詳細(xì)步驟，Nordic SDK有多個(gè)版本，從SDK13.0.0到現(xiàn)在SDK16.0.0，他們的升級(jí)步驟基本上一模一樣，大家完全可以參考上述步驟來做。SDK12升級(jí)步驟也與上述步驟基本一樣，唯一如下地方需要注意一下：

編譯application代碼的時(shí)候，把如下語句注掉，否則會(huì)造成BootLoader和application兩者的hex文件相沖突

3.2 節(jié)會(huì)按照上述步驟，對一些經(jīng)典的安全式BLE OTA例子進(jìn)行測試，并生成可直接運(yùn)行的腳本，以供大家參考。 3.2 各種安全式藍(lán)牙空中升級(jí)例子 3.1節(jié)是以升級(jí)nRF52832 application為例，詳細(xì)闡述了安全式BLE OTA步驟。除了升級(jí)application，有的人還需要升級(jí)softdevice和BootLoader；除了52832，有的人還會(huì)用52840/52833/52811/52810/51822等；除了SDK16.0.0，有的人還會(huì)用SDK15.3/15.2/14.2/12.3等。為此我選了一些經(jīng)典組合，將他們DFU用得的所有腳本都做好了，并進(jìn)行了實(shí)際測試，有需要的可以去百度網(wǎng)盤下載。這些腳本在百度網(wǎng)盤的命名規(guī)則為：安全模式_固件傳輸接口_升級(jí)哪一部分固件_SDK版本號(hào)_芯片型號(hào).rar，比如secure_ble_S132_app_SDK160_nRF52832.rar表示采用安全簽名，固件通過BLE傳輸，BLE使用S132協(xié)議棧，升級(jí)的時(shí)候只升級(jí)application而不升級(jí)BootLoader和SoftDevice，基于SDK16.0.0和nRF52832。 目前百度網(wǎng)盤上傳了如下安全式BLE OTA示例腳本（注：這些腳本都經(jīng)過我的測試，全都可以直接運(yùn)行）：

3.3 通過UART口進(jìn)行安全式固件升級(jí)示例腳本 我們以nRF52810為例來闡述如何通過UART進(jìn)行安全式固件升級(jí)步驟： 1) 請參考3.1節(jié)第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節(jié)講述OTA的時(shí)候，我們選擇的例子是ble_app_buttonless_dfu，因?yàn)槲覀兪峭ㄟ^藍(lán)牙給設(shè)備發(fā)送一條命令，從而讓設(shè)備進(jìn)入DFU模式。通過串口升級(jí)固件，如何進(jìn)入DFU模式，取決于你的應(yīng)用設(shè)計(jì)，你可以采用通過發(fā)送藍(lán)牙命令讓其進(jìn)入DFU模式，也可以通過上電檢測按鍵是否按下以決定是否進(jìn)入DFU模式。如果想采用ble_app_buttonless_dfu作為application，那么你需要把該工程中的main函數(shù)如下語句刪掉（這些語句是為藍(lán)牙版BootLoader設(shè)計(jì)的，我們現(xiàn)在是UART版BootLoader，不支持這些語句）： err_code =ble_dfu_buttonless_async_svci_init(); APP_ERROR_CHECK(err_code); 這里我們選擇以上電檢測按鍵的方式來決定是否進(jìn)入DFU模式，并以ble_app_blinky作為應(yīng)用例子，請直接編譯如下工程： SDK根目錄examplesle_peripheralle_app_blinkypca10040es112arm5_no_packs，將生成的hex文件改名為：app.hex 4) 生成BootLoader settingspage并同時(shí)燒寫老固件，雙擊“program.bat”即可完成，這個(gè)腳本是使用nrfjprog來完成固件燒寫的。 5) 生成新固件zip包并進(jìn)行UART DFU，雙擊“dfu.bat”即可完成，這個(gè)腳本是使用nrfutil作為UART主機(jī)，并將新固件通過電腦COM口傳給設(shè)備的。請記得一定要修改腳本中的UART對應(yīng)的電腦COM口，否則升級(jí)無法完成。 注：所有bat腳本都可通過右鍵選擇Notepad++打開，然后查看里面包含的具體命令，并按照自己的需求進(jìn)行修改。如需進(jìn)一步理解腳本中的命令，請參考3.1節(jié)的說明。 上述所有操作步驟已打包并上傳到百度網(wǎng)盤，請去網(wǎng)盤下載文件：secure_uart_app_SDK160_nRF52810.rar，這個(gè)文件已經(jīng)過我的測試，大家可以直接使用。 3.4 通過USB口進(jìn)行安全式固件升級(jí)示例腳本 我們以nRF52840為例來講述如何通過USB進(jìn)行安全式固件升級(jí)，其實(shí)通過USB口升級(jí)固件步驟與3.3節(jié)的操作幾乎一模一樣，唯一不同的是，選擇如下目錄的BootLoader工程進(jìn)行編譯： SDK根目錄 examplesdfusecure_bootloaderpca10056_usbarm5_no_packs 通過USB口進(jìn)行安全式固件升級(jí)示例腳本已打包并上傳到百度網(wǎng)盤，請去網(wǎng)盤下載文件：secure_usb_app_SDK160_nRF52840.rar，這個(gè)文件已經(jīng)過我的測試，大家可以直接使用。 3.5 通過USB口進(jìn)行開放式固件升級(jí)示例腳本 我們還是以nRF52840為例來講述如何通過USB進(jìn)行開放式固件升級(jí)，其升級(jí)步驟與3.3節(jié)的操作幾乎一模一樣，唯一不同的是，選擇如下目錄的BootLoader工程進(jìn)行編譯： SDK根目錄 examplesdfuopen_bootloaderpca10056_usbarm5_no_packs 相關(guān)腳本已上傳百度網(wǎng)盤，請下載：open_usb_app_SDK160_nRF52840.rar，這個(gè)文件已經(jīng)過我的測試，大家可以直接使用。 3.6 開放式藍(lán)牙空中升級(jí)（Legacy DFU）步驟 所謂開放式OTA，是指OTA過程中，不需要檢驗(yàn)新固件的簽名，也就是說BootLoader代碼里面不包含公鑰及相關(guān)密碼算法庫，升級(jí)的時(shí)候，只校驗(yàn)版本信息，版本校驗(yàn)通過，就可以開始升級(jí)流程。Nordic SDK目前支持兩套開放式OTA方案，一套是SDK15和SDK16提供的，一套是SDK9/SDK10/SDK11提供的。SDK15/16提供的開放式OTA工作原理和流程，與安全式OTA基本上一樣，只不過刪掉了簽名驗(yàn)簽部分。SDK9/SDK10/SDK11提供的開放式OTA也叫l(wèi)egacy OTA DFU，它的工作流程與SDK15/16略有不同，下面將以nRF52832/S132為例，闡述如何在SDK11中實(shí)現(xiàn)無按鍵式開放式藍(lán)牙空中升級(jí)，詳細(xì)步驟如下所示： 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三個(gè)hex文件合成一個(gè)文件，命令如下所示： mergehex --merge s132_nrf52_2.0.1_softdevice.hexapp.hex bootloader.hex –output whole.hex 4) 燒寫固件到設(shè)備中，大家可以用nRF Connect桌面版燒寫，也可以通過nrfjprog燒寫，nrfjprog燒寫命令如下所示： nrfjprog.exe --eraseall -f NRF52 nrfjprog --program whole.hex --verify -f NRF52 5) 另外我們還需要在Flash中寫一個(gè)application有效標(biāo)志位，從而上電后程序直接跑到application中去執(zhí)行，而不是停留在bootloader中不出來，其對應(yīng)的命令如下所示： nrfjprog --memwr 0x0007F000 --val 0x01 --verify -f NRF52 6) 用老版本的nrfutil生成新固件對應(yīng)的zip包。該zip包除了包含新固件image，還包含一些配置信息。升級(jí)時(shí)，zip包會(huì)通過云端下發(fā)到手機(jī)端app，手機(jī)端app再把zip包傳給藍(lán)牙設(shè)備以進(jìn)行固件升級(jí)。請使用老版本nrfutil（版本號(hào)0.3.0）來生成該zip包，老版本nrfutil跟隨nRFgo studio一起安裝的，只要你安裝了nRFgo studio，老版本nrfutil就會(huì)自動(dòng)安裝好，并放在目錄“C:Program Files (x86)Nordic Semiconductor RFgo Studio”中。生成zip包對應(yīng)的命令如下所示： nrfutil dfu genpkg --application app_new.hex --application-version 1SDK110_app_s132.zip 7) 把上述的‘SDK110_app_s132.zip’拷到手機(jī)中，安卓和蘋果手機(jī)都可以通過微信的‘文件傳輸助手’拷過去，非常方便。注：手機(jī)nRF Connect和nRF Toolbox都支持DFU功能，蘋果手機(jī)拷貝的時(shí)候可以隨便選擇其中一個(gè)app。 8) 使用nRF Connect或者nRF Toolbox來完成DFU過程。這里以nRF Connect為例來闡述整個(gè)升級(jí)過程。

成功執(zhí)行完第5）步后，如果開發(fā)板運(yùn)行正常，那么它將進(jìn)行廣播，廣播名字為：Nordic_HRM

連接該設(shè)備，并使能CCCD，然后選擇“DFU”

選擇“DFU”后，將跳出一個(gè)對話框，讓你選擇新固件對應(yīng)的zip包。由于zip包放在了微信下面的download目錄下，我們需要通過文件瀏覽器找到這個(gè)zip包，大家可以先用系統(tǒng)自帶的文件瀏覽器打開這個(gè)zip包（如果打開失敗，那么大家就要去下載一些第三方的文件瀏覽器了，比如es explorer），相關(guān)操作界面如下所示：

一旦zip包打開成功，升級(jí)過程開始，界面如下所示：

升級(jí)成功，設(shè)備將自動(dòng)啟動(dòng)，此時(shí)你會(huì)看到新固件已經(jīng)在運(yùn)行，廣播名字也變成了：Nordic_HRM_new，如下所示：

目前百度網(wǎng)盤上傳了如下開放式BLE OTA示例腳本（注：這些腳本都經(jīng)過我的測試，全都可以直接運(yùn)行）：

open_ble_S132_app_SDK110_nRF52832.rar

open_ble_S130_app_SDK110_nRF51.rar

如果你的應(yīng)用是基于SDK11開發(fā)的，并且需要集成DFU功能，請參考上述例子ble_app_hrs來移植DFU功能，主要工作包括兩部分：一把BLE_DFU_APP_SUPPORT這個(gè)宏包括的所有代碼拷到你的工程中，二如果你的設(shè)備支持bonding的話，還需把Device manager相關(guān)代碼也拷到你的工程中，如此即可完成DFU功能的移植。 4. 詳解如何移植DFU功能到ble_app_uart 為了讓SDK14及以后版本的ble_app_uart具有DFU功能，有2種做法，一是把NUS服務(wù)移植到ble_app_buttonless_dfu中，這種方法相對來說更簡單，大家可以自己去實(shí)踐一下；二是把DFU服務(wù)移植到ble_app_uart中，這種移植方式挑戰(zhàn)更大，但更有利于我們理解DFU的工作原理，我們現(xiàn)在就來闡述如何給ble_app_uart加上OTA功能。如前所述，OTA過程中，手機(jī)跟設(shè)備可以進(jìn)行配對和bonding，也可以用明文進(jìn)行藍(lán)牙通信。配對bonding的時(shí)候，我們可以讓BootLoader和application共享bonding信息，也可以只讓application進(jìn)行配對bonding，而BootLoader還是以明文方式進(jìn)行藍(lán)牙通信。 Nordic已經(jīng)把DFU服務(wù)做成了一個(gè)模塊，大家只要把這個(gè)模塊加到自己的應(yīng)用中，然后完成一些必須的配置，初始化以及回調(diào)函數(shù)的撰寫，再加上把SVCI模塊（SVCI模塊主要用來修改BootLoader的一些配置參數(shù)）加入到應(yīng)用中移植即可大功告成。在SDK中，DFU服務(wù)的名字是：BLE_DFU_SERVICE，這個(gè)服務(wù)放在文件ble_dfu.c中，而ble_dfu.c又有兩個(gè)后端實(shí)現(xiàn)：ble_dfu_unbonded.c和ble_dfu_bonded.c，分別對應(yīng)無bonding明文藍(lán)牙連接和有bonding的藍(lán)牙連接，下面也將分這兩種情況詳細(xì)闡述移植過程。 4.1 明文正常連接OTA（無bonding） 1) 用Keil打開如下工程：SDK根目錄examplesle_peripheralle_app_uartpca10040s132arm5_no_packs 2) 添加DFU服務(wù)有關(guān)的文件，目錄和宏定義。首先添加如下DFU目錄及相關(guān)文件：

在define中添加這些宏：DEBUG DFU_SUPPORT BL_SETTINGS_ACCESS_ONLY NRF_DFU_SVCI_ENABLEDNRF_DFU_TRANSPORT_BLE=1，其中DEBUG宏只是為了調(diào)試方便而設(shè)置的，跟DFU本身無關(guān)。DFU_SUPPORT是我用來控制我添加的DFU代碼的，刪掉DFU_SUPPORT，將不編譯所有DFU有關(guān)代碼。其余的宏都是系統(tǒng)自帶的，如果要支持DFU，就必須要添加。

然后包含如下目錄：

3) 修改sdk_config.h文件。首先我們需要使能BLE_DFU模塊，及選擇OTA藍(lán)牙連接方式，如下為使用明文進(jìn)行藍(lán)牙通信的配置： #define BLE_DFU_ENABLED 1 #defineNRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 0 同時(shí)我們還需要修改softdevice配置。現(xiàn)在整個(gè)應(yīng)用包括2個(gè)供應(yīng)商自定義UUID：NUS和DFU（其實(shí)這兩個(gè)UUID可以合成一個(gè)，但由于歷史原因，DFU和NUS分別使用了兩個(gè)不同的vs UUID），相應(yīng)地ATT table size也要變大，然后應(yīng)用程序RAM起始地址也需要跟著變，如下（注：這里的NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 設(shè)置得稍稍偏大）： #define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1600 #define NRF_SDH_BLE_VS_UUID_COUNT 2 修改應(yīng)用程序RAM起始地址，如下：

4) 修改main.c文件。首先添加如下頭文件： #include "ble_dfu.h" #include "nrf_bootloader_info.h" #include "nrf_power.h" 然后在main函數(shù)的開始處，添加修改BootLoader廣播名字的代碼，這一行代碼是可選的，如果想改掉BootLoader默認(rèn)的廣播名字，就需要它；反之就不需要： err_code =ble_dfu_buttonless_async_svci_init(); APP_ERROR_CHECK(err_code); 然后在services_init()中添加ble dfu服務(wù) 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回調(diào)函數(shù)的撰寫，大家只要按照要求來，就沒問題，如果應(yīng)用只支持一個(gè)連接，那么ble_dfu_evt_handler可以直接為空。如果應(yīng)用支持多個(gè)連接，可以參考ble_app_buttonless_dfu做法，這里就不貼代碼了。 5) 在跳轉(zhuǎn)到bootloader之前，如果你想做一些專門的代碼處理，比如完成pending的Flash操作，比如關(guān)閉某些模塊，那么你可以注冊一個(gè)app_shutdown_handler來做這些工作。（注：這一步不是必須的，是可選的！） NRF_PWR_MGMT_HANDLER_REGISTER(app_shutdown_handler,0); 6) （這一步可選）之前的ble_app_uart是沒有BootLoader的，所以啟動(dòng)起來非常快。現(xiàn)在加了BootLoader代碼，為了加快system off喚醒的速度，可以定義如下語句， nrf_power_gpregret2_set(BOOTLOADER_DFU_SKIP_CRC); 然后先disable softdevice，然后再進(jìn)入system off模式。這一步本身跟DFU沒有什么關(guān)系，主要是為了加快程序啟動(dòng)速度而另加的。 7) 編譯工程，并將生成的hex文件改名為“app.hex” 8) 然后按照3.1節(jié)的步驟一步一步完成后續(xù)的DFU過程。 4.2 bonding連接OTA 4.1節(jié)的工程已經(jīng)移植了DFU功能，現(xiàn)在我們再把bonding功能移植到4.1節(jié)工程上，就可以讓我們的應(yīng)用同時(shí)支持DFU和bonding。Bonding功能是通過peer_manager模塊來實(shí)現(xiàn)的，大家只要把peer_manager有關(guān)的文件添加進(jìn)來，就可以實(shí)現(xiàn)bonding的目標(biāo)。 1) 打開4.1節(jié)的工程 2) 添加如下文件：

3) 修改sdk_config.h文件，需要修改多個(gè)地方，如下： #define PEER_MANAGER_ENABLED1 #define FDS_ENABLED 1 #define NRF_SDH_BLE_SERVICE_CHANGED 1 #define NRF_FSTORAGE_ENABLED 1 #define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 1 當(dāng)NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS設(shè)為1時(shí)，表示application將與主機(jī)進(jìn)行bonding，同時(shí)該bonding信息將共享給BootLoader，也就是說，進(jìn)入bootloader模式后，主機(jī)將使用以前的bonding信息與設(shè)備進(jìn)行加密連接。 4) 在main.c文件開頭，包含如下頭文件： #include "peer_manager.h" 5) 在main函數(shù)中添加peer_manager_init()，其定義如下所示：

添加pm_evt_handler定義，代碼如下所示：

6) 在ble_evt_handler中刪除BLE_GAP_EVT_SEC_PARAMS_REQUEST分支，因?yàn)檫@個(gè)分支在peer_manager模塊中已經(jīng)進(jìn)行處理了，這里再處理一次，會(huì)產(chǎn)生異常： // 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信息功能（如果你不需要這個(gè)功能，也可以不改） 8) （此步可選）一般來說，如果用戶在手機(jī)端把配對信息刪掉了，為了安全起見，設(shè)備端也需要把相關(guān)配對信息清掉，然后才可以允許手機(jī)和設(shè)備再次進(jìn)行配對和bonding。如何觸發(fā)設(shè)備端bonding信息的刪除操作？可以通過按鍵檢測的方式來做，比如目前我們這個(gè)例子的做法。但是有很多設(shè)備沒有按鍵，而且很多人希望這種二次配對的操作對用戶來說無感，即哪怕用戶刪掉了手機(jī)端配對信息，如果用戶想發(fā)起第二次配對請求，設(shè)備也能接受，而且操作過程跟用戶第一次發(fā)起配對請求的過程一模一樣。Nordic SDK其實(shí)是兼容這種操作的，用戶只需在pm_evt_handler()中添加如下代碼即可：

9)上述所有代碼都包括在“BONDING_SUPPORT”宏中。 10)編譯工程，將生成的hex文件改名為app.hex 11)然后按照3.1節(jié)步驟來執(zhí)行OTA過程，不過如下幾點(diǎn)需要注意：

如果你在應(yīng)用中把NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS設(shè)為1，那么bootloader代碼就不能采用默認(rèn)配置，請修改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”選項(xiàng)，如下：

手機(jī)連接設(shè)備成功后，請手動(dòng)使能CCCD，以讓手機(jī)自動(dòng)發(fā)起bonding請求

DFU升級(jí)成功后，設(shè)備將會(huì)與手機(jī)自動(dòng)重連，此時(shí)需點(diǎn)擊“Refresh services”，以獲得設(shè)備最新服務(wù)列表，如下：

上述代碼工程我已打包成：ble_app_uart_ota_SDK16_0_0.rar，并上傳到百度網(wǎng)盤，大家下載下來解壓縮到：SDK根目錄examplesle_peripheral這個(gè)目錄下，就可以直接編譯和運(yùn)行。DFU過程中用到的所有腳本我也幫大家做好了，大家可以直接下載下來使用，其中secure_ble_S132_uart_SDK160_nRF52832_Nobonding.rar對應(yīng)明文藍(lán)牙傳輸，secure_ble_S132_uart_SDK160_nRF52832_bonding.rar對應(yīng)bonding藍(lán)牙傳輸。

5. 手機(jī)端DFU參考代碼

Nordic不僅提供DFU設(shè)備端的參考代碼，同時(shí)提供手機(jī)端的參考代碼。Nordic分別開發(fā)了Android版和iOS版的DFU庫，大家可以直接拿過來使用，集成到自己的移動(dòng)端app中，這兩個(gè)庫都放在github上，鏈接如下所示：

Nordic還提供了一個(gè)移動(dòng)端app：nRF Toolbox，nRF Toolbox是代碼開源的，里面也集成了上面提到的DFU庫，大家可以參考nRF Toolbox來開發(fā)自己的移動(dòng)端app。nRF Toolbox源碼也可以在github上找到：

nRF Toolbox軟件界面如下所示：