From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31565 invoked by alias); 19 Nov 2008 16:31:41 -0000 Received: (qmail 31354 invoked by uid 22791); 19 Nov 2008 16:31:39 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32,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 16:30:47 +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 1L2pwz-0003VB-X3; Wed, 19 Nov 2008 16:30:45 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id DB454138780; Wed, 19 Nov 2008 16:30:43 +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> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Wed, 19 Nov 2008 16:31:00 -0000 In-Reply-To: <1227008854.29306.73.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/msg00035.txt.bz2 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. 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. > > *** cvs-14.11.08/ecos/packages/hal/cortexm/arch/current/src/vectors.S > 2008-11-03 14:53:51.000000000 +0000 > --- > working-14.11.08/ecos/packages/hal/cortexm/arch/current/src/vectors.S > 2008-11-18 11:10:31.000000000 +0000 > *************** > *** 129,140 **** > --- 129,142 ---- > isb // Insert a barrier > > msr psp,sp // Copy SP to PSP > + ldr sp,=hal_startup_stack // Reset SP to top of RAM > > #if !defined(CYGPKG_KERNEL) > sub sp,#(CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE/2) > #endif > > orr lr,#0xD // Adjust return link > + bic lr,#0x2 > bx lr // Return to init code on PSP > > Chris. > -- 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