nRF Connect SDK的OTA，默認都是使用MCUboot(或者帶B0功能)，即一個開源的第三方bootloader程序；在這里我們重新理一下nRF Connect SDK OTA的整個流程：

簽名升級的image，注：app_update.bin已經是簽過名的image了

上傳image，即把app_update.bin傳送到目標設備

列出image以獲得image的hash值

測試image，即寫magic字段，以讓MCUboot進入DFU模式復位設備，以重新進入MCUboot，從而MCUboot進入DFU模式，并執行相應的swap操作，并完成兩個slot image之間的交換或者拷貝動作

Confirm image，即新image啟動成功后，對其image_ok字段進行置1操作

按照前面所述，為了實現OTA的功能，需要DFU協議來將新的image傳輸到你的第二分區里面即secondary slot，nRF Connect SDK里面最重要的DFU協議就是SMP——Simple Management Protocol，此協議用來管理整個升級流程，包括設備的分區狀態，設備的復位，設備MCUboot交換文件的時候是test還是confirm等。

SMP協議是應用層協議，與鏈路層不是一個概念，或者說應用層協議是建立在鏈路層的基礎上的，所以物理通道上，最后我們可以使用多種方式，USB， UART，BLE，或者TCP UDP都是可以的。

本文重點講解的是SMP協議，以及它的數據格式，后面對升級過程中對每條指令進行講解。在講解SMP數據格式之前，我們先解說一下CBOR數據格式，因為SMP的payload里面的所有數據都必須使用這個數據格式。

一、CBOR格式和數據解讀

CBOR是一種數據格式，其設計目標包括極小的代碼大小、相當小的消息大小以及無需版本協商的可擴展性的可能性。該表示必須能夠明確地編碼互聯網標準中使用的最常見的數據格式。

編碼器或解碼器的代碼必須能夠緊湊，以便支持內存、處理器能力和指令集非常有限的系統

數據必須能夠在沒有模式描述的情況下被解碼

序列化必須相當緊湊

該格式必須適用于受限節點和大容量應用程序

該格式必須支持所有 JSON 數據類型以便與 JSON 相互轉換

格式必須是可擴展的

單個 CBOR ，即一個數據項的結構可以包含零個、一個或多個嵌套數據項，在基本（未擴展）通用數據模型中，數據項是以下之一：

0-正數

1-負數

2-字節串（byte string）

3-UTF-8字符串（text string）

4-數組

5-map（又稱字典）

6-tag（這個用得少）

7-浮點數或者特殊類型，其中特殊類型將short count 20–23定義為 false, true, null和undefined

CBOR包含數據格式眾多，在nRF Connect SDK里面使用最多的是下面幾種格式：

整數

文本字符串

數組

和字典

每個編碼數據項的初始字節包含有關主要類型的信息（高位 3 位,用來表示數據項）和附加信息（低位 5 位表示數據值），少數編碼例外：

小于 24：參數的值是附加信息的值。

24、25、26 或 27：參數的值按網絡字節順序分別保存在以下 1、2、4 或 8 個字節中。對于主類型 7 和附加信息值 25、26、27，這些字節不用作整數參數，而是用作浮點值。

28、29、30：這些值被保留以供將來添加到 CBOR 格式中。在當前版本的 CBOR 中，編碼項的格式不正確。

31：沒有導出任何參數值。如果主要類型為 0、1 或 6，則編碼項的格式不正確。對于主要類型2至5，該項的長度是不定長的，對于主要類型7，該字節根本不構成數據項，而是終止一個不定長項。

CBOR 解碼器實現可以基于包含初始字節的所有 256 個定義值的跳轉表，我們經常使用的表格如下：

示例：

用定長和不定長數組來表示[1, [2, 3], [4, 5]]:

二、SMP的數據格式如下

注意： 
  原生SMP specification是支持Big-endian 和Little-endian，
  但實際上mcumgr-library已經固定使用Big-endian模式。

2.1 定義里面各數據域的解釋如下：

2.1.1 Operation Code 對應的定義如下：

0：read request

