Error #17003-D

This is the output from the Console in CCS:

"C:/Dropbox/CCS_Workspace/Bluetopia/Source/MSP430_Experimentor/Samples/SPPDemo/SPPDemo.c", line 3120: warning #17003-D:
relocation from function "GetQueueParams" to symbol "$C$SL186" overflowed;
the 17-bit relocated address 0x1fa88 is too large to encode in the 16-bit
field (type = 'R_MSP_REL16' (161), file = "./SPPDemo.obj", offset =
0x00000040, section = ".text:GetQueueParams")

Hopefully that provides some more information on resolving this issue...

Could you check if the code memory model and data memory model options in your project are set the same as it is in the example project? You can find these options under Project Properties->Build->Compiler->Processor Options.

Yes, they are the same. 

Silicon Version: mspx

Application binary interface: coffabi

Specify the code memory model: large

Specify the data memory model: small

Indicates what data must be near: {empty}

Seth Berggren said:

"warning #17003-D: relocation to symbol "_main" overflowed; the 18-bit relocated address 0x23a21 is too large to encode in the 16-bit field (type = 'R_RELWORD' (16), file = "x.obj", offset = 0x00000000, section = ".data")"

This suggests that you are assigning the value of the function pointer "main" to a data object.   Is this the case?  If so, could you show us that line of code?

How would I check this?

The example that I showed above is one of 400 of the same error. They occur in HCITRANS.c   HAL.c   BTPSVEND.c   BTPSKRNL.c and SPPDemo.c

Seth Berggren said:

warning #17003-D:
relocation from function "GetQueueParams" to symbol "$C$SL186" overflowed;
the 17-bit relocated address 0x1fa88 is too large to encode in the 16-bit
field (type = 'R_MSP_REL16' (161), file = "./SPPDemo.obj", offset =
0x00000040, section = ".text:GetQueueParams")

My guess is that you have a gigantic function (or one huge file) with many, many string constants in it, perhaps from assert statements.  Is this the case? 

Note that this is a linker error which seems to indicate that your whole program has just too many strings to fit small data model.  I'd have to see more information, such as the linker map file (linker option --map_file)

They may all be error number 17003, but you need to look at the symbol in the error message, which distinguishes them.  For example:

"warning #17003-D: relocation to symbol "_main" overflowed; the 18-bit relocated address 0x23a21 is too large to encode in the 16-bit field (type = 'R_RELWORD' (16), file = "x.obj", offset = 0x00000000, section = ".data")"

This means that there is a relocation in file x.obj, in section .data to the symbol _main.  That means that you have a data object which contains an expression involving the symbol _main, which usually means a pointer.  However, in large data model, a pointer will not fit in R_RELWORD, so there's something funky going on.  Notice that the offset is 0; this means that we are looking at the very first data object in that .data section.  If you use the standalone disassembler (dis430), you will be able to see which variable that is, but you could probably just look in x.c

That message is not from my code, it is just an example of a Typical Message that I copied from CCS "Advice" Tab for error #17003-D

My second post contains an actual example of what the Console output looks like with the details of the error message.

Some of those files are pretty big. HAL.c is 1000 lines and SPPDemo.c is 4500 lines.

Attached is the caBT.map file for this project

8765.caBT.txt

Try "restricted" data model, which is probably necessary for this project.  I'm going to have to consult someone on this.

Setting restricted gave me a whole slew of other errors (mostly conversion errors and interrupt vector pointer errors). I did notice one other error that occurs at the end of compilation that may be important:

warning #10247-D: creating output section ".patch" without a SECTIONS
specification

I'm not familiar with that section.  For most sections you can ignore that warning, but I don't know if  that's the case with .patch

Can you show me one of these "conversion errors"?

This error says Restricted setting is not compatible:

error #16019-D: file
"C:/Dropbox/CCS_Workspace/Bluetopia/Source/MSP430_Experimentor/Bluetopia/lib
/CCS/libBluetopia.a<BSC.obj>" specifies small data memory model, which is
not compatible with restricted large data memory model specified in a
previous file or on the command line

Other errors (just warnings):

1)  "C:/Dropbox/CCS_Workspace/Bluetopia/Source/MSP430_Experimentor/Bluetopia/hcitrans/HCITRANS.c", line 204: warning #770-D: conversion from pointer to smaller integer

2)  "../lnk_msp430f5438a.cmd", line 191: warning #10374-D: Interrupt vector
"TIMER0_B0" does not have an interrupt handler routine.

If you switch to restricted data model, you'll need to use a version of Bluetopia compiled for restricted data model, if such a thing is available.

From the "conversion from pointer to smaller integer" error, I suspect Bluetopia is not set up to support anything but small data model.  Bluetopia is not a product of the compiler team, so this is just guessing.

I still need that consult regarding small data model .const, which I won't be able to get to day, but I think if you change your linker command file so that .text is not allowed to go into FLASH, it will instead go into FLASH2, and then there will be enough room for .const in FLASH, which will make your program link in small model. 

You may need to post in the MSP430 forum to get advice for working with Bluetopia; there may be special requirements for the linker command file.

OK, I just can't imagine why it won't work when I have the exact same settings as the other project. I just want to have a separate project where I can modify the code and get going on this...

Thanks for the help, I will try your suggestion and also will try posting in the other forums.

Regards,

Seth Berggren

I found this in the link file:

