• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 2216 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/CC2640: CC2640 - How to configure Sensor Controller AUX RAM as general purpose SRAM

Garry Clarkson
Expert 4635 points
Part Number: CC2640

Tool/software: TI C/C++ Compiler

Team,

I have been working on a customer application that is running low on system SRAM in the device due to the amount of data being collected and processed. I would like to reclaim the 2KB of memory mapped Sensor Controller AUX RAM exclusively for use by the CM3 core because the SCE is not needed in their application.

To do this I have simply modified the linker .cmd file to add the region to the MEMORY and SECTION define as '.scratchpad':

#define AUX_RAM_BASE           	0x400E0000
#define AUX_RAM_SIZE            0x800

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = FLASH_BASE, length = FLASH_SIZE
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = RAM_BASE, length = RAM_SIZE
    /* Application uses AUX RAM for scratcpad data */
    AUX_SRAM (RWX) : origin = AUX_RAM_BASE, length = AUX_RAM_SIZE
}

/* Section allocation in memory */

SECTIONS
{
    .text           :   > FLASH
    .const          :   > FLASH
    .constdata      :   > FLASH
    .rodata         :   > FLASH
    .cinit          :   > FLASH
    .pinit          :   > FLASH
    .init_array     :   > FLASH
    .emb_text       :   > FLASH
    .ccfg           :   > FLASH (HIGH)

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc     : {} load=FLASH, run=SRAM, table(BINIT)
#endif
#endif
    .data           :   > SRAM
    .bss            :   > SRAM
    .sysmem         :   > SRAM
    .stack          :   > SRAM (HIGH)
    .nonretenvar    :   > SRAM
    .scratchpad		:	> AUX_SRAM
}

then within application code I can now define buffers and use this admittedly non-contiguous scratchpad region:

// Allocate some buffers in our (AUX_RAM) scratchpad area
#pragma DATA_SECTION(bufferA, ".scratchpad")
char bufferA[512];
#pragma DATA_SECTION(bufferB, ".scratchpad")
char bufferB[512];

I can see the linker allocating the AUX_RAM region to the buffers in the .map file correctly

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  FLASH                 00000000   00020000  00003420  0001cbe0  R  X
  SRAM                  20000000   00005000  0000124b  00003db5  RW X
  AUX_SRAM              400e0000   00000800  00000400  00000400  RW X

This all seems to work fine with default configurations within a TI-RTOS based sample application (idle task and standard power management framework).

Is there anything else I need to do to use this safely? Are there any other configuration requirements that are needed to do this safely such as enabling AUX clock and power domains, ensuring the SCE core is halted (AON_WUC_AUXCTL_SCE_RUN_EN_M cleared in AON_WUC_O_AUXCTL) or explicitly enabling AUX RAM retention (AON_WUC_AUXCFG_RAM_RET_EN set in AON_WUC_O_AUXCFG)?

Thanks for your recommendations.

Regards,

Garry

  • 0
    TI__Guru 56590 points
    Hello Garry,
    I will confer with one of our experts for a review and get back to you.
    BTW: Access to the AUX RAM is considerable slower than access to system RAM.
  • 0 in reply to Eirik V
    TI__Expert 4635 points

    Hello Eirik,

    thanks for the response and I look forward to additional feedback. Can you also quantify the AUX RAM access speed difference so that I have the whole picture. It may not be an issue for this particular customer application.

    Regards,
    Garry

  • 0 in reply to Garry Clarkson
    TI__Guru 56590 points
    Hello Garry,
    AUX clock and power domains are powered and retention enabled by default after boot. the SCE core is halted. The TI-RTOS Power manager will set the sensor controller domain (AUX) in standby (with AUX_RAM retention) when the device enter standby (the sensor controller has power modes similar to that of the device power modes).

    We did some testing on our desk for read/write access times with memcpy() of 2kB (512 x 32-bit words) to and from the AUX_RAM:
    1 cycle = 1/48 us.
    AUX RAM to MCU RAM = 200 us = 9600 cycles = 18.75 cycles per 32-bit word
    MCU RAM to MCU RAM = 36.5 us = 1752 cycles = 3.42 cycles per 32-bit word
    MCU RAM to AUX RAM = 109 us = 5232 cycles = 10.21 cycles per 32-bit word

    The Application Processor (AP-CM3) can do other tasks while the data is being transferred to AUX_RAM, but if the bus buffer gets full during back2back writes, it will stall the AP until there is free space in the buffer. After you write a series of data to AUX_RAM you should implement a singe read access to make sure all the data has been written. The read access will stall the AP until all the data has been transferred to AUX_RAM.
  • 0 in reply to Eirik V
    TI__Expert 4635 points

    Many thanks Eirik,

    this is very useful information. We will test this out.

    Regards,

    Garry