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/TM4C1233D5PM: Run time RAM allocation

Part Number: TM4C1233D5PM
Other Parts Discussed in Thread: TM4C1233H6PM

Tool/software: TI C/C++ Compiler

Hi all

We use the Tiva series MCU in our product.

Originally, we used the TM4C1233D5PM and changed at some point to TM4C1233H6PM - that is, we have both MCUs in field.

The differences between the two are:

TM4C1233H6PM, Flash: 256, RAM: 32
TM4C1233D5PM, Flash: 64, RAM: 24

We frequently push firmware updates to the devices in the field. Until now, we have pushed firmware compiled for TM4C1233D5PM to both the TM4C1233D5PM and the TM4C1233H6PM based products - and this has worked well.

Now, we want to make use of the additional RAM in the TM4C1233H6PM based products in field. We would like to be able to use the same firmware file for both devices.

The firmware can run-time determine if it runs on the TM4C1233D5PM or the TM4C1233H6PM.

Specifically, we want to allocate more FreeRTOS heap when the firmware runs on the TM4C1233H6PM.

Do any of you have suggestions on how we can obtain this in the most elegant way?

Thanks

Best regards

Christian

  • The firmware can read the SSIZE register to determine the amount of static RAM on the part.

  • Hi

    Thanks for the reference to the RAM size register!

    I am not sure what the best way is to setup the linker file. I imagine that one solution is to setup an additional RAM region, which the linker cannot freely use for variables etc. Run-time, I would then be able to determine based on the SSIZE register if the additional RAM region should be added to the heap or not. Does this seem reasonable?

    Thanks

    Br

    Christian

  • Christian Steiniche said:
    Do any of you have suggestions on how we can obtain this in the most elegant way?

    Might 'elegance' - as employed here - be subject to (some)  'Variability of Definition?'       (perhaps explains why it received tangential address...)

    Elegance may include the key elements:  'Performance, Speed, Robustness, Added Capability, & Simplicity.'      Rarely though - do 'all' appear (or operate optimally) - when combined.     (in fact - our firm has noted that optimizing one - will often - degrade several others!)      Thus - any request for L'Élégance - should identify those elements of  highest perceived  value.

    May we note too - that, "Universal Heap increases" may lead - under certain conditions - to unwanted/unanticipated consequences.      Altering 'heap-size' - dynamically  - 'as/if/when' needed (and then returning 'heap size' to 'normal') - may 'best' meet your objective.     And - does this not 'MOVE the job' of  'MCU Identification' - from 'Linker to your executable code' - which (may) add other 'safeties & advantages!'

    As (both) MIT & Amazon have licensed 'FreeRTOS' - a certain degree of  'L'Élégance' - has (already) attached to your project.      (single vendor offerings - rarely (if ever) - can rise to such standard...)

  • Hi

    Thanks for the reply.

    I am not really sure how to respond to this...

    I simply need some advice on how to handle different amounts of on chip RAM run-time. I imagine that this a very standard situation, which likely have one common solution. I dont agree that performance / speed etc. can be traded in this specific situation.

    Br
    Christian
  • Christian Steiniche said:
    I dont agree that performance / speed etc. can be traded in this specific situation.

    Your meaning of 'elegant' still remains 'cloudy.'

    No claim was made that 'Performance / Speed' ... 'Can be traded.'     (that's another word (traded) - requiring further definition...)

    It's possible that we may, 'Agree to Disagree' - that's always your right...    (I have tried to 'actually address' your request - which was judged 'vague.')

  • Hi Christian,

    I have to admit that I have not used FreeRTOS with the TivaC devices (we provide TIRTOS), but I have used it on the TI Hercules safety devices. I suspect that it should be similar. My comments apply to using the TI Compiler and linker.

    It looks like the heap is created as a static variable in the file os_heap.c

    #pragma DATA_SECTION(ucHeap, ".kernelHEAP")
    
    
    /* Allocate the memory for the heap. */
    static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
    
    

    Notice that the #pragma puts this variable in the linker section ".kernelHEAP". That section is allocated to RAM in the link command file without being bound to any specific address:

    SECTIONS
    {
        .intvecs : {} > VECTORS
        /* FreeRTOS Kernel in protected region of Flash */
        .kernelTEXT   : {} > KERNEL
        .cinit        : {} > KERNEL
        .pinit        : {} > KERNEL
        /* Rest of code to user mode flash region */
        .text         : {} > FLASH0 
        .const        : {} > FLASH0 
        /* FreeRTOS Kernel data in protected region of RAM */
        .kernelBSS    : {} > KRAM
        .kernelHEAP   : {} > RAM
        .bss          : {} > RAM
        .data         : {} > RAM    
        .sysmem       : {} > RAM
    }
    

    Let's say that for example you want to allocate 8K bytes of RAM to the heap for the 24K RAM device, and 16KB of RAM to the heap for the 32KB device. I would leave the configuration file "FreeRTOSConfig.h" allocating 8KB, and leave the link command file defining a 24KB RAM. I would modify the link command file to specifically place the ".kernelHEAP" section in the last 8KB of RAM.

        .kernelHEAP   : {} > 0x20004000
    

    Then in the function prvHeapInit(), initialize the variable xTotalHeapSize to be 8KB or 16KB depending on the value read from the SSIZE register.

    Again, I took this information from a TI Hercules device. It may not match the TM4C implementation of FreeRTOS. My hope is that this helps more than it confuses.

  • Hi Bob

    Thanks a lot for the detailed information - just what I was looking for!

    With FreeRTOS (and heap5.c) it is even possible to add more heap from a different location in RAM (does not need to be adjacent). 

    We will use your example and work from there.

    Thanks a lot!

    Br 

    Christian