DPRG
DPRG List  



[DPRG] HELP with 68HC11 stack problem

Subject: [DPRG] HELP with 68HC11 stack problem
From: Mike McCarty jmccarty at ssd.usa.alcatel.com
Date: Wed Jun 20 14:14:21 CDT 2001

On Wed, 20 Jun 2001, Clay Timmons wrote:

> 
> 
> HELP!   I'm having a problem with a 68HC11 microcontroller board.
> I consider myself a near expert on the 68HC11 but this one has me baffled.
> I'm not even sure of the most basic question.  Is this a software or hardware
> problem.   I've spent about 3 hours tracking down this one and still haven't
> found it.  For reference I'm using a New Micros NMIY-0020 board and
> Imagecraft ICC11 C-compiler.

I am familiar with that board, having used one myself. It's a nice board.

I am not familiar with ICC, however.

> My code runs fine when the very first instruction is  LDS #0x00FF
> which loads the stack pointer to the 256 byte RAM internal to the HC11 itself.
> 
> When I cange the code to LDS #0x4000 to initalize the stack pointer
> to external RAM  I have a problem.   On powerup nothing happens
> but then if I hit the reset button it works fine.   I can't figure out why
> it would hang on powerup but work after reset?  Powerup should be
> the same as reset right...  I also really wonder what its doing when
> it appears to hang.
>
>
> Anyone ever set the stack to external memory?    Any advantage/disadvantage?

Yes.

> I think everything should work the same with the stack in external or internal
> memory.  My code has grown and grown and now I'm needing more stack space.

"Everything" is a very big word. It depends on your MODA and MODB
settings, whether you were using port B for anything, etc.

> The external memory is a ST Microelectronics NVSRAM.   I started to suspect
> that it takes some time after powerup before you can access it.  I added some
> delay in the code to compensate but it had no effect.  So much for that idea.

I suspect that you are right. I looked up an NVSRAM STK10C48 (2Kx8),
and found that on power up it does an automatic RESTORE of the RAM
contents from the EEPROM part of the NVSRAM. This is noted to take
550us max. The docu I saw says that the memory ignores all signals
during the RESTORE cycle. This RESTORE does not take place on a RESET.
Now, if you are running with an 8MHz crystal, that's 250ns per E cycle
(bus clock) which means that you must burn 2116 bus clocks before the
memory is ready. 

How many bus clocks did you burn?

What is the exact part number of the NVSRAM?

What does the datasheet for that part specify as the time to restore on
power up?

I looked up another, the STK1744 (32Kx8) and it states it needs 500us
max after power up before it is ready.

Date: Wed, 20 Jun 2001 14:15:21 -0500 (CDT)

If you can't wait for that, then go ahead and run with your stack in
internal RAM for a few, then switch to external after a ms or so.

> Any ideas, even crazy ones, are appreciated,

Well, hopefully this idea is not crazy. It may be wrong, but not crazy,
I think.

Mike
-- 
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel      <- They make me say that.



>From dprglist-admin at nimon.ncc.com  Wed Jun 20 14:20:15 2001
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by nimon.ncc.com (8.9.3/8.9.3) with ESMTP id OAA29816
	for <dprglist at dprg.org>; Wed, 20 Jun 2001 14:20:15 -0500
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA15351;
	Wed, 20 Jun 2001 14:19:43 -0500 (CDT)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5KJJhp01517;
	Wed, 20 Jun 2001 14:19:43 -0500 (CDT)
Received: from sun1307.ssd.usa.alcatel.com (sun1307.ssd.usa.alcatel.com [143.209.155.82])
	by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5KJIg107764;
	Wed, 20 Jun 2001 14:18:42 -0500 (CDT)
Date: Wed, 20 Jun 2001 14:18:42 -0500 (CDT)
>From: Mike McCarty <jmccarty at ssd.usa.alcatel.com>
To: Clay Timmons <ctimmons at cadence.com>
cc: dprglist at dprg.org, "tcrobots at orbis.net" <tcrobots at orbis.net>,
        "NMI Technical Dept." <nmitech at newmicros.com>
Subject: Re: [DPRG] HELP with 68HC11 stack problem
In-Reply-To: <Pine.SOL.4.10.10106201402080.1633-100000 at sun1307.ssd.usa.alcatel.com>
Message-ID: <Pine.SOL.4.10.10106201417330.1633-100000 at sun1307.ssd.usa.alcatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Jun 2001, Mike McCarty wrote:

[snip]

> I suspect that you are right. I looked up an NVSRAM STK10C48 (2Kx8),
> and found that on power up it does an automatic RESTORE of the RAM
> contents from the EEPROM part of the NVSRAM. This is noted to take
> 550us max. The docu I saw says that the memory ignores all signals
> during the RESTORE cycle. This RESTORE does not take place on a RESET.
> Now, if you are running with an 8MHz crystal, that's 250ns per E cycle
> (bus clock) which means that you must burn 2116 bus clocks before the
> memory is ready. 

OOPS! Sorry. That's 500ns per bus clock. So you'd have to burn 1058
clocks.

Mike
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel      <- They make me say that.




More information about the DPRG mailing list