Re: [ECOS] Ctrl-c interrupt priority

["Enrico Piria" <epiria at libero dot it>]

> > The answer I gave myself, instead, was the following: the ISR should be run
> > at the highest maskable priority. This avoids race conditions on the
> > hal_saved_interrupt_state variable, that otherwise could be
> > rewritten by the architecture HAL interrupt handling code, during
> > higher priority interrupts.
>
> Most eCos systems don't use nested interrupts, so this is not an
> issue, and the priorities only decide which of several pending
> interrupts gets passed to the CPU next. However, if nested interrupts
> are being used, then yet, it is probably a good idea to make the
> Ctrl-C interrupt higher priority than any others.
> 

> > The answer I gave myself, instead, was the following: the ISR should be run
> > at the highest maskable priority. This avoids race conditions on the
> > hal_saved_interrupt_state variable, that otherwise could be
> > rewritten by the architecture HAL interrupt handling code, during
> > higher priority interrupts.
>
> Most eCos systems don't use nested interrupts, so this is not an
> issue, and the priorities only decide which of several pending
> interrupts gets passed to the CPU next. However, if nested interrupts
> are being used, then yet, it is probably a good idea to make the
> Ctrl-C interrupt higher priority than any others.

Thank you for the answer. I thought a bit more about what
I said in the previous mail, and I found it is wrong.
In fact, when Ctrl-C ISR accesses the hal_saved_interrupt_state
variable, it means that higher priority ISRs have completed,
so the variable points to the correct state.

However, there is the possibility of another race condition, in the
process of breakpoint insertion.
While the Ctrl-C ISR is substituting an instruction with the breakpoint
instruction, a higher priority interrupt can occur, and the related ISR
can execute the code with the partially inserted breakpoint, thus
causing an illegal istruction exception or a crash.

The solution to this can be either:

1) Executing Ctrl-C ISR at the highest possible priority, or
2) disabling the interrupts while inserting the breakpoint, or
3) forcing, through CDL scripts, interrupt nesting to be disabled
when GDB debugging is enabled.

I'm concerned with this issue because I'm working with the ColdFire
architecture, where higher priority interrupts pre-empt
lower priority ones, as soon as they occur.

Regards

Enrico Piria



____________________________________________________________
Navighi a 4 MEGA e i primi 3 mesi sono GRATIS. 
Scegli Libero Adsl Flat senza limiti su http://www.libero.it



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss