9S08GT16A illigal address

[jtjans]

    I am porting code from an HC705 to a 9S08GT16A  and have had several screwups by not managing the H register properly.  The result is usually an illigal address as a result of a stack error from not having the same number of pshh and pulh instructions.  The problem is that I cant find a way to trap or trace these errors.  The processor ends up back at the start with all registers reset includding the stack pointer so I cant find out where it came from.  any ideas on how to trap these errors.

jtjans

[tonyp]

The H register in (S)08 starts out zeroed, exactly for assuring compatibility with 05 code.

So, if you haven't added new (S)08 specific code (that affects the HX register directly or indirectly), you shouldn't have to worry about H.

Nevertheless, you need to trace your code using a debugger.

If you have used HX in your updated code make sure as a minimum that your ISR routines save and restore H (which isn't done automatically as with the other registers -- supposedly that too was for compatibility even though no stack manipulation was possible with the HC05, except with some very unorthodox compiler schemes, so who knows for whose sake they had to ruin it for everyone else.)

In short, every ISR should start with PSHH and end with PULH, RTI to be totally safe.



Message Edited by tonyp on 2008-01-16 09:20 PM

[PeterHouse]

Code Review should be able to catch most of these.  There are only a few instructions which modfy the H register.  Search for them and review if the H register is restored correctly OR make sure to always set it to 0 after using it for something.  This way it works like the '05.

As far as mismatched push and pulls - I think the only way to fix this is code review.

Good Luck,

Peter

[bigmac]

Hello,

Further to the comments already given -

Check that the H-register is explicitly initialised prior to the use of any indexed address instruction (search for ,X in your code).  I believe these are the only instructions where there is implicit use of the H-register value.  I can only reiterate to double check every ISR, to confirm that the current H-value is saved, and restored just prior to terminating the ISR.

Assuming your main loop is relatively simple (and does not directly store data to the stack), the stack pointer should reside at the top of stack whilst anywhere within the main loop.  If the stack pointer is some other value, this would indicate a problem.

It should be possible to provide simple debug code, so that the stack pointer value is tested at one or more locations within the main loop code, and to provide a break point only in the event of a corrupt stack pointer.  It may then help to examine the contents of the stack, to identify the likely problem area.

Regards,

Mac

[peg]

Hi,

Its possibly a bit late now, but when I have done this, I do a first pass which just ignores the H register completely. When attempting a port like this you have the oportunity to make so many errors right throughout the code. So I like to simply convert it first, get it working, then optimise it by using the new resources available in the newer device as a second pass.
If you completely ignore the H register it will just stay at zero and have no effect whatsoever.