OAD即Over the Air Download，是通過無線的方式遠程更新固件的一種方法。On chip，就是片上， 升級的對象不需要外掛Flash， 通過芯片片內Flash完成新固件存儲及老固件向新固件的切換。On chip OAD方案因為不需要外部接口就能夠實現固件的更新，在傳感器，智能門鎖，電力監控等無線應用廣受歡迎。

在TI新發布的CC1310 片內OAD工程里, 由于很多細節沒有說明, 用戶使用過程可能出錯. 這里將結合TI CC1310 SDK 1.60.00.21 版本， 講解在工程編譯和OAD測試過程中的注意事項.

試驗提前準備：

兩個CC1310的Launchpad評估板

CC1310 軟件開發包：simplelink_cc13x0_sdk_1_60_00_21

工具：Uniflash燒寫工具

PYTHON環境及工具：PYTHON 2.7

CC1310 片內OAD例程編譯

CC1310 片內OAD的例程在上述SDK的文件夾examplesrtosCC1310_LAUNCHXLeasylink中, 對應有采集器(rfWsnConcentratorOadServer)和節點(rfWsnNodeIntFlashOadClient)兩個例程; 我們將其導入到CCS(7.0 以上版本)中.

這里需要注意的第一個點,在SDK的文文件夾examplesrtosCC1310_LAUNCHXLeasylinkhexfilesonChipOad中已經有已經編譯好的固件, 這個固件目前不能夠和工程編譯的固件混合使用. 你可以只使用已經編譯好的進行測試,或者只使用工程編譯好的.

我們首先編譯好采集器工程(無需任何修改),并將工程下載到CC1310 Launchpad 1 中;

接著, 按照工程內的README.md指導(第136~145行)設置,我們編譯節點工程, 發現報錯,如下圖, 錯誤原因可使用存儲不足;

針對這個,我們可以從工程編譯生成的.map文件察看具體的存儲的細節,可以看出是.const太大導致。

我們如果將之前工程設置的FEATURE_OAD_ONCHIP取消，重新編譯，察看正常的.map文件, 可以發現主要占用.const空間的主要被smartrf_settings_predefined.obj占用，經過檢查后，發現主要是無線RF的補丁導致，而這部分補丁針對我們對OAD的驗證沒有關系。

恢復到README.MD的工程設置后，打開工程目錄文件夾smartrf_settings中的smartrf_settings_predefined.c，將下面四個RF_Mode變量修改如下， 接著重新編譯工程。

RF_Mode RF_prop_lrm =

{

.rfMode = RF_MODE_PROPRIETARY_SUB_1,

.cpePatchFxn = 0,

.mcePatchFxn = 0,

.rfePatchFxn = 0,

};

RF_Mode RF_prop_ook =

{

.rfMode = RF_MODE_PROPRIETARY_SUB_1,

.cpePatchFxn = 0,

.mcePatchFxn = 0,

.rfePatchFxn = 0,

};

RF_Mode RF_prop_hsm =

{

.rfMode = RF_MODE_PROPRIETARY_SUB_1,

.cpePatchFxn = 0,

.mcePatchFxn = 0,

.rfePatchFxn = 0,

};

RF_Mode RF_prop_sl_lr =

{

.rfMode = RF_MODE_PROPRIETARY_SUB_1,

.cpePatchFxn = 0,

.mcePatchFxn = 0,

.rfePatchFxn = 0,

};

成功編譯，從下圖可以看到編譯后的程序大小為57K，滿足不能大于60K的限制。

這里需要說明的一點是，README.MD里面說的另外一點nodeFwVersion修改應該是在oad_client.c而不是NodeTask.c中；

CC1310 片內OAD例程BIN固件生成及加載測試

因為這個工程的設置是針對IMAGE文件，如果直接下載到芯片是沒辦法正常運行的（因為芯片的復位向量沒有可執行程序，需要借助BIM來跳到IMAGE程序入口），需要將編譯好的固件和Boot管理的BIM固件結合在一起，步驟如下

先mergy BIM和節點固件（請將兩個固件拷貝至python的目錄后執行）

python /usr/bin/hexmerge.py -o rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.hex "--overlap=error" rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_tirtos_ccs.hex bim_intflash_cc1350lp.hex

接著，因為BIM需要檢驗IMAGE的CRC文件，需要通過下面的命令將生成的hex轉換成bin。（需要下載安裝一個crc計算組件crcmod https://pypi.python.org/pypi/crcmod/1.7#downloads）

python oad_image_tool_13x0.py -t onchip -i production -v 0x0100 -m 0x1000 -ob rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.bin rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.hex

我們通過Uniflash， 把bin文件下載到節點Launchpad 2后，節點固件就可以正常工作了。你可以看到Launchpad的指示燈閃爍，從Launchpad 2串口可以看到SCE的ADC信息。我們開啟采集器launchpad 1，可以看到節點已經和采集器建立通訊，可以正常工作了。

這里還需要注意的是通過oad_image_tool_13x0.py -v生成的版本號只是采集器端Available FW顯示的版本號，不是實際的固件版本號。

下一步是將升級需要的程序加載到采集器端。首先，我們需要根據README.MD的說明設置成IMAGE B。 接著，通過上述的python工具，將編譯生成的.hex 文件轉換成.bin文件。注意oad_image_tool_13x0.py 的-m參數需要設置成0x10000。之后，我們在采集器評估板右鍵選擇Update available FW, 再同時按下左鍵和右鍵，采集器進入加載固件界面，如下：

接著斷開采集器的串口，我們將結合PYTHON把需要更新的節點固件傳遞到采集器的外部Flash。 這里，因為PYTHON的腳本是針對LINUX寫的，為了在WINDOWS能夠工作，請先安裝模塊pyserial并修改腳本oad_write_bin.py （目錄C:tisimplelink_cc13x0_sdk_1_60_00_21toolseasylinkoad）。PYTHON的安裝不在文檔討論范圍。Pyserial的下載安裝可參考http://blog.csdn.net/oxp7085915/article/details/52191698

修改后的腳本參考如下（已經用黃色MARK）

#!/usr/bin/python

import serial, sys, io, os

import serial.tools.list_ports

plist =list(serial.tools.list_ports.comports())

if len(plist) <= 0:

print "The Serial port can't find!"

else:

plist_0 =list(plist[0])

port0 = plist_0[0]

file = sys.argv[1]

斷開原串口助手（采集器所連接）打開命令行，執行oad_write_bin.py腳本，將新生成的節點固件bin文件傳遞給采集器。可以看到傳輸提示。等待傳輸完成。

C:Python27>python C:tisimplelink_cc13x0_sdk_1_60_00_21toolseasylinkoadoad

_write_bin.py C:tisimplelink_cc13x0_sdk_1_60_00_21examplesrtosCC1310_LAUNCHXLeasylinkhexfilesonChipOadccsrfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v2.bin

傳輸完成后，重新打開串口連接采集器串口，按Launchpad右鍵出現Update Available Firmware后，再同按左鍵同時按下右鍵，然后可看到V02的固件已經可供使用。

接下來通過采集器Launchpad右邊按鍵選擇Update Node Firmware，再按左鍵同時按下右鍵執行選擇。可以看到升級開始和完成。

升級完成后，通過Send Fw Ver Req可以看到固件已經從V01更新到V02了。

總結

本文，針對TI最新發布的CC1310片內OAD解決方案，描述了在對應工程編譯，鏈接，測試過程中需要注意到的點，并成功實現了片內OAD功能。

審核編輯：郭婷