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

[Klaus Rudolph]

Hi Petr,

back again from my little lab:

I executed the follwing code on a atmega32 (real device on stk500 )


  1 #include <avr/io.h>
  2 #include <avr/interrupt.h>
  3
  4 #undef _SFR_IO8
  5 #define _SFR_IO8(x) (x)
  6 #undef _SFR_IO16
  7 #define _SFR_IO16(x) (x)
  8
  9
 10 .global main
 11 main:
 12     ldi r16, 0xff          ; all pins output
 13     out DDRB, r16          ; all pins output
 14     ldi r16, 0x01          ; one pin on
 15     out PORTB, r16         ; initial only 1 pin
 16
 17     ldi r17, 0x55
 18     sei                    ; enable interrupts
 19     ldi r16, (1<<UDRIE)    ; lets generate a usart data register
empty irq
 20     out UCSRB, r16         ; which should exactly now take place BUT ->
 21     out PORTB, r17         ; if this instruction is executed, we
will see 0x55 on portb!
 22
 23 ; normaly never execute any of the following instructions, we caught
into irq handler
 24     ldi r17, 0x0f;         ; if irq will not be executed or comes back
 25     out PORTB, r17         ; we see 0x0f on port b which should not
happen
 26     ret                    ; this will result in going back to
ctors_end -> exit
 27
 28 .global USART_UDRE_vect
 29 USART_UDRE_vect:
 30    rjmp USART_UDRE_vect
 31
 32 .global stopsim
 33 stopsim:
 34     reti
 35

The result is:
PORTB shows 0x55 pattern!

That is exactly what I expect but seems first unbelievable :-)

What we have: After raising the irq on line 20 we have one more
instruction executed which writes the port value to the 0x55 pattern.
The reason for this is not manipulating the I flag in the instruction
before. So it looks that every pending interrupt will execute a single
instruction on normal program flow before entering the irq handler.

If there is no coding error or an interpretation issue I think my patch
is exactly doing what the real device do in respect of the instruction
following the pending irq.

What I could not check is the timing behavior for the wait states of the
next instructions. Maybe it is possible to setup a timer and read back
the counter after execution or some other idea. But I think that is not
so important in the moment (for me).

I will do some more testcases on real device and on simulavr and make
unit tests for them.

Please tell me if you could find any mistakes!

Regards
 Klaus