CC2640 R2是一款面向 Bluetooth Smart 應(yīng)用的低功耗無(wú)線(xiàn) MCU。該芯片運(yùn)行TI的BLE協(xié)議棧，并支持OAD（Over the Air Download）空中固件升級(jí)功能，此空中固件升級(jí)功能就是利用Android或者iOS的產(chǎn)品對(duì)應(yīng)app通過(guò)BLE對(duì)CC2640R2的產(chǎn)品進(jìn)行固件升級(jí)。同時(shí)，TI其實(shí)提供了Anroid和iOS的源碼對(duì)其支持：http://www.ti.com/tool/SENSORTAG-SW？keyMatch=sensortag&tisearch=Search-EN-Everything。這部分的源碼是基于TI的SensorTag硬件進(jìn)行開(kāi)發(fā)的，包含了很多內(nèi)容，對(duì)于客戶(hù)來(lái)說(shuō)，基本上不適合直接拿去使用，但是其中的OAD部分代碼，卻是可以通用的。但是對(duì)于客戶(hù)的iOS或者Android app工程師來(lái)說(shuō)，往往對(duì)BLE協(xié)議不熟，那就更不用說(shuō)TI的OAD協(xié)議了，所以即使提供了源碼，客戶(hù)在這一部分開(kāi)發(fā)起來(lái)還是很困難。本文就針對(duì)這一點(diǎn)，針對(duì)app開(kāi)發(fā)過(guò)程中對(duì)OAD功能做一個(gè)流程和代碼解讀，用以幫助客戶(hù)更方便完成此功能開(kāi)發(fā)。

首先，第一步是從上面的鏈接下載到最新的android和iOS源碼，上述鏈接最終會(huì)指引到github的下載地址。

有了源碼之后，我們就可以解讀了。

從app的角度上來(lái)看TI的OAD協(xié)議，大致是這樣的：

App連接上設(shè)備之后，就能發(fā)現(xiàn)OAD的service和characteristics（服務(wù)和特征值）：

服務(wù)的UUID：0xFFC0，對(duì)應(yīng)的128bit UUID：

F000FFC0-0451-4000-B000-000000000000

服務(wù)下面有兩個(gè)主要特征值：（其他特征值可以暫且忽略）

OAD Image Identify，UUID：0xFFC1；OAD Image Block，UUID：0xFFC2，對(duì)應(yīng)的128bit UUID：

– OAD Image Identify F000FFC1-0451-4000-B000-000000000000，用于交互確認(rèn)固件版本信息。

– OAD Image Block F000FFC2-0451-4000-B000-000000000000，用于傳送新的固件。

固件更新的所有操作都是對(duì)上面這兩個(gè)特征值進(jìn)行操作。

用TI的SensorTag app可以看到：

用第三方app比如light blue也能看到，安卓手機(jī)的情況也是一樣。

在TI提供的示例代碼中，在A(yíng)ndroid中，客戶(hù)唯一要用到的文件其實(shí)就是FwUpdateActivity_CC26xx.java，所有的OAD流程基本全部都在這里。另外有一個(gè)相關(guān)的文件BluetoothLeService.java，這個(gè)是TI的SensorTag App封裝的BLE相關(guān)API接口集合，主要用于一些特征值的操作，比如write，read等，OAD用到的主要就是write，通過(guò)write來(lái)神奇地實(shí)現(xiàn)各種流程。在iOS源碼中，流程相關(guān)的主要是BLETIOAD2Profile.m（注意，另外一個(gè)BLETIOADProfile.m，這是針對(duì)舊版的CC254x的，和CC26xx略有不同，這里不做討論，有興趣可以自己去看），基本就在這里，另外對(duì)應(yīng)也有一個(gè)BLE相關(guān)接口集合BLEUtility.m。

第一步

從app來(lái)講，開(kāi)始OAD的第一步就是先使能上面兩個(gè)特征值的notification功能。

簡(jiǎn)單來(lái)說(shuō)就是調(diào)用android或者iOS提供的現(xiàn)有API，分分鐘完成。（藍(lán)牙協(xié)議上來(lái)說(shuō)就是往這兩個(gè)特征值的CCC句柄上寫(xiě)01:00，我們這里盡量不討論具體藍(lán)牙協(xié)議，從簡(jiǎn)考慮，有興趣的人可以自己去研究一下）。

對(duì)應(yīng)到代碼里，

