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.

CC2652RSIP: On-chip OAD using 1 copy of BLE stack

Part Number: CC2652RSIP
Other Parts Discussed in Thread: CC2652R7

I am porting application from nRF52832 to CC2652RSIP due to unique set of peripherals that Sensor Controller offers. Our application is already 193kB (on nRF52832) WITHOUT ble stack and we need to have secure OAD functionality. Currently TI on-chip OAD implementation is made from these components:

  • BIM, responsible for security and image verification, 8kB
  • Persistent application + BLE stack, responsible for OAD image download, ~120 kB
  • User application + BLE stack, responsible for product function, can use remaining flash 352kB-8kB-120kB =  224 kB

This approach has 2 copies of BLE stack. Currently our "work in progress" application + BLE stack is 232 kB. I believe if we only had 1 copy of the stack we will free enough space to implement on-chip OAD. Goal would be for persistent and user applications to use same BLE stack.

Question - how do I make persistent application and user application share the BLE stack? I saw some forum threads from 3-4 years ago about BLE stack as a separate project, but most links to guides are not working or obsolete.

Tools used:

  • SDK - simplelink_cc13xx_cc26xx_sdk_5_40_00_40
  • CCS - 11.1.0.00011 
  • Hi Marius,

    I don't know if this is possible given the text in our user's guide here

    "This approach requires two full application and stack library pairs on the target device".

    That being said, I'm going to forward this internally to other members of the team who may have more ideas. In the meantime, you also have the following options:

    1. Reduce the amount of memory your device consumes with the following guide : 

    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_5_40_00_40/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/creating-a-custom-bluetooth-low-energy-application-cc13xx_cc26xx.html#optimizing-bluetooth-low-energy-stack-memory-usage

    2. Consider upgrading to the CC2652R7 device, which has double the memory

    3. Consider running off-chip OAD

    Best,

    Nate

  • Hey Marius,

    To echo Nathan's reply: Unfortunately in the latest stack for the CC2652RSIP, split image OAD's are not supported since the app and stack are built together. I would recommend trying some of Nate's suggestions.

  • 1. Reduce the amount of memory your device consumes with the following guide : 

    Already did.

    2. Consider upgrading to the CC2652R7 device, which has double the memory

    No, size is a big factor for us. We chose RSIP because it integrates crystals and antenna matching in the same 7x7mm footprint. If we need to use TI 7x7mm device + passives (antenna matching and crystals), then it is not much an improvement over current implementation.

    3. Consider running off-chip OAD

    Will evaluate this internally.

    However, I am still thinking about different approach. I can improve OAD to work with whatever image configuration I need. Main question is - how do I tell CCS linker to re-use BLE stack code from the persistent application when I link user application?

  • Hey Marius,

    Thanks for evaluating the other options, I understand your concern more clearly now.

    However, I am still thinking about different approach. I can improve OAD to work with whatever image configuration I need. Main question is - how do I tell CCS linker to re-use BLE stack code from the persistent application when I link user application?

    A quick disclaimer before we discuss this further: As the configuration you are asking about is not provided by TI, we are unfortunately unable to also test this configuration so a large part of this effort will have to be self-driven in terms of final testing/verification.

    The linker file (.cmd) in CCS is the file where the project is mapped out in memory. Once CCS builds the project, refer to the .map file of that project for a final say in where things are placed and where symbols are being referenced.

    One hurdle you will face is that you need to somehow decouple the project so that the stack dependencies are built in a separate project. This will help immensely moving forward to avoid any issues with custom memory maps. Then, you can more easily and freely modify the memory map in the .cmd and have a single stack source. This is no trivial task I'm afraid. Right now, the projects build a single app+stack image together as you are aware.

    I hope this helps and provides context for some next steps.

  • Did some initial investigation, it looks like sharing BLE stack and common drivers can save ~72kB of flash space. Which leaves ~296 kB for user application.