From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24109 invoked by alias); 25 Nov 2010 11:26:18 -0000 Received: (qmail 24083 invoked by uid 22791); 25 Nov 2010 11:26:16 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.stmi.com (HELO mail.stmi.com) (70.169.254.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Nov 2010 11:25:46 +0000 X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Cortex-M3 HAL interrupt-priority code bug Date: Thu, 25 Nov 2010 11:26:00 -0000 Message-ID: In-Reply-To: References: From: "Christophe Coutand" To: "Nick Garnett" , "Nagaraj K" Cc: X-IsSubscribed: yes 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: 2010-11/txt/msg00006.txt.bz2 My understanding is: CYGNUM_HAL_CORTEXM_PRIORITY_MAX is defined equal to 1<<(8-CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS) What the eCos implementation really does is to reserved level 0 for DEBUG and SVC traps. If you call hal_interrupt_set_level with level 0 what you will really get is a priority of 1. Nothing wrong with that? Christophe -----Original Message----- From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Nick Garnett Sent: 25. november 2010 12:19 To: Nagaraj K Cc: ecos-devel@ecos.sourceware.org Subject: Re: Cortex-M3 HAL interrupt-priority code bug Nagaraj K writes: > I see that this function wrongly implements the priority level in > Cortex-M3 processor. According to the Cortex-M3 data sheet, we need to > write the priority level to the top N bits of the register where N is > the number of priority level bits implemented in this particular > version of the cortex variant. The intention in the design of the hardware is that software can use a 256 level prioirity scheme on all implementations. By defining the actual priority in terms of the top N bits of the registers, the hardware essentially groups the 256 virtual priorities into a set of real priorities by ignoring the less significant bits. eCos simply follows the lead given by the hardware and implements 256 priorities. It is a good scheme and allows us to write code that will work in all implementations. --=20 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