From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30577 invoked by alias); 25 Nov 2010 12:10:17 -0000 Received: (qmail 30567 invoked by uid 22791); 25 Nov 2010 12:10:16 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from anchor-post-1.mail.demon.net (HELO anchor-post-1.mail.demon.net) (195.173.77.132) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Nov 2010 12:10:10 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1PLaeO-0006Sr-h6; Thu, 25 Nov 2010 12:10:08 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id B2CA113874B; Thu, 25 Nov 2010 12:10:07 +0000 (GMT) To: "Christophe Coutand" Cc: "Nagaraj K" , Subject: Re: Cortex-M3 HAL interrupt-priority code bug References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Thu, 25 Nov 2010 12:10:00 -0000 In-Reply-To: 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: 2010-11/txt/msg00008.txt.bz2 Nick Garnett writes: > "Christophe Coutand" writes: > > > 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? > > This is intensional. The Cortex-M3 prioritizes exceptions alongside > interrupts in the same number space. If you try and throw an > exception, such as a breakpoint, of the same, or lower, priority as > the current level then the processor takes a Hard Fault, which is > unrecoverable. The simplest solution to this is to set all exceptions > to the highest priority, zero, and ensure that no interrupts have that > priority. In practice the highest priority interrupt actually needs to > be set to the highest real priority implemented by the CPU. That should of course read: ...set to the *next* highest real priority... -- 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