This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1350现有CCS工程如何生成OAD IMG文件?

Other Parts Discussed in Thread: CC1350, CC1310

请教一个问题。关于CC1350使用433M空中升级。

目前公司的产品需要增加空中升级功能,通过学习TI提供的例程,已经学会了如何生成HEX文件以及进行合并与转BIN。

现在碰到的问题是:

TI提供的OAD Client例程中是没有独立的RTOS工程的,而我们之前开发工程都有独立RTOS的例程。如何配置现有工程来生成可以OAD的HEX?

主要是OAD需要给BIM程序预留FLASH空间,我们之前写的程序都是默认从地址0开始的,并没有预留BIM空间。

已经尝试过在CMD文件中修改FLASH的起始地址,

#define FLASH_BASE 0x1010
#define FLASH_SIZE 0x1EFF0

但是编译时会报错,原因是RTOS分配了一些变量在FLASH地址范围之外。

"D:/WORK/OAD_TEST/stdandproject/tirtos_builds_CC1350_LAUNCHXL_433_release_ccs/Debug/configPkg/linker.cmd", line 581: warning #10096-D: specified address lies outside memory map
error #10264: DEFAULT memory range overlaps existing memory range FLASH
error #10264: DEFAULT memory range overlaps existing memory range SRAM
"D:/WORK/OAD_TEST/stdandproject/tirtos_builds_CC1350_LAUNCHXL_433_release_ccs/Debug/configPkg/linker.cmd", line 699: warning #10096-D: specified address lies outside memory map
error #10263: DEFAULT memory range has already been specified
error #10264: DEFAULT memory range overlaps existing memory range DEFAULT
error #10264: DEFAULT memory range overlaps existing memory range FLASH
error #10264: DEFAULT memory range overlaps existing memory range SRAM

error #10010: errors encountered during linking; "empty_CC1350_LAUNCHXL_433_tirtos_ccs.out" not built

在网上查找资料时,发现有人提到用tirtos-bim_builds_CC1310_LAUNCHXL_release_ccs来替代tirtos_builds_CC1310_LAUNCHXL_release_ccs可以解决

但一直找不到tirtos-bim_builds_CC1310_LAUNCHXL_release_ccs的获取途径。

