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

簽名升級(jí)的image，注：app_update.bin已經(jīng)是簽過(guò)名的image了

上傳image，即把a(bǔ)pp_update.bin傳送到目標(biāo)設(shè)備

列出image以獲得image的hash值

測(cè)試image，即寫(xiě)magic字段，以讓MCUboot進(jìn)入DFU模式復(fù)位設(shè)備，以重新進(jìn)入MCUboot，從而MCUboot進(jìn)入DFU模式，并執(zhí)行相應(yīng)的swap操作，并完成兩個(gè)slot image之間的交換或者拷貝動(dòng)作

Confirm image，即新image啟動(dòng)成功后，對(duì)其image_ok字段進(jìn)行置1操作

按照前面所述，為了實(shí)現(xiàn)OTA的功能，需要DFU協(xié)議來(lái)將新的image傳輸?shù)侥愕牡诙謪^(qū)里面即secondary slot，nRF Connect SDK里面最重要的DFU協(xié)議就是SMP——Simple Management Protocol，此協(xié)議用來(lái)管理整個(gè)升級(jí)流程，包括設(shè)備的分區(qū)狀態(tài)，設(shè)備的復(fù)位，設(shè)備MCUboot交換文件的時(shí)候是test還是confirm等。

SMP協(xié)議是應(yīng)用層協(xié)議，與鏈路層不是一個(gè)概念，或者說(shuō)應(yīng)用層協(xié)議是建立在鏈路層的基礎(chǔ)上的，所以物理通道上，最后我們可以使用多種方式，USB， UART，BLE，或者TCP UDP都是可以的。

本文重點(diǎn)講解的是SMP協(xié)議，以及它的數(shù)據(jù)格式，后面對(duì)升級(jí)過(guò)程中對(duì)每條指令進(jìn)行講解。在講解SMP數(shù)據(jù)格式之前，我們先解說(shuō)一下CBOR數(shù)據(jù)格式，因?yàn)镾MP的payload里面的所有數(shù)據(jù)都必須使用這個(gè)數(shù)據(jù)格式。

一、CBOR格式和數(shù)據(jù)解讀

CBOR是一種數(shù)據(jù)格式，其設(shè)計(jì)目標(biāo)包括極小的代碼大小、相當(dāng)小的消息大小以及無(wú)需版本協(xié)商的可擴(kuò)展性的可能性。該表示必須能夠明確地編碼互聯(lián)網(wǎng)標(biāo)準(zhǔn)中使用的最常見(jiàn)的數(shù)據(jù)格式。

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

數(shù)據(jù)必須能夠在沒(méi)有模式描述的情況下被解碼

序列化必須相當(dāng)緊湊

該格式必須適用于受限節(jié)點(diǎn)和大容量應(yīng)用程序

該格式必須支持所有 JSON 數(shù)據(jù)類型以便與 JSON 相互轉(zhuǎn)換

格式必須是可擴(kuò)展的

單個(gè) CBOR ，即一個(gè)數(shù)據(jù)項(xiàng)的結(jié)構(gòu)可以包含零個(gè)、一個(gè)或多個(gè)嵌套數(shù)據(jù)項(xiàng)，在基本（未擴(kuò)展）通用數(shù)據(jù)模型中，數(shù)據(jù)項(xiàng)是以下之一：

0-正數(shù)

1-負(fù)數(shù)

2-字節(jié)串（byte string）

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

4-數(shù)組

5-map（又稱字典）

6-tag（這個(gè)用得少）

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

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

整數(shù)

文本字符串

數(shù)組

和字典

每個(gè)編碼數(shù)據(jù)項(xiàng)的初始字節(jié)包含有關(guān)主要類型的信息（高位 3 位,用來(lái)表示數(shù)據(jù)項(xiàng)）和附加信息（低位 5 位表示數(shù)據(jù)值），少數(shù)編碼例外：

小于 24：參數(shù)的值是附加信息的值。

24、25、26 或 27：參數(shù)的值按網(wǎng)絡(luò)字節(jié)順序分別保存在以下 1、2、4 或 8 個(gè)字節(jié)中。對(duì)于主類型 7 和附加信息值 25、26、27，這些字節(jié)不用作整數(shù)參數(shù)，而是用作浮點(diǎn)值。

28、29、30：這些值被保留以供將來(lái)添加到 CBOR 格式中。在當(dāng)前版本的 CBOR 中，編碼項(xiàng)的格式不正確。

