Re: Cortex-M3 HAL interrupt-priority code bug

[Nick Garnett <nickg@ecoscentric.com>]

"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.


-- 
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