HC08: Project.map

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

HC08: Project.map

5,156 次查看
patti
Contributor I
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

标签 (1)
标记 (1)
0 项奖励
回复
12 回复数

1,842 次查看
bigmac
Specialist III
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

0 项奖励
回复

1,842 次查看
patti
Contributor I
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
0 项奖励
回复

1,842 次查看
J2MEJediMaster
Specialist I
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
0 项奖励
回复

1,842 次查看
CompilerGuru
NXP Employee
NXP Employee
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
0 项奖励
回复

1,842 次查看
patti
Contributor I
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
0 项奖励
回复

1,842 次查看
CompilerGuru
NXP Employee
NXP Employee
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
0 项奖励
回复

1,842 次查看
patti
Contributor I
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
0 项奖励
回复

1,842 次查看
patti
Contributor I
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
:smileyhappy:
 
thanks Patrik
0 项奖励
回复

1,842 次查看
J2MEJediMaster
Specialist I
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
0 项奖励
回复

1,842 次查看
patti
Contributor I
Hi
 
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
0 项奖励
回复

1,842 次查看
Lundin
Senior Contributor IV
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:
0 项奖励
回复

1,842 次查看
patti
Contributor I
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.
 
patrik
0 项奖励
回复