AVR Freaks

Many thanks, John.  You're quite right that I had omitted the save/restore of the SREG (I'm new at this), but doing so has not corrected the issue.  It is exactly the same as described.  I'm sorry, the description was a bit convoluted, but I couldn't think of a way of stating it more simply.  Invoking the symptom is quite complex.  It depends on triggering the interrupt on the right instruction (the compare, not the branch), and when I click PIN[2] to invoke the interrupt, if the PIN[2] square goes white, it returns from the interrupt back to the compare, whereas if the PIN[2] square goes grey, it returns from the interrupt to the instruction after the compare, so the compare never gets done, and the next single-step takes it back to the interrupt (INT0_handler).

Thanks for the example you gave, and for the suggested method - however, your worked example was for a regular subroutine, not an ISR - I misled you by returning from it with a reti - but that was an error on my part.  It is called with an RCALL and should have been returned with a RET.  My two interrupt routines are INT0_handler and TCNT0_overflow.  I have saved/restored SREG in them now, though I stepped through them and SREG was not actually changed.  In INT0_handler, "clr R14" sets the Zero flag, then "inc R9" clears it again, so SREG was unchanged, and while single-stepping the program, the TCNT0_overflow ISR never gets called.  Still, I agree, I should be doing this as a matter of habit.

Here are my sanitised ISR's - but the simulation fault is still there.  The problem is that the program doesn't run in my MCU either, and I don't know if this is my cause, or whether this is just an artifact of SR-7 and I should be looking for something else.

INT0_handler:   ; INT0 vector points here
  ; interrupts are stopped because we're in one.
  
  in R15,SREG   ; save the status register
  in R12,TCNT0  ; save LSB
  mov R11,R14   ; save MSB
  out TCNT0,R9  ; clear the timer
  clr R14       ; MSB (overflow counter)
  inc R9        ; indicates to main that INT0 has completed.
  out SREG,R15
  reti

TCNT0_overflow:
  ; increment overflow counter 
  in R15,SREG  ;
  inc R14      ; number of overflows.  Typically 0x3C-40
  out SREG,R15 ; restore SREG
  reti

Thanks meolsen, I had already done that.  If I had not, I don't think the interrupt would have triggered at all.

I found the reason why the program wasn't running.  When it has developed its numbers, it displays them on an oscilloscope, and I had made a mistake in the display routine.  That happens after the section of program that I posted at the top of this thread, so my programming error does not affect the symptoms I was seeing.  Now, the chip runs, but there is still a problem in AS-7.

That means that my fault is definitely looking like an AS-7 issue.

I've had a few suggestions based on the usual errors that newbies make, but has anybody copied my code and tried to reproduce the issue?

There is a part of my script that goes ...

; Divide R2:R3 by 8 (shift them right 3 times)
lsr R2 ; LSb -> [C]  1st time
ror R3 ; [C] -> MSb

If my single-step highlight is on the first instruction (lsr R2) and I modify the value of R2 to '4', then execute the single step, the value of R2 goes to '2', so I know that when the single-step highligjt is on an instruction, that instruction has not yet been executed.

Now, back to the issue.  In my waiting loop ...

average_time:  ; averages the timer counts over 8 counts
; R4 is the sample number.  We will average 8 of them
cp R8,R9       ; R8 = 1
brne average_time

... if "cp R8,R9" is highlighted, it has not yet been executed.  Before single-stepping, if I invoke INT0 by clicking PIN[2], the interrupt is not invoked immediately.  The single step appears to do the cp test, then go to the branch (brne average_time), then the ISR is invoked.  However, when I clicked PIN[2], if it went white, the reti returns to returns to "cp R8,R9", and the comparison gets tested.

If PIN[2] went grey (which it does on alternate clicks), the reti returns to "brne average_time", and the comparison does not get tested.

Is that how it's supposed to work?  Is there something I haven't thought of?  Probably - but if somebody could try it out, that would resolve it.

Edited a line out of the prohram inclusion to make it more readable

Thanks, clawson,  I searched for it in AS-7 help.

Can you say a bit more about it please?

And even though another method of invoking an INT0 may exist, it poking PIN[2] invalid?

Thanks.

Yes, that works, John, because it is part of the MCU spec that "The flag is cleared when the interrupt routine is executed" (from the datasheet).  That stops the ISR from being executed twice.  Of course, it's not a simulation of the real world any more, because a hardware interrupt will put a pulse on pin 7 of the chip - it won't directly change the flag.  Thanks for giving it some thought.

Finally, I decided not to report it.  My experience with dealing with companies is a lot like dealing with authority - nobody will take much interest, and nothing will be done about it - so why bother?  I know about it, and it won't phase me when simulating, so it's not really a disadvantage to me.  I know how to work around it - by triggering the ISR on the right instruction - and although I'm not 100% sure, I don't think it's happening in the MCU - only in AS-7.  I may devise a test at some point to be certain.  I'm just going to accept it and move on with my project.  Next bit - fast binary division - if I can get it worked out!

Incidentally, I don't have any other version of Studio.  This one works fine (with a small reservation!)