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.

CCS/LAUNCHXL-CC2640R2: Unable to reconfigure cache as GPRAM

Part Number: LAUNCHXL-CC2640R2
Other Parts Discussed in Thread: CC2640, BLE-STACK

Tool/software: Code Composer Studio

Hi,

I have just upgraded to BLE Stack SDK 3_10_00_15 and CCS 9.0.1 and am having difficulty reconfiguring cache as GPRAM.

I have followed the instructions in  SimpleLink™ CC2640R2 BLE-Stack User's Guide for *Bluetooth®* 4.2 (v3.02.00.00)

I have built the out-of-the-box ProjectZero and it runs fine before reconfiguration.  However, after performing the steps in the User's Guide the project I get a linker warning and the project does not run.

The linker warning is: 

"...ti/simplelink_cc2640r2_sdk_3_10_00_15/source/ti/blestack/common/cc26xx/ccs/cc26xx_app.cmd", line 287: warning #10068-D: no matching section..."

Here is the section of the file that is throwing the warning (see highlight):

  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) <--- This line thows a warning
    }
    #endif /* CACHE_AS_RAM */
  } LOAD_END(heapStart)

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

    #ifdef CACHE_AS_RAM

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

Any assistance would be appreciated

Regards,

AC

  • Ugh.. the code snippet is corrupted with HTML and I can't edit it.  The line should read:


    --library=cc2640_ll_*.a<ll.o> (.bss) <--- This line throws a warning

  • Hi Andrew,
    I'm assigning an expert to reproduce and aid with a solution to your problem.
  • Hi Andrew,

    I suspect the archive filenames have changed. You could probably use "cc2640_ctrlll*.a" instead, it's the only place I can find ll.o in the map file.

    Best regards,
    Aslak
  • Hi Aslak,

    Thank you for your response.

    In both cases, out-of-the-box unmodified ProjectZero and reconfigured to repurpose cache as GPRAM, cc2640_ctrlll_pxxx.a is being used.  The problem is that for the case where the cache has been reconfigured, the ram usage for ll.o has been moved to GPRAM.  According to the docs, this is incorrect.  Referring to the instructions for reconfiguration section 5:

    "...5. If your project is based on a BLE-Stack project, this will move as much of the .bss section that the SRAM can fit, from SRAM to GPRAM. The exception is ll.o and, if you’re using the BLE5-Stack ll_ae.o. The RF driver requires ll.o (and if applicable ll_ae.o) to be placed in SRAM...."

    Here is one entry in the map file before cache reconfiguration:

    ll.o is in the .bss segment at memory address 0x2000_xxxx which is SRAM.

    Here is the same entry after reconfiguration:

    Still in .bss but in GPRAM.

    So the docs say that this isn't going to work...

    I don't know the relevance of the linker warning message but the above is wrong, assuming that the docs are correct.

    I've come across another related thread: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/699108?CC2640R2F-simple-peripheral-example-with-CACHE-AS-RAM-enabled-go-on-infinite-loop

    This is from July 2018 and acknowledges an issue that is scheduled to be fixed in the next release. There's been two releases since July 2018 so I'm guessing that this is not the issue. Just throwing it out there in case...

    Regards,

    ac

  • Hi Andrew,

    There have been issues where a few things didn't work out when they were placed in GPRAM. I'm not clear right now on why this was or if it's still an issue that needs to be worked around.

    Are you saying that if you changed the line to --library=cc2640_ctrlll*.a<ll.o> (.bss) it was still placed in GPRAM? Does the application work, or does it crash/not work?

    Best regards,
    Aslak
  • Hi Aslak,

    >> Are you saying that if you changed the line to --library=cc2640_ctrlll*.a<ll.o> (.bss) it was still placed in GPRAM?
    Both those snippets are the output of the build process so changing the line as above will have no effect, yes?

    >> Does the application work, or does it crash/not work?
    The application does not run. After uploading, both the red and green LEDs are fully on. Normally, the green LED is off when running. In the past, my experience has been that this indicates that the app is not initialising, not getting off the ground.

    Regards,
    ac
  • Hi Aslak,

    Apologies, my mistake - I thought you were talking about changing that line in the .map file but you were not. You were talking about changing the line in the linker command file.

    Let me try and I'll get back to you.

    Regards,
    ac
  • Hi Andrew,

    I'm not sure I understand - I took your screenshots to be configuration as described in the documentation, not the change I suggested. If you change the linker file to refer to a different library name for ll.o/bss, does that _not_ change where ll.o gets placed in the map file?

    I'll try to reproduce and have a look tomorrow if this did not help you.

    Best regards,
    Aslak
  • Hi Aslak,

    The confusion was on my end.

    Changing the filename as you suggest has resolved the problem. The warning is no longer issued and the project runs just fine.

    Looking at the .map file, however, I see that ll.o is being placed in GPRAM which leads back to the comments in para. 5 of the docs being incorrect.

    Regards,
    ac
  • Hi Andrew,

    I could not see that the .bss section of ll.o was still in GPRAM when I try to replicate. Glad it worked.

    Best regards,
    Aslak