31：沒(méi)有導(dǎo)出任何參數(shù)值。如果主要類型為 0、1 或 6，則編碼項(xiàng)的格式不正確。對(duì)于主要類型2至5，該項(xiàng)的長(zhǎng)度是不定長(zhǎng)的，對(duì)于主要類型7，該字節(jié)根本不構(gòu)成數(shù)據(jù)項(xiàng)，而是終止一個(gè)不定長(zhǎng)項(xiàng)。

CBOR 解碼器實(shí)現(xiàn)可以基于包含初始字節(jié)的所有 256 個(gè)定義值的跳轉(zhuǎn)表，我們經(jīng)常使用的表格如下：

示例：

用定長(zhǎng)和不定長(zhǎng)數(shù)組來(lái)表示[1, [2, 3], [4, 5]]:

二、SMP的數(shù)據(jù)格式如下

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

2.1 定義里面各數(shù)據(jù)域的解釋如下：

2.1.1 Operation Code 對(duì)應(yīng)的定義如下：

0：read request

1：read response

2：write request

3：write response

每一條request都有一條response指令作應(yīng)：

read response就是read request的應(yīng)答；

write response就是write request的應(yīng)答。

21.2 跟 nRF Connect SDK 相關(guān)的 Management Group ID, 以及對(duì)應(yīng)Group下面對(duì)應(yīng)的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 我們?cè)倭谐?nRF Connect SDK dfu使用的指令

前言里 DFU 流程對(duì)應(yīng)的命令如下：

1. mcumgr add myCOM type=“serial“ connstring=”dev=COM13,baud=115200,mtu=256” (UART升級(jí)和USB升級(jí))
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：

示例數(shù)據(jù)為：00 00 00 01 00 FF 06 A0。

對(duì)應(yīng)image header的8個(gè)字節(jié)就是 00 00 00 01 00 FF 06, A0表示一個(gè)空的字典。

response

示例數(shù)據(jù)為：

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。

對(duì)應(yīng)image header的8個(gè)字節(jié)為：01 00 00 19 00 00 FF 06

Payload對(duì)應(yīng)為：

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。

我們解析一下這塊數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)格式：

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

那么我們?nèi)绾卫斫馕覀冞@個(gè)數(shù)據(jù)的意思呢，我們?cè)倏磎cumgr parameter response的數(shù)據(jù)格式：

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

???這里我們就可以理解了，這條指令就是看設(shè)備里面配置的參數(shù)，我們的buf_size 設(shè)置的是多大，配置了多少個(gè)這么大的buf；對(duì)應(yīng)我們?cè)購(gòu)臋C(jī)代碼里面設(shè)置的參數(shù)是什么呢？就是這兩條參數(shù)：

CONFIG_MCUMGR_BUF_SIZE=2475
CONFIG_MCUMGR_BUF_COUNT=4

2.3.2 mcumgr image upload

request

數(shù)據(jù)為：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。

對(duì)應(yīng)image header的8個(gè)字節(jié)為：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。

我們解析一下這塊數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)格式：

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

那么我們?cè)賮?lái)看一下這條寫(xiě)指令對(duì)應(yīng)的CBOR的數(shù)據(jù)格式：

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

那么這條指令對(duì)應(yīng)的意思就是向設(shè)備發(fā)送一條長(zhǎng)度為2432字節(jié)的image數(shù)據(jù)，它的偏移地址為1CA0；如此循環(huán)往復(fù)，第二包在第一包的基礎(chǔ)上增加偏移量，一直傳輸?shù)阶詈笠话?；?duì)于2432超過(guò)MTU的大小的話，那就需要對(duì)2432字節(jié)再次分包發(fā)送，并等待設(shè)備的image upload response.其中，sequence number會(huì)遞增加1。

response

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

對(duì)應(yīng)image header的8個(gè)字節(jié)就是 03 00 00 0D 00 01 03 01，當(dāng)中0x0D表示數(shù)據(jù)長(zhǎng)度為13字節(jié)。

對(duì)應(yīng)payload為：BF 62 72 63 00 63 6F 66 66 19 1C A0 FF。

我們解析一下這塊數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)格式：

BF                  ------字典的開(kāi)始 
  62                ------字節(jié)string數(shù)組，長(zhǎng)度為3 
      72 63         ------“rc” 字段 
  00                ------整數(shù)，值為0 
  63                ------字節(jié)string數(shù)組，長(zhǎng)度為3 
      6F 66 66      ------“off” 字段 
  19  
      1C A0         ------這端數(shù)據(jù)偏移地址為1CA0 
