From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15561 invoked by alias); 19 Nov 2008 18:12:55 -0000 Received: (qmail 15515 invoked by uid 22791); 19 Nov 2008 18:12:53 -0000 X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from lon1-post-1.mail.demon.net (HELO lon1-post-1.mail.demon.net) (195.173.77.148) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Nov 2008 18:12:02 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by lon1-post-1.mail.demon.net with esmtp (Exim 4.69) id 1L2rWy-0004lq-WZ; Wed, 19 Nov 2008 18:12:00 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 4075A138703; Wed, 19 Nov 2008 18:11:59 +0000 (GMT) To: Chris Holgate Cc: ecos-devel@ecos.sourceware.org Subject: Re: Minor fix for CortexM vectors.S References: <1227008854.29306.73.camel@hercules.zynaptic.com> <1227117919.29306.106.camel@hercules.zynaptic.com> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Wed, 19 Nov 2008 18:12:00 -0000 In-Reply-To: <1227117919.29306.106.camel@hercules.zynaptic.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2008-11/txt/msg00037.txt.bz2 Chris Holgate writes: > On Wed, 2008-11-19 at 16:30 +0000, Nick Garnett wrote: > > Chris Holgate 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! If that is all you have then maybe. But you would have to shave the interrupt stack down to the absolute minimum for it to make much of a difference. > > > 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. > That is all very odd, it shouldn't make any difference. Do keep us informed if you find anything out. You could try replacing the BIC with a NOP, or perhaps a barrier instruction and see if the behaviour stays the same. My experience is that in some situations the Cortex-M behaves somewhat non-intuitively, until you work out what the designers intended. So it is possible there is some unexpected behaviour here. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071