Topic : Why has XSTACK appeared?

Forum : 8051

Original Post
Post Information Post
November 19, 2010 - 7:49pm
Guest

Hi
I have an 8051 project with Memory Model Small, and Use external stack not selected.

After extending some of the C files in the project, the following line now appears in the .M51 listing:

PDATA 0F96H 0001H INPAGE ?C_XSTACK

i.e. it appears that an external stack is being used.

This did not occur is earlier versions of the same project.

Is there something that can trigger the use of an External stack, even when not selected?

Any help will be appreciated.

Thank you
Damien
Replies
Post Information Post
+1
0
-1
November 20, 2010 - 11:24am
Guest

Hi

Just to clarify.

On closer inspection,

- the selected Small memory model in the project Options has been overridden to Large
- an external stack lib has been loaded.

(I have not used any pragmas etc to set the memory model.)

What property of the project code can cause the selected memory model to be overridden in this way?

Thanks

Damien
+1
0
-1
November 22, 2010 - 9:36am
Raisonance Support Team

Hi Damien,

Are you using the old Ride 6 or the new Ride 7 ?

Stéphane
+1
0
-1
November 22, 2010 - 10:24am
Guest

Hi Stephane

I am using Ride 6.

Thanks

Damien
+1
0
-1
November 22, 2010 - 10:41am
Raisonance Support Team

I can't see any reason why the memory model changed.

If you select the small one and uncheck the external stack, do the large memory model and the external stack come back?

Stéphane
+1
0
-1
November 22, 2010 - 11:01am
Guest

Hi Stéphane

I have just tried a compilation on a second PC where I have my latest version of Ride 6. (I have to keep an earlier version because the latest version loads different libraries which in some cases causes the code size to be too big; but that is a problem I can live with.)

With Small selected and External stack unchecked:

on the older Ride 6 the memory model changes to Large and the external stack appears;

on my latest Ride 6 the memory model stays as Small, and the external stack appears.

If I had unintentionally introduced functions that mutually call each other could this have caused the external stack to be used? I have looked for this but I cannot see it. And so far I cannot find any generated ASM code in the listings that is accessing the external stack.

The reason I am trying to solve the issue of the external stack is that I think it may be causing the instability I am seeing. By this I mean that when I make a small change to a working version of the program, (e.g. change a variable from data to idata; remove an unimportant function call) the program will fail.

Thank you

Damien
+1
0
-1
November 22, 2010 - 11:09am
Guest

Hi Stephane

I may have unintentionally caused confusion in an earlier post.

When I said
"- the selected Small memory model in the project Options has been overridden to Large"

I meant that despite selecting Small in the Options, the Linker listing reports the memory model as Large, viz
MEMORY MODEL: LARGE WITHOUT ANY FLOATING POINT ARITHMETIC

Thanks

Damien
+1
0
-1
November 22, 2010 - 11:23am
Raisonance Support Team

Damien,

Does the application or any source file have some local options (a red dot)?

Stéphane
+1
0
-1
November 22, 2010 - 11:25am
Guest

Stephane

No, there are no local options set.

Damien
+1
0
-1
November 22, 2010 - 11:37am
Raisonance Support Team

Damien,

OKay, let's try to identify where the problem comes from.

You said that the trouble is on your old Ride, but not on the new one.

Could you compare the command lines in both MAP files and on compiler/assembler listing
files?

Stéphane

PS: on compiler listing ckeck the QCW on 3rd line it codes the compiler options.
+1
0
-1
November 22, 2010 - 11:45am
Guest

Stephane

"You said that the trouble is on your old Ride, but not on the new one."

Not quite: the problem is in in both Ride versions: an external stack that is not intended to be there.

(The older Ride also sets memory model to Large whereas the newer one does not; but I think this is a subsidiary effect.)

Can you suggest how I can identify the source file that is generating the requirement for the external stack? I am still considering the possibility that it is arising from something unintentional in the new code I have added.

Thanks

Damien
+1
0
-1
November 22, 2010 - 11:53am
Raisonance Support Team

Damien,

Can you send me by email the whole project file zipped?

Stéphane
+1
0
-1
November 22, 2010 - 12:02pm
Guest

Hi Stephane

Do you mean just the .prj file?

I am likely to have difficulties getting permission to send you source files.

Thanks

Damien
+1
0
-1
November 22, 2010 - 12:22pm
Raisonance Support Team

Damien,

The whole stuff would be better, but let's start with the .prj

Stéphane
+1
0
-1
November 22, 2010 - 12:28pm
Guest

Stephane

Ok, will send a zipped prj file.

Tried using "Send e-mail to Stephane via the forum" but seems to be no facility there for an attachment.

Do you have a direct email address?

Thanks.
+1
0
-1
November 22, 2010 - 12:30pm
Raisonance Support Team

Please send to support at raisonance.com that will forward.

Stéphane
+1
0
-1
November 22, 2010 - 2:18pm
Guest

Hi Stephane

I emailed the .prj file as requested.

Damien
+1
0
-1
November 24, 2010 - 2:52pm
Guest

Thanks to Stephane's help I found the reason for the XSTACK being included:

INT8_U /*xdata*/ MySeq;

...
MyFunction( ..., ..., (INT8_U xdata *) &MySeq, 1 );
...

000A 7F01 MOV R7,#001H
000C 7C1F MOV R4,#01FH
000E 7B00 R MOV R3,#MySeq
0010 7A00 R MOV R2,#HIGH ( _XSTK0)
0012 120000 R LCALL _MyFunction

In other words, having moved the variable MySeq from xdata to data (to save code space in accessing it), the cast of function argument (INT8_U xdata *) caused the reference to XSTACK, whick in turn caused the following to be linked:

c:\RIDE\Lib\RC51L.LIB(_C_STKX)]

PDATA 0F96H 0001H INPAGE ?C_XSTACK

Damien