1：read response

2：write request

3：write response

每一條request都有一條response指令作應：

read response就是read request的應答；

write response就是write request的應答。

21.2 跟 nRF Connect SDK 相關的 Management Group ID, 以及對應Group下面對應的Command ID如下：

0：Default/OS Management Group

0．Echo

4．System reset

5．MCUMGR parameter

1：Application/software image management group

0．State of images

1．Image upload

2.2 我們再列出 nRF Connect SDK dfu使用的指令

前言里 DFU 流程對應的命令如下：

1. mcumgr add myCOM type=“serial“ connstring=”dev=COM13,baud=115200,mtu=256” (UART升級和USB升級)
2. mcumgr parameter request
3. mcumgr image upload app_update.bin
4. mcumgr image list
5. mcumgr image test 
6. mcumgr reset
7. mcumgr image confirm.

2.3 完整解讀SMP指令

2.3.1 mcumgr parameter

request：

示例數據為：00 00 00 01 00 FF 06 A0。

對應image header的8個字節就是 00 00 00 01 00 FF 06, A0表示一個空的字典。

response

示例數據為：

01 00 00 19 00 00 FF 06 BF 68 62 75 66 5F 73 69 7A 65 19 09 AB 69 62 75 66 5F 63 6F 75 6E 74 04 FF。

對應image header的8個字節為：01 00 00 19 00 00 FF 06

Payload對應為：

BF 68 62 75 66 5F 73 69 7A 65 19 09 AB 69 62 75 66 5F 63 6F 75 6E 74 04 FF。

我們解析一下這塊數據對應的數據格式：

BF                                    --------map 
  68                                  ------數組，8個字節 
      62 75 66 5F 73 69 7A 65         ------“buf_size” 
  19                                  ------整數值，用2字節表示 
      09 AB                           ------2475 
  69                                  ------數組，9個字節 
      62 75 66 5F 63 6F 75 6E 74      ------“buf_count” 
  04                                  ------整數，數值就是4
FF                                    ------結束符 

那么我們如何理解我們這個數據的意思呢，我們再看mcumgr parameter response的數據格式：

{
  (str)"buf_size"   :(uint) 
  (str)"buf_count"  :(uint) 
  (opt,str)"rc"     :(int)
}

???這里我們就可以理解了，這條指令就是看設備里面配置的參數，我們的buf_size 設置的是多大，配置了多少個這么大的buf；對應我們再從機代碼里面設置的參數是什么呢？就是這兩條參數：

CONFIG_MCUMGR_BUF_SIZE=2475
CONFIG_MCUMGR_BUF_COUNT=4

2.3.2 mcumgr image upload

request

數據為：02 00 09 A0 00 01 01 01 BF 64 64 61 74 61 59 09 80 ………payload (2432 bytes)…….63 6F 66 66 19 1C A0 FF。

對應image header的8個字節為：02 00 09 A0 00 01 01 01，這是第一包upload指令，sequence number為1。

Payload為：BF 64 64 61 74 61 59 09 80 ………payload (2432 bytes)…….63 6F 66 66 19 1C A0 FF。

我們解析一下這塊數據對應的數據格式：

BF                    ------字典的開始 
  64                  ------字節string數組，長度為4 
      64 61 74 61     ------“data” 字段 
  59                  ------長度為2字節字符串 
      09 80           ------這一包數據長度為 “2432” 
  63                  ------字節string數組，長度為3 
      6F 66 66        ------“off” 字段 
  19                  ------整數值，2字節表示 
      1C A0           ------這端數據偏移地址為1CA0 
FF                    ------結束符 

那么我們再來看一下這條寫指令對應的CBOR的數據格式：

{
  {
    (str,opt)"image"   :(uint)
    (str,opt)"len"     :(uint) 
    (str)"off"         :(uint)
    (str,opt)"sha"     :(str)
    (str,opt)"data"    :(byte str)
    (str,opt)"upgrade" :(bool)
  }
}

