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.

CC2630: TIMAC flash only build, not sure how to allocate RAM

Part Number: CC2630
Other Parts Discussed in Thread: SYSBIOS, TIMAC, Z-STACK,

I am writing for an existing deployment so I cannot use the resources available in ROM. SYSBIOS and Stack has to entirely be in flash. I'm seeing that the FLASH_ONLY config of Stack takes a full 50% of onboard RAM (10kb), SYS/BIOS and other application side RTOS resources take over 7k (summing the large items on my map file) leaving almost nothing left for the actual application. I've noticed that if I use a thread stack size of much smaller than 750 bytes I crash when making ICall queries. The MSA example uses a stack size of 704 for reference.

What I am trying to figure out is

1. Is there any way to reduce the RAM needs of Stack or the application side system components?

2. How do I figure out how large a stack I need to give my thread that makes the ICall to talk with the radio? Given how tight my constraints are I need a hard number for space I can safely work with.

  • Hi Daniel,

    You can reference the linker configuration (icf) and output .map files to further understand your compile time RAM allocation.  You might be able to track Heap Memory, see timac_1_05_02_43299\Documents\Heap Memory Management.pdf.  If you are not using the Sensor Controller then you may be able to utilize the AUX_RAM, or consider using the cache as GPRAM.

    Regards,
    Ryan

  • An additional 8k from cache as GPRAM would give me everything I need. I'll look into the AUX_RAM but that probably wont be needed. Thanks!

  • I'm confused about the heap management. I am unaware of any heap and not sure how I'd re-allocate one if it's managed by the internal libraries. The document referenced looks Z stack related which is odd since its different software and doesn't even support the CC26x0 platform. I've seen references to some code composer tools regarding a heap but I can't actually find them (and they seem relevant to newer software packages that I can't use).

    Cache as GPRAM looks like a nonstarter. It is not supported on the cc2630 nor the version of TI RTOS I have to use for TIMAC. It also requires CCFG changes I cannot make in the field.

    I'm still trying to figure out how to give the linker AUX_RAM but it looks a lot more straightforward so I'll update once I figure that out.

  • Hi Daniel,

    I am sorry to hear about the difficulties you are continuing to experience.  Thank you for reminding me about TI-RTOS and CC2630 not supporting GPRAM.  I also see the references to Z-Stack and if the same definitions are not existent then agree that this may not be useable for your solution.  It is hard to keep track of these deprecated documents and code packages.  Please give me an update once you get further with linker AUX_RAM configuration.

    Regards,
    Ryan

  • The AUX RAM is a solution, but not a great one. I couldn't find a way to add it to GPRAM and that is probably a good thing. I see other threads advising that using the AUX RAM for any system feature is unsupported since it is much slower (I profiled it at worse than 1/4th speed). I could, however, create a read/write region in that address space and use the location pragma to place static buffers within. The AUX RAM addresses are also accessible by C code without any ICF file involvement, but its usually best to leave things to the linker.

    // ICF file
    define symbol AUXRAM_START           = 0x400E0000;
    define symbol AUXRAM_SIZE            = 0x800;
    define symbol AUXRAM_END             = AUXRAM_START + AUXRAM_SIZE - 1;
    define region AUXRAM_MEM          = mem:[from AUXRAM_START to AUXRAM_END];
    place in AUXRAM_MEM { readwrite section AUXRAM };
    
    // C code
    #define AUXMEM _Pragma("location=\"AUXRAM\"")
    AUXMEM static uint8_t tx_buf[128];
    AUXMEM static uint8_t tx_buf_enc[128];
    // ect