Linker file fill value causing strange behavior and incorrect readout of ram size in console. Code Composer Essentials

More information.  The crashing appears to be related to the .cinit section.  It appears the cinit section is going one init value too far and loading garbage.  Example memory block below.

0006    02F0    F104    F104    F104    0002   
030E    001C    0002    0324    0000    0002   
02DC    0000    0001    0298    4600    0001   
027A    4600    0001    0237    4600    0001   
0299    4600    4646    0000    0000    4646

The italics area appears to be the issue.  The length sent to memcopy gets loaded as 0x4646 (which is ironically my fill value).  The initial location is 0 which is also bad.  If I look in the map file I can see some irregularity as well.  See below.

.cinit     0    0000f17e    0000003a    
                  0000f17e    0000000a     **my_stuff**
                  0000f188    00000006     **my_stuff**
                  0000f18e    00000006     **my_stuff**
                  0000f194    00000006     **my_stuff**
                  0000f19a    00000005     **my_stuff**
                  0000f19f    00000001     --HOLE-- [fill = 4646]
                  0000f1a0    00000005     **my_stuff**
                  0000f1a5    00000001     --HOLE-- [fill = 4646]
                  0000f1a6    00000005     **my_stuff**
                  0000f1ab    00000001     --HOLE-- [fill = 4646]
                  0000f1ac    00000005    **my_stuff**
                  0000f1b1    00000003     --HOLE-- [fill = 4646]
                  0000f1b4    00000004     (.pad.cinit) [fill = 0]

I now have to think of a workaround unless someone can think of one first.  Getting rid of the fill is not a great solution because I need that to create a checksum value using srec_cat (unless someone has a better idea).  See bottom for more on srec_cat solution.

If it is doing what it appears to be doing - it could cause some dangerous bugs.

Mark

srec_cat solution for jamming a checksum into the hex file.

"srec_cat my.hex -intel --fill 0x55 0xC000 0xFFFF -Exclude 0xFFDC 0xFFE0 --l-e-checksum-neg 0xFFDC 4 2 -o my_result.hex -intel"

The fill in srec is a just in case fill.  All areas should be filled by the linker.
This does require the compiler to convert the .out to .hex.  Which is fairly trivial.  It also requires us to skip the checksum address.

just_working said:

For example:  If I put the fill definition  "    FLASH                   : origin = 0xC000, length = 0x3FDC, fill = 0x4646" in the linker file I get a report from the console at download of: "MSP430: Program loaded. Code Size - Text: 196 bytes  Data: 16168 bytes".  If I remove the fill definition I get 2bytes. 

This difference is because when you have the fill value, a data section called $fill000 is created to fill the unused FLash with your fill value. If you create a link map file and take a look at the map file, you can add up the sizes of the $fill000 and other data section and check that it matches up with what is displayed on the console.

When there is no fill in your linker command file, this additional large data section is not created.

Interesting that the fill qualifies as data.  The explanation helps. 

Any idea on the second part?  The cinit getting "messed up"?  Or at least appearing to be messed up.

Mark

I have uploaded a project called TestProj1.zip which contains the lockup and bad cinit behavior.

Working on it a bit more it has to do with the variable size last initialized in the cinit section.  If the variable is 8bit the problem occurs.  If it is 16bit (ie even) the problem goes away.  Any suggested workarounds until it is fixed?

Mark

It appears that the problem can be solved by using a flash fill value of 0x0000.  This fools the autoinit (cinit section) into being properly terminated.  I would like some verification if this is a  compiler (or linker) issue or if it is a code problem.