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 4.0.1.01001 - filling unused memory with a specific value

Other Parts Discussed in Thread: MSP430F2274

Hi,

I'm currently developing with MSP430F2274 and my application (output) size is around 16kB. I want to fill the unused memory with a 0x0a0a polynom and now I'm asking myself how to do this.

Under Project properties -->  Linker Options --> Runtime environment I have specified the 'Default Fill Value' (here's also a type in the explenation: full instead of fill) as 0x0a0a but my output is still 16kB instead of 32kB as expected. So, can somebody pls tell me what I'm doing wrong?

Rgds
aBUGSworstnightmare

  • It is good that you are polite about our typos. Is this typo in the Runtime Environment dialog box, or if not then specifically where is it?

    There are a confusingly large number of ways to fill memory, and they do different things. Please find the Assembly Language Tools User's Guide for the version of the CodeGen tools you are using. The version I looked at is for MSP430 ALT v3.1, but the fill options for the linker are probably the same for all of them.

    I strongly recommend that you pull up the pdf of this document and do a search on "fill". There are a lot of hits, but the ones near the top show you the places in the Table of Contents where the different commands are located. From what I have seen of your other postings, you are probably like me and will find it interesting reading even if you just skim through some of the hits.

    The one that I discovered doing this search for you is a very cool feature. It may have been around for MSP430 for a long time, but I usually work with another processor family and had never seen it before.

    This one, that may do what you want, is used within the MEMORY directive where you specify the physical memory components and their origin and size parameters. You can add f=0x0a0a or fill=0x0a0a and it looks like this will do what you want. I have not tried it, so I cannot promise it will do any more than the other fill options. But this one is definitely different in its description, and even the note on it implies strongly that it will do exactly what you want it to do.

    Let us know if it works, and Mark this An Answer if so. If not, I will look again for an answer..

  • Hi Randy,

    thanks for answering! I will post a screenshot regarding the position of the typo later this evening.

    I'm a little bit confused about the difference of --fill_value and the -f option!

    When using the MEMORY-directive approach it look like:
    MEMORY
    {
    name 1 [(attr)] : origin = constant, length = constant, fill = constant
    .
    }

    with constant of type unsigned int (0x0a0a in my example).

    This is done by editing the .cmd-file (as you pointed out above).


    I expected that the --fill_value constant defined in the linker context would produce the same result. So, why is there a difference??
    Hope somebody can clarify this.
    Rgds
    aBUGSworstnightmare

  • aBUGSworstnightmare said:

    MEMORY
    {
    name 1 [(attr)] : origin = constant, length = constant, fill = constant
    .
    }

    Please let me know if this does what you wanted. It may be that you must use both the MEMORY-directive 'fill' as well as the --fill_value to fully accomplish your goal, but specifically to your stated goal, the MEMORY-directive syntax should be your solution.

    aBUGSworstnightmare said:

    I'm a little bit confused about the difference of --fill_value and the -f option!

    I expected that the --fill_value constant defined in the linker context would produce the same result. So, why is there a difference??

    I will not be able to explain the differences any better than the explanations in the MSP430 Assembly Language Tools User's Guide slau131 (rev c). It is very understandable that there is confusion over this because of three or more different uses of the term 'fill' or 'fill_value'.

    Depending on where you use the command, it will have a slightly or greatly different meaning. You can use different fill commands or options on the command-line when the linker is called, or within the MEMORY-directive as we have discussed above, or within the SECTIONS-directive. Each does something different, and I refer you to the descriptions in slau131c.pdf for the detailed descriptions.

  • Hi Randy,

    MEMORY
    {
    FLASH : origin = 0xF800, length = 0x07E0, f = 0x0a0b
    ..
    }

    --> I've tested with an F2012; The line above is the approach I had and this gives the correct result (which I was expecting): everything were is NO code is filled with 0x0a0a.

    Pls find a sreenshot with the typo below. I'm now asking myself why this will not give the same result (-f is stated here!).

    Rgds
    aBUGSworstnightmare

  • My understanding of the difference between the 2 fill options from what is described in the Users Guide is the following:

    The fill specifier within the MEMORY directive as you have used above will fill areas of the memory range that are not allocated to a section. In other words, you have a FLASH region of length 0x07E0, after all sections allocated to FLASH in your linker command file are allocated, the remaining memory range will be filled with this fill value.

    The default fill value (--fill_value linker option) fills the holes formed within output sections. Output sections are a group of input sections, for example, the .text output section in your executable (.out file) is a combination of multiple .text input sections that come from all the different source files. If there are holes within the output section during the combining of input sections (due to alignment or other reasons), those holes are filled with this fill value. If no value is specified, the linker default it to zero.

  • I will submit a bug report for the typo in CCS v4.

  • Hi Aarti,

    thanks for your answer! Maybe the -f option stated there caused the confusion.

    Rgds
    aBUGSworstnightmare