[CC2650] How to check the runtime RAM usage

Hello Sunny,

Please see the "9 Development and Debugging" section in SWRU393, specifically the section for profiling the ICall heapmgr.

Best wishes

Thank you RCFOCUS and JXS for the pointers.

I want to know that in a given amount of time e.g. 1 minute of system usage, what is the peak of SRAM being utilized out of the 20KB available (Not just the HEAP).

This will help us to estimate some of our other system requirements.

From the map file, I am getting 5KB of free SRAM. Does the map file --> Free SRAM, account the HEAP memory or does that mean that the 5KB can still be used for new CODE, and DATA sections.

One more question:

Earlier, we were using CC2541 which has 8KB SRAM and these same functionalities were working fine with that. Then why it is taking so much of RAM, around 15KB, with this chipset i.e. CC2650. We were expecting the RAM usage will improve with this migration!

Thanks,
Sunny

Hi RCFOCUS,

Thank you for the information.

I am not sure if you can, but, I was just curious to know that from where did you port the RTOS to the CC2650 ?
How much of free SRAM are you getting by using your own RTOS ?
Can you share more information on that if you can ?


@JXS,
Can you please reply for the below query:
Earlier, we were using CC2541 which has 8KB SRAM and these same functionalities were working fine with that. Then why it is taking so much of RAM, around 15KB, with this chipset i.e. CC2650. We were expecting the RAM usage will improve with this migration!


Thanks,
Sunny

Sunny,

There are a number of things that contribute to the SRAM consumption in the CC2640. There are also a number of ways to profile the amount of SRAM needed by the RTOS. Note that the BLE stack and application layer use the heap memory to store data. However, the heap size is configurable and perhaps you are not needing all that is allocated.

Can you please follow the section that JXS linked from the Software developer's guide and report your max heap usage, so that we may help you free up some RAM for your application. In short, the heapmanger metrics are exactly what you are using for and will show the "high water mark" of your heap memory useage. Also it would be helpful to know what SDK example project you are basing your development off of.

Hi Sean,

Thank you for the pointers.

Our project is based on the SimpleBLEPeripheral Project. We started with this project and modified / ported our proprietary code from CC2541 code base.

I have gone through the chapters pointed by JXS in Software Developer Manual.

I have defined the HEAPMGR_METRICS and got the below:

0x4F8 == 1272 bytes - heapmgrMemAlo: Current total memory allocated in bytes.

Below are the defines for Heap and Stack in the "Project Properties -> CCS Build -> ARM Compiler":

--define=SBP_TASK_STACK_SIZE=700
--define=GAPROLE_TASK_STACK_SIZE=520
--define=HEAPMGR_SIZE=2672

That means that out of the 2672 bytes of Heap, we are using 1272 bytes, right ?

Also, currently we have enabled the TI_DRIVERS_LCD_INCLUDED for debugging. If this feature is disabled, then 1KB of unused SRAM is increased. So is there a way to further optimize the inbuilt drivers because we need SPI Interface ?

For SPI Interface, we have the below flags defined:

TI_DRIVERS_SPI_DMA_INCLUDED
TI_DRIVERS_SPI_INCLUDED

Do we need both the flags for SPI Inteface ?

Below are the defines in the project. Please suggest if we can still optimize anything further:

--define=USE_ICALL
--define=POWER_SAVING
--define=SBP_TASK_STACK_SIZE=700
--define=GAPROLE_TASK_STACK_SIZE=520
--define=HEAPMGR_SIZE=2672
--define=TI_DRIVERS_LCD_INCLUDED
--define=TI_DRIVERS_SPI_DMA_INCLUDED
--define=TI_DRIVERS_SPI_INCLUDED
--define=ICALL_MAX_NUM_TASKS=3
--define=ICALL_MAX_NUM_ENTITIES=6
--define=xdc_runtime_Assert_DISABLE_ALL
--define=xdc_runtime_Log_DISABLE_ALL
--define=MAX_NUM_BLE_CONNS=1
--define=CC2650EM_7ID
--define=CC26XXWARE
--define=CC26XX
--define=ccs
--define=DEBUG
--define=HEAPMGR_METRICS  --> Enabled only for current debugging for Heap USAGE
--diag_warning=225
--display_error_number
--diag_suppress=48
--diag_wrap=off
--gen_func_subsections=on

Thanks,
Sunny

Hi TI Team,

Can anybody please reply.

Thanks,
Sunny

Hello Sunny,

You can probably reduce the System Stack (i.e., Program.stack) to 512 bytes. Beyond that, reducing the heap based on profiling and removing LCD debug code is your best option.

There is also 2kB of SRAM in the Sensor Controller if you are not using this. It is not setup to be accessed by the linker, but you can manually use this as a buffer. See the AUX_RAM section of the CC26xx TRM (SWCU117).

Best wishes

Hi JXS,

Thank you for the pointer.

The LCD code under the TI_DRIVERS_LCD_INCLUDED is taking 1KB of extra SRAM space and that we will be disabling in the final code.

Moreover the Application stack that we have is currently 700, so reducing it to 512 will not be a big savings.

As you suggested to use the SCE - AUX_RAM section, but how to manually use the address. From the SWCU117:

AUX_RAM                   AUX SRAM                          0x 400E 0000

the AUX_RAM address is 0x400E0000. But can you please give pointers to how to manually use this address.

Can I like use the below snippet:

uint8_t *ptr = (uint8_t *) 0x400E0000;

and start using this pointer upto 2KB boundary ?

Thanks,
Sunny

You will likely also have to modify your linker file to acknowledge this area of memory.

Hi Sean,

I am able to use the SCE AUX_RAM area by using pointer to this memory location.

But, I did not understand "modify your linker file to acknowledge this area of memory".

Can you please elaborate ?

Thanks,
Sunny

Hi Sunny,

Yes, I have ported my RTOS to CC26xx. And now, I am building basic device drivers based on C++ class, for example, I2C, uDMA... This job is almost done. So, now I am planing in building the BLE stack in C++ class.

In RTOS, the used SRAM size is depended on how many tasks created in a RTOS system. For each task, how to minimise the task-control-block (TCB) and the task stack size is an art. As in TI-RTOS, you can define the stack size for each task individually. You can also use CCS Plug-ins to view the used stack size and decrease it when necessary. So, the "free SRAM" size is not easy to answer if the application is not well defined.

The design of device driver is also important for memory usage, for example, if the driver's code looks like:

uint8_t myDriverBuf[128];

myDriverInit(driver_t* dry)
{
    memset(myDriverBuf,...);
    ....
}

This is not good because it will take 128 bytes even the device is in sleep/idle state. This is why I prefer to design all my device drivers instead of using what provided by TI.

The other reason is I prefer to use C++ for most of the program. Nowadays, C++ is very efficient. Yes, it still use a little more memory compared to C. But, in fact, the side effect can be minimised if well designed. The best benefit is the whole program structure is more clear and easier to maintain.

But please don't blame on TI because TI need to provide drivers and BLE stack for "general purpose". And I only need to  implement what I need.

The linker command file (*.cmd) and the memory map file (*.map) is a good starting point. At least you can figure out who is using global memory. Then, try to profile the HEAP memory usage.

Hi RCFOCUS,

Thank you for your detailed reply.

I need to use the TI provided code as of now.

But thanks for the pointers that you gave. I will keep them in mind.

Thanks,
Sunny