• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 583 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.

Globals allocation problem with the TMS320F28335 (Code Generation Tool v5.2.5) : INT allocated in 1 byte !!!

Nicolas F
Prodigy 30 points

Hello,

I am using the F28335 in my application. I currently have a problem with the compiler:

I noticed during a debugging session some bad behaviours from some of my globals. In fact, the value these globals had during debug were impossible.

Later, I checked the .MAP file of my project, and I observed something weird:

The compiler actually allocated these globals, which were declared as INT, in a 1 byte memory space. For example:

 

int a1;

int b1,b2,b3;

 

And in the MAP file I see:

00a040 _a1

00a041 _b1

00a042 _b2

00a043 _b3

 

I am sure that it's the  reason of these weird behaviours.

 

But I'm asking myself how the compiler could have done this.

For information , in the build options I disabled all the optimization options.

These variables are not declared as external char in an other file...

 

Can someone help me ?

  • 0
    TI__Guru* 93800 points

    Nicolas F said:
    The compiler actually allocated these globals, which were declared as INT, in a 1 byte memory space.

    Nicholas,

    On 28x memory addresses point to 16-bits.  So each of those variables is taking up 16-bits.  Also a char is 16-bits on 28x as well.

    Does that answer your question?

    -Lori

  • 0 in reply to Lori Heustess
    Prodigy 30 points

    Thank you Lori for your answer

     

    Actually, the problem is that my application crashes at some point. During a debug session, I discovered that these globals were the origin of the problems, as these ones were assigned with unlogical values.

     

    In the MAP file, I saw that these variables took only 1 address unit, like I said in my first message:

    0x00a050 _a1

    0x00a051 _a2

    0x00a052 _a3

     

    Then I decided to declare these globals as LONG, and not as INT any moire.

    And my application worked perfectly !

     

    When I checked the MAP file, globals were seperated by two address units now:

    0x00a050 _a1

    0x00a052 _a2

    0x00a054 _a3

    So I thought that maybe variables must be seperated with two address units to work correctly, I know that this problem can occurs with some microprocessors (actually I have already met the same problem with a Motorola ColdFire).

    By the way, I know that it's not an overflow problem, because these variables are assigned with values from 0 to 100.

     

    What do you think ?

    Regards

    Nicolas

  • 0 in reply to Nicolas F
    TI__Guru* 93800 points

    Nicolas F said:
    So I thought that maybe variables must be seperated with two address units to work correctly, I know that this problem can occurs with some microprocessors (actually I have already met the same problem with a Motorola ColdFire).

    No, there is no problem with ints being in consecutive memory locations.  Each address points to 16-bits which is an int.

    When you change to long, two memory locations get allocated or 32-bits as you've seen.

    The one alignment issue you may encounter is a 32-bit value is always even aligned.  This means:

    if you write a long to address 0 it takes up address 0 and 1.

    if you write a long to address 1 it still takes up address 0 and 1.

    If you are writing in C the compiler takes care of this for you so no issues.

    Nicolas F said:
    What do you think ?

    It's difficult to say what was causing the crash/bad values without performing some debug.

    -Lori