Stack problem in H8/S - documented?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

This one ranks as one of the more unusual problems I have run
into.  Thankfully, it only cost me a day to isolate and work around.
We love the parts and the high integration/peripheral mix they offer.
My intent in posting this is to hopefully save others the pain of having
to solve this problem for themselves.


We have been using the H8/S 2357, 2328, and 2329 processors.
The 2328 is essentially a 3.3 volt "equivalent" of the 2357.  These
processors have 8K of internal RAM starting at t FFDC00. The
2329 is in the same hardware family as the 2329 and has 32K
of internal RAM starting at FF7C00.

Typically I place the program stack in the lowest 512 bytes of RAM.
When porting a design from the 2328 to the 2329 to take advantage of
the increased RAM, I ran into a most unusual problem.

The instruction:  MOV  ER7,@MAINSP failed to execute if MAINSP
was located in the lowest part of 30 KB RAM  - yet worked when MAINSP
was in the region above FFDC00. (The 8K RAM base).

Since this instruction was part of a multi-tasking kernel that needed to
preserve the current stack, once this instruction was hit, the program
ceased to execute its programmed path.

It appears that Hitachi does a hardware compare on the addresses involving
the Stack.  When they produced the 32 KB RAM version, they did not
upgrade the Stack limit compare.

Hitachi has one other problem indirectly related to the  Stack Pointer as
detailed in errata # TN-H8-193 AE.

The quirk I have encountered may be resident only in the particular stepping
of the 2329 that I am using.  If anyone else has any Stack related problems
with the H8s family, I would like to learn of them as well.

Site Timeline