请问这种情况下,我应该如何配置CCS的现有工程来生成符合OAD要求的HEX文件。谢谢。

  • 请参考这边的OAD guide: dev.ti.com/.../node
  • 您好,感谢你的回复,这个文档中的配置方法我已经尝试过了,但并没有解决我的问题。
    我们现有的项目工程都是在例程中的empty_CC1350_LAUNCHXL_433_tirtos_ccs基础上完成的。
    用这个工程生成的HEX文件与BIM工程的HEX文件无法成功合并,提示地址有冲突。
    请问empty工程如何配置可以实现与BIM的HEX文件合并,谢谢。
  • empty_CC1350_LAUNCHXL_433_tirtos_ccs是一个不具备OTA功能。
    如果你想实现OTA功能建议基于rfWsnNodeExtFlashOadClient.
    “TI提供的OAD Client例程中是没有独立的RTOS工程的”

    rfWsnNodeExtFlashOadClient 是基于TI RTOS的,你所有的TI RTOS的接口以及应用程序都可以移植上去。
  • 你好,我在阅读rfWsnNodeExtFlashOadClient 里的代码时,发现有这样一个函数,不知道是不是一个BUG。
    这里面的status 变量在函数开头定义以后,在整个函数过程中没有使用到,函数最后直接返回了这个值。
    按照我的理解,函数的返回值应该总是OADProtocol_Failed,请问这是否正确?

    static OADProtocol_Status_t oadRadioAccessPacketSend(void* pDstAddr, uint8_t *pMsgPayload, uint32_t msgLen)
    {
    OADProtocol_Status_t status = OADProtocol_Failed;
    uint8_t* pMsg;
    uint8_t dstAddr = (uint8_t) *((uint8_t*)pDstAddr);
    /*
    * buffer should have been allocated with oadRadioAccessAllocMsg,
    * so 2 byte before the oad msg buffer was allocated for the source
    * addr and Packet ID. Source addr will be filled in by
    * NodeRadioTask_sendOadMsg
    */
    pMsg = pMsgPayload - 2;
    pMsg[RADIO_PACKET_PKTTYPE_OFFSET] = RADIO_PACKET_TYPE_OAD_PACKET;

    NodeRadioTask_sendOadMsg( dstAddr, pMsg, msgLen + 2);

    //free the memory allocated in oadRadioAccessAllocMsg
    free(pMsg);

    return status;
    }

    这段位于rfWsnNodeExtFlashOadClient 工程的 oad_client.c的最后一个函数
  • Radio access function for OAD module to send messages
    这是用来处理OAD module to send messages。
    此外这个函数有用的啊,只是你没有发现;
    void OADClient_open(OADClient_Params_t *params)
    {
    OADProtocol_Params_t OADProtocol_params;

    memcpy(&oadClientParams, params, sizeof(OADClient_Params_t));

    OADProtocol_Params_init(&OADProtocol_params);
    OADProtocol_params.pRadioAccessFxns = &oadRadioAccessFxns;
    OADProtocol_params.pProtocolMsgCallbacks = &oadMsgCallbacks;

    OADProtocol_open(&OADProtocol_params);

    oadClockInitialize();
    }
    oadRadioAccessFxns包含了oadRadioAccessPacketSend
    你用的什么板子要有外部flash芯片。 此外你要先下载BIM和然后再下载这个hex,请你看下面的知道手册按照操作:

    dev.ti.com/.../node
  • 不不不,我不是说这个函数没有用,我是说这个函数的返回值!
    这个函数刚开始定义了status 变量并赋值为OADProtocol_Failed,
    但是在整个函数过程中没有进行status的使用,
    最后又直接返回了status。
    因此这个函数无论怎样调用,最后返回值都是OADProtocol_Failed。
    请问这是正确的吗?
  • 所以你现在不能OAD?这个返回值没有使用,应该不会有影响
  • 我们之前的工程由于某些原因没有使用EasyLink无线接口,因此移植程序需要修改OADClient工程中RF操作相关的接口。
    然后在修改过程中发现了刚才的情况,不确定这个会不会有影响,所以请教一下确认问题。
  • 你好,我还有一个问题请教,在资料上有写道使用 oad_write_bin.py 下载固件,在实际使用时发现速度较慢,每处理64个字节需要半分钟左右,请问这是正常的的吗?还是我使用时的操作有问题?

    在操作时我使用的命令如下
    E:\oad_py>python oad_write_bin.py COM19 OadClient.hex



    执行后返回如下信息:
    opening file:
    <open file 'OadClient.hex', mode 'rb' at 0x0000000002B084B0>
    file size: 164162
    sending header
    Out: 3a
    Out: 32
    Out: 30
    Out: 31
    Out: 30
    Out: 31
    Out: 30
    Out: 30
    Out: 30
    Out: 30
    Out: 30
    Out: 34
    Out: 43
    Out: 30
    Out: 05
    Out: 32
    sending blocks
    writing block num:
    Reading: 64bytes
    Blocks sent: 0
    writing block num:
    Reading: 64bytes
    Blocks sent: 1
    writing block num:
    Reading: 64bytes
    Blocks sent: 2
    writing block num:
    Reading: 64bytes
    Blocks sent: 3
    writing block num:
    Reading: 64bytes
    Blocks sent: 4
    writing block num:
    Reading: 64bytes
    Blocks sent: 5
    writing block num:
    Reading: 64bytes
    Blocks sent: 6
    writing block num:
    Reading: 64bytes
    Blocks sent: 7
    writing block num:
    Reading: 64bytes
    Blocks sent: 8
    writing block num:
    Reading: 64bytes
    Blocks sent: 9
    writing block num:
    Reading: 64bytes
    Blocks sent: 10
    writing block num:
    Reading: 64bytes
    Blocks sent: 11
    writing block num:
    Reading: 64bytes
    Blocks sent: 12
    writing block num:
    Reading: 64bytes
    Blocks sent: 13
    writing block num:
    Reading: 64bytes
    Blocks sent: 14
    writing block num:
    Reading: 64bytes
    Blocks sent: 15
    writing block num:
    Reading: 64bytes
    Blocks sent: 16
    writing block num:
    Reading: 64bytes
    Blocks sent: 17
    writing block num:
    Reading: 64bytes
    Blocks sent: 18
    writing block num:
    Reading: 64bytes
    Blocks sent: 19
    writing block num:
    Reading: 64bytes
    Blocks sent: 20
    writing block num:
    Reading: 64bytes
    Blocks sent: 21
    writing block num:
    Reading: 64bytes
    Blocks sent: 22
    writing block num:
    Reading: 64bytes
    Blocks sent: 23
    writing block num:
    Reading: 64bytes
    Blocks sent: 24
    writing block num:
    Reading: 64bytes
    Blocks sent: 25
    writing block num:
    Reading: 64bytes
    Blocks sent: 26
    writing block num:
    Reading: 64bytes
    Blocks sent: 27
    writing block num:
    Reading: 64bytes
    Blocks sent: 28
    writing block num:
    Reading: 64bytes
    Blocks sent: 29
    writing block num:
    Reading: 64bytes
    Blocks sent: 30
    writing block num:
    Reading: 64bytes
    Blocks sent: 31
    writing block num:
    Reading: 64bytes
    Blocks sent: 32
    writing block num:
    Reading: 64bytes
    Blocks sent: 33
    writing block num:
    Reading: 64bytes
    Blocks sent: 34
    writing block num:
    Reading: 64bytes
    Blocks sent: 35
    writing block num:
    Reading: 64bytes
    Blocks sent: 36
    writing block num:
    Reading: 64bytes
    Blocks sent: 37
    writing block num:
    Reading: 64bytes
    Blocks sent: 38
    writing block num:
    Reading: 64bytes
    Blocks sent: 39
    writing block num:
    Reading: 64bytes
    Blocks sent: 40
    writing block num:
    Reading: 64bytes
    Blocks sent: 41
    writing block num:
    Reading: 64bytes
    Blocks sent: 42
    writing block num:
    Reading: 64bytes
    Blocks sent: 43
    writing block num:
    Reading: 64bytes
    Blocks sent: 44
    writing block num:
    Reading: 64bytes
    Blocks sent: 45
    writing block num:
    Reading: 64bytes
    Blocks sent: 46


    每执行一个Block需要半分钟左右。。。。
  • 刚找到问题了。。。明明是操作有问题。。。。
    如果你不懂,可以不回答,本来文档就乱,请不要再误导我了。
    我已经耗费太多时间在这个坑里了。
    谢谢。
  • ok,升级一般大概在几十分钟很正常,您没有描述您的操作,但是sub1g 带宽很小,升级慢属于正常现象。所以请您认真阅读文档,提供有效信息我们才能更好的解决您的问题。

  • 我确实没看清楚,半分钟过分了,一般1s左右一个包,最多几秒。我看成了半秒
  • 您好,关于空中升级我还有一个疑问

    在文档中提到需要将应用程序与BIM程序生成的HEX合并到一起,然后转成BIN文件后,下载到OAD客户端中。

    文档中也有提到空中升级只升级用户应用程序,不升级BIM程序。

    请问这个合并BIM这个步骤是不是只需要进行一次?

    也就是说,是不是后续的空中程序升级,只需要将应用程序转为BIN文件,然后下载到OAD服务端进行空中升级即可?

    还是在后续每一次空中升级前,都需要合并BIM文件?

  • 当然你可以继续选择合并然后升级整个文件。也可以:
    OAD Image Tool
    The OAD image tool is a script written in python that is intended to process the compiler output in the form of a hex file and prepare the image for over the air transfer.

    The major components of the oad_image_tool include:

    Conversion from *.hex to *.bin
    Padding the image to be word aligned
    Calculating the CRC and embedding it in the image header
    Optional: Merging a split image into a single app + stack image

    你可以试着直接去Conversion hex到bin 文件试试,在我理解里面只要你原来第一次具备了bim文件就不要了,如果试了不行可能就必须要,因为都是包含bim文件升级了没有试过。此外你之前说的特别慢,是不是你按BTN-1 来唤醒方式升级每次大概50s。
  • 你好,之前说的特别慢是因为我用按键选择option的时候选择错了。
    另外在使用oad_image_tool插件的时候,参数中有五种目标文件类型可以生成
    'app', 'stack', 'np', 'production', 'remoteapp'
    查看oad_image_tool的代码,production 不生成数据元,NP不能嵌入数据元。
    剩下的三种都不能在FLASH page0的地方有代码
    问题是我们使用BIM+应用程序生成BIN文件的时候,应该选择哪一种文件类型?
  • 空中升级步骤.docx

    你好,我使用remoteapp生成BIN文件时出现错误,文件内是我详细的操作步骤以及问题截图,请问操作步骤是否正确?这个错误要如何解决呢?谢谢

  • 你为什么禁用ccfg?
    The internal flash memory contains the BIM followed by the 16 Bytes long meta data header of the current firmware image and finally, the firmware image. The firmware image contains also the CCFG area. It must always provide OAD capabilities so that further updates are possible. The BIM is not intended to be upgraded via OAD.

    此外你第一次需要向CC1310下载BIM和OAD的app 工程,然后去去升级。
    关于你这个错误可能是一个已知问题,请直接参考下面的帖子并在下面的帖子跟帖;
    e2e.ti.com/.../805354
  • 如果不禁用ccfg.c
    在与BIM程序合并的时候,会有如下报错
    > python hexmerge.py -o allinone.hex "--overlap=error" ex_bim.hex Ex_Client.hex
    Merging: Ex_Client.hex
    Data overlapped at address 0x1FFA8
    所以禁用了ccfg.c,不知是否有其他解决方法。


    两个工程已经按照下文进行了配置
    Modify the BIM CCS project by adding TIRTOS_IN_ROM to Project->Properties->Arm Compiler->Predefined Symbols

    Modify the sensor_oad application:

    Add TIRTOS_IN_ROM Project->Properties->Arm Compiler->Predefined Symbols
    Add TIRTOS_IN_ROM to Project->Properties->Arm Linker->Advanced Options->Command File Processing
    Add NO_ROM=1 to Project->Properties->XDCtools->Advanced Options->Configuration Script Arguments
  • 这可能跟python的版本之类的有关,我之前操作时可以的。
    e2echina.ti.com/.../479570
    你把这个两个问题都发到我给你那个帖子上去问问吧,不清楚。
  • 是不是不同的SDK版本的操作方式不一样?我使用的是1.60.00.21版本的SDK。
    这个帖子的第一个回答提供了 3.10.00.11版本的文档,请问这个文档是否有参考性?能否按照文档中的步骤去操作?
    是否有针对1.60.00.21SDK的空中升级文档?
  • 你最好升级上去,老版本的估计只能在SDK里面找到了。你先去那个帖子上问一下你的问题吧。
  • 请参考下面我们的博客:忽略那个改错的部分。不需要修改ccfg,如果不行请发到英文版问一下我们研发团队。
    e2echina.ti.com/.../cc1310
  • 这个是片内升级的,我已经仔仔细细看过N遍了。。。
    不修改CCFG是没办法合并的。请问英文版我可以说中文嘛 :(
  • 修改ccfg以后,HEX文件最后会少一段数据。但是合并BIM的时候,BIM会把这一段数据补上的,我查看过HEX数据,BIM补上的数据与CCFG生成的数据是一样的。
  • 你好,请问你测试时使用的是那个版本的SDK?能否提供已经验证过可以成功OAD的SDK版本,最好有详细点的文档,谢谢。
  • 你好,我用的是3.10.只有SDK里面的User guide可以提供,我会在E2E 的英文版帮你跟进,该帖不再更新,谢谢。
    C:\ti\simplelink_cc13x0_sdk_3_10_00_11\docs\proprietary-rf
  • 好的,英文版那边请你多多跟进,我英文不好,怕表达不清楚问题,拜托了。
  • 你好,SDK 1.60版本的空中升级已经跑通了。我之前上传的文档的操作步骤基本是对的。
    但是有两个问题需要注意与修改
    1、在SDK的ccfg.c中,如果使用空中升级,就不要开启串口BOOTLOAD,我们之前的应用中使用过串口BOOT,因此开启了串口BOOT,造成在空中升级硬件不启动。

    2、在使用 oad_image_tool.py的时候,不能使用remoteapp,只能使用APP。原因是BIM启动时只检查0X78000地址的metadata。而OAD client在空中升级时,只将APP保存在0X78000。所以,在使用oad_image_tool的时候,只能使用APP。
    #define EFL_IMAGE_INFO_ADDR_APP ( EFL_ADDR_META + 0x0000 )
    #define EFL_IMAGE_INFO_ADDR_BLE ( EFL_ADDR_META + EFL_PAGE_SIZE )
    #define EFL_IMAGE_INFO_ADDR_FACTORY ( EFL_ADDR_META + EFL_PAGE_SIZE*2 )
    #define EFL_IMAGE_INFO_ADDR_REMOTE_APP ( EFL_ADDR_META + EFL_PAGE_SIZE*3 )

    以上信息希望对大家有用。
  • 所以有问题的时候先用原始demo去试试把,因为做了什么修改这么很难意识到,基本想到你能做了什么修改。你可以用原始的试试看。
    感谢你的分享。