Compiler/CC1310: Using the Cache as GPRAM for application

user4746892

Part Number: CC1310
Other Parts Discussed in Thread: BLE-STACK

Tool/software: TI C/C++ Compiler

Hi all,

For my project I need more RAM than I have got available by now. I tried to reduce the amount of needed RAM but in the end its already at its limits. I tried to compile the project with the needed memory spaces for several vars, the result is I need about 6 kByte more RAM. As I know the CC1310 has got 8kByte additional Cache that can be used alternatively as GPRAM. I rearranged at least some of the needed space from SRAM to GPRAM. Furthermore I modified the the Linker File to set the moved vars to GPRAM area. The compiler says that memory fits as well as that the gpram memory area is used as expected.

In details this is what I did:

1.) Manually set vars to another section by __attribute__ ((section(".gpram.rxbuf_data"))) static uint8_t rxbuf_data[BUFSIZE];

2.) Added a wildcard subsection inside gpram section with

 .gpram (NOLOAD):
    {
     _gpram = .;
	*(.gpram*)
	 _egpram = .;
    } > GPRAM

I am using NOLOAD making sure that the generated Hex File has no initialization values for GPRAM area

3.) Manually let initialize the gpram area in startup_gcc function ResetISR(void) like it is done with SRAM, too.

//
// Zero fill the gpram segment if configured as such
//

#if SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_GPRAM == 0x1

__asm(" ldr r0, =_gpram\n"
" ldr r1, =_egpram\n"
" mov r2, #0\n"
" .thumb_func\n"
"zero_loop:\n"
" cmp r0, r1\n"
" it lt\n"
" strlt r2, [r0], #4\n"
" blt zero_loop");

#endif

4.) Defined the flag of additional memory used as GPRAM instead of CACHE in the main project header

//#####################################
// Select between cache or GPRAM
//#####################################
#define SET_TO_GPRAM 0x0
#define SET_TO_CACHE 0x1

#undef SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_GPRAM
#define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_GPRAM SET_TO_CACHE

Once I programmed the device with the generated HEX file, I can see that the device wants to start (serial output during startup) but doesn't work almost immediately.

What am I doing wrong? What is missing, what is the problem.

Kind regards

Markus

over 7 years ago

0 Marie H over 7 years ago

TI__Guru* 81531 points

Hi Markus,

We wrote a guide on how to do this on CC2640R2 with a BLE-Stack project. See: dev.ti.com/.../memory_management.html (Since both devices use a similar software structure the non-ble-specific points are valid for CC1310 as well.)

The check-list is as follows:
- Change CCFG (which you already did)
- Disable VIMS in main (if you're using it).
- Define the GPRAM section in the linker file
- Add the following radio override:
#ifdef CACHE_AS_RAM
0x00018063,
#endif //CACHE_AS_RAM

For code snippets, please refer to the link.

0 user4746892 over 7 years ago in reply to Marie H

Intellectual 270 points

Hi Marie,

Thanks for check list. Up to the last item I think I understand everything. Could you please tell me more about this radio override?
I think I got, that there are inner core mechanisms that still try to use the GPRAM as CACHE. To be honest, I don't know where to place that Hex value in what way.

Kind regards

Markus

0 Marie H over 7 years ago in reply to user4746892

TI__Guru* 81531 points

Hi Markus,

What example project are you working from? (Easylink or RF Driver or other?)

If you're using the radio you have a list of overrides, whether you're aware of it or not. The override I gave is required to use the GPRAM as RAM not cache, and should be added to the list of overrides.

0 user4746892 over 7 years ago in reply to Marie H

Intellectual 270 points

Hi Marie,

I am using Contiki OS as basis on my project. This OS uses TI libraries as basis. If I get you right, there is a file where it is possible to place your so called overrides. Another Tool processes all values to generate a valid binary for the CCFG or whatever RF area to make sure this part of CC1310 won't use the Cache. Do you have more precise information where the information has to be placed in the end? I think this override belongs to more than one specific bit function. I am afraid that I may smash other configuration things from rf core.

Kind regards

Markus

0 PrashanthS over 7 years ago in reply to user4746892

TI__Expert 8765 points

Hello Markus,

You can add the hex value mentioned in RF override in the smartrf-settings.c file

In your case, add it in this file github.com/.../smartrf-settings.c

on line 161 before "(uint32_t)0xFFFFFFFF"

Regards,
Prashanth

0 user4746892 over 7 years ago in reply to PrashanthS

Intellectual 270 points

Hi Prashanth,

sorry for this following question:

do you mean "(uint32_t)0x00018063" has to be written instead of "(uint32_t)0xFFFFFFFF"

or do you mean

(uint32_t)0x00018063,
(uint32_t)0xFFFFFFFF",

add value in the line before?

Currently the device is compiling the application very well it is programmed very well, but it does a kind of reset after less than 3 seconds each time --> mayber there is a lpm active that causes the vims to be enabled again...?

Kind regards
Markus

0 PrashanthS over 7 years ago in reply to user4746892

TI__Expert 8765 points

Markus,

It has to be added as below.
(uint32_t)0x00018063,
(uint32_t)0xFFFFFFFF,

Please let us know if that fixes it.

Regards,
Prashanth

0 user4746892 over 7 years ago in reply to PrashanthS

Intellectual 270 points

Hi Prashanth,

I did as you said. It seems to work!!!

I will let work my network now to see if it runs stable. I will give you another feedback tomorrow.

Thanks Marie and Prashanth for your support!

Regards Markus

0 user4746892 over 7 years ago in reply to user4746892

Intellectual 270 points

Hi Prashanth,

This morning I has to see that the qty. of devices in my network is shrinking continuously within hours. I have a guess, taking Maries Howto as basis:

In the howto she includes the need for so called Power_constraints. If I understand that correct this is a logical solution by presenting a bit mask indicating which part can be switched power off and which part not. As long as the power domain changing mechanisms use this logical masks it might work perfectly.
I tried to include those mechanisms, but I had to find out that my system is doing it with lpm structures. All in all both systems are competing to each other.
I am not sure, but I think the cc1310 is sometimes switching in sleep and deep sleep mode. All used lpm modules do not expect to keep any power domain active. For my understanding it means, with the RF settings I added I can guarantee that the RF core won't switch off GPRAMs power domain from itself; but if any lpm module is switching off power domain for GPRAM there is no active "constraint" about keeping power domain for GPRAM active as long as VIMs is used for this purpose.
I am saving the networking routes inside SRAM, but networking packages are saved inside GPRAM.
What do you think Prashanth?

Kind regards

Markus

Sub-1 GHz

Sub-1 GHz forum

Compiler/CC1310: Using the Cache as GPRAM for application