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.

CC2650MODA: I2C open/close issue

Part Number: CC2650MODA
Other Parts Discussed in Thread: CC2650STK, CC2650, CC1310, CC2640,

Is there a known issue with opening and closing I2C interface periodically for a low power application? In my application I am using I2C_open() when I need to sample a sensor and I2C_close() to close interface when not needed. By closing I2C interface i am able to achieve much low power when TI-RTOS puts system in standby mode. But for some reasons after a while system simply halts/hangs. After days of debugging and repeated tests, I am able to confirm that it is related to periodic I2C_open() and I2C_close() routines.

if I just open I2C interface with I2C_open() at the beginning of the task and never close I2c interface system runs without halting or hanging, but I do not low low power compared with closing I2C interface.

I also reviewed few example projects like "sensortag_cc2650stk_app" and there too I2C interface is only initialized and open once at the start of an application task and never closed.

Is there any issue with opening and closing I2C interface periodically in TI-RTOS?

Project is based of "simple_broadcaster_cc2650bp_app" example project.

BLE SDK and TI Drivers Versions: "ble_sdk_2_02_04_06" and "tidrivers_cc13xx_cc26xx_2_21_01_08".

  • Hi Pritesh,

    There has been a few bug fixes with the I2C driver the last few years, unfortunately, the CC2650 SDK tools does not get this as they are not actively supported. Could you check where you are getting stuck in the application when this happen? I would expect you might have a issue where the I2C module is stuck with a "BUSY" status if you read out the peripheral registers when this occur. 

    I would suggest you try to port the I2C driver from the latest CC1310 SDK to your application. It is the most up to date driver we got and as the CC2650 and CC1310 uses the same I2C peripheral, you should be able to use this driver. You might need to update a few of your board file structures while doing the port but I would expect the compiler to inform you in any mismatch that might be. 

  • M-W

    Thank you for a quick response and conforming I2C driver issue. I2C open/close bug was driving me nuts for couple of weeks now. I will try out proposed solution of porting I2C driver from CC1310 SDK to CC2650 SDK; and test it out.

    I noticed there is a latest BLE SDK release "BLE-STACK-2-X_2.02.05.02" couple weeks ago 31-Aug-2020. It supports CC2640 and CC2650. Do you know if it supports CC2650MODA? Logically it should since it the same chipset, just confirming. Also more important question is, does it fix I2C driver issue?

    https://www.ti.com/tool/BLE-STACK

    Regards,

    Pritesh

  • Hi Pritesh,

    The new BLE stack should be fine for the CC2650MOD as well, it does however not feature the most up to date drivers as it is shipped with the latest TI-RTOS which is from 2018. 

  • M-W,

    I tried porting I2C drivers from latest Simplelink SDK "simplelink_cc13x2_26x2_sdk_4_20_01_04" and try to update dependency files as well but there is to big of difference from "tidrivers_cc13xx_cc26xx_2_21_01_01" SDK and I don't think dependencies can be satisfied.

    So I took a different approach and compared source code in I2C.h/c and I2CCC26XX.h/c files between two SDK and try to implement source code from new SDK in old SDK. I am able to successfully satisfy all dependencies and compile driver files source code. But I am getting "redefined" linker errors. Can you suggest a solution? I am out of ideas.

    <Linking>
    error #10056: symbol "I2C_init" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_defaultParams" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_control" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_cancel" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_close" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_Params_init" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2C_open" redefined: first defined in "./Drivers/I2C/I2C.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2C.oem3>"
    error #10056: symbol "I2CCC26XX_close" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10056: symbol "I2CCC26XX_cancel" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10056: symbol "I2CCC26XX_fxnTable" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10056: symbol "I2CCC26XX_open" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10056: symbol "I2CCC26XX_init" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10056: symbol "I2CCC26XX_transfer" redefined: first defined in "./Drivers/I2C/I2CCC26XX.obj"; redefined in "C:/ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/packages/ti/drivers/lib/drivers_cc26xxware.aem3<I2CCC26XX.oem3>"
    error #10010: errors encountered during linking; "cs600_app.out" not built

    >> Compilation failure
    makefile:240: recipe for target 'cs600_app.out' failed
    gmake[1]: *** [cs600_app.out] Error 1
    gmake: *** [all] Error 2
    makefile:236: recipe for target 'all' failed

    **** Build Finished ****

    BLE Stack 2_2_5 for CC2650 was released few weeks ago 31 Aug 2020, but support for tirtos drivers is still 2.21.xx when latest tirtos simplex SDK is 4.10.xx.

    Will BLE Stack 2_2_5 for CC2650 work with simplex SDK is 4.10.xx?

    Why is support for CC2650 so behind? Even CCS tools required is V7 when latest is V10. Is CC2650 going to get discontinued, specially CC2650MODA?

    http://software-dl.ti.com/simplelink/esd/ble_stack_2_x/2.02.05.02/exports/release_notes_BLE_Stack_2_2_5.html

  • Hi Pritesh,

    Based on the error you are seeing, I think you are forgetting to add the ".c" files to your project. If you do not do this, it will try to pull in the library versions and as you updated the header files, the library version will not "fit the model" and you get these errors. Adding the .c files to the project (just drag them into the project root if you will) should make the linker favor these over the library versions.

    As for CC2650, there is no plans to discontinue it. On the "why" part, all I could really say is that at some point, it was decided to move it out of active SW support into long-term support, meaning updates are rare and kept as close to the last "proper" release. Bringing it fully into the "SimpleLink SDK" family would require some work and would also not be directly backwards compatible with what is today. 

  • Hi M-W,

    There is something else going on. I have I2C driver files in my project linked to actual files in SDK.

    For updating I2C drivers, I kept original I2C driver files in my project and just replaced and updated source code in the function from latest TI RTOS SDK. This still results in same linking errors as in my post.

    For e.g. Here I have two versions if I2C_init() functions from two SDK. The original one compile and links fine but when in the same file if I replace it with a I2C_init() from latest SDK, compilation works but linker throws redefine error. It feels like linker is comparing precompiled binary with source code for confirmation. This is true with any function updates in I2C.c and I2CCC26XX.c source files.

    /*
     *  ======== I2C_init ========
     * From tidrivers_cc13xx_cc26xx_2_21_01_01
     * Compilation and Linker Works
     */
    void I2C_init(void)
    {
        if (I2C_count == -1) {
            /* Call each driver's init function */
            for (I2C_count = 0; I2C_config[I2C_count].fxnTablePtr != NULL; I2C_count++) {
                I2C_config[I2C_count].fxnTablePtr->initFxn((I2C_Handle)&(I2C_config[I2C_count]));
            }
        }
    }
    
    /*
     *  ======== I2C_init ========
     * From simplelink_cc13x2_26x2_sdk_4_20_01_04
     * Compilation works but Linker Fails, gives "redefined" errors
     */
    void I2C_init(void)
    {
        uint_least8_t i;
        uint_fast32_t key;
    
        key = Hwi_disable();
    
        if (!isInitialized) {
            isInitialized = (bool) true;
    
            /* Call each driver's init function */
            for (i = 0; i < I2C_count; i++) {
                I2C_config[i].fxnTablePtr->initFxn((I2C_Handle)&(I2C_config[i]));
            }
        }
    
        Hwi_restore(key);
    }

    I also tried suggestions from this post that had similar redefined issue, but unfortunately did not work in my case: https://e2e.ti.com/support/tools/ccs/f/81/t/601905?tisearch=e2e-sitesearch&keymatch=CC2650%2525252520redefined

  • Hi Pritesh,

    Could you share the linker settings for you project? 

  • Hi M-W,

    I am attaching a file with screenshots of my project linker settings. Let me know what you find.

    Regards,

    PriteshLinker Settings.docx

  • Hi Pritesh,


    Could you try unchecking the "disable automatic RTS selection" option and see if that impacts anything? I tried setting up a similar example myself based on the this "old TI-RTOS" but I do not see any issues with the approach. Could you maybe share your complete project with me?

  • Hi M-W,

    I tried unchecking "disable automatic RTS selection" but it did not resolve issue. I build my project in side SDK folder same way some of the sample projects are build due to lot of dependencies. Both BLE SDK and tirtos packages are both few hundred MBs. Don't know if I can upload such large zip files.

    I found the issue with new I2C files i snot limited to just my project. The "sensortag_cc2650stk_app" project that comes with "ble_sdk_2_02_04_06" also runs in to same redefine issue and produce same list of errors as my project. May be you can try that out and if problem resolves in "sensortag_cc2650stk_app" project then it will resolve problem i my project.

    I am attaching I2C files that I switch and able to recreate the error.

    I2C_v4.20.zip

    I2CCC26XX_v4.20.zip

    Setup:

    BLE SDK:          tirtos_cc13xx_cc26xx_2_21_01_08 ble_sdk_2_02_04_06

    TIRTOS Ver:     tirtos_cc13xx_cc26xx_2_21_01_08

    Project:             sensortag_cc2650stk_app

    To recreate problem:

    1. Replace I2C.h/c in "C:\ti\tirtos_cc13xx_cc26xx_2_21_01_08\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages\ti\drivers" with files in attached archive "I2C_v4.20".

    2. Replace I2CCC26XX.h/c in "C:\ti\tirtos_cc13xx_cc26xx_2_21_01_08\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages\ti\drivers\i2c" with files in attached archive "I2CCC26XX_v4.20".

    where attached archive I2C files are from latest BLE SDK 4.20.

    3. Try compiling "sensortag_cc2650stk_app" project that is part of "ble_sdk_2_02_04_06".

    Let me know what you find.

  • Hi Pritesh,

    Based on private conversations, the issue seems to have been resolved. The I2C port was successful but the actual error seamed to be to a stack overflow in the main application.