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.

CCS/CC1350: rfWsnNodeIntFlashOadClient example from Simplelink 1.5 SDK failed to build

Part Number: CC1350
Other Parts Discussed in Thread: CC1310, SYSBIOS

Tool/software: Code Composer Studio

Hello!

I followed instructions in rfWsnNodeIntFlashOadClient\Readme.md to build Image A, but project failed to build, because of big size of output .bin file (72k).

It's strange, but then i tried to do the same thing in November - all works fine, since November i got several auto-updates in CCS.

I tried to replace *.c and *.h files in rfWsnNodeIntFlashOadClient with files from my project. Project compiles and works fine, but size of output .bin also rised:

from 45k to 52k with Optimization level = 4

from 54k to 61k with Optimization level = off

+10% of size is to much for me because of small Internal flash size.

1. How can i fix it?

2. What settings i must do in my project (based on Simplelink_cc13x0_sdk_1_50) to implement OnChip OAD? I tried to copy .cmd and .cfg files from rfWsnNodeIntFlashOadClient, but got 15 build errors.

3. In rfWsnNodeIntFlashOadClient Hwi are not disabled while writing/erasing the flash. Is it right?

4. I found a small mistake in Readme.md:

"python /usr/bin/hexmerge.py -o app_v1-all.hex "--overlap=error" app_v1.bin bim_intflash_cc1350lp.hex"

must be 

"python /usr/bin/hexmerge.py -o app_v1-all.hex "--overlap=error" app_v1.hex bim_intflash_cc1350lp.hex"

My rfWsnNodeIntFlashOadClient project in attach.

