Re: Cortex-M3 HAL interrupt-priority code bug

[Nick Garnett <nickg@ecoscentric.com>]

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