This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Cortex-M3 HAL interrupt-priority code bug
Nick Garnett <nickg@ecoscentric.com> writes:
> "Christophe Coutand" <ccoutand@stmi.com> 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