SECTIONS
{
.bss : {} > RAM /* GLOBAL & STATIC VARS */
.data : {} > RAM /* GLOBAL & STATIC VARS */
.sysmem : {} > RAM /* DYNAMIC MEMORY ALLOCATION AREA */
.stack : {} > RAM (HIGH) /* SOFTWARE SYSTEM STACK */

.text : {}>> FLASH | FLASH2 /* CODE */
.text:_isr : {} > FLASH /* ISR CODE SPACE */
.cinit : {} > FLASH /* INITIALIZATION TABLES */

If you look at the .text section it has a double ">>" instead of just the single ">"

I fixed that and got rid of all of those errors that we were running into before. Now it still has 20 interrupt vector errors:

"../lnk_msp430f5438a.cmd", line 187: warning #10374-D: Interrupt vector
"USCI_B0" does not have an interrupt handler routine.

I suspect something with the link file again...

In general you want the double >> because .text may be split, but for your program, you want it to go into FLASH2 instead of FLASH; a better fix would have been to reverse the order of the two in that line.

You might not need all of those interrupt handlers if those interrupts don't occur in the program; I can't even begin to tell you if you do or not.   Ask in the MSP430 forum.

The linker command files for MSP430 are pre-constructed, it's rare to need to mess with them.  I'm surprised this didn't just work from the start.

fixed it.

I just copied the link file from the Demo Project and replaced the pre-constructed one that was provided from my new project.

It all works fine now. Thanks for your help you pointed me to the link file and problem is now solved.

I have one more question...

How can I create a .hex file from Code Composer Studio instead of the .out format?

I need something in the following format for a Panasonic Engineer who is evaluating my device:

@5C00
31 40 00 5C B1 13 AC 72 0C 93 12 24 8C 00 C0 1D  
3E 40 7F 2E 3F 40 00 00 B1 13 E8 66 8C 00 00 1C  
8D 02 80 0E 3E 40 C0 01 3F 40 00 00 B1 13 F0 73  
B1 13 3A 62 B1 13 08 74 3F 14 B1 13 78 1B B1 13  
9A 6F 40 18 D2 93 42 1D 0F 20 8E 00 E8 3B 3F 0E  
66 00 DF B3 00 00 08 2C 82 93 0A 07 05 20 3F 0E  
1C 00 DF CE 18 00 00 00 3C 16 00 13 3F 14 1E 42  
1E 02 40 18 C2 4E 99 40 32 D2 40 18 82 43 62 3C  
40 18 82 43 64 3C 40 18 1F 42 22 3D 8E 00 9B 40  
40 18 C2 93 98 40 12 20 40 18 D2 43 98 40 A2 D3  
AA 04 CE 93 00 00 0A 20 0D 4F 40 18 DD 42 99 40  
76 4B 1F 53 3F 90 28 00 01 20 0F 43 40 18 82 4F  
22 3D DE 93 00 00 15 20 CE 43 00 00 40 18 D2 D2  
9A 40 02 02 B1 13 D8 73 B2 D0 40 01 A0 04 B2 C0  
00 40 A0 04 B1 13 78 1B B1 13 C0 4B B1 C0 D0 00  
10 00 3C 16 00 13 1F 14 8E 00 E8 3B 3F 0E 1C 00  
@5D00
DF DE 18 00 00 00 40 18 92 42 20 07 38 2A 40 18  
92 42 22 07 3A 2A 40 18 92 42 24 07 3C 2A 40 18  
92 42 26 07 3E 2A 82 43 0A 07 B2 F0 DC FF 00 07  
40 18 D2 93 42 1D 0D 20 3F 0E 66 00 DF B3 00 00  
08 2C 82 93 0A 07 05 20 3F 0E 1C 00 DF CE 18 00  
00 00 1E 16 00 13 0E 14 40 18 5E 42 A4 41 40 18  
DE 42 0C 06 A5 40 40 18 D2 53 A4 41 B1 C0 D0 00  
04 00 0E 16 00 13 5F 14 21 83 8A 00 E8 3B 3E 0A  
1C 00 DE DA 18 00 00 00 40 18 82 43 62 3C 40 18  
82 43 64 3C 1F 4A 52 00 2F 4F 6F B3 19 28 8F 00  
94 29 1D 43 2D 5F 40 18 1D 92 96 29 3B 24 1E 4A  
5C 00 E1 4E 00 00 6C 41 2E 4F 40 18 CE 4C 69 3D  
9F 53 00 00 3D 90 00 02 2D 20 8F 43 00 00 2A 3C  
6F B2 28 28 1E 43 40 18 1E 52 5E 3C 3E F0 FF 01  
40 18 82 4E 5E 3C 40 18 1F 42 60 3C 0F 8E 3F B0  
FF 01 07 20 40 18 82 43 E4 3B 40 18 82 43 E6 3B 

FYI the file Seth is referring to is the linker command file lnk_msp430f5438a.cmd. In my case lnk_msp430f5438a.cmd had a few modifications that were specific to the device I was using. I had the same problem and replacing the CCS generated lnk_msp430f5438a.cmd file in the project directory with the one that was provided to me fixed the problem.

I was also getting strange #17003 flags, and just thought I'd add what worked for me.  Also linker .cmd file related, my default .cmd file looked like this at one point:

//#ifdef (__LARGE_DATA_MODEL__)
.const : {} > FLASH | FLASH2 /* CONSTANT DATA */
//#else
//.const : {} > FLASH /* CONSTANT DATA */

//#endif

Looks like CCS lost the ability to detect the Large Data Model, so they just set it to use Flash or Flash2.  But if you don't have the large date model turned on, the linker will work, but the addresses will be invalid if it actually ends up using Flash2.  I changed my linker to:

.const : {} > FLASH /* CONSTANT DATA */

and this got rid of my 17003 errors