changes to the core Nios2 RTEMS IIC model

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Aug 15 16:53:23 UTC 2012


On 15/08/12 16:41, Hill, Jeff wrote:
> Hello Sebastian,
>
>> some more comments regarding the thread stack usage of ISRs.
>>
>> On 14/08/12 03:05, Hill, Jeff wrote:
>>> __attribute__ ((section (".text_hotspot")))
>>> void __ISR_Handler ( void )
>>> {
>>>
>> [...]
>>
>> The code that calls __ISR_Handler() will save the volatile context on
>> the thread stack, right?
> correct
>
>>>     if ( _ISR_Nest_level == 0) {
>>> #   if( CPU_HAS_SOFTWARE_INTERRUPT_STACK == TRUE)
>>>         stack_ptr = _old_stack_ptr;
>>> #   endif
>>>
>>>       if ( !_Thread_Dispatch_in_critical_section() ) {
>>>         if ( _Thread_Is_dispatch_necessary () ) {
>>>           _CPU_ISR_Enable ( isrCookie );
>> What does the _CPU_ISR_Enable() here?  Will it really enable the
>> interrupts?
> The _CPU_ISR_Enable will of course _globally_ enable interrupts in the Nios2
> status register.

The name _CPU_ISR_Enable() might be a bit misleading since it restores 
only the state in isrCookie.

>> In case it enables interrupts then the code that calls
>> __ISR_Handler() will save a volatile context on the thread stack (it is
>> now the second).  In case the interrupt is pending a long time (some
>> sort of error) or you have a bad sequence of interrupts, then this can
>> stack several times and blow your thread stack.
>>
> With the IIC the interrupt's priority is defined by its bit position
> in the ipending  and ienable register.
>
> Note that this is the Nios2 with internal interrupt controller so a
> particular interrupt will not occur unless it is _also_ enabled in the
> Nios2 ienable register, and as I mentioned in my previous
> mail the interrupts of equal or lower priority are previously disabled
> by the following code that writes to the Nios2 ienable register. We will
> not start a new interrupt context for the same or lower priority interrupt
> with the IIC unless it is _also_ enabled in the ienable register; therefore
> the interrupt contexts will nest only 32 deep.

This is weird the IENABLE register is restored in the low level code, 
but the context switch doesn't touch the IENABLE register.  Does this 
mean that the outer most level is disabled if the interrupt leads to a 
context switch?

This seems to be a bit asymmetric.  For example this is the EIC code:

http://git.rtems.org/rtems/tree/cpukit/score/cpu/nios2/nios2-eic-rsie-low-level.S

Here you enable/disable the interrupts directly around the handler.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the users mailing list