那么這條指令對應的意思就是向設備發送一條長度為2432字節的image數據，它的偏移地址為1CA0；如此循環往復，第二包在第一包的基礎上增加偏移量，一直傳輸到最后一包；對于2432超過MTU的大小的話，那就需要對2432字節再次分包發送，并等待設備的image upload response.其中，sequence number會遞增加1。

response

數據為：03 00 00 0D 00 01 03 01 BF 62 72 63 00 63 6F 66 66 19 1C A0 FF。

對應image header的8個字節就是 03 00 00 0D 00 01 03 01，當中0x0D表示數據長度為13字節。

對應payload為：BF 62 72 63 00 63 6F 66 66 19 1C A0 FF。

我們解析一下這塊數據對應的數據格式：

BF                  ------字典的開始 
  62                ------字節string數組，長度為3 
      72 63         ------“rc” 字段 
  00                ------整數，值為0 
  63                ------字節string數組，長度為3 
      6F 66 66      ------“off” 字段 
  19  
      1C A0         ------這端數據偏移地址為1CA0 
FF                  ------結束符

我們再來看一下這條寫應答對應的CBOR的數據格式：

{
  (str,opt)"off"  :(uint) 
  (str)"rc"       :(int)
  (str,opt)"rsn"  :(str)
}

這條應答指令的意思就是，剛才那條寫image命令沒有出錯(此處對應的rc為0)，然后它的偏移地址為1CA0。

2.3.3 mcumgr image list

request ：

數據為：00 00 00 02 00 01 00 00 BF FF。

對應image header的8個字節就是 00 00 00 02 00 01 00 00，數據BF FF表示一個空的字典。

response

數據為：

01 00 00 86 00 01 00 00 BF 66 69 6D 61 67 65 73 9F BF 64 73 6C 6F 74 00 67 76 65 72 73 69 6F 6E 65 30 2E 30 2E 30 64 68 61 73 68 58 20 68 3D BA 00 D2 7C 7A D4 98 A7 D5 BA 55 55 BB B4 E8 CA 9F EA 91 DD CC FC A2 F8 DD 13 40 A0 05 79 68 62 6F 6F 74 61 62 6C 65 F5 67 70 65 6E 64 69 6E 67 F4 69 63 6F 6E 66 69 72 6D 65 64 F5 66 61 63 74 69 76 65 F5 69 70 65 72 6D 61 6E 65 6E 74 F4 FF FF 6B 73 70 6C 69 74 53 74 61 74 75 73 00 FF。

對應image header的8個字節就是 01 00 00 86 00 01 00 00，86表示整段數據長度為0x86字節。

Payload為：

BF 66 69 6D 61 67 65 73 9F BF 64 73 6C 6F 74 00 67 76 65 72 73 69 6F 6E 65 30 2E 30 2E 30 64 68 61 73 68 58 20 68 3D BA 00 D2 7C 7A D4 98 A7 D5 BA 55 55 BB B4 E8 CA 9F EA 91 DD CC FC A2 F8 DD 13 40 A0 05 79 68 62 6F 6F 74 61 62 6C 65 F5 67 70 65 6E 64 69 6E 67 F4 69 63 6F 6E 66 69 72 6D 65 64 F5 66 61 63 74 69 76 65 F5 69 70 65 72 6D 61 6E 65 6E 74 F4 FF FF 6B 73 70 6C 69 74 53 74 61 74 75 73 00 FF。

我們解析一下這塊數據對應的數據格式：

