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功能。
審核編輯:郭婷
-
傳感器
+關注
關注
2550文章
51035瀏覽量
753083 -
芯片
+關注
關注
455文章
50714瀏覽量
423157 -
FlaSh
+關注
關注
10文章
1633瀏覽量
147944
發布評論請先 登錄
相關推薦
評論