 |  | |
OAD 概述
本章節旨在從更高層次解釋OAD主要概念，這些概念将在下一章節進一步擴充。一些概念，例如Boot鏡像管理（BIM）在具體實作細節上可能有所不同。但是本章盡可能的覆寫這些概念，下一章節解釋它們具體實作細節。
OAD類型
BLE5-Stack隻支援片外OAD（off-chip OAD）。下載下傳的鏡像檔案儲存在低功耗的外部flash裡面，通過BIM加載到C2640R2F内部flash中。
OAD 拓撲概述
實作OAD自定義GATT service需要兩個BLE裝置。OAD資料交換中涉及以下定義：
| 名稱 | 概念 |
|---|---|
| OAD Target | 該裝置固件通過空中傳輸更新，該裝置必須支援TI OAD service |
| OAD Downloader | 該裝置負責接收鏡像檔案，然後通過空中傳輸傳送給OAD Target |
OAD Target始終是實作OAD服務GATT服務端的裝置。通常它是一個将要進行固件更新的peripheral裝置。OAT Target使用boot鏡像管理器（BIM）協助應用程式進行新的固件鏡像檔案更新。當裝置複位之後執行BIM，并确定是否進行固件更新，如果沒有固件更新，BIM将跳轉到主程式運作。
OAD Downloader始終是實作OAD服務GATT用戶端的裝置。通常它是提供固件更新鏡像檔案的central裝置。下圖顯示了執行OAD所需的裝置。OAD Downloader可以使任何滿足BLE的裝置（例如智能手機）。
OAD鏡像檔案中繼資料(OAD Image Metadata)
使用OAD傳輸的所有固件均為二進制格式，并包含一個鏡像檔案中繼資料頭，該中繼資料頭的資訊用于OAD服務确定鏡像檔案是否可以下載下傳，或在BIM中使用中繼資料頭确定鏡像檔案應該被加載主程式flash中還是直接運作主程式。為防止該元素頭資訊被多次計算。所有的TI OAD鏡像檔案使用一個标準的16位中繼資料向量。該向量被嵌入到鏡像檔案開始處，占用應用程式固件代碼的前16個位元組。
本部分将介紹中繼資料向量中的各個字段及其含義。
大多數中繼資料檢查通過
OADTarget_validateNewImage()
函數完成.
TI提供了一個工具用于生成OAD就緒鏡像檔案，也就是包含中繼資料向量的将向檔案，參考 Generating Metadata Vector for OAD Image.
下表顯示了中繼資料向量各個字段的描述。
| 域名 | 大小（byte） | 描述 |
|---|---|---|
| CRC | 2 | 循環備援校驗 |
| CRC Shadow | 2 | CRC影子 |
| Version | 2 | 版本 |
| Length | 2 | 鏡像檔案長度（Words） |
| UID | 4 | 使用者ID |
| Start Address | 2 | 鏡像檔案目标位址（words） |
| Image Type | 1 | 下載下傳的鏡像檔案類型 |
| State | 1 | 鏡像檔案狀态 |
這些格式使用的是32-bit words。舉個例子，如果鏡像檔案長度為0x100。實際就是256*32/8=1024 byte。OAD word 大小使用宏
EFL_OAD_ADDR_RESOLUTION
定義。
CRC和CRC Shadow
循環備援校驗（CRC）是檢查鏡像檔案完整性的手段。這必須分兩步進行。首先，當從工具生成鏡像檔案時，必須計算CRC，這将被存儲在中繼資料向量中的CRC字段中。
該初始CRC将通過OAD服務（見OAD服務（0xFFC0）部分）通過空中發送 。
一旦目标已經收到OAD圖像，就會計算CRC Shadow，以确定鏡像檔案在傳輸過程中是否已損壞。并将計算結果存儲在中繼資料向量的CRC Shadow字段中。
如果CRC和CRC Shadow相當，則目标可以假設鏡像檔案在空中傳輸時沒有被破壞。
選擇用于CRC計算的算法是CRC-16-CCITT，它是16位CRC計算，在最壞的情況下具有99.9984％的錯誤檢測率。除了該CRC之外，BLE中的所有資料傳輸均由鍊路層上的CRC進行保護，進而進一步降低了未檢測到的資料損壞風險。
Version
鏡像版本字段用于跟蹤鏡像的修訂版本，并確定更新相容性。客戶可以實作自己的版本控制方案; 然而，TI OAD配置檔案還附加了一些檢查。請參考函數OADTarget_validateNewImage()在oad_target_external_flash.c 看到這些版本檢查是如何在片外OAD完成。
Length
長度字段是鏡像檔案以world為機關的長度，其中world的大小由片外OAD EFL_OAD_ADDR_RESOLUTION定義。使用者使用不同外部flash可能需要修改 EFL_OAD_ADDR_RESOLUTION比對的world的大小。
User Identification (UID)
該字段未被TI OAD配置檔案使用，但是客戶可以添加自己的基于UID驗證鏡像檔案是否正确加載。
預設情況下，片外鏡像檔案使用“E”，“E”，“E”，“E”。
Start Address
Start Address是鏡像檔案存儲在内部flash中的第一個位址。類似于長度字段，這是用world計算的。片外OAD解決方案基于鏡像檔案類型對起始位址進行限制（下一節更詳細地介紹）。
Image Type
在具有外部flash的片外OAD系統中，可以更新多種類型的鏡像檔案。這些鏡像檔案類型包括：
- App+Stack
- APP only
- Network Processor
- Stack only
注意：雖然使用片外OAD可以進行Stack更新，但使用者必須確定目前固件映像和建議的OAD映像之間的App/Stack邊界RAM和flash位址沒有更改。由于App/Stack邊界上沒有運作時檢查，是以隻有OAD才能覆寫應用程式，如果邊界已經增長。使用此選項時，使用者應該小心。TI建議在使用片外OAD方法時執>行應用+堆棧更新。
如果需要邊界位址更改（即Stack正在增長或縮小），則需要使用者執行合并更新（App+Stack），以確定OAD映像已準備好運作。
支援的鏡像類型如下所示：
| 鏡像類型 | 值 | 描述 |
|---|---|---|
| EFL_OAD_IMG_TYPE_APP | 1 | 應用程式或應用程式+Stack合并更新 |
| EFL_OAD_IMG_TYPE_STACK | 2 | 隻更新Stack |
| EFL_OAD_IMG_TYPE_NP | 3 | 網絡處理器更新。這僅适用于SimpleAP + SimpleNP示範 |
| EFL_OAD_IMG_TYPE_FACTORY | 4 | 工廠永久鏡像檔案，在任何OTA更新之前就運作在裝置上 |
Image State
鏡像狀态是一個單位元組資料字段僅用于片外OAD更新方案。狀态通知BIM該鏡像是否準備好運作或已經運作。這可以防止BIM在每次啟動時将相同的圖像從外部flash複制到内部flash。
OAD Service (0xFFC0)
OAD服務目的是為客戶提供簡單的和可定制的實作。在其最基本的形式中，該服務負責接收/拒絕基于鏡像檔案頭标準的OAD互動，将鏡像存儲在其适當位置，并且如果下載下傳成功則導緻裝置重置，以便下載下傳的應用程式映像由BIM加載到主程式區并運作。
顯示OAD服務的BTool的螢幕截圖如下所示：
OAD服務一個基礎的服務，擁有4個特征值。OAD服務的characteristic，UUID和描述如圖上圖所示。
注意
characteristic使用格式為F000XXXX-0451-4000-B000-000000000000的128位TI基本UUID，其中XXXX是其縮短的16位UUID。為簡潔起見，本文将以16位的簡短UUID表示該characteristic。
| UUID | 名字 | 描述 |
|---|---|---|
| 0xFFC0 | OAD Service | OAD服務聲明 |
| 0xFFC1 | 鏡像辨別 | 用于發送鏡像中繼資料，以便OAD Target裝置可以确定是否接受或拒絕該鏡像 |
| 0xFFC2 | 鏡像塊 | 鏡像資料的實際塊以及所占整個鏡像的偏移。 |
| 0xFFC3 | 鏡像計數 | 目前下載下傳的完整的鏡像個數 |
| 0xFFC4 | 鏡像狀态 | 目前OAD下載下傳狀态 |
将資料從OAD Downloader發送到OAD Target的主要方式是GATT寫入，沒有響應消息。GATT通知是用于将狀态資料從Target發送到Downloader的主要方法。選擇該通信方案以防止Target裝置必須包括為了從Downloader接收通知所需的GATT client代碼。該OAD Downloader使用寄存器CCCD接收任何特征的通知 （通過寫01:00到CCCD）。
注意:GATT通知和沒有響應的GATT寫入都是不可靠的的消息通訊。為了確定可靠性，建議每個連接配接事件将OAD有效載荷傳輸限制為一個步驟。
OAD鏡像辨別（0xFFC1）
鏡像辨別特征值用于在OAD Downloader和OAD Target之間交換鏡像中繼資料。當OAD Downloader将OAD鏡像的16位元組中繼資料發送到Target時，OAD程序開始 。一旦接收到更新鏡像的中繼資料，target将進行一些計算，以确定是否應該下載下傳目前鏡像。（有可能會拒絕下載下傳，如果目前運作的鏡像和要下載下傳的鏡像一樣）“01:00”應寫入該特性的CCCD，以便啟用通知。
注意:請參閱oad_target_external_flash.c 中 OADTarget_validateNewImage()函數，該函數具體實作了拒絕下載下傳鏡像檔案。
如果Target接受鏡像，它将通過發送一個請求第一個鏡像塊的通知以繼續OAD程序。否則Target将通過發送目前運作鏡像的中繼資料的一部分來拒絕該鏡像。拒絕中繼資料包含鏡像版本和使用者ID字段。
下面是使用抓包器抓出的用于拒絕下載下傳OAD鏡像的資料。請注意，拒絕通知中隻包含映像版本，長度和使用者ID。
或者，成功啟動OAD如下所示：
OAD鏡像塊（0xFFC2）
OAD鏡像塊特征用于請求和傳送OAD圖像塊。“01:00”應寫入該特性的CCCD，以便能夠通知塊請求。Target發送下一個鏡像塊的塊号的通知給OAD Downloader。該OADDownloader将響應（GATT寫無響應）與所述塊号和一個16位元組的OAD的鏡像塊。該鏡像塊包含來自OAD鏡像偏移的實際二進制資料塊号。 下圖顯示了一個塊請求/響應嗅探器捕獲。
OAD鏡像計數特性（0xFFC3）
OAD圖像計數特性用于設定要下載下傳的OAD圖像的數量。這僅用于片外OAD，特征值的預設值為1。
OAD鏡像狀态（0xFFC4）
OAD圖像狀态特性用于報告OAD過程中可能發生的各種故障。該OAD Downloader可以使用該資訊來确定OAD為什麼失敗，是以它可以糾正錯誤，然後再試一次。要使這個特征的通知“01:00”應寫入該特性的CCCD。預設情況下定義了四個OAD狀态消息。OAD狀态代碼列在下表中：
| OAD狀态碼 | 值 | 描述 |
|---|---|---|
| OAD_SUCCESS | OAD成功 | |
| OAD_CRC_ERR | 1 | 下載下傳的鏡像的CRC與中繼資料中預期的CRC不比對 |
| OAD_FLASH_ERR | 2 | 外部flash無法打開 |
| OAD_BUFFER_OFL | 3 | 接收到的資料包的塊号與請求的資料塊不比對。發生溢出。 |
客戶可以根據需要擴充這些值，并使用該 OAD_sendStatus()函數将更新發送到OAD Downloader。
OAD流程
此配置檔案旨在為客戶提供一個簡單的可定制的OAD配置檔案。在其最基本的形式中，該配置檔案負責接受基于鏡像頭（header）标準的OAD互動，将鏡像存儲到flash上，并且如果下載下傳成功則導緻裝置複位，以便下載下傳的應用程式映像由BIM運作。在OAD Downloader和OAD Target分别執行用戶端角色和服務端角色。
啟動OAD流程
建立新連接配接後，更新連接配接間隔到更快的連接配接間隔，使能Target的OAD鏡像辨別和OAD鏡像塊通知，OAD Downloader将寫入鏡像辨別特征值到OAD Target,消息資料 更新OAD Target的OAD映像辨別和OAD映像塊特性的更快OAD的連接配接間隔， OAD Downloader将寫入OAD Target的映像辨別特性 。在接收到鏡像表示特征的寫入請求後，OAD Target将可用于OAD更新的鏡像與其自己的運作鏡像進行比較。OADTarget_validateNewImage()函數在OAD配置檔案中負責确定新的鏡像時候接受。
如果Target接受鏡像，它将通過發送一個請求第一個鏡像塊的通知以繼續OAD程序。否則Target将通過發送目前運作鏡像的中繼資料的一部分來拒絕該鏡像。拒絕中繼資料包含鏡像版本和使用者ID字段。在這種情況下，OAD過程将立即結束，如圖83所示。
鏡像塊傳輸
鏡像塊傳輸特性值允許兩個裝置請求和響應OAD鏡像，一次一個塊。鏡像塊的大小被定義為16個位元組-見OAD_BLOCK_SIZE在 oad.h中。OAD Target從OAD Downloader 請求一個鏡像塊，通過塊序号發送通知給OAD Downloader。然後OAD Downloader将通過寫入OAD鏡像塊特性進行響應。消息的資料格式是所請求的塊的索引，後跟鏡像的對應的16位元組。每當OAD Target準備好接收OAD鏡像的下一個塊時，它将通過所需鏡像塊的索引來通知圖像塊傳輸特性值。
完成OAD流程
當OAD Target 接收到最後一個鏡像塊時，對接收的所有鏡像進行校驗來驗證這次傳輸時候正确的接收了并存儲所有鏡像塊。
當校驗通過之後，OAD Target将複位，以便BIM進行驗證和加載目前接收的鏡像塊。最後，OAD Downloader将失去連接配接，它将重新開始掃描，然後建立連接配接，連接配接後對新鏡像進行校驗，是否是新的鏡像在運作。
OAD過程中的錯誤處理
為了確定可靠性，在OAD傳輸過程中發生的任何錯誤或故障都要求OAD Downloader從一開始重新啟動OAD傳輸過程。如果啟用通知，可能會通過OAD鏡像狀态（image state）特征值報告錯誤。
BOOT Image Manager（BIM）
由于運作的映像無法更新OAD，必須使用引導映像管理器（BIM）。該BIM是被設計為每次複位後運作，檢查新下載下傳鏡像的正确性，如果正确，新的鏡像将加載到内部flash。
注意：從BLE5-Stack 1.00.00 BIM總是連結到内部flash的第31頁，并将始終連結CCFG部分。是以，OAD應用程式不需要自己的CCFG。
連結器責任
一般來說，連結器指令檔案必須支援TI OAD Profile，TI Tools和TI BIM（TI OAD Ecosystem）的一些基本要求：
- OAD鏡像中繼資料和應用程式開始位置的Flash空間
- (CCFG + BIM)參見OAD流程中處理錯誤
- 中斷向量表的對齊請參閱為應用程式使用自定義複位向量位址
這些要求至關重要; 不僅僅是在TI OAD系統中需要得到支援，而且在前面部分讨論過的應用程式的穩定性。
SimpleLink CC2640R2 SDK提供cc26xx_app_oad.cmd（CCS）和cc26xx_app_oad.icf（IAR）連結器指令檔案，以顯示與TI OAD生态系統相容性的這些要求。修改一個現有的連接配接器指令檔案為一個OAD off-chip庫檔案參考： sec-generating-library-oad-linker-file。
通常，TI Image Tool将處理OAD鏡像的頁面對齊，不需要連結器幹預。但是如果需要，可以進行一些堆棧的更改，使堆棧進入點頁面對齊，參見OAD項目的堆棧更改。
加入我們
文章所有代碼、工具、文檔開源。加入我們QQ群 591679055擷取更多支援，共同研究CC2640R2F&BLE5.0。
© Copyright 2017, 成都樂控暢聯科技有限公司.