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.

CCS/TMS470MF06607: Is there a way to append fixed data at the end of the generated files(.hex/.out)

Part Number: TMS470MF06607

Tool/software: Code Composer Studio

I want to append four bytes of data (0x01 0x02 0x03 0x04) at the end of generated file. 

The memory location is not fixed. Memory location to be used will be the next location of the generated file end location.

Please let me know if this is possible using CCS version  5.2.0.00069 

  • There is no way to do it in the hex utility.  It only converts what is in the input executable file.  

    I think there is way to do it in the linker command file, so that those 4 bytes are there for the hex converter to output.  I've never done it before, but I'm confident I can figure it out.  I suspect it will be a bit ugly.  Are you interested?

    Thanks and regards,

    -George

  • Thank you for the Quick Reply.

    Yes I would be interested to know if there is any way via linker file.

  • I found a method to do it.  But it is quite ugly.  You may decide it is not worth it.

    Please start by reviewing the first part of the article Linker Command File Primer.  Get a clear understanding of the terms input section, output section, and memory range.

    In your current linker command file, identify the memory range with the highest address that is allocated an initialized output section.  Here in this post I name that memory range HIMR (highest initialized memory range).  Put all of the initialized output sections allocated to HIMR in a GROUP.  Then add one additional memory range that is filled with the desired value.  It will look something like this ...

        GROUP
        {
           .text
           .const
           .pinit
           .cinit
           last4 
           {
              . += 4;
           } fill = 0x01020304
        } > HIMR
    

    The order of the output sections before last4 does not matter.  The list of initialized sections may be different in your case.  Only name the initialized output sections that, in the current linker command file, are allocated to HIMR.  Line 7 creates an output section named last4.  It contains no input sections.  Line 9 creates a 4-byte hole in the output section.  Line 10 fills that hole with the value shown.

    Because the .cinit section is part of the GROUP, you have to add the linker option --cinit_compression=off.  By default the .cinit section is compressed.  This option disables the compression.  Why must compression be disabled?  The answer is unfortunately long.  Not compressing .cinit avoids the problem discussed in this forum thread.   This means the .cinit section takes up more memory than before.  This may, or may not, be a problem for your project.

    Thanks and regards,

    -George

  • Thanks a lot for your idea!!

    I tried it and it seems to work. I just need to analyze for any Side effects.
    I compared the files generated before and after the change. In these, .hex and .map files look good. But there seems to be quite some changes in .out file and I am not sure on how to validate .out file.


    I used the following piece of code. If you think there is any risk associated, Please let me know so I can have a background check for this.
    SECTIONS
    {
    .intvecs : {} > VECTORS
    .vim_table : {} > VIM_TABLE
    .text : palign(1){} > FLASH0
    .bss : {} > RAM
    .data : {} > RAM
    .sysmem : {} > RAM

    .stack : /* SOFTWARE SYSTEM STACK */
    { /* initial stack pointer values */
    . += 0x00000400; _Stack_Table_Pointer = .;
    . += 0x00000400; _Stack_Handler_Pointer = .;
    } > STACKS

    GROUP
    {
    .const
    .cinit
    .pinit
    last4
    {
    . += 4;

    } fill = 0xABCDEF00
    } > FLASH0 | FLASH1
    }
  • I have one small suggestion to consider.  Change the allocation of the GROUP to ...

    } >> FLASH0 | FLASH1   /* Change > to >> */

    To understand the difference, please see this part of the Linker Command File Primer article.

    Thanks and regards,

    -George

  • Thank you for the suggestion.

    But from the base project, it was intended that the .text/.const/.cinit/.pinit should not be split.

    Please find the below snapshot.

    ".text : {} > FLASH0

    .const : {} > FLASH0 | FLASH1

    .cinit : {} > FLASH0 | FLASH1

    .pinit : {} > FLASH0 | FLASH1"

     

    I was not able to give this inside the group.

    >> means split hence I did not use it as I was worried if half of .const was in FLASH0 and other half in FLASH1. This is against the intended behavior.

    Is there a way we can assign the memory individually inside GROUP?

  • Sorry, but I should not have told you to split the GROUP allocation.  Your GROUP includes the output section .cinit, which cannot be split.  

    Kavya Ramachandra said:
    Is there a way we can assign the memory individually inside GROUP?

    No.

    Thanks and regards,

    -George