This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minor fix for CortexM vectors.S


On Wed, 2008-11-19 at 16:30 +0000, Nick Garnett wrote:
> Chris Holgate <chris@zynaptic.com> writes:
> 
> > Hi folks,
> > 
> > This is a minor fix that I found while building the ROM based target for
> > my STM32 board.  The hal_switch_state_vsr can generate invalid
> > EXC_RETURN values in the link register for certain alignments - the fix
> > is to ensure that bit 1 is always cleared.  It's also possible to
> > reclaim a bit of RAM for the interrupt stack:
> 
> I'm not sure about either of these.
> 
> The stack reset is benign. However, on other targets we often assign a
> few words padding at the top of the interrupt stack to allow for
> errant ISRs. There's no proof that this has ever been necessary, so
> it is just a safety margin. By not adjusting the stack here, we got
> that buffer zone implicitly.

OK - I was just looking at the 20k RAM on my '103RB device and thinking
that any saving is worthwhile!

> I'm not sure I understand the change to LR. Normally the SWI from the
> reset VSR should set LR to 0xFFFFFFF1, a return to handler mode on the
> main stack. The state switch VSR sets it to 0xFFFFFFFD, a return to
> thread mode on the process stack. The only other valid value would be
> 0xFFFFFFF9, a return to thread mode on the main stack, which we never
> use. None of these has bit 0x2 set, so I'm not sure what problem you
> are seeing that requires this bit to be cleared. I don't see how
> alignment can affect this bit, or the LR value here at all.

On the alignment issue, I'd assumed (obviously incorrectly) that the
value held in the LR inside the state switch VSR would be the address
after the SWI opcode that called it (just as it is with the old ARM
exception model), so a marginal change in the location of the SWI
instruction would affect bit 1.  The CortexM 'application' reference
manual is a bit vague on the matter - but now you mention it, it makes
sense that a valid EXC_RETURN value should be placed there on entry.

Ideally, I'd have noticed this from a register dump from inside the VSR,
but the new toolchain and my J-Link GDB server seem to be having
disagreements.  All I know is that the additional BIC instruction seems
to be the difference between working correctly and failing at that
point.  Since the BIC doesn't do anything useful in itself, maybe it's
just acting as pipeline padding.  I'll do some more tests and report
back.

Chris.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]