[Bug 1002169] Broken cyg_interrupt_disable/enable for cortex m3

[bugzilla-daemon at ecoscentric dot com]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1002169

--- Comment #2 from Nick Garnett <nickg@ecoscentric.com> ---
Bernard,

Problem 1:

The Cortex-M architecture defines an 8 bit priority value. Implementations are
allowed to impose some granularity on this by ignoring some of the least
significant bits. For the LPC family that is 3 bits, for the STM32 family it is
four.

eCos continues to implement most of that 8 bit priority range. The highest
hardware granule is reserved for system use, mainly for exceptions. To allow
zero to still map to the highest available interrupt priority, eCos priorities
are all shifted down a granule, with the lowest granule mapping into the next
one up.

We don't try to map eCos priorities only on to the subset of priority bits
implemented. So there will be ranges of priorities that all map to the same
hardware granule. We implement something as close to the architecture
definition as possible.

Within the 8 bit range, setting the default interrupt priority to 0x80 places
it roughly in the middle of the range and allows drivers to select higher and
lower priorities for their interrupts. For all interrupts that are actually
used, the priority will be set when it is attached to the vector. 


Problem 2:

While the SysTick priority is initialized to 0 at boot time, it is changed to
the value defined by CYGNUM_KERNEL_COUNTERS_CLOCK_ISR_PRIORITY when the clock
interrupt object is attached to the vector. 

The original Cortex-M definition did not give indexes to the SHPR registers. I
chose to index them from 0. It looks like ARM have subsequently given them
indexes starting from 1.

We do not use PRIMASK for interrupt disables since it also causes exception to
be redirected to HardFault if they occur when it is set. This would interfere
with debugging via the GDB stubs in RedBoot if we wanted to set breakpoints in
code that had disabled interrupts.


Regards

Nick

-- 
You are receiving this mail because:
You are the assignee for the bug.