Stack problem in H8/S - documented?

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.

Reply to
Blakely LaCroix
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.