This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: changing the stack ptr
- To: "Ecos-Discuss (E-mail)" <ecos-discuss at sources dot redhat dot com>
- Subject: RE: [ECOS] changing the stack ptr
- From: "Dan Conti" <danc at iobjects dot com>
- Date: Thu, 26 Jul 2001 18:26:15 -0700
> -----Original Message-----
> From: Gary Thomas [mailto:gthomas@redhat.com]
> Sent: Thursday, July 26, 2001 6:02 PM
>
> On 27-Jul-2001 Dan Conti wrote:
> > Even with 'Use seperate stack for interrupts' enabled ?
> >
>
> Actually, you can probably do it safely. However, the actual switch
> might need to be protected with the interrupts off.
>
> The notion of a separate interrupt stack is that while ISR
> and DSR routines
> run, it uses a dedicated stack which is separate from the
> thread stacks.
> In this way, interrupt stack requirements (which could be
> large) are not
> bourn by all threads.
Ok, i see the distinction. During the actual execution of the isr/dsr
routines the interrupt stack will be used.
> Fair enough. Try changing the stack while the interrupts are
> disabled.
> Note that this can be very tricky. Anything can be on the
> stack and the
> C compiler [at least] will assume that the stack looks the
> way it thinks
> it should at all times. Thus, after you change stacks, you have to be
> very careful about what you fiddle with, etc.
>
> Is this code in C or assembly?
It's in assembly (luckily) so i'm in full control of the stack usage.
I'll see about disabling interrupts and see if that helps out.
> > I feel like i'm missing something here. On this processor
> the sp and lr
> > are banked in irq and fiq mode. When an irq occurs shouldn't it be
> > referencing the irq stack at that point?
> >
>
> That only happens for a few instructions. We switch back to
> supervisor
> mode for the majority of the interrupt handing code. This
> makes for much
> more uniform thread context handling all around.
That would be the something i am missing :)
As it turns out, my problems might be related to something else. I took
out the offending sp replacing code, and put a similarly timed chunk of
sp friendly code, and am still having some issues. But i'm glad i know
the sp story now, thanks gary.
-Dan