FF                  ------結(jié)束符

我們?cè)賮?lái)看一下這條寫(xiě)應(yīng)答對(duì)應(yīng)的CBOR的數(shù)據(jù)格式：

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

這條應(yīng)答指令的意思就是，剛才那條寫(xiě)image命令沒(méi)有出錯(cuò)(此處對(duì)應(yīng)的rc為0)，然后它的偏移地址為1CA0。

2.3.3 mcumgr image list

request ：

數(shù)據(jù)為：00 00 00 02 00 01 00 00 BF FF。

對(duì)應(yīng)image header的8個(gè)字節(jié)就是 00 00 00 02 00 01 00 00，數(shù)據(jù)BF FF表示一個(gè)空的字典。

response

數(shù)據(jù)為：

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。

對(duì)應(yīng)image header的8個(gè)字節(jié)就是 01 00 00 86 00 01 00 00，86表示整段數(shù)據(jù)長(zhǎng)度為0x86字節(jié)。

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。

我們解析一下這塊數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)格式：

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   ------長(zhǎng)度為32字節(jié)的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 

此命令對(duì)應(yīng)的CBOR數(shù)據(jù)格式如下：

{
  (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)
}

通過(guò)這條指令，可以看到1個(gè)或2個(gè)slot分區(qū)里面的image的狀態(tài)是不是confirmed，是不是active等等。

2.3.4 mcumgr image test

request:

對(duì)應(yīng)的數(shù)據(jù)為：

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。

對(duì)應(yīng)image header的8個(gè)字節(jié)就是 02 00 00 32 00 01 61 00。

對(duì)應(yīng)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。

我們解析一下這塊數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)格式：

BF                            ------字典的開(kāi)始
  67                          ------字節(jié)string數(shù)組，長(zhǎng)度為7
      63 6F 6E 66 69 72 6D    ------ “confirm”  字段
  F4                          ------值為false
  64                          ------字節(jié)string數(shù)組，長(zhǎng)度為4
      68 61 73 68             ------“hash” 字段
  58 20                       ------長(zhǎng)度為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字節(jié)hash值
FF                            ------字典結(jié)束 

這條寫(xiě)命令對(duì)應(yīng)的CBOR的數(shù)據(jù)格式：

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

可以看出，這條指令對(duì)應(yīng)的意思就是，下發(fā)confirm為false的帶hash值的寫(xiě)命令。

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

如果“confirm”為 false，則將設(shè)置帶有“hash”的值進(jìn)行測(cè)試，這意味著它將不會(huì)被標(biāo)記為永久，并且在復(fù)位之后，以前的應(yīng)用程序?qū)?huì)回滾到之前的image。如果“confirm” 為 true，則 “hash” 是可選的，當(dāng)前運(yùn)行的應(yīng)用程序?qū)⒈辉O(shè)置為目標(biāo)運(yùn)行程序，意味著不再回滾到之前的版本。

response

其應(yīng)答與image list response應(yīng)答相同，不再重復(fù)。

2.3.5 mcumgr reset

request

數(shù)據(jù)為：02 00 00 02 00 00 62 05 BF FF。

對(duì)應(yīng)image header的02 00 00 02 00 00 62 05；

Payload為：BF FF，表示這是一個(gè)空的map，沒(méi)有實(shí)際數(shù)據(jù)。

response

數(shù)據(jù)為：03 00 00 02 00 00 62 05 BF FF。

對(duì)應(yīng)image header的03 00 00 02 00 00 62 05。

Payload為：BF FF，表示這是一個(gè)空的map，沒(méi)有實(shí)際數(shù)據(jù)。

三、SMP central的實(shí)現(xiàn)

SMP central的實(shí)現(xiàn)按照上面所述流程操作，那么我們首先就是需要把升級(jí)文件放到內(nèi)部或者外部flash里面，central通過(guò)內(nèi)部代碼把flash操作讀出來(lái)，通過(guò)指令完成image upload操作。

上述有幾個(gè)步驟，可以通過(guò)發(fā)命令遠(yuǎn)程去完成，也可以通過(guò)調(diào)用本地API自己去完成，兩種選擇都可以。

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

Mcumgr parameter指令也可以不通過(guò)request完成操作，我們只需要在central端和peripheral端統(tǒng)一好參數(shù)就可以。

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;

審核編輯 黃宇