Re: [Simulavr-devel] irq handling is broken in simulavr

[Petr Hluzín]

Ok, conclusions so far (if I understood the participants correctly):
Klaus Rudolph and Joerg Wunsch say that: if interrupts were are enabled or
just became enabled (because of SEI, RETI, OUT) and an interrupt was
pending or just became pending, then one more instruction will be executed
and then the interrupt handler (typically a JMP/RJMP instruction) will be
executed.
Also Klaus Rudolph experimentally verified [1] part of this on atmega32.

In such case the current simulavr (after yesterday patch from Klaus)
behaves correctly.

[1]
http://lists.nongnu.org/archive/html/simulavr-devel/2013-01/msg00005.html



On 24 January 2013 19:26, Klaus Rudolph <address@hidden> wrote:

> Hi all,
>
> yesterday I did one real apllication example on simulavr and it runs
> totally instable on it but works on a real device.
>
> After a few hours I found out that the irq handling is broken.
>
> What I expect:
>
> If a irq comes up the core runs exactly one more instruction before
> changing the pc to jump to the irq vector.
>
> This was already implemented in my early versions, but someone wrote the
> AvrDevice::Step method new and brake the irq behavior. :-(
>
> 0100:    nop
> --- now a hardware irq comes up ----
> 0102:    nop     ; one more instruction runs on core
> 0014:    jmp 0x2000 ; vetcor xx jump
>
> actually the implementation only works correct, if the instruction
> before the irq is a sei() :-) I have no idea why this was implemented
> this way.
>
>
> QUESTION:
>
> If I have the wrong idea to the avr core behavior please give me a hint
> to the correct one!
>
> I will now start working on a hot fix for the topic. If there is no
> other advice I will commit after I finished the fix.
>
> In hope that the actually broken implementation is the problem and not
> my idea of avr and the gcc generated code :-)
>
> Regards
>  Klaus
>
>
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/simulavr-devel
>



-- 
Petr Hluzin