CCS/MSP430FR5994: Memory allocation for a command structure with the CCS linker file

To understand what happened, I need to reproduce it.  I'd appreciate if you would submit your CCS project.  Please create a zip file of the project by following the directions in the article Sharing projects.  Then attach that zip file to your next post.

If you are not comfortable submitting your project, then put the linker command file and the map file together into a zip and attach that.  I'm less confident that I can work the problem with just those files, but I'm willing to try.

Thanks and regards,

-George

Actually, I'm at the very starting point of the transcription to the new processor (tested with TI MSP430FR5994 LaunchPad, and the original MSP430F149 hardware). So unfortunately, I haven't yet a working version of the MSP430FR5994 code. But the original MSP430F149 code could be downloaded at:

www.mi.fu-berlin.de/.../ScatterWeb_Source_v2_0.zip

There we have the linker command file under "system/ldscript.x", this file would be replaced by the default "lnk_msp430fr5994.cmd" file. There we need to modify and integrate the command structure of the old linker file.

Under "Systen/src/ScatterWeb.Messaging.h", we could find the declaration of the command structure "#define COMMAND(x, flags)", and "typedef struct command_struct".

Under "Systen/src/ScatterWeb.Messaging.c", we could find the declaration of the function that calls the right command to be executed: "void doCommand(const UINT8* str, UINT8 flags)". There we have a while loop that tested witch command to call:

while(c < &__term_end){

   if( (str[0] == c->code[0]) && (str[1] == c->code[1]) && (str[2] == c->code[2]) )

      {c->function(str);}   //Call the command

}

With these two declarations, we could declare anywhere in the code a new command, like the following model:

COMMAND(abc, 0) {

...; //Do something

}

In the transcription of the project linker file, I tried to integrate the command structure as:

SECTIONS
{…

   .commands : {

      __term_start =.;

      *(.commands) //#10068-D no matching section

      __term_end =.;

   } > FRAM

...

}

But I always obtain the following error message "#10068-D no matching section", and I could see that in the "doCommand(const UINT8* str, UINT8 flags)" function, we never enters the "while(c < &__term_end)" loop. So the commands are all ignored. Actually, I don't know, if it is a memory allocation problem of the linker file, or an other declaration error. According to me, I think that the problem is probably a false declaration in the linker file.

user1082833 said:

But I always obtain the following error message "#10068-D no matching section"

The issue was that there were no references to the contents of the .commands section in the program, and so the linker discarded the sections.

After modifying the COMMAND macro to add __attribute((retain)) then:

1. The .commands sections were retained by the linker
2. The "#10068-D no matching section" warning no longer occurred
3. The program now iterates over the entries in the .commands sections

The COMMAND macro is:

#define COMMAND(x, flags)             void term_##x (const UINT8* str); \
                                      __attribute__((section(".commands"))) __attribute((retain)) const command_t com_##x = { term_##x, #x, flags }; \
                                      void term_##x (const UINT8* str)

The attached project, created using CCS 10.0.0 and MSP430 compiler v20.2.1, demonstrates the updated COMMAND macro and can run on a MSP-EXP430FR5994

3718.MSP430FR5994_command_structure.zip