Assembly problem

[chop]

I'm attempting to convert an assembly language program originally written for a 705JK to use with the 9s08qg8 , It's going well so far apart from a problem that part way into the program I get a failure due to trying to jump to an unused location ( hex 6091) , I've traced it back to a point in the program where I call a JSR and the return address is put into the stack as 6091 , rather that the correct current program counter value (E28E)

The system is already inside another subroutine ( with the correct return address) so I'm at a loss to figure out why the third address on the stack should be wrongly wiritten/corrupted

Any ideas ? , The software I'm using is Codewarrior 6.1   build 6124 , are there amy issues with this ?

Art 

[Ake]

Hi,

Move the stack pointer up to 0x025f at the beginning of your code:

         ldhx  #$25f            ;hx = $25f

         tsx                         ;move hx to sp

This makes it much more room for the stack.

When it crashes, you ought to be able to look in the stack and see what it has done.

Have you saved/restored the reg H in the interrupt routines?

Regards,

Ake

[chop]

Thanks for the reply , I'd actually already moved the stack to the end of memory (025F) but had forgotten the thing about the H reg , pushing and pulling the H reg at the start and end of the subroutines has helped , but it still appears that for some reason I get well into the program execution and then I get a failure at a JSR instruction as it seems to want to find the return address from the location after the stack end ( 0260) and I can see no rhyme or reason why it should do this returning from a subroutine that the program has used at least 30 times before without failure

Art

[chop]

Sorry corrections , failure occurs at a RTS instruction and the original processor used was a 705J1A not JK ( don't think such a beast exists !)

Art

[peg]

Hi Art,

The HC05 did not have a H register, so if you are simply converting code you can ignore it completely. No need to push/pull it if you never change or use it.
The HC05 had the stack fixed at $FF with no need to change it so it should still work here when you convert. This is why it defaults to $FF in an S08 to maintain compatibility. The only reason it would not convert is if there was less available RAM between the top of the registers and $FF and the old one was using this much.

So, these are only reasons why these two things won't be causing the problem.
As for what is:
Do you have branches out of your ISR that may mean that it never gets back to execute the RTI?
In your last post you corrected to RTS, is this correct? Or did you mean RTI?
Putting RTS where you should have RTI will cause problems.
Have you accidently put in some of the new stack manipulation instructions somewhere that don't have the corresponding "undo" part for? Do a search on your code for AIS and the like, you should not have any if you are converting '05 code.



Message Edited by peg on 2009-01-13 08:11 AM

[chop]

Thanks for the time Peg

              No interrupts being used as yet so it is RTS not RTI  ! , my conversion of this software is being done in a very "slow and steady" fashion with most of the original program commented out  , I'm just adding in the various routines and making sure they run before adding more complex parts .
              It's many years since I wrote the program and I'm hoping that doing it this way may make it easier to find my way around  when I come to modify it.   At the moment these problems are occuring in the delay subroutines  for lcd initialisation and "brag screen" setup .

        I'd probably be better off to use the timer as some of the delays are in the several  mS range and , at the moment, I'm using the default , out of reset clock ,so I'm burning a lot if time in dbnz loops, which is where the problem comes on return from these delay subroutines  ( Probably not good programming practice , but then I'm a mechanical engineer , not a programmer !)

Regards  Art

[peg]

Hi again,

I was confused about the ISR's as you were talking about push/pulling H. This is not necessary for subroutines, but can be for ISR's.

Because of the way you are doing this, my guess is you have either a subroutine that never does its RTS or your code is running in to a subroutine (just by sequential execution and not by JSR)(could also be a BRA) and then when the RTS is executed it fouls the stack.

I would be searching for JSR's then checking where they jump to for the associated RTS. Or you could search for RTS and check there is no way for execution above the subroutine to fall into the subroutine.

[peg]

Hi Art,

I very much doubt there has been any recent changes to CW's assembler recently, especially at this sort of basic level. A bug like this would not have been around very long.

How about you post the relevant code or a simplified example of this.

Sounds more like a stack crash or something like it.



Message Edited by peg on 2009-01-07 02:34 PM