CC1310片内固件升级的工程编译

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功能。

审核编辑：郭婷