CC2640R2F: SDKv1.40: Enabling Cache as RAM causes board not to advertise?

Hey Kel,

I tried the steps in the User's Guide on the default example and did not see any issues advertising. As such, can you verify any changes made to the linker file? What information are you storing in the cache ram? The Cache as RAM has a slower access speed so perhaps this is influencing some time critical operation from the BLE stack or even at the application.

Did the device hit a fault, or just stop advertising? Can you enable the HEAPMGR_METRICS define to see if there is a potential heap issue?

Hi Ammar,

Following the guide, I put this code at ccfg_app_ble.c.. That was the only part missing at the guide to support CACHE AS RAM.

#ifdef CACHE_AS_RAM
  #define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_GPRAM  0x0 /* Enable GPRAM */
#endif //CACHE_AS_RAM

I set CACHE_AS_RAM predefined symbol and rebuild all. That did not reduce the RAM usage according to View->Memory Allocation.

According to the guide you can set what uses CACHE AS RAM. We have global array with size 4k and I want to move that from SRAM to CACHE AS RAM. Following the guide, I add this code above the array.

#pragma DATA_SECTION(sectorbytes16x256, "my_section")
uint8_t sectorbytes16x256[16][HS_TOTALONOFFREC_LEN] = {0};

I rebuild all and I see the RAM usage reduced from 75% to 51% which is great.

At the linker file cc26xx_app.cmd I added the halologger_peripheral.obj(my_section)

  GROUP > SRAM
  {
    .data
    #ifndef CACHE_AS_RAM
    .bss
    #endif /* CACHE_AS_RAM */
    .vtable
    .vtable_ram
    vtable_ram
    .sysmem
    .nonretenvar
    /*This keeps ll.o objects out of GPRAM, if no ll.o would be placed here
      the warning #10068 is supressed.*/
    #ifdef CACHE_AS_RAM
    ll_bss
    {
      --library=cc2640_ll_*.a<ll.o> (.bss)
    }
    #endif /* CACHE_AS_RAM */
  } LOAD_END(heapStart)

  .stack            :   >  SRAM (HIGH) LOAD_START(heapEnd)

    #ifdef CACHE_AS_RAM
    halologger_peripheral.obj(my_section)

    .bss :
    {
      *(.bss)
    } > GPRAM
  #endif /* CACHE_AS_RAM */

I rebuild all and flash the hex file, and the board does not advertise. I undo my changes and still the board does not advertise. The activity above messes up the CCS project.

-kel

I am also in need of help with this issue.

Clement, if you are out there, this is my next 'fire' to put out... ;)

Markel,

Did you try to enable the HEAPMGR_METRICS define... as Ammar suggests, I do not see in your reply that you did...

Dale 

Markel,

I have made some progress on this.

I believe that a 'CACHE_AS_RAM' pre-define is also needed in the LINKER at: Properties->Build->Linker->Advanced Options->Command File Preprocessing.

EDIT: It looks like the proper LINKER define should be 'CACHE_AS_RAM=1'  (but I seem to get the same results if simply 'CACHE_AS_RAM' is define in LINKER)  

When I do that, the project does not build and the error is at your added line 'halologger_peripheral.obj(my_section)' in cc26xx_app.cmd.

Not sure where to go from here though,

I will plod on :( until a TI expert joins in here...

Dale

Dale Kramer said:

I believe that a 'CACHE_AS_RAM' pre-define is also needed in the LINKER at: Properties->Build->Linker->Advanced Options->Command File Preprocessing.

Yes, I did that also. If you follow their procedure without adding the code to put sectorbytes16x265[] array to CACHE RAM. No modifications to linker file. After you rebuild all and flash the hex file the board does not advertise.

-kel

How did you compile without error after you pre-defined CACHE_AS_RAM' in the LINKER?

Did you receive the same build error of 10030-D expecting section type?

Dale

Dale Kramer said:

How did you compile without error after you pre-defined CACHE_AS_RAM' in the LINKER?

You need to comment out or not add this code above sectorbytes16x256[]

//#pragma DATA_SECTION(sectorbytes16x256, "my_section")
uint8_t sectorbytes16x256[16][HS_TOTALONOFFREC_LEN] = {0};

At linker file .cmd file do not add the halologger_peripheral.obj(my_section) code line.

After this, I get a warning "no matching section" at .cmd linker file.

Dale Kramer said:

Did you receive the same build error of 10030-D expecting section type?

Maybe that is caused by the halologger_peripheral.obj(my_section) code line at the .cmd linker file.

-kel

I clicked the wrong button.

Dale Kramer said:

BUT we lose the functionality of why you put that line in there, what was your reason for adding that line

As I have mentioned in this post I wanted to transfer the sectorbytes16x256[] from SRAM to CACHE RAM. Mentioned in the procedure "Other objects in .bss can be moved as desired. See Using the AUX RAM as RAM for an example"

-kel

Yes, but adding that line in .cmd file caused a build error after predefining CACHE_AS_RAM in the linker.

When we take away your failed efforts to move sectobytes16x256[] to CACHE RAM and then also predefine CACHE_AS_RAM in the linker, we do get advertising back but unfortunately we still are not able to get notifying on 4 characteristics at the same time 

So:

1. How do we properly move sectorbytes16x256[] to CACHE RAM?
2. Achieve notifying on 4 characteristics at the same time?

I was able to add HEAPMGR_METRICS and the values can be seen here:

Unfortunately when I break the running code, I can not use ROV>Task>Detailed view to investigate stack usage.  My forum topic on that issue has not been answered yet cc2640r2f-received-exception-from-rov-server.

Dale

Dale Kramer said:

So:

1. How do we properly move sectorbytes16x256[] to CACHE RAM?

I have figured out the syntax for the .cmd line that was needed to move sectorbytes16x256[] to CACHE RAM.

We have LOTS of FREE RAM available now and we advertise but we still are not able to achieve notifying on 4 characteristics at the same time

Here is the code and memory status's with the code advertising:

Still no joy, perhaps I should start a separate topic about not being able to achieve notifying on 4 characteristics at the same time since this topic has been resolved as far as advertising goes...

Dale

PS: It looks like the proper LINKER define should be 'CACHE_AS_RAM=1' as per this doc cache-gpram (but I seem to get the same results if simply 'CACHE_AS_RAM' is define in LINKER)

Hi all,

Glad you were able to resolve this.

I will take this thread and incorporate this feedback to our documentation. Do you all have any specific points you would like to be addressed?