Android在FwUpdateActivity_CC26xx.java中，新的固件文件裝載到手機(jī)內(nèi)存后：public void onLoad（View v）中調(diào)用：

mLeService.setCharacteristicNotification（mCharIdentify， true）;

和

mLeService.setCharacteristicNotification（mCharBlock， true）;

實(shí)際上可以根據(jù)客戶(hù)真實(shí)代碼在適當(dāng)位置加上面兩個(gè)函數(shù)就行，這樣第一步其實(shí)就完成了。

*更多說(shuō)明：

上面兩個(gè)函數(shù)，其實(shí)就是BluetoothLeService.java中的API，最終追蹤下去的話(huà)是調(diào)用Android SDK 的BLE API來(lái)使能notification：

mBluetoothGatt.setCharacteristicNotification（request.characteristic， request.notifyenable）

其實(shí)我們也可以直接調(diào)用這個(gè)來(lái)實(shí)現(xiàn)上面的功能。

iOS在BLETIOAD2Profile.m里的-（void） configureProfile 函數(shù)里調(diào)用：

CBUUID *sUUID = ［CBUUID UUIDWithString:TI_OAD_SERVICE］;

CBUUID *cUUID = ［CBUUID UUIDWithString:TI_OAD_IMAGE_NOTIFY］;

［BLEUtility setNotificationForCharacteristic:self.d.p sCBUUID:sUUID cCBUUID:cUUID enable:YES］;

cUUID = ［CBUUID UUIDWithString:TI_OAD_IMAGE_BLOCK_REQUEST］;

if （self.notifications）［BLEUtility setNotificationForCharacteristic:self.d.p sCBUUID:sUUID cCBUUID:cUUID enable:YES］;

注意，iOS代碼里面OAD Image Identify和OAD Image Block對(duì)應(yīng)的是TI_OAD_IMAGE_NOTIFY和TI_OAD_IMAGE_BLOCK_REQUEST。同樣，在iOS里適當(dāng)位置調(diào)用這個(gè)函數(shù)就行。

*更多說(shuō)明：

對(duì)于iOS TI給出的源碼，是BLEUtility.m中封裝了Apple的BLE API來(lái)使能notification：

- （void）setNotifyValue：（BOOL）enabled forCharacteristic：（CBCharacteristic *）characteristic;

一樣，我們也可以直接調(diào)用這個(gè)來(lái)實(shí)現(xiàn)上面的功能。

空中sniffer抓包看的話(huà)，就能看到這兩個(gè)使能notification的流程：

第二步

從app角度來(lái)講，第二步就是要把新固件的版本信息從手機(jī)傳送到外設(shè)上，讓外設(shè)進(jìn)行判斷是否要升級(jí)。

這一步就要用到OAD Image Identify，這個(gè)特征值在整個(gè)OAD過(guò)程中只會(huì)用到一次，就是在這里。

App這邊先從獲得到的新固件里把固件的image header （16個(gè)字節(jié)） 讀出來(lái)，image header就是固件的二進(jìn)制文件的開(kāi)始16個(gè)字節(jié)，很容易獲取到。

體現(xiàn)在代碼里，

Android：還是在FwUpdateActivity_CC26xx.java中，在打開(kāi)新固件文件的時(shí)候：

private boolean loadFile（String filepath， boolean isAsset） {

順便創(chuàng)建要發(fā)送的16個(gè)字節(jié)image header結(jié)構(gòu)：

mFileImgHdr = new ImgHdr（mFileBuffer，readLen）;

這個(gè)構(gòu)造函數(shù)就會(huì)把image header部分給組織好放到16字節(jié)的一個(gè)buffer中去，用以接下來(lái)發(fā)送給設(shè)備。這個(gè)類(lèi)的定義也在FwUpdateActivity_CC26xx.java中：

private class ImgHdr {

……

ImgHdr（byte［］ buf， int fileLen） {

this.len = （fileLen / （16 / 4））;

this.ver = 0;

this.uid［0］ = this.uid［1］ = this.uid［2］ = this.uid［3］ = ‘E’;

this.addr = 0;

this.imgType = 1; //EFL_OAD_IMG_TYPE_APP

this.crc0 = calcImageCRC（（int）0，buf）;

crc1 = （short）0xFFFF;

……

}

可以看到構(gòu)造函數(shù)里面，雖然有讀取到的實(shí)際固件文件的image header作為輸入?yún)?shù)，但我們實(shí)際的代碼里面為了演示，只是寫(xiě)死了一些內(nèi)容。這里可以根據(jù)實(shí)際情況修改一下，根據(jù)前面提到的16字節(jié)header的順序來(lái)就行，比如：

