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/TM4C123FH6PM: Const Arrays are Allocated Sometimes in RAM

Part Number: TM4C123FH6PM

Tool/software: TI C/C++ Compiler

Hello!

I have the following code in my project:

const uint8_t A3InitSub[] =
{
 SQ_CFLOAT(5000 * 4),
 SQ_CHW(2, 2),                  // Freq
 SQ_CFLOAT(2000 * 4),
 SQ_CHW(2, 3),                  // Start freq
 SQ_CLEAR,
 SQ_CONST_B(0, 0, 4, 0x01),     // Mask
 SQ_CONST_B(0, 4, 4, 0x00),     // Sens
 SQ_CMD(2, 1),                  // Stop mode
 SQ_CLEAR,
 SQ_CONST_D(0, 100),            // Steps forward
 SQ_CMD(2, 0),                  // Run
 SQ_WAIT(2),
 SQ_CLEAR,
 SQ_CONST_B(0, 0, 4, 0x01),     // Mask
 SQ_CONST_B(0, 4, 4, 0x01),     // Sens
 SQ_CMD(2, 1),                  // Stop mode
 SQ_CLEAR,
 SQ_CONST_D(0, -10000),         // Steps backward
 SQ_CMD(2, 0),                  // Run
 SQ_WAIT(2),
 SQ_CLEAR,
 SQ_CMD(2, 3),                  // Reset position
 SQ_END
};

const uint8_t A3InitSequence[] =
{
 SQ_SUB(AS2_INIT),              // AS2 Init
 SQ_SUB(AS3_INIT0),             // AS3 Init
 SQ_END
};

const uint8_t A3GoSequence[] =
{
 SQ_SUB(AS2_INIT),              // AS3 Init
 SQ_SUB(AS3_INIT0),             // AS3 Init
 SQ_CLEAR,
 SQ_CONST_B(6, 0, 0, 0x01),     // Hold forever
 SQ_CONST_D(2, 1),              // Enable hold
 SQ_CMD(2, 1),                  // Stop mode
 SQ_PARAM_D(0, 2),              // Target position
 SQ_CMD(2, 0),                  // Run
 SQ_WAIT(2),
 SQ_SUB(AS2_GO),                // Go on AS2
 SQ_END
};

const uint8_t A3UpSequence[] =
{
 SQ_SUB(AS2_UP),                // Up on AS2
 SQ_CLEAR,
 SQ_CMD(2, 1),                  // Stop mode
 SQ_CMD(2, 2),                  // Stop
 SQ_END
};

All the initialization values are constant and compile time. But when I stop in debugger I see the following information:

A3InitSub : 0x20006D8D

A3InitSequence : 0x0002C65D

A3GoSequence: 0x0002C55A

A3UpSequence: 0x0002CDA2

So, first array is allocated in RAM, others in FLASH.