rfWsnNodeIntFlashOadClient_CC1350_LAUNCHXL_tirtos_ccs.zip

  • Hi Rustem,

    Rustem Avkhadiev said:
    1. How can i fix it?

    I also saw build issues in the OAD examples in SDK 1.50. Since 1.60 is out, could you test this SDK version? Thanks.

    Rustem Avkhadiev said:
    2. What settings i must do in my project (based on Simplelink_cc13x0_sdk_1_50) to implement OnChip OAD? I tried to copy .cmd and .cfg files from rfWsnNodeIntFlashOadClient, but got 15 build errors.

    First of all, update to SimpleLink SDK 1.60, then try it again. Usually, you need to:

    • modify the linker script according to the OAD example project
    • change m3Hwi.resetVectorAddress = 0x1010 in the .cfg file
    • disable the ROM module in the .cfg file (this increases the memory footprint a lot)

    Rustem Avkhadiev said:
    3. In rfWsnNodeIntFlashOadClient Hwi are not disabled while writing/erasing the flash. Is it right?

    No, they are not disabled. Have a look at oad_target_internal_flash.c

    Rustem Avkhadiev said:
    4. I found a small mistake in Readme.md:

    Thanks. I will report this to the team that implemented the OAD example.

  • And one more comment to the code size. Yes, there is not much space. Try to remove functionality. For instance, either the UART or LCD display.
  • Hello, Richard! Thank you for your replay.

    1. I tried SDK 1.6 and got the same problems.

    2.1. "linker script"  - you mean ".cmd" file?

    2.2. Then i add ".cfg" file to, for example, "rfEasyLinkTx" project, i get this build error:

     "DeviceFamily_XYZ undefined. You must defined DeviceFamily_XYZ!" .ccsproject /rfEasyLinkTx_CC1310_LAUNCHXL_tirtos_ccs line 151, external location: C:\ti\simplelink_cc13x0_sdk_1_60_00_21\source\ti\devices\DeviceFamily.h"

    But this symbol is defined, and then i open DeviceFamily.h in ccs, i can see, that it's defined

    3. As i wrote before, "Hwi are not disabled". I other words, then i write to flash, do i need to disable Hwi? 

    In OAD example it's not disabled, but in e2e i see that it's must be disabled ()

  • Rustem Avkhadiev said:
    2.1. "linker script"  - you mean ".cmd" file?

    Yes. Linker command file equals linker script. The latter term is usually used for GNU LD, but proprietary closed source toolchains seem to go for the other term.

    Rustem Avkhadiev said:
    2.2. Then i add ".cfg" file to, for example, "rfEasyLinkTx" project, i get this build error:

    The examples are usually split into a kernel project with .cfg and a plain application project that references the kernel project.

    You want to turn such a split project into a self-containing project. The error that you are seeing originates in XS from XDCTools which tries to build the kernel from the .cfg file.

    • Since the project had no settings for XDCTools before, you need to add them. Maybe you can extract the relevant information from the porting guide. It shows which settings to add to the XDCTools tab in CCS.
    • Make sure to remove the project reference to a separate kernel project if there is any in Project Configuration -> Project References.

    Rustem Avkhadiev said:
    3. As i wrote before, "Hwi are not disabled". I other words, then i write to flash, do i need to disable Hwi? 

    You are right. Interrupts must be disabled when not executing interrupt handlers in RAM. This is not the case here. I have reported this to the team that has implemented the OAD example. Here is the suggested solution:

    key = Hwi_disable();
    status = FlashProgram((uint8_t*)srcBuf, (uint32_t)dstBuf, writeIncrement);
    Hwi_restore(key);

    Same for FlashErase().

  • Thank you, i will try it.
    And what about the main problem (N.1): Build failure and code size increasing?
  • Rustem Avkhadiev said:

    I followed instructions in rfWsnNodeIntFlashOadClient\Readme.md to build Image A, but project failed to build, because of big size of output .bin file (72k).

    It's strange, but then i tried to do the same thing in November - all works fine, since November i got several auto-updates in CCS.

    I tried to replace *.c and *.h files in rfWsnNodeIntFlashOadClient with files from my project. Project compiles and works fine, but size of output .bin also rised:

    from 45k to 52k with Optimization level = 4

    from 54k to 61k with Optimization level = off

    +10% of size is to much for me because of small Internal flash size.

    If you didn't change anything in your project code nor .cfg nor SDK version, then it's only the toolchain version that could have changed. Or did you maybe build with another version of XDCTools? When I compile the project with XDCTools 30.50.3.33 and TI CGT 16.9.4LTS and with optimization level 4, I get 48KiB flash size. Without optimization I get 72 KiB.

  • I hope, you can reproduce "size increasing" in your computer:
    1. Import and build rfEasyLinkTx project. With optimization level 4, size will be 42,7k
    2. Import rfWsnNodeIntFlashOadClient project
    3. Delete from rfWsnNodeIntFlashOadClient project "native_oad" folder, delete files: ccfg.c, NodeRadioTask.c, NodeRadioTask.h, NodeTask.c, NodeTask.h, RadioProtocol.h, rfWsnNode.c, SceAdc.c, SceAdc.h
    4. Copy rfEasyLinkTx.c from rfEasyLinkTx project to rfWsnNodeIntFlashOadClient project
    5. Build rfWsnNodeIntFlashOadClient project. With optimization level 4, size will be 48,4k

    Also, then building unchanged rfWsnNodeIntFlashOadClient project i get 5 warnings like this:
    "warning #112-D: statement is unreachable .xdchelp /rfWsnNodeIntFlashOadClient_CC1350_LAUNCHXL_tirtos_ccs line 9369"
    return ((ti_sysbios_hal_Hwi_Object__ * const)ti_sysbios_hal_Hwi_Object__table__C) + i;
    return ((ti_sysbios_knl_Event_Object__ * const)ti_sysbios_knl_Event_Object__table__C) + i;

    I tried "clean install" latest software: CCS 7.4, 17.9.0 STS, XDCTools 3.50.4.43. Results are same.
  • Hi,

    thanks for the explanation. Now I understand the problem. I think the reason is that the kernel .cfg file in the OAD example disables the TI-RTOS kernel in ROM and hence the flash consumption increases. This is necessary because enabling the kernel in ROM requires the application to reserve space at address 0x1000..0x13fff. There, the ROM kernel expects configuration structures. In an OAD application, this is isn't possible because (unfortunately), the image always starts with a small OAD image header. Since CC13x0 keeps the BIM in the first flash page, the application image start address is 0x1000. So there would be a placement conflict.

    This is the "guilty" config option:

    /* ================ ROM configuration ================ */
    /*
     * To use BIOS in flash, comment out the code block below.
     */
    /* Can not run TIRTOS in ROM with BIM
    var ROM = xdc.useModule('ti.sysbios.rom.ROM');
    if (Program.cpu.deviceName.match(/CC26/)) {
        ROM.romName = ROM.CC2650;
    }
    else if (Program.cpu.deviceName.match(/CC13/)) {
        ROM.romName = ROM.CC1350;
    }
    */
    

  • Thank you, Richard!

    And what about warnings?
    "warning #112-D: statement is unreachable .xdchelp /rfWsnNodeIntFlashOadClient_CC1350_LAUNCHXL_tirtos_ccs line 9369"
    return ((ti_sysbios_hal_Hwi_Object__ * const)ti_sysbios_hal_Hwi_Object__table__C) + i;
  • I can reproduce these warnings only with the TI toolchain 17.09. They are not critical. Actually, the code is valid, but the compiler seems to be able to deduce the parameters used in those functions (might be constants). So the compiler now realizes that this section ins unreachable and warns.

    Maybe only the warning behavior has changed in this compiler version.