R Develop wrote:
Hi all, I have come across what appears to be a bug in the MSP430
interrupt hardware.
I would appreciate critiques and comments.
Hi,
I guess, that the situation is possible and not illegal. Read 2.2.3 in
slau049f.pdf, "Interrupt Acceptance":
"
1) Any currently executing instruction is completed.
"
I'm interpreting this as follows: the interrupt detection and
instruction execution are asynchronous. If this is true, it is possible
that
1. the interrupt occurs at the beginning of the DINT (GIE=0),
2. because DINT is already in the pipeline, it will be executed
3. SR with GIE=0 is pushed onto the stack as a consequence
4. the interrupt handler is called with GIE=0
> When is it a problem?
>
> If from an ISR, you want to force another interrupt after the completion
> of the current ISR, you will be out of luck.
> Since upon exit from the ISR, interrupts are disabled.
Good point. In this case you will not get two consecutive interrupt
handlers. How to get the intended behavior? Further reading in 2.2.3
leads to "Interrupt Nesting", which says
"
Interrupt nesting is enabled if the GIE bit is set inside an interrupt
service routine. When interrupt nesting is enabled, any interrupt
occurring during an interrupt service routine will interrupt the
routine, regardless of the interrupt priorities.
"
If the last (but one?) instruction of the interrupt handler would be an
EINT (GIE=1), it would give the chained interrupt handler the chance to
be called consecutively after (or better in between) the first handler.
Price in this case would be some bytes extra on the stack.
Not sure if I'm right, because not tested...
Hardy
PS: last but one instruction, because on many microprocessors the
instruction directly after the EINT will be executed in any case without
interrupt acceptance