Why this could happend?

  • When things work normally, the compiler puts the array A3InitSub in the section .const, and the linker command file allocates the section .const to a range of flash memory.  This normal flow must have been disrupted somehow.   For the source file which defines the array A3InitSub, please follow the directions in the article How to Submit a Compiler Test Case.  In addition, please attach the linker command file.  So the forum will accept it, add the file extension .txt.

    Thanks and regards,

    -George

  • Compiler version is 19.6.0.STS

    Build command is:

    "C:\\ti\\ccs930\\ccs\\utils\\bin\\gmake" -k -j 4 AS3VApp.obj -O

    Building file: "../AS3VApp.cpp"
    Invoking: ARM Compiler
    "C:/ti/ccs930/ccs/tools/compiler/ti-cgt-arm_19.6.0.STS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path="G:/Git/JC2_ASM/JC2_HPLC_ASM" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/app" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/drv" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/graphics" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/gui" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/kernel" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/proto" --include_path="E:/workspace_JC2/JC2/JC2_Kernel/include/resource" --include_path="E:/workspace_JC2/HPLC/JC2_HPLC/include/app" --include_path="E:/workspace_JC2/HPLC/JC2_HPLC/include/resource" --include_path="C:/ti/TivaWare_C_Series-2.1.4.178" --include_path="C:/ti/ccs930/ccs/tools/compiler/ti-cgt-arm_19.6.0.STS/include" --define=ccs="ccs" --define=PART_TM4C123FH6PM -g --gcc --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --preproc_with_compile --preproc_dependency="AS3VApp.d_raw" "../AS3VApp.cpp"
    Finished building: "../AS3VApp.cpp"

    Linker command file is:

    /******************************************************************************
     *
     * Default Linker Command file for the Texas Instruments TM4C123FH6PM
     *
     * This is derived from revision 15071 of the TivaWare Library.
     *
     *****************************************************************************/
    
    --retain=g_pfnVectors
    
    MEMORY
    {
        FLASH (RX) : origin = 0x00000000, length = 0x00030000
        HIS (R)    : origin = 0x00030000, length = 0x00005000
        MTD (R)    : origin = 0x00035000, length = 0x0000A000
        CFG (R)    : origin = 0x0003F000, length = 0x00001000
        SRAM (RWX) : origin = 0x20000000, length = 0x00008000
    }
    
    /* The following command line options are set as part of the CCS project.    */
    /* If you are building using the command line, or for some reason want to    */
    /* define them here, you can uncomment and modify these lines as needed.     */
    /* If you are using CCS for building, it is probably better to make any such */
    /* modifications in your CCS project and leave this file alone.              */
    /*                                                                           */
    /* --heap_size=0                                                             */
    /* --stack_size=256                                                          */
    /* --library=rtsv7M4_T_le_eabi.lib                                           */
    
    /* Section allocation in memory */
    
    SECTIONS
    {
        .intvecs:   > 0x00000000
        .text   :   > FLASH
        .const  :   > FLASH
        .cinit  :   > FLASH
        .pinit  :   > FLASH
        .init_array : > FLASH
        .ARM.exidx	> FLASH
        .ARM.extab	> FLASH
        .cfg    :   > CFG, type = NOINIT
    	.mtd    :   > MTD, type = NOINIT
    	.his    :   > HIS, type = NOINIT
    
        .vtable :   > 0x20000000
        .data   :   > SRAM
        .bss    :   > SRAM
        .sysmem :   > SRAM
        .stack  :   > SRAM
    }
    
    __STACK_TOP = __stack + 512;
    

  • Preprocessed C++ file is attached.

    AS3VApp.pp.txt

  • Cannot attach .pp file, forum reports an error. Here is Google Disc link:

    drive.google.com/open

  • Thank you for submitting the linker command file.  It allocates the .const section to the FLASH memory range.  This means the problem reduces to determining why the compiler puts the array A3InitSub in .data instead.  

    The array A3InitSub is the only one which contains instances of this macro ...

    Oleg Kobrin said:
    SQ_CFLOAT(5000 * 4)

    In the preprocessor file, the same line becomes ...

       0x0A,
       ((uint8_t*)(&(float){5000 * 4}))[0],
       ((uint8_t*)(&(float){5000 * 4}))[1],
       ((uint8_t*)(&(float){5000 * 4}))[2],
       ((uint8_t*)(&(float){5000 * 4}))[3],
    

    This odd initialization of a floating point value into an array of uint8_t is not done at compile time, but by the startup code which runs just before main starts.  That being the case, it cannot be in the section .const (i.e. FLASH), but must in the section .data (i.e. RAM).  We failed to find a way to get this initialization to go straight into read-only memory at compile time.  We tried several techniques, and a few different compilers.  Even on platforms other than ARM.  Unfortunately, we never found a way to do it.  I think it is safe to say no such method exists.

    Regarding the problem you had attaching the preprocessed source code ... The forum only accepts a few different files as attachments.  Text files, with the file extension .txt, are accepted.  That's why, for text files, no matter what the original file extension may be (.pp, .cmd, and so on), it is necessary to add the file extension .txt before attaching the file.

    Thanks and regards,

    -George

  • Really? 

    It's so weird!

    There is no way to convert float value to bytes at compile time?

  • Oleg Kobrin said:
    There is no way to convert float value to bytes at compile time?

    I got help from the compiler development team.  We tried all sorts of tricks.  Nothing worked.  I'm convinced no method exists to do it.

    If you really want to do it ... You could consider defining that one table in hand-coded assembly.  

    Thanks and regards,

    -George