BF
  66
      69 6D 61 67 65 73                   ------“images“ 字段 
  9F
        BF
        64
            73 6C 6F 74                   ------ “slot” 字段，值為0 
            00
        67
            76 65 72 73 69 6F 6E          ------“version” 字段 
        65
            30 2E 30 2E 30                ------值為”0.0.0” 
        64
            68 61 73 68                   ------ “hash” 字段 
        58 20
            68 3D BA 00 D2 7C 7A D4 98 A7 D5 BA 55 55 BB B4 E8 CA 9F EA 91 DD CC FC A2 F8 DD 13 40 A0 05 79   ------長度為32字節的hash值 
        68
            62 6F 6F 74 61 62 6C 65       ------ “bootable” 字段，值為false 
            F5
        67
            70 65 6E 64 69 6E 67          ------ “pending” 字段，值為 false. 
            F4
        69
            63 6F 6E 66 69 72 6D 65 64    ------ “confirmed” 字段，值為 true. 
            F5
        66
            61 63 74 69 76 65             ------“active” 字段，值為 true 
            F5
        69
            70 65 72 6D 61 6E 65 6E 74    ------ “permanent” 字段，值為 false 
            F4
        FF
  FF
  6B
      73 70 6C 69 74 53 74 61 74 75 73    ------  “splitstatus”  字段，值為false 
      00
FF 

此命令對應的CBOR數據格式如下：

{
  (str)"images":[
  {
    (str,opt)"image"      :(int)
    (str)"slot"           :(int)
    (str)"version"        :(str)
    (str)"hash"           :(str)
    (str,opt)"bootable"   :(bool)
    (str,opt)"pending"    :(bool) 
    (str,opt) "confirmed" :(bool)
    (str,opt)"active"     :(bool) 
    (str,opt)"permanent"  :(bool)
  }
  ]
  (str,opt)"splitStatus"  :(int)
}

通過這條指令，可以看到1個或2個slot分區里面的image的狀態是不是confirmed，是不是active等等。

2.3.4 mcumgr image test

request:

對應的數據為：

02 00 00 32 00 01 61 00 BF 67 63 6F 6E 66 69 72 6D F4 64 68 61 73 68 58 20 EF 71 9F 16 7C 06 8F 44 AC 53 DD 89 1C F9 CD 05 3F 0A 34 B2 A0 75 2F 62 87 C3 97 CC 68 7C AE 4A FF。

對應image header的8個字節就是 02 00 00 32 00 01 61 00。

對應payload為：

BF 67 63 6F 6E 66 69 72 6D F4 64 68 61 73 68 58 20 EF 71 9F 16 7C 06 8F 44 AC 53 DD 89 1C F9 CD 05 3F 0A 34 B2 A0 75 2F 62 87 C3 97 CC 68 7C AE 4A FF。

我們解析一下這塊數據對應的數據格式：

BF                            ------字典的開始
  67                          ------字節string數組，長度為7
      63 6F 6E 66 69 72 6D    ------ “confirm”  字段
  F4                          ------值為false
  64                          ------字節string數組，長度為4
      68 61 73 68             ------“hash” 字段
  58 20                       ------長度為0x20的bin string類型
  EF 71 9F 16 7C 06 8F 44 AC 53 DD 89 1C F9 CD 05 3F 0A 34 B2 A0 75 2F 62 87 C3 97 CC 68 7C AE 4A     ------32字節hash值
FF                            ------字典結束 

這條寫命令對應的CBOR的數據格式：

{
  (str,opt)"hash" :(str)
  (str)"confirm"  :(bool)
}

可以看出，這條指令對應的意思就是，下發confirm為false的帶hash值的寫命令。

Mcumgr Confirm request指令與其類似，zephyr文檔寫到：

如果“confirm”為 false，則將設置帶有“hash”的值進行測試，這意味著它將不會被標記為永久，并且在復位之后，以前的應用程序將會回滾到之前的image。如果“confirm” 為 true，則 “hash” 是可選的，當前運行的應用程序將被設置為目標運行程序，意味著不再回滾到之前的版本。

response

其應答與image list response應答相同，不再重復。

2.3.5 mcumgr reset

request

數據為：02 00 00 02 00 00 62 05 BF FF。

對應image header的02 00 00 02 00 00 62 05；

Payload為：BF FF，表示這是一個空的map，沒有實際數據。

response

數據為：03 00 00 02 00 00 62 05 BF FF。

對應image header的03 00 00 02 00 00 62 05。

Payload為：BF FF，表示這是一個空的map，沒有實際數據。

三、SMP central的實現

SMP central的實現按照上面所述流程操作，那么我們首先就是需要把升級文件放到內部或者外部flash里面，central通過內部代碼把flash操作讀出來，通過指令完成image upload操作。

上述有幾個步驟，可以通過發命令遠程去完成，也可以通過調用本地API自己去完成，兩種選擇都可以。

比如confirm image這一步，你可以等待新image啟動成功，然后重連主機，主機再發“confirm image”命令，這個時候升級才算真正完成；也可以在新image啟動成功后，在不連主機的情況下，通過調用前述API：boot_write_img_confirmed () 來完成這個確認過程。不管采用那種方法，本質上都是調用 boot_write_img_confirmed () 來實現，不同的是觸發方式或者時機，發命令的方式由主機遠程觸發（SMP DFU 就是選擇這種主機遠程發命令方式），而本地API方式則是設備自己選擇時機來觸發（nrf dfu 就是選擇這種本地API調用方式。

Mcumgr parameter指令也可以不通過request完成操作，我們只需要在central端和peripheral端統一好參數就可以。

3.1 Mcumgr reset指令：

SMP Payload

zcbor_map_start_encode(zse, CBOR_MAP_MAX_ELEMENT_CNT);
zcbor_map_end_encode(zse, CBOR_MAP_MAX_ELEMENT_CNT);

SMP Header

smp_cmd.header.op = 2; /* Write */
smp_cmd.header.flags = 0;
smp_cmd.header.len_h8 = (uint8_t)((payload_len >> 8) & 0xFF);
smp_cmd.header.len_l8 = (uint8_t)((payload_len >> 0) & 0xFF);
smp_cmd.header.group_h8 = 0;
smp_cmd.header.group_l8 = 0; /* OS */
smp_cmd.header.seq = load_seq;

3.2 Mcumgr test指令：

SMP Payload

zcbor_map_start_encode(zse, CBOR_MAP_MAX_ELEMENT_CNT);
zcbor_tstr_put_lit(zse, "confirm");
zcbor_bool_put(zse, false);
zcbor_tstr_put_lit(zse, "hash");
zcbor_bstr_put_lit(zse, hash_value_secondary_slot);

SMP Header

smp_cmd.header.op = 2; /* Write */
smp_cmd.header.flags = 0;
smp_cmd.header.len_h8 = (uint8_t)((payload_len >> 8) & 0xFF);
smp_cmd.header.len_l8 = (uint8_t)((payload_len >> 0) & 0xFF);
smp_cmd.header.group_h8 = 0;
smp_cmd.header.group_l8 = 1; /* app/image */
smp_cmd.header.seq = load_seq;

3.3 Mcumgr upload指令：

SMP Payload

if(!zcbor_map_start_encode(zse, encode_len))
  LOG_INF("zcbor_map_start_encode(zse, encode_len) fail");
zcbor_tstr_put_lit(zse, "data");
if(!zcbor_bstr_encode_ptr(zse, data, upload_chunk))
  LOG_INF("zcbor_bstr_encode_ptr(zse, data, upload_chunk) fail");
zcbor_tstr_put_lit(zse, "len");
if(!zcbor_uint64_put(zse, (uint64_t)(last_addr-start_addr)))
  LOG_INF("zcbor_uint64_put(zse, (uint64_t)(last_addr-start_addr)) fail");

zcbor_tstr_put_lit(zse, "sha");
zcbor_bstr_put_lit(zse, "123");

zcbor_tstr_put_lit(zse, "off");
if(!zcbor_uint64_put(zse, curr_addr - start_addr))
LOG_INF("zcbor_uint64_put(zse, curr_addr - start_addr) fail");

SMP Header

smp_cmd.header.op = 2; /* write request */
smp_cmd.header.flags = 0;
smp_cmd.header.len_h8 = (uint8_t)((payload_len >> 8) & 0xFF);
smp_cmd.header.len_l8 = (uint8_t)((payload_len >> 0) & 0xFF);
smp_cmd.header.group_h8 = 0;
smp_cmd.header.group_l8 = 1; /* IMAGE */
smp_cmd.header.seq = load_seq;

審核編輯 黃宇