DFU協(xié)議簡介 NCS DFU升級步驟說明
nRF Connect SDK (NCS) / Zephyr固件升級，主要包括MCUboot和藍牙空中升級。
隨著nRF Connect SDK(NCS)/Zephyr固件升級，近期不少朋友在后臺給Nordic君發(fā)來不少疑問： 為此，Nordic君特地找到一篇來自 Nordic 中國區(qū) FAE 經理 Kevin 艾的原創(chuàng)博客文章對以上問題進行解答。目錄
CONTENT
1.概述2. NCS中的Bootloader 2.1 nRF5 SDK Bootloader 2.2 MCUboot 2.3 B0，亦稱nRF Secure Immutable Bootloader（NSIB）3. DFU協(xié)議 3.1 概述 3.2 SMP DFU協(xié)議 3.2.1 SMP包頭和命令 3.2.2 SMP包payload和CBOR編碼 3.2.3 SMP包詳細解析示例 3.2.4 SMP DFU流程 3.3 nrf dfu協(xié)議4. NCS DFU升級步驟說明 4.1 SMP DFU升級步驟說明 4.2 nrf_dfu升級步驟說明 4.3 存儲器分區(qū)（多image情況）5. 移植SMP DFU功能到peripheral_uart(NUS)6. 手機端DFU參考代碼 ●1、概述 ●DFU概念
DFU（Device Firmware Update），就是設備固件升級的意思。OTA概念
OTA（Over The Air）是實現DFU的一種方式而已，準確說，OTA的全稱應該是OTA DFU，即通過空中無線方式實現設備固件升級。只不過大家為了方便起見，直接用OTA來指代固件空中升級（有時候大家也將OTA稱為FOTA，即Firmware OTA，這種稱呼意思更明了一些）。 只要是通過無線通信方式實現DFU的，都可以叫OTA，比如4G/WiFi/藍牙/NFC/Zigbee/NB-IoT，他們都支持OTA。DFU除了可以通過無線方式（OTA）進行升級，也可以通過有線方式進行升級，比如通過UART，USB或者SPI通信接口來升級設備固件。 不管采用OTA方式還是有線通信方式，DFU包括后臺式（background）和非后臺式兩種模式。 1、后臺式DFU，又稱靜默式DFU（Silent DFU），在升級的時候，新固件在后臺悄悄下載，即新固件下載屬于應用程序功能的一部分，在新固件下載過程中，應用可以正常使用，也就是說整個下載過程對用戶來說是無感的，下載完成后，系統(tǒng)再跳到BootLoader程序，由BootLoader完成新老固件拷貝操作，至此整個升級過程結束。比如智能手機升級Android或者iOS系統(tǒng)都是采用后臺式DFU方式，新系統(tǒng)下載過程中，手機可以正常使用哦。 2、非后臺式DFU，在升級的時候，系統(tǒng)需要先從應用程序跳到BootLoader程序，由BootLoader進行新固件下載工作，下載完成后BootLoader繼續(xù)完成新老固件拷貝操作，至此升級結束。早先的功能機就是采用非后臺式 DFU來升級操作系統(tǒng)的，即用戶需要先長按某些按鍵進入bootloader模式，然后再進行升級，整個升級過程中手機正常功能都無法使用。 下面再講雙區(qū)（2 Slot）DFU和單區(qū)（1 Slot）DFU，雙區(qū)或者單區(qū)DFU是新固件覆蓋老固件的兩種方式。 后臺式DFU必須采用雙區(qū)模式進行升級，即老系統(tǒng)（老固件）和新系統(tǒng)（新固件）各占一塊Slot（存儲區(qū)），假設老固件放在Slot0中，新固件放在Slot1中，升級的時候，應用程序先把新固件下載到Slot1中，只有當新固件下載完成并校驗成功后，系統(tǒng)才會跳入BootLoader程序，然后擦除老固件所在的Slot0區(qū)，并把新固件拷貝到Slot0中，或者把Slot0和Slot1兩者的image進行交換。 非后臺式DFU可以采用雙區(qū)也可以采用單區(qū)模式，與后臺式DFU相似，雙區(qū)模式下新老固件各占一塊Slot（老固件為Slot0，新固件為Slot1），升級時，系統(tǒng)先跳入BootLoader程序，然后BootLoader程序把新固件下載到Slot1中，只有新固件下載完成并校驗成功后，才會去擦除老固件所在的Slot0區(qū)，并把新固件拷貝到Slot0區(qū)。 單區(qū)模式的非后臺式DFU只有一個Slot0，老固件和新固件分享這一個Slot0，升級的時候，進入bootloader程序DFU模式后立馬擦除老固件，然后直接把新固件下載到同一個Slot中，下載完成后校驗新固件的有效性，新固件有效升級完成，否則要求重來。 跟非后臺式DFU雙區(qū)模式相比，單區(qū)模式節(jié)省了一個Slot的Flash空間，在系統(tǒng)資源比較緊張的時候，單區(qū)模式是一個不錯的選擇。不管是雙區(qū)模式還是單區(qū)模式，升級過程出現問題后，都可以進行二次升級，都不會出現“變磚”情況。 不過雙區(qū)模式有一個好處，如果升級過程中出現問題或者新固件有問題，它還可以選擇之前的老固件老系統(tǒng)繼續(xù)執(zhí)行而不受其影響。而單區(qū)模式碰到這種情況就只能一直待在bootloader中，然后等待二次或者多次升級嘗試，此時設備的正常功能已無法使用，從用戶使用這個角度來說，你的確可以說此時設備已經“變磚”了。 所以說，雖然雙區(qū)模式犧牲了很多存儲空間，但是換來了更好的升級體驗。 可參考下面三個圖來理解上述過程
?如果你是第一次接觸nRF Connect SDK(NCS)，那么建議你先看一下這篇文章：開發(fā)你的第一個NCS/Zephyr應用程序，以建立NCS的一些基本知識，然后再往下看以下章節(jié)。
●2、NCS中的Bootloader
●
如果你的應用不需要DFU功能，那么Bootloader就可以不要；反之，如果你的應用需要DFU功能，Bootloader就一定需要。
Bootloader在其中起到的作用包括：一判斷正常啟動還是DFU升級流程，二啟動并校驗應用image，三升級的時候完成新image和老image的交換或者拷貝工作。
Bootloader首先需要判斷是進入正常應用程序啟動流程還是DFU流程。
要啟動應用image，Bootloader必須知道啟動image的啟動向量表在哪里。 要校驗一個image，Bootloader必須知道這個image正確的校驗值存在哪里。 要完成升級，Bootloader必須知道新image所在位置和老image所在位置，并執(zhí)行一定的拷貝算法。 啟動向量表可以放在image的最開始處，也可以放在其他地方，這就涉及到image的格式。 Image正確的校驗值可以跟image合在一塊存放，也可以單獨放在一個flash page里面。如果image的校驗值是跟image本身合在一塊存放的，這里再次涉及到image的格式。 關于新image和老image存放位置，這就涉及到存儲器分區(qū)問題。Bootloader的實現將直接決定image的格式，以及存儲器的結構劃分。 NCS支持MCUboot，B0和nRF5 Bootloader三種Bootloader，三個Bootloader選其一即可，一般推薦大家使用MCUboot。 由于很多讀者對Nordic老的SDK，即nRF5 SDK比較熟悉，我們先以這個nRF5 Bootloader為例來講解他們的Flash分區(qū)以及image格式，然后再講MCUboot和B0，看看他們又是如何分區(qū)和定義image格式的。 注意：如果你只對其中某一個具體的Bootloader感興趣，可以跳過其他章節(jié)，直接閱讀相關章節(jié)，比如如果你只對MCUboot感興趣，可以只看2.2節(jié)。2.1 nRF5 SDK Bootloader介紹
nRF5 Bootloader 是指：nRF5_SDK_17.1.0_ddde560examplesdfusecure_bootloader 這里面定義的Bootloader。 如果你的DFU想使用這個Bootloader，那么nRF5 SDK的存儲區(qū)劃分（雙bank）是下面這樣的：
在nRF Connect SDK（NCS）中，如果也使用nRF5 Bootloader，此時存儲器的分區(qū)跟上面大同小異，我們用NCS中的語言重新組織如下：
?當前固件（老固件）在Bank0里面執(zhí)行，新固件接收后直接存放在Bank1，而且程序永遠只執(zhí)行Bank0里面的代碼，Bank1的起始地址是動態(tài)的，其計算公式為：Bank0起始地址 + Bank0 image大小。
由于nRF5 Bootloader跳到Bank0的時候，直接跳到一個固定地址（0x1000），因此它不需要專門去找新image的啟動向量，換句話說，如果使用nRF5 Bootloader的話，新image就是應用代碼編譯后的樣子，不需要添加任何的頭或者尾信息。
如果這樣的話，image的SHA256或者簽名校驗怎么做？
在nRF5 Bootloader中，把正確的SHA256或者簽名放在settings page里面，這樣image就真得不需要任何頭或者尾信息，當需要校驗image的時候，從settings page中取出標準值，然后進行校驗。
那這些標準的SHA256或者簽名怎么從遠程傳過來呢？
答案是init包，所以nRF5 Bootloader升級的時候，需要把一個zip包傳給目標設備，如下所示：
這個zip包除了新image本身，還包含一個dat文件，這個dat文件包含新image的大小，SHA256，簽名等信息。至于升級拷貝，nRF5 Bootloader做法也很簡單，先擦掉Bank0里面的內容，然后把Bank1里面的內容拷貝到Bank0，然后重新從Bank0啟動，完成整個升級。
在拷貝之前，Bootloader會校驗Bank1里面的image完整性，只有校驗通過才會做下一步的拷貝工作，否則退出升級模式。
從上可以看出，雖然nRF5 Bootloader會校驗image的完整性，但是如果出現發(fā)版錯誤（打個比方，Win11和Win7都是微軟驗簽，因此完整性校驗都可以通過，但是如果微軟把Win11發(fā)到一臺只能跑Win7的設備上，那么這臺設備將無法運行），由于它沒有新image確認操作，也不支持回滾操作，那么升級后系統(tǒng)有可能掛死在一個錯誤的版本里面。
說完了啟動，校驗和升級拷貝，最后說一下如何進入DFU模式。在nRF5 Bootloader里面，通過判斷某些Flag（標志位）來決定要不要進入DFU模式，這些標志位有一個為真，進入DFU模式，否則正常啟動app：
- 特定按鍵是否按下
- 保持寄存器GPREGRET1是否為0xB1
- Settings page里面當前bank是否為Bank1
- 上次DFU過程是否還在進行中
- 應用程序校驗是否通過
- 我們是通過把Settings page里面的當前bank設置為Bank1來觸發(fā)DFU模式的。
- 由于是后臺式DFU，我們只把DFU進度信息保存在RAM里面，沒有將其保存在Settings page這個Flash頁面中。
?2.2 MCUboot
MCUboot位于如下目錄：bootloader/mcuboot/boot/zephyr 在NCS中做DFU的時候，一般都推薦使用MCUboot。 MCUboot功能強大，兼容的芯片平臺多，而且是一個久經考驗的第三方開源Bootloader。 MCUboot把存儲區(qū)劃分為Primary slot和Secondary slot，而且primary slot跟secondary slot兩者大小是一樣的，程序默認在Primary slot中執(zhí)行。 有一點需要大家注意，NCS對MCUboot進行了定制，在NCS中，程序只能在Primary slot中執(zhí)行，Secondary slot只是用來存儲新image，而且Secondary slot可以放在內部Flash，也可以放在外部Flash，這樣在NCS中，存儲器分區(qū)有如下兩種典型情況：
?
?
?注：MCUboot放在0x000000地址。
如前所述，Bootloader有四大功能：啟動image，校驗image，拷貝image以及DFU模式判斷。
那么MCUboot是如何完成這4項功能的：
- 啟動image
從上可以看出，image的最開始是image header，而不是image啟動向量。
Image header里面有一個字段image header size，啟動向量就位于image header size的偏移處，image header一般為0x200大小，一般來說，app的基地址是0xC000，這樣image的啟動向量就在0xC000+0x200=0xC200，MCUboot啟動app的時候就跳轉到0xC200這個地址。
2. 校驗image
MCUboot通過讀image的尾信息（tail或者tlv），得到image的SHA256和簽名，從而完成校驗。
Image tlv緊跟在image后面，其內容示例如下所示：(感興趣的讀者，仔細看一下各個結構體字段定義，并對應image hex進行解讀)
?上述示例解讀結果為：沒有IMAGE_TLV_PROT_INFO_MAGIC，只有普通的IMAGE_TLV_INFO_MAGIC，IMAGE_TLV_INFO_MAGIC總共有3個tag：IMAGE_TLV_SHA256 (0x10), IMAGE_TLV_KEYHASH(0x01)，以及IMAGE_TLV_ECDSA256(0x22)。
nRF5 Bootloader把app image的SHA256和簽名放在settings page里，這樣每次重新編譯一次app image，還需要重新生成一個settings page，然后把兩者一起合并燒到芯片里，這樣Bootloader才能通過image完整性校驗而跳到app。
如果只把新編譯的app image燒到芯片里，此時image完整性校驗將失敗而導致程序一直死在Bootloader里，可以看出這種方案是不太方便開發(fā)和調試的。
而MCUboot把app image的SHA256和簽名放在image后面，這樣每次重新編譯一次app image，新的sha256和簽名會自動跟著一起更新，你只需直接下載app而無需去更改Bootloader任何部分，大大方便了開發(fā)和調試。
3. Image拷貝
MCUboot支持多種image拷貝動作，確切說是image swap（交換）操作，即把secondary slot里面的image交換到Primary slot，如何swap呢？
總體上分swap和overwrite兩種。Overwrite跟上面的nRF5 Bootloader一樣，即先擦除primary slot里面的老image，然后把secondary slot里面的新image拷貝到primary slot，完成整個升級過程。
Swap就是把primary slot和secondary slot里面的image進行交換，即primary slot里面的image搬移到secondary slot，secondary slot里面的image搬移到primary slot。
欲swap A和B，我們需引入一個媒介：C，算法是C=A;A=B;B=C，這樣就實現了A和B的交換。從上可知，實現swap的關鍵是媒介C的引入，據此MCUboot支持兩種swap算法：swap_move和swap_scratch，默認采用swap_move。
swap_scratch的做法是：在存儲區(qū)中專門劃分一塊scratch區(qū)作為swap媒介，swap的時候，primary slot里面的image先放在scratch區(qū)，然后把secondary slot里面的image拷貝到primary slot，最后把scratch區(qū)里面的內容拷貝到secondary slot，從而完成一次交換操作，Scratch區(qū)應該比primary或者secondary slot小很多，因此要完成整個image交換，需要循環(huán)執(zhí)行多次上述操作直至整個image（以兩個slot中最大的為準）交換完成。
這種算法有兩個弊端：一浪費了scratch區(qū)，二由于一次image交換，scratch區(qū)需要執(zhí)行多次擦寫操作，scratch區(qū)的Flash壽命有可能會不夠，為解決上述兩個問題，引入了第二套算法：swap_move，具體做法是：先把primary slot里面整個image向上搬移一個扇區(qū)，即先擦掉image size + 1的扇區(qū)，然后把image size所在的扇區(qū)內容拷貝到image size + 1扇區(qū)，然后擦掉image size扇區(qū)，并把image size -1所在的扇區(qū)內容拷貝到image size扇區(qū)，以此循環(huán)往復，直至把整個image向上挪動一個扇區(qū)，這樣就為下面的primary slot和secondary slot image交換做好準備。
Primary slot和secondary slot image交換的時候，先擦掉primary slot第一個扇區(qū)，然后把secondary slot第一個扇區(qū)的內容拷貝到primary slot第一個扇區(qū)并擦掉secondary slot第一個扇區(qū)，然后把primary slot第二個扇區(qū)內容拷貝到secondary slot第一個扇區(qū)并擦掉primary slot第二個扇區(qū)，然后把secondary slot第二個扇區(qū)內容拷貝到primary slot第二個扇區(qū)并擦掉secondary slot第二個扇區(qū)，然后把primary slot第三個扇區(qū)內容拷貝到secondary slot第二個扇區(qū)并擦掉primary slot第三個扇區(qū)，以此往復，直至primary slot或者secondary slot兩者中最大的那個image size拷貝完成，整個image swap流程宣告完成。
從上面算法描述大家可以感覺出，swap操作是比較耗時的，但是它安全，支持回滾操作。
如果大家不需要這個回滾操作的話（就像nRF5 SDK那樣），那么大家可以選擇overwrite模式（打開#define MCUBOOT_OVERWRITE_ONLY）以加快MCUboot拷貝速度。
4. 是否進入DFU模式
nRF5 Bootloader通過判斷某些標志位以此決定是否進入DFU模式，與此簡單判斷不同，MCUboot是通過primary slot和secondary slot的狀態(tài)組合來決定是否進入DFU模式。
在MCUboot中，有一個變量：swap_type，它的取值將決定是否進入DFU模式，而swap_type的值又依賴如下真值表：
上述的magic，image_ok和copy_done三個字段位于slot最后一個扇區(qū)，即slot的最高扇區(qū)，他們在扇區(qū)中的排布如下所示（magic字段在扇區(qū)的最高地址）：
從上可知，根據magic，image_ok和copy_done三個變量的不同取值情況，可以得到不同的結果，即swap_type。我們以State1 表格為例來解讀其中的結果，State1表格如下：
可以看出，當secondary slot最后一個扇區(qū)的magic字段為Good，即設置成正確的值，而且image_ok字段不等于1，即為unset狀態(tài)，則不管其他變量為什么值（正常情況下，此時其他變量的值都是0xFF），此時swap_type的結果為：BOOT_SWAP_TYPE_TEST，大家以此類推，就知道State2，State3和State4表格的swap_type結果是怎么來的。這里有一點需要大家注意的，magic字段在Flash中只有兩種正常取值：全FF和0x96f3b83d，而image_ok和copy_done在Flash中也只有兩種正常取值：全FF和0x01，而表格中所謂的“Good”，“Any”，“Unset”，“0x01”，是對上述兩種取值的泛化，比如magic字段等于0x96f3b83d，就叫“Good”；image_ok等于0xFF，就叫“Unset”或者“Any”（當然“Any”意味著0x55等其他非法值也可以兼容）。swap_type總共有6種結果，每種結果的意義如下所示：
- BOOT_SWAP_TYPE_TEST。MCUboot將進入DFU模式，而且為test目的的DFU。跟下面的BOOT_SWAP_TYPE_ PERM模式相比，BOOT_SWAP_TYPE_TEST的DFU過程與之一模一樣，也就是說BOOT_SWAP_TYPE_TEST就是進行正常的真正DFU，只不過DFU完成后，MCUboot跳到新app，這個時候新app必須把secondary slot里面的image_ok字段寫為1，即調用boot_write_img_confirmed()這個API來完成，否則再次復位進入MCUboot的時候，MCUboot會認為新image有問題（沒有確認），從而執(zhí)行回滾操作，重新把老image換到primary slot，然后繼續(xù)跑老image（此時升級應該算失?。?/span>
- BOOT_SWAP_TYPE_ PERM。如前所述，BOOT_SWAP_TYPE_ PERM跟BOOT_SWAP_TYPE_TEST DFU過程一模一樣，唯一區(qū)別的是，一旦設為PERM（永久）模式，哪怕新image沒有去寫image_ok字段，再次復位進入MCUboot，MCUboot也不會去執(zhí)行回滾操作，而強制認為升級已成功。
- BOOT_SWAP_TYPE_ REVERT，回滾操作。前述的回滾操作，swap_type就是BOOT_SWAP_TYPE_ REVERT。一旦檢測到BOOT_SWAP_TYPE_ REVERT，MCUboot將進行回滾操作。
- BOOT_SWAP_TYPE_ NONE。正常啟動模式，MCUboot將直接跳到app，而不是進入DFU模式。
- BOOT_SWAP_TYPE_ FAIL。當MCUboot校驗primary slot里面的image失敗時，就會報BOOT_SWAP_TYPE_ FAIL，此時程序將死在MCUboot里面。
- BOOT_SWAP_TYPE_ PANIC。當MCUboot啟動過程中出現了致命錯誤，就會報BOOT_SWAP_TYPE_ PANIC，此時程序將死在MCUboot里面。
?很多人會好奇為什么MCUboot使用這么復雜的DFU模式判斷算法？究其根本，還是因為Flash的限制導致的。Flash每次只能擦一個page（擦除時間還比較長），而且壽命又有限，在盡可能少擦Flash的情況下，又要實現上述那么多swap操作，然后有人就想出了上面的算法。
一旦你使能MCUboot(CONFIG_BOOTLOADER_MCUBOOT=y)，編譯系統(tǒng)會自動幫你生成升級需要的升級文件：app_update.bin或者app_signed.hex（兩者內容一模一樣）。當然如果你選擇雙核MCU，那么除了上述應用核的升級文件，編譯系統(tǒng)還會自動生成網絡核的升級文件：net_core_app_update.bin或者net_core_app_signed.hex（兩者內容一模一樣）。
升級文件示例如下所示：
升級的時候，把相應的升級文件傳給設備端，設備端把接收到的升級文件放在secondary slot，待整個image接收完畢，復位進入MCUboot，MCUboot將完成后續(xù)工作直至升級成功。
2.3B0=nRF Secure Immutable Bootloader（NSIB）
NSIB(nRF Secure Immutable Bootloader)，亦稱B0，位于nrf/samples/bootloader，這個是Nordic自己開發(fā)的一個不可升級的Bootloader。 b0把存儲區(qū)劃分成slot0和slot1，并且slot0大小等于slot1大小，s0_image跑在slot0，s1_image跑在slot1，B0根據s0_image和s1_image的版本號來決定跑哪一個image，如果s0_image的版本號高于或等于s1_image的版本號，那么B0啟動的時候就會跳到s0_image；反之，如果s1_image的版本號高于s0_image的版本號，那么B0啟動的時候就會跳到s1_image。 由于s0_image和s1_image都有可能被執(zhí)行，所以s0_image和s1_image必須都放置在內部Flash，也就是說slot0和slot1必須都在nRF設備內部Flash中。 B0將存儲區(qū)劃分成如下模樣：
如前所述，Bootloader有四大功能：啟動image，校驗image，拷貝image以及DFU模式判斷。
那么b0是如何完成這4項功能的：
1. 啟動image
B0通過讀provision區(qū)域信息，得到s0_image和s1_image信息，provision屬于B0的一部分，下面為provision的定義及一個示例：(感興趣的讀者，仔細看一下結構體各個字段定義，并對應image hex進行解讀)
從上面示例可以看出，s0_address為0x9000，0x9000即為s0_image的起始地址，s1_image起始地址可以用同樣道理獲得。得到S0_image或者S1_image的起始地址后，就可以得到兩個image的fw_info，fw_info定義及示例如下所示：
通過fw_info就可以找到boot_address，從而跳轉到相應app。
2、校驗image
B0也支持SHA256或者簽名驗簽，SHA256或者簽名放在image的最后，稱為fw_validation_info，其定義及示例如下所示：
B0通過magic字段找到hash和signature，然后進行校驗。
3、拷貝image
B0沒有拷貝image的操作，所謂升級，就是執(zhí)行高版本image，具體來說，如果s1_image版本比s0_image版本高，則執(zhí)行s1_image；否則執(zhí)行s0_image。
4、DFU模式進入
B0不存在DFU模式，也就不存在所謂進入DFU模式判斷。每次復位B0都去讀s0_image和s1_image的版本，那個image版本高就執(zhí)行那個image。
基于b0的DFU，有一點需要特別注意，由于S0_image和S1_image兩者的偏移或者啟動向量不一樣，因此即使S0_image和S1_image兩者功能一模一樣，他們的image內容也不一樣，這也意味著slot0和slot1對應的升級image是不一樣的。一般來說，手機app或者其他主機并不知道設備當前正在運行哪個slot里面的image，因此DFU的時候，手機app或其他主機需要先跟設備溝通，獲知設備當前正在執(zhí)行哪個image。如果S0_image在運行，就給它傳S1_image（signed_by_b0_s1_image.bin）并放置在slot1中；如果S1_image在運行，就給它傳S0_image（signed_by_b0_s0_image.bin）并放置在slot0中。
升級image接收完畢，系統(tǒng)復位，B0自動選擇高版本image執(zhí)行，至此整個升級完成。從上可知，DFU的升級文件必須同時包含signed_by_b0_s0_image.bin 和signed_by_b0_s1_image.bin，實際中我們一般使用如下zip文件：
這里我們做了一個基于b0的DFU例子：https://github.com/aiminhua/ncs_samples/tree/master/nrf_dfu/ble_intFlash_b0
大家感興趣的話，可以自己去看一下（按照里面的readme來操作）。下面是B0正常啟動的一個示例，可以看出B0選擇了slot0里面的s0_image進行裝載，校驗和跳轉。
●3、DFU協(xié)議
●
3.1 概述
前面說過，為了實現固件升級，需要把新image放在secondary slot（以MCUboot為例），如何把新image傳輸到secondary slot？這就是DFU協(xié)議要做的事情，一般來說，DFU協(xié)議需要把image文件分塊一塊一塊傳給設備端，然后設備端按照要求將image塊寫入secondary slot，并回復寫入結果給主機。
期間有可能還需要校驗傳輸的image對不對，或者告知每次image塊寫入的偏移地址。最后DFU協(xié)議還有可能涉及一些管理操作，比如image塊寫入的準備工作，讀取設備狀態(tài)，復位設備等。
這里需要特別強調一下，DFU協(xié)議是脫離于傳輸層的，也就是說，同樣的DFU協(xié)議可以跑到不同的傳輸層，比如藍牙，WiFi，UDP，USB CDC，UART等，千萬不要把DFU協(xié)議跟特定的傳輸層混為一談。
nRF Connect SDK包含多種DFU協(xié)議，最著名的就是SMP DFU協(xié)議，除此之外，還有其他DFU協(xié)議，比如http_update，hid_configurator，USB DFU class，PCD DFU，以及從nRF5 SDK移植過來的nrf_dfu協(xié)議。
不同的應用場景有不同的DFU協(xié)議需求，大家需要根據自己的情況選擇合適的DFU協(xié)議，就像前述的Bootloader一樣，這些DFU協(xié)議選擇一個適合自己的就可以，不需要全部都要會用。下面著重講一下smp dfu和nrf_dfu兩個dfu協(xié)議。
3、2 SMP DFU協(xié)議
smp 全稱simple management protocol（簡單管理協(xié)議），它是設備管理協(xié)議的一種，在NCS中，mcumgr模塊實現了smp協(xié)議，或者說，smp協(xié)議按照mcumgr的要求對相應的傳輸數據進行編碼，這樣mcumgr里面注冊的命令組（command group）可以直接對傳輸數據進行解析。
mcumgr實現的功能比較多，smp DFU只是其中一種，除此之外，它還有很多其他功能，比如shell管理，日志管理等。這里我們只對DFU相關命令組進行介紹，其他命令組就不在這里講了。
3.2.1SMP包頭和命令
mcumgr里面有兩個命令組跟DFU有關：
1、img_mgmt，即image管理命令組，該命令組又具體包括3個命令集4個具體命令，詳細定義如下：
2、os_mgmt，即OS管理命令組，該命令組又具體包括3個命令集4個具體命令，詳細定義如下：（實際上，DFU只用到了os_mgmt_reset這個命令）
smp協(xié)議把數據包（packet）分成兩部分：包頭(header)和有效載荷(payload)，包頭每一個字節(jié)正好對應如下結構體的每一個字段，即第一個字節(jié)代表nh_op（操作類型），第二個字節(jié)代表nh_flags，第三和四個字節(jié)代表nh_len，第五和六個字節(jié)代表nh_group（命令組編號），第7個字節(jié)代表nh_seq，第8個字節(jié)代表nh_id（命令在該命令組中的編號）。
?這樣我們就可以通過SMP的包頭找到相應的handler，比如包頭00 00 00 02 00 01 00 00，即對應命令組1的0號命令集的00操作（讀命令），最終找到img_mgmt_state_read這個handler。我們會在3.2.3節(jié)對此示例的解析做詳細說明。
3.2.2SMP包payload和CBOR編碼
SMP payload采用CBOR編碼，CBOR將一連串二進制數據分成多個data item，如下所示：
?從上可知，每個data item第一個字節(jié)包含2部分：數據類型和數據長度，數據類型定義如下：
- 0，正數
- 1，負數
- 2，字節(jié)串（byte string）
- 3，UTF-8字符串（text string）
- 4，數組
- 5，map（又稱字典）
- 6，tag（這個用得少）
- 7，浮點數或者特殊類型，其中特殊類型將short count 20–23定義為 false, true, null和undefined
-
如果長度為0–23，則直接用short count的5 bits來表示，從第2個字節(jié)開始表示data payload
-
如果short count為24（0x18），則表示第2個字節(jié)代表長度，從第3個字節(jié)開始表示data payload
-
如果short count為25（0x19），則表示第2和第3個字節(jié)合起來表示長度，從第4個字節(jié)開始表示data payload
-
如果short count為26（0x1A），則表示第2，第3，第4和第5個字節(jié)合起來表示長度，從第6個字節(jié)開始表示data payload
-
如果short count為27（0x1B），則表示第2至第9個字節(jié)合起來表示長度，從第10個字節(jié)開始表示data payload
-
如果short count為31（0x1F），則表示長度為未定義，從第2個字節(jié)開始表示data payload，直到遇到停止符：0xFF
- 00 00 00 02 00 01 00 00 bf ff
nh_group的值為0x0001，目前mcumgr支持的group ID見下圖，所以該數據包將觸發(fā)img_mgmt命令組。
nh_id為00，由于nh_group指向 image management group，而img_mgmt命令組定義了如下命令，可以看出00為IMG_MGMT_ID_STATE。
再次結合下面這個命令或者handler定義列表：
我們現在可以解讀出最終的結果：00 00 00 02 00 01 00 00 bf ff這個數據包將觸發(fā)img_mgmt組里面的IMG_MGMT_ID_STATE集里面的mh_read函數，即img_mgmt_state_read，這個函數的定義是：
- int img_mgmt_state_read(struct mgmt_ctxt *ctxt)
-
簽名升級image。注：app_update.bin已經是簽過名的image了
-
上傳image，即把app_update.bin傳送到目標設備
-
列出image以獲得image的hash值
-
測試image，即寫magic字段，以讓MCUboot進入DFU模式
-
復位設備，以重新進入MCUboot，從而MCUboot進入DFU模式，并執(zhí)行相應的swap操作，并完成兩個slot image之間的交換或者拷貝動作
-
Confirm image，即新image啟動成功后，對其image_ok字段進行置1操作
-
mcumgr conn add myCOM type="serial" connstring="dev=COM13,baud=115200,mtu=256" (Note: change the COM if needed)
-
mcumgr -c myCOM image upload app_update.bin
-
mcumgr -c myCOM image list
-
mcumgr -c myCOM image test
-
mcumgr -c myCOM reset
-
mcumgr -c myCOM image confirm
藍牙DFU流程解讀
當采用BLE作為傳輸層的時候，上面命令都被手機app打包成二進制數據包直接下發(fā)給設備端，但解析出來之后，你會發(fā)現藍牙DFU流程跟上面說明的流程基本上一模一樣。比如前面的00 00 00 02 00 01 00 00 bf ff，就是手機發(fā)給設備的第一條DFU命令或者說請求（request）。 我們再舉一個例子：上傳image命令（request），它的第一個數據包示例如下所示：
?從包頭02 00 00 eb 00 01 00 01可以看出，這個數據包將觸發(fā)handler：
img_mgmt_upload，我們再來看數據包payload的前面8個字節(jié)：bf 64 64 61 74 61 58 cc，bf表示后面是map數據，即key/value數據對，0x64，表示后面是text string數據，長度為4，從而得到64這個data item對應的payload為：64 61 74 61，即key=”data”；
從0x58開始，就表示value這個data item了，0x58表示這個item為字節(jié)串并且長度為下一個字節(jié)：0xcc，也就是說”data”這個key對應的value包含了0xcc個數據的字節(jié)流，這樣第一個key/value對解析完畢。然后再解析63 6c 65 6e 1a 00 02 05 a8，0x63，表示此item為text string數據，長度為3，從而得到payload為6c 65 6e，即key = ”len”；
0x1a表示此item為正數，count為后面4個字節(jié)，也就是說”len”這個key對應的value為0x000205a8，至此第二個key/value對解析完畢。以此類推，我們后面又可以解析出”sha”和”off”兩個key以及他們各自的value，最后碰到停止符：0xFF，整個map item結束。
前面說過，整個數據包的payload會通過參數傳給img_mgmt_upload作為實參，img_mgmt_upload的函數聲明為：
- img_mgmt_upload(struct mgmt_ctxt *ctxt)
這樣我們就把一個image chunk拷貝到變量：req.img_data，再通過如下代碼調用Flash訪問API。
如前所述，每一個request命令都會有一個response，比如上面request命令的response為：
- 03 00 00 0d 00 01 00 01 bf 62 72 63 00 63 6f 66 66 19 09 40 ff
- 02 00 00 32 00 01 00 00 BF 67 63 6F 6E 66 69 72 6D F4 64 68 61 73 68 58 20 47 7C C8 4B 52 27 23 03 DA 27 41 F1 1D 38 46 0F 11 AE DB 5E 75 A2 D3 25 0C 6E DE EF 15 84 24 49 FF，大家可以仿照上面的做法來解析一下這個數據包，它解析的結果是：調用img_mgmt_state_write，并寫入magic字段，同時將swap類型設為BOOT_SWAP_TYPE_TEST
- 02 00 00 02 00 00 00 05 BF FF，這個包解析的結果是：調用os_mgmt_reset，對設備進行復位
3.3 nrf dfu協(xié)議
nrf dfu協(xié)議就是nRF5 SDK使用的DFU協(xié)議，相信很多讀者都很熟悉它。 nrf dfu協(xié)議定義了兩個角色：controller和target，controller發(fā)request，target回response，一來一往，完成DFU傳輸過程。 nrf dfu定義了如下request命令以及他們的response。
Request命令的格式是：Opcode + parameters
Response的格式是：60 + Opcode + parameters
比如編碼：01 02 00 10 00 00，通過上面解析可以知道它是一個創(chuàng)建數據對象命令NRF_DFU_OP_OBJECT_CREATE，而這條命令的響應是：60 01 01，可以看出也符合上面的定義。
nrf dfu用到了對象概念，什么叫對象（object）？
對象分兩種：command object和data object，其中init包是command對象，而image chunk（image塊）是data對象。
我們可以進一步提煉一下，nrf dfu協(xié)議主要涉及的命令是如下幾個：
- 選擇對象（NRF_DFU_OP_OBJECT_SELECT），用來選擇init包或者image包
- 創(chuàng)建對象（NRF_DFU_OP_OBJECT_CREATE），用來創(chuàng)建init包或者一個image 4kB塊
- 寫對象（NRF_DFU_OP_OBJECT_WRITE），即傳輸實際數據。由于藍牙將命令和數據分成兩個不同characteristic，寫對象其實就是寫數據，是一個專門的characteristic：packet characteristic，因此發(fā)送寫對象命令時，就沒有必要加上Opcode，而是直接把數據寫到packet characteristic上。由于串口只有一個RX線，因此通過串口DFU的時候，寫對象命令還是有Opcode的。
- 獲取對象的CRC（NRF_DFU_OP_CRC_GET），用來獲取前面init包或者4kB image塊的CRC值
- 執(zhí)行對象（NRF_DFU_OP_OBJECT_EXECUTE），即把數據真正寫入Flash中
- 選擇init對象
- 創(chuàng)建init對象
- 執(zhí)行init對象
- 選擇image data對象
- 建第一個4kB data對象
- 寫對象，即設備（target）循環(huán)接收主機發(fā)過來的image chunk，直至4kB
- 計算4kB image塊的CRC，并返回給主機（controller）以供其校驗
- 執(zhí)行4kB image塊對象，即將其寫入到Flash中
- 循環(huán)往復，直至整個image寫入完畢
- 寫DFU標志，并復位設備
- 復位后進入Bootloader DFU模式，Bootloader完成后續(xù)的拷貝工作，至此整個DFU過程宣告結束
- 進入項目目錄：cd zephyrsamplessubsysmgmtmcumgrsmp_svr
- 編譯：west build -b nrf52840dk_nrf52840 -d build_nrf52840dk_nrf52840 -p -- -DOVERLAY_CONFIG="overlay-bt.conf"（根據你自己手上的板子情況，把nrf52840dk_nrf52840換成其他DK，比如nrf5340dk_nrf5340_cpuapp）
-
燒寫：west flash -d build_nrf52840dk_nrf52840，此時設備將廣播“Zephyr”
-
修改原始工程，比如廣播名字（CONFIG_BT_DEVICE_NAME="NEW_DFU"放在overlay-bt.conf中）再重新編譯，然后拷貝以下字段到手機版nRF Connect“build_nrf52840dk_nrf52840/zephyr/app_update.bin"
-
用手機nRF Connect連接設備，成功后，點擊右上角的“DFU”圖標，選擇前面的“app_update.bin”文件，然后選擇“Test and Confirm”，DFU開始
-
升級文件傳輸完畢，系統(tǒng)將重啟
-
MCUboot完成swap操作，并跳到新app，廣播將變成“NEW_DFU”
- 手機nRF Connect連接新app，并發(fā)送confirm命令
- 至此整個升級結束
- 準備。a. 安裝PC版nrfutil。nrfutil安裝有兩種方式，一種是直接下載exe文件，一種是以Python的方式進行安裝。nrfutil.exe直接下載鏈接為：https://github.com/NordicSemiconductor/pc-nrfutil/releases，記得把nrfutil.exe所在目錄放在Windows環(huán)境變量中。Python方式安裝nrfutil步驟如下所示： i. 安裝Python，下載地址//www.python.org/downloads/，安裝成功后請確保Windows環(huán)境變量包含Python目錄 ii. 通過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下載b. 進入nrf_dfu/ble_intFlash/sdk_change目錄，選擇你的SDK版本。比如ncs_v1.8.0，把nrf_dfu/ble_intFlash/sdk_change/ncs_v1.8.x下面內容直接覆蓋nrf倉庫目錄c. 建議大家對照例子里面的readme看一下還有沒有其他準備工作
- 進入項目目錄：cd nrf_dfu/ble_intFlash
- 編譯：west build -b nrf52840dk_nrf52840 -d build_nrf52840dk_nrf52840 -p（根據你自己手上的板子情況，把nrf52840dk_nrf52840換成其他DK，比如nrf5340dk_nrf5340_cpuapp）
-
燒寫：west flash -d build_nrf52840dk_nrf52840此時設備將廣播“Nordic_DFU”
-
修改原始工程:比如廣播名字（CONFIG_BT_DEVICE_NAME="NEW_DFU"），再重新編譯，然后拷貝“build_nrf52840dk_nrf52840/zephyr/ app_signed.hex”到update目錄
-
雙擊update目錄中的zip_generate.bat，將生成ble_intFlash.zip，將ble_intFlash.zip拷貝到手機nRF Connect中
-
用手機nRF Connect連接設備，成功后，點擊右上角的“DFU”圖標，選擇前面的“ble_intFlash.zip”文件
-
升級文件傳輸完畢，系統(tǒng)將重啟
-
MCUboot完成swap操作，并跳到新app，新app自動完成image confirm操作
-
此時廣播已經變成“NEW_DFU”，至此整個升級結束
從上面可以看出，這個partitions.yml定義了很多分區(qū)，比如app，mcuboot，mcuboot_pad，mcuboot_primary等（冒號前面的就是分區(qū)名），而且每一個分區(qū)規(guī)定了它的起始地址，結束地址，大小，相對位置以及放在什么物理存儲器上，比如app這個分區(qū)：
關于分區(qū)名，只有“app”這個名字是必須有，而且是固定的，代表著主應用程序image；其他分區(qū)名，比如mcuboot，settings_storage，external_flash等，都是隨意定義的，可以修改。
比如0x0~0xc000這塊內部Flash區(qū)，上面取名叫mcuboot，你也可以改成“my_boot”之類的名字，這個也沒關系的，取名字主要考慮兩點：一是能醒目標識這塊區(qū)域的功能，二是跟代碼里面的引用對起來，比如如下分區(qū)定義，經常有人困惑：
第一個“external_flash”是分區(qū)名，第二個“external_flash”是物理存儲器名。
作為分區(qū)名的“external_flash”，其實我們可以改成其他名字，以消除某些困惑，之所以使用這個名字，是因為老的littlefs例子里面對外部文件系統(tǒng)所在區(qū)域就稱為“external_flash”，代碼如下所示：
實際上最新的littlefs例子已經把這塊區(qū)域重新命名為：littlefs_storage或者storage，所以大家可以把這塊分區(qū)名改為littlefs_storage，如下：
partitions.yml 里面使用的 region 其實是在這個文件：nrfcmakepartition_manager.cmake定義的。
大家可以通過 build 目錄下的 regions.yml 文件得知目前定義了幾個物理存儲器：
至于partitions.yml里面使用的placement/span等，這個是用來指定各個分區(qū)的相對位置的，很多人會疑問，既然指定了分區(qū)的起始地址和結束地址，那還有必要去指定各個分區(qū)的相對位置嗎？
這種情況下的確沒必要再指定相對位置了，其實這里弄反了一件事情：partitions.yml里面的地址是placement相對位置定下來之后的結果。使用placement相對位置，為編譯系統(tǒng)動態(tài)確定各個分區(qū)的位置提供了便利。如果是我們自己來劃分存儲器的分區(qū)，我們就可以直接使用絕對地址的方式靜態(tài)指定各個分區(qū)的位置（當然使用placement也是可以的）。
如何人為靜態(tài)指定？
答案就是把剛才動態(tài)生成的partitions.yml文件拷貝到項目根目錄下，然后改名為：pm_static.yml，然后再按照自己的需求去修改，比如smp_dfu/ble_extFlash這個例子，如果由系統(tǒng)動態(tài)生成partitions.yml文件，此時mcuboot_secondary分區(qū)所在地址為0x0~0xf0000，而文件系統(tǒng)external_flash或者littlefs_storage分區(qū)所在地址為0xf0000~0x800000，實際上很多客戶喜歡把文件系統(tǒng)放在外部Flash 0x00地址，而把secondary slot放在外部flash最后，據此可以做如下修改：
這個pm_static.yml文件沒有定義的分區(qū)，還是由系統(tǒng)動態(tài)分配。有時為了后續(xù)升級方便，我們會在pm_static.yml文件里面把所有的分區(qū)都按照自己的規(guī)劃重新定義一遍，這樣就不擔心某個image突然變大而導致新的partitions.yml跟老的文件不兼容，從而無法升級。在定義pm_static.yml文件時，有如下規(guī)則必須遵守：
- mcuboot_primary大小必須等于mcuboot_secondary，而且CONFIG_BOOT_MAX_IMG_SECTORS最好也等于他們大小/4096
-
如果使用了一個region（flash_primary這個region除外），那么這個region每一塊區(qū)域都要屬于一個分區(qū)名字，不能出現某塊區(qū)域沒有分區(qū)名字情況。比如上面重新定義了external_flash region，根據regions.yml文件定義，external_flash總共有8Mbytes，那么這8Mbytes都必須有一個分區(qū)名字，而我們定義的littlefs_storage和mcuboot_secondary兩個分區(qū)的確包含了全部8MB區(qū)域。如果我們定義littlefs_storage所在區(qū)域為0x0~0x700000，而mcuboot_secondary所在區(qū)域為0x710000~0x800000，那么系統(tǒng)就會報錯，因為這里還有一個空隙（gap）：0x700000~0x710000是沒有取分區(qū)名字的。解決這個問題有兩個辦法：一個就是上面的方法把0x700000~0x710000劃到littlefs_storage分區(qū)，一個就是給這塊區(qū)域專門取一個名字，比如：my_unused_area（見下面示意），也是可以解決問題的。
對于flash_primary這個region，由于系統(tǒng)默認認為必須要有一個“app”分區(qū)，所以它可以存在而且只能存在一個空隙（gap），這樣系統(tǒng)默認這個gap就是“app”分區(qū)。當然你也可以把flash_primary所有區(qū)域都分好區(qū)，包括“app”分區(qū)。
- regions.yml文件里面各個存儲器的物理大小必須符合實際，這個通過修改dts文件來保證的。這里面最容易出錯的就是external_flash，external_flash的大小在regions.yml文件里面是以字節(jié)為單位（在kconfig文件里面也是以字節(jié)為單位的），但是external_flash對應的設備樹，比如MX25R64，它在dts文件里面是以bit為單位的，所以當大家使用其他外部Flash的時候，請仔細檢查這些size對不對
- settings_storage，即settings使用的分區(qū)，大家可以將分區(qū)名改成：storage，這是其一，其二settings系統(tǒng)最終使用的最大flash區(qū)域大小是由CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE決定，而不是settings_storage分區(qū)本身大小決定，所以建議大家把CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE的值設為settings_storage分區(qū)大小。
- 至于RAM分區(qū)，道理也是一樣的。這里需要注意的是，RAM各個分區(qū)的大小大家可以直接到dts文件里面去調整，而無需在pm_static.yml文件里面調整。當然，大家在pm_static.yml里面調整也是可以的，殊途同歸，達到目的就好了。對于nRF52系列，只有一個sram_primary分區(qū)，這個沒什么好講的；對于nRF53系列，除了sram_primary這個分區(qū)，它還有rpmsg_nrf53_sram分區(qū)以及pcd_sram分區(qū)，其中rpmsg_nrf53_sram是用來藍牙協(xié)議棧host和controller之間進行雙核通訊的，而pcd_sram是用來升級網絡核image的。
main.c的修改就更簡單，在啟動廣播之前，我們加入如下初始化函數：
smp_bt_register(); os_mgmt_register_group(); img_mgmt_register_group();
就這樣兩步工作，輕輕松松就把SMP DFU服務移植到peripheral_uart上，整個代碼已經上傳到：https://github.com/aiminhua/ncs_samples/tree/master/smp_dfu/peripheral_uart大家可以下載下來參考或者測試一下。 從上述例子我們可以看出，在NCS中移植一個例子非常方便，它不需要去添加c文件和頭文件，也不需要去修改編譯選項，還不需要去修改傳統(tǒng)的頭文件進行配置，僅僅修改conf文件和初始化函數，就輕輕松松完成了整個移植，這也是NCS非常大的一個好處。 https://github.com/aiminhua/ncs_samples/tree/master/smp_dfu其實鏈接下面包含的例子都同時具備smp和nus兩個服務，并且區(qū)分各種不同情形下的DFU情況，比如secondary slot在外部Flash，通過串口傳輸image等，同時其對peripheral_uart例子進行了小小改動，以更符合某些實際應用場景，建議大家好好看一下，相信對大家理解MCUboot和SMP會幫助不少。 ●6、手機端DFU參考代碼 ● Nordic不僅提供設備端的DFU參考代碼，同時提供手機端的參考代碼。Nordic分別開發(fā)了Android版和iOS版的DFU庫，大家可以直接拿過來使用，集成到自己的移動端app中，這兩個庫都放在github上，其中smp dfu對應的DFU庫鏈接如下所示：
- Android版SMP DFU庫：https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager
- iOS版SMP DFU庫：https://github.com/JuulLabs-OSS/mcumgr-ios
- Android版nrf dfu庫：https://github.com/NordicSemiconductor/Android-DFU-Library
- iOS版nrf dfu庫：https://github.com/NordicSemiconductor/IOS-DFU-Library
- Android版nRF Toolbox源代碼及開發(fā)說明請參考：https://github.com/NordicSemiconductor/Android-nRF-Toolbox
- iOS版nRF Toolbox源代碼及開發(fā)說明請參考：https://github.com/NordicSemiconductor/IOS-nRF-Toolbox
感興趣的朋友可以按步驟實操，今天Nordic君就分享到這里啦~
原文標題：【Nordic博文分享系列】nRF Connect SDK(NCS)/Zephyr固件升級詳解來啦！
文章出處：【微信公眾號：Nordic半導體】歡迎添加關注！文章轉載請注明出處。
審核編輯：湯梓紅
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
固件升級
+關注
關注
0文章
34瀏覽量
12099 -
NCS
+關注
關注
1文章
8瀏覽量
9076 -
Nordic
+關注
關注
9文章
168瀏覽量
47322
原文標題：【Nordic博文分享系列】nRF Connect SDK(NCS)/Zephyr固件升級詳解來啦！
文章出處：【微信號：nordicsemi，微信公眾號：Nordic半導體】歡迎添加關注！文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
如何實現自己的DFU
腳本是按照SDK版本進行分類的，建議大家把自己SDK版本對應的腳本下載下來，然后跟著第3章的操作步驟一步一步去實現自己的DFU。
轉：利用 USB DFU實現 IAP功能
前言伴隨著固件升級需求的增加，STM32提供了靈活的升級方式。本文一步一步介紹如何利用USB DFU Class以及ST提供的DfuSe demo軟件工具實現IAP（In Application
發(fā)表于 07-12 15:18
求助 STM32F205 DFU升級問題
做DFU升級的時候，進入DFU模式正常，升級正常，最后Level DFU Mode的時候卡在49%的位置，動不了。file:///C:/WI
發(fā)表于 10-04 13:37
stm32如何進入dfu模式
stm32如何進入dfu模式，相當部分的 STM32芯片都帶USB模塊,有時我們會考慮利用STM32芯片的USB模塊進行程序代碼的下載或升級。USB協(xié)議中有專門針對設備固件升級的類
發(fā)表于 08-09 08:09
STM32芯片的DFU編程
STM32芯片的DFU編程，相當部分的 STM32芯片都帶USB模塊,有時我們會考慮利用STM32芯片的USB模塊進行程序代碼的下載或升級。USB協(xié)議中有專門針對設備固件升級的類
發(fā)表于 08-09 08:41
基于DfuSe工具從APP跳轉到DFU模式
我們之前經常有講到過如何通過USB的DFU方式來對固件進行升級，在示例中我們通常是通過一個按鍵來觸發(fā)APP跳轉到BOOT從而進入到DFU升級模式。
megawin_USB_DFU_v1.22升級
DFU（設備固件升級）可以直接通過USB電纜執(zhí)行固件升級，而無需通過執(zhí)行一些簡單的步驟重新連接設備。
發(fā)表于 06-21 15:35
?2次下載
如何使用CubeMx生成一個DFU工程
DFU用來做IAP是很方便的，可以直接通過USB來對APP進行升級，因此，掌握DFU的制作還是挺有好處，特別是使用CubeMx工具可以快速制作，本文將基于STM3240G-EVL評估板來一步一步實現一個
AN3156_基于STM32微控制器引導程序的USB_DFU協(xié)議應用手冊
AN3156_基于STM32微控制器引導程序的USB_DFU協(xié)議應用手冊
發(fā)表于 11-21 17:07
?3次下載
AN3156_STM32 引導加載程序中使用的 USB DFU 協(xié)議
AN3156_STM32 引導加載程序中使用的 USB DFU 協(xié)議
發(fā)表于 11-21 17:07
?2次下載
工商網監(jiān)
評論