private class ImgHdr {

……

ImgHdr（byte［］ buf， int fileLen） {

this.len = （fileLen / （16 / 4））;

this.ver = buf［5］;

this.ver = （this.ver 《《 8） | buf［4］;

this.uid［0］ = buf［8］;this.uid［1］ = buf［9］;

this.uid［2］ = buf［10］; this.uid［3］ = buf［11］;

this.addr = buf［13］;

this.addr = （this.addr 《《 8） | buf［12］;

this.imgType = buf［14］;//EFL_OAD_IMG_TYPE_APP

this.crc0 = calcImageCRC（（int）0，buf）;

crc1 = （short）0xFFFF;

……

}

這樣就基本能拿到實(shí)際的真實(shí)數(shù)據(jù)了。

iOS：就很簡(jiǎn)單了，直接把新固件文件開(kāi)始的16字節(jié)header復(fù)制到代碼里就可以了，還是在BLETIOAD2Profile.m里，在-（void） uploadImage 函數(shù)中：

img_hdr_t2 imgHeader;

uint32_t pages = （（uint32_t）self.imageFile.length / 4096）;

//做個(gè)CRC校驗(yàn)，放到image header中去，同時(shí)把image header的16字節(jié)內(nèi)容補(bǔ)完整。

［self calcImageInfo:0 pages:pages imageHeader：&imgHeader buf:imageFileData］;

memcpy（requestData， &imgHeader， 16）;

需要注意的是iOS給的源碼里面，image header內(nèi)容的補(bǔ)充是在crc校驗(yàn)函數(shù)里面一并完成的：-（void） calcImageInfo里：

imageHeader buf：（uint8_t *）buf {

imageHeader-》len = （pages * FLASH_PAGE_SIZE） / （OAD_BLOCK_SIZE / FLASH_WORD_SIZE）;

imageHeader-》ver = 0;

imageHeader-》uid［0］ = imageHeader-》uid［1］ = imageHeader-》uid［2］ = imageHeader-》uid［3］ = ‘E’;

imageHeader-》addr = （firstpage * FLASH_PAGE_SIZE） / （OAD_BLOCK_SIZE / FLASH_WORD_SIZE）;

imageHeader-》imgType = EFL_OAD_IMG_TYPE_APP;

imageHeader-》res［0］ = 0xff;

imageHeader-》crc0 = ［self calcImageCRC:firstpage imageHeader:imageHeader buf:buf］;

imageHeader-》crc1 = 0xffff;

}

這樣iOS這里也得到完整的image header信息了。

接下來(lái)app將通過(guò)OAD Image Identify這個(gè)特征值首先把前面得到的新的固件的版本信息發(fā)送給設(shè)備（CC2640R2），這個(gè)版本信息包含在前面得到的image header的16個(gè)字節(jié)buffer里，把這個(gè)發(fā)出去給設(shè)備就行了。

體現(xiàn)在代碼里，

Android，還是在FwUpdateActivity_CC26xx.java中，開(kāi)始流程函數(shù)：

private void startProgramming（） {

獲取image identify（其實(shí)就是image header）：

mCharIdentify.setValue（mFileImgHdr.getRequest（））;

并通過(guò)BLE的write characteristic動(dòng)作從app發(fā)送到設(shè)備端：

mLeService.writeCharacteristic（mCharIdentify）;

*更多說(shuō)明：

上面write characteristic函數(shù)其實(shí)就是BluetoothLeService.java中的API，最終追蹤下去的話(huà)是調(diào)用Android SDK 的BLE API來(lái)進(jìn)行BLE的write command操作：

mBluetoothGatt.writeCharacteristic（request.characteristic）;

其實(shí)我們也可以直接調(diào)用這個(gè)來(lái)實(shí)現(xiàn)上面的功能。

iOS代碼中，在BLETIOAD2Profile.m里，還是在-（void） uploadImage 函數(shù)里：

CBUUID *cUUID = ［CBUUID UUIDWithString:TI_OAD_IMAGE_NOTIFY］;

［BLEUtility writeNoResponseCharacteristic:self.d.p sCBUUID:sUUID cCBUUID:cUUID data：［NSData dataWithBytes:requestData length:16］］;

通過(guò) write characteristic來(lái)把image header發(fā)送到設(shè)備端。

*更多說(shuō)明：

這個(gè)的write函數(shù)，其實(shí)也是在BLEUtility.m里面封裝了Apple的BLE標(biāo)準(zhǔn)API：

- （void）writeValue：（NSData *）data forCharacteristic：（CBCharacteristic *）characteristic type：（CBCharacteristicWriteType）type;

我們也可以直接調(diào)用這個(gè)來(lái)實(shí)現(xiàn)上面的功能。

空中sniffer抓包能看到write command發(fā)送image header：

最后，設(shè)備收到image header之后，會(huì)進(jìn)行和自己本身的固件版本號(hào)進(jìn)行比較。如果發(fā)現(xiàn)image header中的版本號(hào)沒(méi)有自己的版本號(hào)新，那么就直接以notification （這里notification是在前面第一步使能）的形式在OAD Image Identify上回復(fù)自己的版本號(hào)給手機(jī)，表示拒絕此次固件升級(jí)，此次升級(jí)就此結(jié)束。

空中sniffer抓包，其中標(biāo)黃的部分就是設(shè)備回復(fù)自身版本號(hào)，表示拒絕此次固件升級(jí)：

如果發(fā)現(xiàn)image header中的版本號(hào)確實(shí)比自己本身的固件版本號(hào)要新，那么就同意這次固件更新，會(huì)在OAD Image Block這個(gè)特征值的notification （這里notification是在前面第一步使能）上回復(fù)0x0000，表示準(zhǔn)備接受序列號(hào)第0個(gè)固件內(nèi)容包。注意實(shí)在OAD Image Block這個(gè)特征值上，不是OAD Image Identify這個(gè)特征值上，OAD Image Identify這個(gè)特征值的使命在前面已經(jīng)完成，后面不會(huì)再使用。

從sniffer看就會(huì)看到0x0000從外設(shè)發(fā)回手機(jī)：

總結(jié)下來(lái)第二步，就是app要在OAD Image Identify特征值上發(fā)送新固件的image header到設(shè)備端，然后設(shè)備端進(jìn)行判斷是否要接收新的固件進(jìn)行升級(jí)，如果要升級(jí)，則在OAD Image Block特征值上向手機(jī)回復(fù)0x0000，不然回復(fù)自己目前的固件版本號(hào)表示拒絕更新?？偨Y(jié)起來(lái)就是下面的兩個(gè)流程圖：

第三步

這一步從app來(lái)講就是按照順序發(fā)送固件內(nèi)容了。

手機(jī)在OAD Image Block特征值上收到0x0000之后就代表設(shè)備端愿意接收新固件，并且意思是對(duì)方準(zhǔn)備好接收第0個(gè)固件包。每個(gè)固件包的內(nèi)容長(zhǎng)度是16個(gè)字節(jié)，并且需要在頭部放上兩個(gè)字節(jié)的序列號(hào)，序列號(hào)從0x0000開(kāi)始累加，一直到最后一個(gè)固件包。

*注意這個(gè)序列號(hào)是小端在前的，所以后面是0x0100，0x0200，0x0300，0x0400，…，0xFF00，0x0001，0x0101，0x0201，…這樣累加上去。

從空中sniffer上看，很容易就能看到整個(gè)流程的交互：

首先是手機(jī)發(fā)送第0包的固件內(nèi)容，通過(guò)BLE的Write方式在OAD Image Block特征值上發(fā)送，固件block內(nèi)容是16個(gè)字節(jié)，注意下圖標(biāo)黃的頭兩個(gè)字節(jié)，是固件包序列號(hào)，第0包是0x0000，所以包的總長(zhǎng)是16+2=18個(gè)字節(jié)。

那么設(shè)備收到APP發(fā)送過(guò)去的第0包固件后，回復(fù)請(qǐng)求下一個(gè)固件包，通過(guò)Notification的方式在OAD Image Block特征值上回復(fù)0x0100：

APP收到設(shè)備發(fā)回的0x0100，就知道對(duì)方已經(jīng)等待接收下一包固件，于是就發(fā)送下一包0x0100的固件包，以此類(lèi)推，一直到固件發(fā)送結(jié)束。

具體到代碼里，

在A(yíng)ndroid中，就是在programBlock（）函數(shù)里，這里我們只關(guān)注核心部分：

private void programBlock（） {

…

…

省略前面邏輯相關(guān)代碼，工程里面很容易看懂。

// Prepare block

首先自然是包序列號(hào)，buffer的頭兩個(gè)字節(jié)：

mOadBuffer［0］ = Conversion.loUint16（mProgInfo.iBlocks）;

mOadBuffer［1］ = Conversion.hiUint16（mProgInfo.iBlocks）;

然后是16個(gè)字節(jié)的固件block包內(nèi)容：

System.arraycopy（mFileBuffer， mProgInfo.iBytes， mOadBuffer， 2， OAD_BLOCK_SIZE）;

// Send block

接著把這18個(gè)字節(jié)通過(guò)write方式在OAD Image Block特征值上發(fā)送：

mCharBlock.setValue（mOadBuffer）;

boolean success = mLeService.writeCharacteristicNonBlock（mCharBlock）;

如果發(fā)送成功，那么就順移相關(guān)的包序列號(hào)還有固件文件中的位移標(biāo)志：

if （success） {

// Update stats

packetsSent++;

mProgInfo.iBlocks++;

mProgInfo.iBytes += OAD_BLOCK_SIZE;

mProgressBar.setProgress（（mProgInfo.iBlocks * 100） / mProgInfo.nBlocks）;

如果最后一個(gè)固件block成功完成，那么就恭喜，OAD順利成功！

if （mProgInfo.iBlocks == mProgInfo.nBlocks） {

…

b.setTitle（“Programming finished”）;

b.setPositiveButton（“OK”，null）;

AlertDialog d = b.create（）;

d.show（）;

mProgramming = false;

mLog.append（“Programming finished at block ” + （mProgInfo.iBlocks + 1） + “\n”）;

}

} else {

mProgramming = false;

msg = “GATT writeCharacteristic failed\n”;

}

…

…

}

*更多說(shuō)明：

上面boolean success = mLeService.writeCharacteristicNonBlock（mCharBlock）;這個(gè)函數(shù)，其實(shí)就是BluetoothLeService.java中的API，最終追蹤下去的話(huà)是調(diào)用Android SDK 的BLE API來(lái)實(shí)現(xiàn)的：mBluetoothGatt.writeCharacteristic（request.characteristic）;

iOS的代碼里，體現(xiàn)在BLETIOAD2Profile.m里的-（void） sendOnePacket 函數(shù)，只看核心部分，和Android很像的，因?yàn)榱鞒桃粯樱?/p>

-（void） sendOnePacket {

…

…

//Prepare Block

首先自然是包序列號(hào)，buffer的頭兩個(gè)字節(jié)：

uint8_t requestData［2 + OAD_BLOCK_SIZE］;

requestData［0］ = LO_UINT16（self.iBlocks）;

requestData［1］ = HI_UINT16（self.iBlocks）;

然后是16個(gè)字節(jié)的固件block包內(nèi)容：

memcpy（&requestData［2］ ， &imageFileData［self.iBytes］， OAD_BLOCK_SIZE）;

CBUUID *sUUID = ［CBUUID UUIDWithString:TI_OAD_SERVICE］;

CBUUID *cUUID = ［CBUUID UUIDWithString:TI_OAD_IMAGE_BLOCK_REQUEST］;

接著把這18個(gè)字節(jié)通過(guò)write方式在OAD Image Block特征值上發(fā)送：

［BLEUtility writeNoResponseCharacteristic:self.d.p sCBUUID:sUUID cCBUUID:cUUID data：［NSData dataWithBytes:requestData length:2 + OAD_BLOCK_SIZE］］;

如果發(fā)送成功，那么就順移相關(guān)的包序列號(hào)還有固件文件中的位移標(biāo)志：

dataWithBytes:requestData length:2 + OAD_BLOCK_SIZE］）;

self.sndDataCount ++;

self.iBlocks++;

self.iBytes += OAD_BLOCK_SIZE;

self.sentPackets++;

如果最后一個(gè)固件block成功完成，那么就恭喜，OAD順利成功！

if（self.iBlocks == self.nBlocks） {

self.inProgramming = NO;

［self.oadDelegate didFinishUploading］;

return;

}

流程和Android完全一樣，我連注釋都直接復(fù)制過(guò)來(lái)了J。

這樣就是完整的OAD流程了?？偨Y(jié)就是分三步走：使能OAD Image Identify和OAD Image Block 的notification，在OAD Image Identify上發(fā)送新固件版本（image header）進(jìn)行確認(rèn)，最后在OAD Image Block上按順序把固件發(fā)送完，結(jié)束。

審核編輯：何安