Starterware's interrupt handler

Hi,

        When the IRQ handler is executed the processor will be in IRQ mode. when the CPSR is modified the mode is changed to system mode. Since the LR is shadowed between different modes of the processor it is automatically backed up.

        IRQ will not occur between 105-139, because IRQ will be disabled when an interrupt occurs allowing us to backup the context before enabling IRQ. So the scenario you predicted will not happen.

Regards

Baskaran

I understand that interrupts cannot happen during execution of lines 105-139 (because interrupts are not enabled). I'm saying that some event, which causes an interrupt, might occur during these lines of execution. And the only reason why such an event would not cause an interrupt is because interrupts are presently disabled.

But, after interrupts are enabled by instruction on line 139, pending interrupt might be kicked off, and this might happen before lr_usr is stored, since it it stored AFTER interrupts are re-enabled. 

My point of concern is that interrupts are enabled before lr_usr is stored. It seems like it would be safer to switch to system mode first, without enabling interrupts, then push lr (which will be lr_usr) and only after that is done re-enable the interrupts. Does this clarify the question?

Thanks,

The LR of IRQ mode is already stored in stack in line 106 (r14). In line 139 the mode is changed to system mode. It is the LR of system mode which is getting stored in line 142.

Regards

Baskaran

I am not speaking about lr_irq. I am concerned about  lr_usr. We must save it and restore before returning from IRQ. But if a higher priority interrupt gets kicked off after
MSR cpsr, r14
but before
STMFD r13!, {r14}
then such an interrupt might spoil lr_usr.

The lr_usr will be automatically backed-up in the shadow register by HW and SW need not save it.