topic Re: Compiler code optimizing in CodeWarrior for MCU

HC08: Project.map

patti — Wed, 27 Sep 2006 12:46:12 GMT

Hi... I am having a strange problem.

I have a struct liks this

#define SIGNED8 char
#define UNSIGNED8 unsigned char
#define UNSIGNED16 unsigned int
#define SIGNED16 int
#define UNSIGNED32 unsigned long int
#define SIGNED32 long int

typedef struct
{
UNSIGNED8 NodeId;
UNSIGNED16 HeartBeatTime;
UNSIGNED16 EmcyInhibitTime;
UNSIGNED32 RPDO_COB_ID;
UNSIGNED16 RPDO_Event_Time;
UNSIGNED32 TPDO_COB_ID;
UNSIGNED16 TPDO_Event_Time;
UNSIGNED8 BaudRate;         // 0x2000
UNSIGNED8 OperatingMode;    // 0x2001
UNSIGNED16 PWM_FrequencyDiv;// 0x2002
UNSIGNED16 P_Gain;          // 0x2003
UNSIGNED32 AnalogOffset;    // 0x6431
UNSIGNED32 AnalogGain;      // 0x6432
UNSIGNED32 Serial;          // 0x1018,04
} ObjectDictionary;

My map file says that the size of obejct is 31 bytes, even though it is 35, and my program returns randomly very strange values(bug). When I change all UNSIGNED32 to UNSIGNED16 the program starts working correct, but map file doesnt change. What is wrong?

I am programming a HC08 with Freescale CodeWarrior v5.0.

Can you use variables of type long int with HC08?

thanks in advance Patrik

Message Edited by CrasyCat on 2007-04-13 01:49 PM

Re: Project.map

Lundin — Wed, 27 Sep 2006 15:23:01 GMT

It sounds weird indeed, I bet the compiler is doing some strange optimization on your struct. long works fine, although it is naturally not very efficient to use it on an 8-bit MCU.

Btw, are you actually implementing CANopen on a HC08?! You are a braver man than me in that case :smileyhappy:

Re: Project.map

bigmac — Wed, 27 Sep 2006 15:33:33 GMT

Hello Patrik,

For your integer variable definitions, I understand the alternatives to be:

char always 8-bits length

int length may be processor dependent, but 16-bits for HC08

short always 16-bits length

long always 32-bits length

These will default to a signed value unless preceeded by unsigned.

So the use of long int is not correct, and might be ambiguous to the compiler.

Regards,

Mac

Message Edited by bigmac on 2006-09-2706:38 PM

Re: Project.map

patti — Wed, 27 Sep 2006 16:05:28 GMT

Hi Lundin.

Yes I am implementing CANopen on a HC08, but it will not have any demanding tasks to do. And actually I am implementing microCANopen, which is much more lighter.

micorCANopen http://www.microcanopen.com/

patrik

Re: Project.map

patti — Wed, 27 Sep 2006 16:08:33 GMT

Hi bigmac.

I have tried to use long instead of long int, but It have no affect at all!

Is it something else I can do?

my map file does not yet correct sizes of my variabels

thanks Patrik

Re: Project.map

J2MEJediMaster — Wed, 27 Sep 2006 20:44:32 GMT

OK, let me ask my stupid question here, but it will clarify things. You mentioned modifying the longs. Did you also modify the short int, that is:

#define SIGNED16 int

becomes:

#define SIGNED16 short

The word "int" should NOT appear in your defines at all, only long and short.

---Tom

Re: Project.map

CompilerGuru — Thu, 28 Sep 2006 01:26:40 GMT

What I would check
- check the preprocessor output of this struct. As there are defines used, sometimes strange things are replaced.
- Where do you read the size of 31 from?
- how is this variable defined?
- how does the debugger show the variable. With the debugger it should also be obvious where the lost 4 bytes are missing.
- I would use typedefs instead of defines for the types for various reasons.
- what options are you using? -T can be used to define the size of a int/long, do you use -T?
- if all this does not help, create a simple new project just with this struct and check it there. If the problem happens in this project as well, post it here.

Daniel

Re: Project.map

patti — Thu, 28 Sep 2006 13:56:51 GMT

Hi....

I have read the size of the variable from project.map

I have now changed the #defines to typedef like this.

typedef char SIGNED8;
typedef unsigned char UNSIGNED8;
typedef unsigned short UNSIGNED16;
typedef short SIGNED16;
typedef unsigned long UNSIGNED32;
typedef long SIGNED32;

The variable is global, defined in main.c and extern in all other c-files.

typedef struct
{
UNSIGNED8 NodeId;
UNSIGNED16 HeartBeatTime;
UNSIGNED16 EmcyInhibitTime;
UNSIGNED16 RPDO_COB_ID;
UNSIGNED16 RPDO_Event_Time;
UNSIGNED16 TPDO_COB_ID;
UNSIGNED16 TPDO_Event_Time;
UNSIGNED8 BaudRate;         // 0x2000
UNSIGNED8 OperatingMode;    // 0x2001
UNSIGNED16 PWM_FrequencyDiv;// 0x2002
UNSIGNED16 P_Gain;          // 0x2003
UNSIGNED32 AnalogOffset;    // 0x6431
UNSIGNED32 AnalogGain;      // 0x6432
UNSIGNED32 Serial;          // 0x1018,04
} ObjectDictionary;

ObjectDictionary volatile MyOd @0x004C;

What do you mean by using -T ?? Compiler options?

thanks Patrik

Re: Project.map

CompilerGuru — Thu, 28 Sep 2006 19:51:36 GMT

Yes, I mean -T as compiler option.

But wait, is the problem we talk about here not that this variable has 31 instead of expected 35 bytes?
In the previous post the listed struct does have fields which sum up to 31 bytes, it has different members types than in the initial posting.
The RPDO_COB_ID and TPDO_COB_ID are now 16 bits, previously they were 32 bits.
So what is the "strange problem."?
Is it that the app does not work?

Daniel

Re: Project.map

patti — Thu, 28 Sep 2006 20:01:59 GMT

Hi, I am sorry for the confusion...

The RPDO_COB_ID and TPDO_COB_ID are now 32 bits.

The other was a copy paste error from me.

Now I have found the "correct" project.map, and the size of the struct is now correct. But my application doesn't work as it should, because some times in my variables (32ibt) the values MSB is not as expected.

Patrik

Compiler code optimizing

patti — Fri, 29 Sep 2006 17:36:25 GMT

Hi,

I have tried one more thing, and that is to disable code optimizing, when optimizing is disabled then my code works fine, no strange values in my variables...

What shall I do?

How to find the problem?

What can be wrong?

Because I want to use code optimizing, so my program doesn't get 1/3 bigger

thanks Patrik

Re: Compiler code optimizing

J2MEJediMaster — Fri, 29 Sep 2006 22:17:26 GMT

Clearly, the optimizer is stripping out what it thinks is unnecessary code, and that's causing trouble with your program's logic.

Every variable name that serves as a register should be declared as a volatile so that the optimizer won't eliminate any operations involved with it.

Beyond that, I'm not clear what else can be done without looking at your code.

---Tom

Re: Compiler code optimizing

patti — Fri, 29 Sep 2006 22:24:12 GMT

I have made all my variables to volatile...

I would realy like a second opinion about my code...

But maby you don't have time or interest!?

Patrik