CC2650 SensorTag with More Flash Memory than 128kB

No, the max flash size of current CC26XX is 128KB.

Hello Yikai,

I have the same situation in the middle of my development with the CC2650 and I am currently looking for what TI can do for me to face this problem. I found that the CC2540/1 can have 256KB of flash, is this the only possibility for my situation or can you suggest other options?
Thank you for your help.

Kind Regards,


Simone Frau

Thank you, I will have a look!

Kind Regards,


Simone Frau

Hello Morgan,

Did you sent OSAL_SNV=0 to disable SNV pages? This can free up to 8kB of app code.
Also what is your application size requirement?

Best wishes

You are welcome and maybe TI would release CC26xx with larger Flash size later.

Can anyone from TI give us an update regarding possible development of a CC2650 with increased Flash size?
Kind regards,
Freddy Gunneweg

Hello JXS,

Can I ask you support for my situation?

Based on my requirements I need OAD and the Bond Manager in my system, then I configured OSAL_SNV = 1 to be able to use the Bond Manager and save the 4kB of the second page for SNV. Based on the SimplePeripheral and SensorTag examples I can evaluate the size of the stack as 60/64 KB (I can not understand why is a bit different between the two projects), it means that we have 52/56 KB free for the application (Because 4KB are for SNV, 4 KB for BIM and 4KB for Int Vectors).

I can evaluate that my application needs 52 KB, but I would like to have a bit more space for some minor changes in the future.

Basically that means I can not use the CC2650 for my development. The only possibility I can see is to use the FlashROM configuration, because this requires a lot less flash than FlashOnly_OAD, and here comes my question for TI. Is it really not possible to have the OAD feature with this configuration? I suppose this uses ROM to store part of the TI-RTOS and drivers and this is risky during an OAD. I just would like to know if this is an high risk or it can be a real possibility.

Thank you very much for your support.

Kind Regards,


Simone Frau

I have just found someone else trying to do that:

e2e.ti.com/.../1940794

Hi Simone,

For your SensorTag project, can you make sure the following is disabled:
/* -DL2CAP_CO_CHANNELS */
/*-DCTRL_V41_CONFIG=PING_CFG+SLV_FEAT_EXCHG_CFG+CONN_PARAM_REQ_CFG+MST_SLV_CFG */

In the buildConfig.opt?

Best wishes

Hi,

I think those options are from the old stack, now in the new stack there are these:

/* BLE v4.1 Features */
/* -DBLE_V41_FEATURES=L2CAP_COC_CFG+V41_CTRL_CFG */
/* -DBLE_V41_FEATURES=L2CAP_COC_CFG */
/* -DBLE_V41_FEATURES=V41_CTRL_CFG */

/* BLE v4.2 Features */
/* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */
/* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG */
/* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */
/* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+EXT_DATA_LEN_CFG */
/* -DBLE_V42_FEATURES=SECURE_CONNS_CFG */
/* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG */
/* -DBLE_V42_FEATURES=EXT_DATA_LEN_CFG */

All of them are disabled by default in the SensorTag project.

Let me know about my use of the OAD with the FlashROM configuration, thank you very much for your help.

Kind Regards,


Simone Frau

Hello Simone,

The FlashOnly RTOS configuration is needed for OAD use cases since the RCFG is located in page 0, which also houses the intVectors. Although you could erase/update page 0 during OAD, if you did not complete this successfully you would field-brick your device and need to recover via JTAG. If your power source is good, then this is not likely to occur.

If you use SensorTag or SimpleBLEPeripheral with OSAL_SNV=1, you can use a buildConfig.opt of:
-DHOST_CONFIG=PERIPHERAL_CFG
-DGAP_BOND_MGR
-DGATT_NO_SERVICE_CHANGED
-DHCI_TL_NONE

To have the minimal stack config for pairing/bonding. Note that the SNV 4kB sector is included in the stack image.

Does this help?

Best wishes

Hello JXS,
yes it was very helpful, thank you.

Now I am able to compile the SensorTag example with the FlashOnly_OAD configuration and everything from my application fit in the flash. But are you sure that I have to define -DGATT_NO_SERVICE_CHANGED, should not stay undefined to save flash?

Moreover now I am trying to check the functionality of the new Stack and unfortunately I found some differences compare to the old Stack. For example I have problem with the bonding, do I have to remove the compiling macro NO_BLE_SECURITY?

Another problem is the power consumption, with the previous stack in idle my application consumes 4uA, now with this stack using exactly the same configuration of the pins for my board I have 400 uA. Do you have some ideas about that? Some different configuration or default setup from the previous stack?

Thank you very much for your support.

Kind Regards,


Simone Frau

Hello Simone,

Leaving -DGATT_NO_SERVICE_CHANGED defined will save flash memory by excluding the lesser used service changed indication support.

For the higher current, did your board file change or are you including the wrong board file?

Best wishes

Hello,

before to test in my PCB I decided to use a SensorTag, then I used the example cc2650stk which includes CC2650STK.h and CC2650STK.c
Should they be correct for the SensorTag, right?

But the example, as it is, it continues to send messages and do stuff, then I have just changed the application to do nothing for 5 minutes. I send an advertise message every 5 minutes and nothing more. In this way I found that using the stack 2.1.1 mainly the SensorTag uses 4uA, using the stack 2.2.0 it uses 400uA.

To obtain the 4uA in the stack 2.1.1 I needed to initialise all the sensors in this way:

/* Initialize the sensors drivers */
bspI2cInit();

sensorTmp007Init();
sensorBmp280Init();
sensorBmp280Enable(false);
sensorHdc1000Init();
sensorOpt3001Init();

Moreover I need to initialise the external flash, otherwise I see more power consumption, but I did not find a better way than this:

extFlashOpen();
extFlashClose();

As I said this is enough for the stack 2.1.1 to see 4uA, but doing exactly the same thing for the stack 2.2.0 I see 400uA.

I do not know if it is a new management of the drivers or a different board configuration. Do you have any idea about that?

Thank you very much for your help.

Kind Regards,


Simone