SP out of allowed range (?)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SP out of allowed range (?)

3,081 Views
jorge
Contributor II
I've initialized the Stack Pointer register using Freescale template:
 
_Startup:
            LDHX   #RAMEnd+1        ; initialize the stack pointer
            TXS
 
But when using PSHA instruction, True-Time Simulator generates this error:
 
Error: Attempt to push or pop with SP out of allowed range
I understand that in the Flexis QE128, the stack could be anywhere within RAM section, right? At the beginning SP register is loaded with $1800 (end of RAM section, wich runs from $0080 to $17FF). But when trying to push Accumulator, TT Simulator throws this message!
 
So, I tried to change manually SP register to $00FF and PSHA works nice.
 
Any help will be appreciated.
 
Jorge
 
Labels (1)
0 Kudos
10 Replies

918 Views
Denn
Contributor I
Hello Jorge,
 
I have a question. What is the value of RAMEnd.
 
 
After the TXS the SP-->(RAMEnd+1)-1=RAMEnd and this SP="RAMEnd" should be an valid RAM location.
 
I also see 0x1800 is outside ram space and you have initialised SP with 0x1800 .Maybe the error is due to it. SP should be 0x17FF or less.
 
I think if you have initialized RAMEnd with 0x1800 , you should replace it with 0x17FF.
 
Good Luck!
 
Regards,
Denn


Message Edited by Denn*** on 2008-03-25 02:22 PM
0 Kudos

918 Views
jorge
Contributor II
Denn>
 
From the MC9S08QE128.inc file:dd
 
Code:
RAMEnd:             equ   $000017FF
 
In fact,TXS transfers (H:X)-$0001 to SP.
 
Code:
_Startup:            LDHX   #RAMEnd+1        ; initialize the stack pointer            TXS

 
LDHX is loaded with #RAMEnd+1 ($17FF+$0001=$1800). Then, when TXS is executed, (H:X)-$0001 is stored in the stack ($1800-$0001=$17FF, a valid location in RAM).
 
Jim> How could I submit a service request?
Freescale guys> Really is this a bug in the simulator?
0 Kudos

918 Views
CompilerGuru
NXP Employee
NXP Employee
>            LDHX   #RAMEnd+1        ; initialize the stack pointer
>            TXS
Hmm. Where is RAMEnd pointing too?
Note that TXS does a SP=H:X + 1 already,
so the SP ends as RAMEnd + 2.

Daniel
0 Kudos

918 Views
allawtterb
Contributor IV


CompilerGuru wrote:
>            LDHX   #RAMEnd+1        ; initialize the stack pointer
>            TXS
Hmm. Where is RAMEnd pointing too?
Note that TXS does a SP=H:X + 1 already,
so the SP ends as RAMEnd + 2.

Daniel


I think you are confusing TXS (subtract 1 from index and transfer to SP) with TSX (add 1 to SP and transfer to index).
0 Kudos

918 Views
JimDon
Senior Contributor III
The point is, it does not seem to matter if the address is ok or not or if the debug information correctly specifies that this is indeed where the stack should be pointed (it would be fair for the simulator the throw an error if it did not KNOW you meant the stack pointer to be there). I tried for sure good address, and still got his error.

Even if you point the stack to memory that simulator simulates and that you can otherwise R/W from, it still throws this error.

There is supposed to be configuration for the simulator to tell it to ignore errors, but in 6.1 I can't find it.


 
0 Kudos

918 Views
jorge
Contributor II


I think you are confusing TXS (subtract 1 from index and transfer to SP) with TSX (add 1 to SP and transfer to index).

Yep, I agree with you.
 
  Anyway, I tried to initialize SP with $17FF and still doesn't work. Manually, only works fine when SP is loaded with a value of $00FF or less.
 
By the way, I'm using CodeWarrior 6.0 with the QE128 Service Pack installed (9S08QE128 is my device).
 


 
    I think it's time to jump to CW 6.1
0 Kudos

918 Views
CompilerGuru
NXP Employee
NXP Employee
Yes, I did mix up the add/sub by one. Anyway, this bug apears to me in 6.1, and it is a simulator bug.
I don't know how to disable it either, I wish there would be a defined way to make the simulator ignore all kinds of things he treats as errors. Also if there ever is something the simulator thinks it is an error, it should still be possible to resume after it suspended. In the end, the HW does not stop for the first bug either....

Daniel
0 Kudos

918 Views
JimDon
Senior Contributor III
Yes, you need to be able to disable these errors. It has made this version of the simulator all but useless, as it will also insist that perfectly valid areas of flash are un-initialized and refuse to run any further.
If you root thru the help you will see other versions did have a configuration method, but I can't find it here.

0 Kudos

918 Views
J2MEJediMaster
Specialist I
Jim:

If the new simulator is really creating trouble for you, then please submit a service request. Let's get this thing fixed. You should be able to tell them in precise detail what the problem is. It sounds like some feature got disabled.

---Tom
0 Kudos

918 Views
JimDon
Senior Contributor III
It would seem this is a bug in the simulator.
It should work fine on the processor, but for some reason the simulator does not like this.
Even if you properly move the stack in the prm file, you still get this error:
In the segments section:
    RAM                      =  READ_WRITE   0x0100 TO 0x15ff ;
    RAM1                     =  READ_WRITE   0x1880 TO 0x207F;
    MY_STK                    = NO_INIT    0x1600 TO 0x17ff ;
....
In the placement section:

    SSTACK        INTO MY_STK;

Then:
STACKTOP 0x17ff

Then in main:
_Startup:
            LDHX   #__SEG_END_SSTACK ; initialize the stack pointer
            TXS
 
This is just to be sure that the debug information clearing indicates where the stack is.
You still get that error. I think you should submit a service request.

0 Kudos