• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 633 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Wrong global structure address when debugging library code

D. Engidea
Intellectual 270 points

I am using Code Composer Essentials Version: 3.2.0.24.2 to write code for a MSP F437 and MSP F157.

I have shared functions and structures that I have put into a "library" (I did create a library using CCE and successfully linked the library to each of the two projects (one for F437 and one for F157)

The program works well, I can debug step by step but I have an issue with global variables.

In the library scheduler.h I have defined 

struct schedulerT  {  unsigned int idle_run_count;  };

extern struct schedulerT sched_stat;

and in scheduler.c

struct schedulerT sched_stat;

Bearing in mind that all works fine when the code runs I must say that when I wish to look at the content of sched_stat using the debugger I end up with the wrong content.

I have produced the map for the linker and sched_stat is put into

00000364   sched_stat

in the actual code that is run and
00000a7a   sched_stat
in the library map file.
The debugger gives me a7a as address of the sched_stat variable (&sched_stat) in the expression window.
The question: What am I doing wrong ? Where is the magic switch to tell to the debugger to load the map from the running project instad of the library ?
NOTE: I can step by step the code correctly, even in the library
Thanks
Damiano

 

  • 0
    Intellectual 270 points

    I upgraded CCE to Version: CCE v3.1   Build: 3.2.4.3.8 but the issue is still there.

    I cannot believe that this is a real bug, I must be doing something wrong...

    Can somebody confirm or deny that the issue is present ?

    Thanks

  • 0 in reply to D. Engidea
    Intellectual 270 points

    To make this issue clear and simple I have "attached" a file with an eclipse workspace that shows the problem.

    The file is actually in the list of files under my "name", that is the place I have been advised to put it.

    Showing the bug is easy, just step the SW with the debugger and show the content of the global variable, the show is wrong.

     

  • 0 in reply to D. Engidea
    TI__Guru**** 173310 points

    I created a example and tested this in CCE and it appears to be a bug in the compiler tools in CCE v3.x. I tested with a newer internal version of the compiler tools and the problem is fixed, so the fix should appear in the next major release of Code Composer. Unfortunately I couldn't find a good workaround to use with the current method by which libraries are created in CCE.

    As you can see in the build output window, a library project in CCE v3 currently compiles the source files and then links them into a relocatable module. The librarian step invokes cl430 -z --relocatable which is what calls the linker with the --relocatable option.

    A better defintion of a object library though is a collection of object modules rather than a relocatable object module. A library can be generated using a tool called the archiver (ar430) which is included with the compiler toolset. Details on the archiver can be found in the MSP430 Assembly Language Tools Users Guide,  http://www-s.ti.com/sc/techlit/slau131

    Creating a library using the archiver should allow you to work around this bug. Please refer to this forum post for details on how to modify the managed make build in CCE to invoke the archiver instead of the linker when building a library project. https://community.ti.com/forums/p/5987/22588.aspx#22588

    Also, for the next release CCS v4, creating a MSP430 Library Project will automatically invoke the archiver instead of the linker with --relocatable option, as mentioned in this forum post, https://community.ti.com/forums/p/5713/21656.aspx#21656

  • 0 in reply to AartiG
    Intellectual 270 points

    Yes, it works !

    Well done !