warning #17003-D: relocation overflowed. 18-bit relocated address is too large to encode in 16-bit signed PC-Relative field

Brendan Simon said:

Do I need to use 20 bit instructions ??  e.g. mov.a ??

Probably.  Tell me what data memory model you are using (small, restricted, large), and I'll give a better answer.

I made the changes I suggested (uint32 and mov.a) and now everything compiles ok and the .out was built (yay !!)

The IAR project uses the medium data model, which I guess maps to the restricted data model in CCS ??  I built with data model set to empty which I believe defaults to the restricted data model.

As to why IAR does not complain about the MOV instruction, my guess is that IAR is clever about the data size or defaults to the largest size for the processor, where as CCS defaults to the word size (MOV.W).  Does that make sense ??

Even if it that's true it didn't pick up that the SP was being stored into a 16 bit variable, which sounds to me could produce bugs (unless the memory map was carefully crafted to fit the code in the first flash segment -- which I don't think is possible given the code size).

A correction/clarification -- The larger memory models can used 20-bit addressing for data and code stored in FLASH.  Since the code I was porting was manipulating the Stack Pointer, then only 16-bits is required as the RAM always fits within the 16-bit address space.  So my guess is that IAR code was smart enough to determine that the SP was being accesses and only required a 16-bit word move (MOV.W), where as the TI compiler took the generic approach that all registers need to be 20-bits, thus the warning.

When you write "MOV" with no suffix, the TI assembler gives you the 16-bit move.  When you write "MOVA" or "MOV.A", you get the 20-bit move.  The assembler has no choice; it must encode the instruction you asked for.  I'd be shocked if the IAR assembler handled this any differently, so I don't think your guess about the IAR assembler having some sort of "smarts" in this case is correct.  Look at the disassembly of the IAR-generated object file to see for yourself.

The instruction "mov tempStore1, SP", being a 16-bit move, treats the label tempStore1 as a 16-bit label (as it must).  Whether or not you get a relocation overflow warning depends entirely on where tempStore1 is located in memory.  This is somewhat related to which memory model you are using, but even in large model, it is possible that this label lands in the lower 16 bits of memory, just by chance. Thus, the memory model is not the whole story.  You will get a relocation overflow warning for this instruction exactly when tempStore1 is not in the lower 16 bits of memory.

Even if it just so happens that you get no warning from IAR, it may be the case that that instruction is not safe even for your IAR project.  I can't tell, because I know very litte about how IAR memory models work.  I do know that the IAR memory models don't quite correspond exactly to the TI memory models, but I don't know the details.

The safest thing to do would be to use "MOV.A" in all circumstances; it will work for every memory model for both TI and IAR.

We can go further and determine whether "MOV.A" is actually necessary, or whether there's a problem with your linker map file, but this requires that you tell me what data memory model you're using in the TI project.

ok, that all makes sense re the assembler.  And IAR possibly isn't smart and possibly does not issue a warning (which could be bad).

I'm using the restricted model.  I've located all data sections in low memory (> FLASH) and all code goes into high memory first (>> FLASH2 | FLASH).

Since the stack pointer in being saved in RAM, then a 16-bit relocation should be fine (because RAM is always in low memory), correct ??  I guess the assembler doesn't have enough information to determine this.  If not, and I get a warning, then I would have to ignore this warning as I generally like to treat all warnings as errors.

Brendan Simon said:

line 230: warning #17003-D: relocation from function "TASK_Switch" to symbol "tempStore1" overflowed; the 18-bit relocated address 0xecfe4 is too large to encode in the 16-bit signed PC-Relative field (type = 'R_MSP430_PCR16_MSPX' (13), file = "./src/OS/RoundRobin.obj", offset = 0x0000001c, section = ".text:_Z17TASK_Switchv")

Look carefully at the "relocated address", which is 0xecfe4.  This warning is claiming that the label tempStore1 is located at address 0xecfe4, which is definitely not in the lower 16 bits of memory.  Look at the linker map file (generated with the --map_file option); what is the actual address of tempStore1?

Also, what is the address of section .text:_Z17TASK_Switchv?