• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 408 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2F: Enabling CACHE_AS_RAM main() is not executed

Deniz Can Cigsar
Intellectual 720 points

Part Number: CC2640R2F

I created simple peripheral sample from SimpleLink 4.30.0.08 and added CACHE_AS_RAM to predefined symbols, also added CACHE_AS_RAM=1 to linker command file processing settings. The code compiles, some variables are located into GPRAM. However, when I debug, the CPU does not run to main. The resume button is not enabled as well.. 

When I looked the documents such as following:
https://software-dl.ti.com/simplelink/esd/simplelink_cc2640r2_sdk/3.20.00.21/exports/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/cache-as-ram.html

It has "In the ccfg file, (called ccfg.c), include the following before #include <startup_files/ccfg.c>". However, it looks like the document is out of sync with the latest release.. There is no "ccfg.c" etc.. There is ble_user_config.c, and it handles CACHE_AS_RAM macro in some places..

What shall I do?

  • 0
    TI__Guru** 101490 points

    Hi,

    Make sure to use the documentation corresponding to your SDK version and to the stack you are using. The following link seems a bit more accurate: https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/blestack/ble_user_guide/html/ble-stack-common/cache-as-ram.html?highlight=cache%20ram#using-the-cache-as-ram

    Could you please review the document and see if this could work better?

    Thanks and regards,

  • 0 in reply to Clément
    Intellectual 720 points

    Hi,

    The link you gave has the same content with the link I gave.. The problem is that this document is out of sync with the current state of SDK.. Could you spend a few minutes on the problem, and try applying the solution in the given link and see yourself..

  • 0 in reply to Deniz Can Cigsar
    TI__Guru** 101490 points

    Hi,

    I confirm the documentation link I have provided is correct for BLE and BLE5 examples on CC2640R2F for SDK 4.30.00.08. If needed the ccfg file (ccfg_app_ble.c) is stored in the folder "Startup" of the project.

    Regards,

  • +1 in reply to Clément
    Intellectual 720 points

    You cannot confirm that.. Because simple_peripheral_cc2640r2lp_oad_offchip_app example does not have ccfg file, also its linker script's memory layout does not have CCFG section..

    If you derive project from simple_peripheral_cc2640r2lp_oad_offchip_app, you have to add ccfg file by yourself.. It will be a .c file with the following content:

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

#include <startup_files/ccfg.c>

    You have to add CASHE_AS_RAM in predefined symbols, and also CASHE_AS_RAM=1 into Command File Processing section of linker.. However, you have to update the linker script as well.. Which is TOOLS/cc26xx_app_oad.cmd. It doesn't have .ccfg section in flash for placement of __ccfg variable..

    The flash section of cc26xx_app_oad.cmd is the following:

     GROUP > FLASH_IMG_HDR
  {
    .img_hdr align PAGE_SIZE
  }

  GROUP > ENTRY
  {
    .resetVecs
    .intvecs
    EntrySection  LOAD_START(prgEntryAddr)
  }

  GROUP >>  FLASH
  {
    .text
    .const
    .constdata
    .rodata
    .emb_text
    .pinit
  }
  .cinit        : > FLASH LOAD_END(flashEndAddr)
     

    So, __ccfg variable is placed in somewhere in the flash, and not at the address 0x0001FFA8.. We found that in reverse order, by boot routines in disassembly.. You also better copy the cc26xx_app_oad.cmd into the project, as it is a linked file and it will not be fixed if you compile on different computer..

    By the way, Making something shall not be that much difficult. We really like your chips, but the framework is a hassle.. We have enough problems in our projects, frameworks shall not step on our toes.. TI should really work on SOLID method:

    S Single Responsiblity Principle
    O Open Closed Principle
    L Liskov Substitution Principle
    I Interface Segregation Principle
    D Dependency Inversion Principle..

    The framework violates all of them and now the linker script is not dependable.. I hope someone in your team pushes others to write cleaner code, simpler implementation etc..