Cortex-M3 HAL interrupt-priority code bug

Cortex-M3 HAL interrupt-priority code bug

[Nagaraj K]

Hi,
   I was browsing through the Cortex-M3 HAL port and everything looks
OK except for the function
hal_interrupt_set_level() in hal\cortexm\arch\current\src\hal_misc.c

Here is the original function.

__externC void hal_interrupt_set_level( cyg_uint32 vector, cyg_uint32 level )
{
    cyg_uint32 l = (level)+CYGNUM_HAL_CORTEXM_PRIORITY_MAX;
    if( l > 0xFF ) l = 0xFF; /* clamp to 0xFF */
    if( vector >= CYGNUM_HAL_INTERRUPT_EXTERNAL &&
        vector <= CYGNUM_HAL_INTERRUPT_NVIC_MAX )
    {
        HAL_WRITE_UINT8(
CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_PR(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL),
                         l );
    }
    else if ( vector == CYGNUM_HAL_INTERRUPT_SYS_TICK )
    {
        cyg_uint32 shpr2;
        HAL_READ_UINT32( CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_SHPR2, shpr2 );
        shpr2 &= ~0xFF000000;
        shpr2 |= (l)<<24;
        HAL_WRITE_UINT32( CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_SHPR2, shpr2 );
    }
    HAL_VAR_INTERRUPT_SET_LEVEL( vector, level );
}

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. Hence I feel that the right
implementation should be

__externC void hal_interrupt_set_level( cyg_uint32 vector, cyg_uint32 level )
{
    cyg_uint32 l = (level)<<(8-CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS);
    if( l > 0xFF ) l = 0xFF; /* clamp to 0xFF */
    if( vector >= CYGNUM_HAL_INTERRUPT_EXTERNAL &&
        vector <= CYGNUM_HAL_INTERRUPT_NVIC_MAX )
    {
        HAL_WRITE_UINT8(
CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_PR(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL),
                         l );
    }
    else if ( vector == CYGNUM_HAL_INTERRUPT_SYS_TICK )
    {
        cyg_uint32 shpr2;
        HAL_READ_UINT32( CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_SHPR2, shpr2 );
        shpr2 &= ~0xFF000000;
        shpr2 |= (level)<<24;
        HAL_WRITE_UINT32( CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_SHPR2, shpr2 );
    }
    HAL_VAR_INTERRUPT_SET_LEVEL( vector, level );
}

I am new to this developer forum and I am sorry if this is not the
right mailing list for this discussion. If so, please suggest an
alternate forum.

Thanks & Regards, Nagaraj

Re: Cortex-M3 HAL interrupt-priority code bug

[Nick Garnett]

Nagaraj K <nagaraj.kmurthy@gmail.com> 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.

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

RE: Cortex-M3 HAL interrupt-priority code bug

[Christophe Coutand]

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 <nagaraj.kmurthy@gmail.com> 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.

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

Re: Cortex-M3 HAL interrupt-priority code bug

[Nick Garnett]

"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

Re: Cortex-M3 HAL interrupt-priority code bug

[Nick Garnett]

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

Re: Cortex-M3 HAL interrupt-priority code bug

[Nagaraj K]

It makes sense now. Thanks, Nagaraj