When it is entered. The wording is slightly vague but I think "when the interrupt routine is executed" means the commencement of execution. Otherwise multiple pin-change interrupts could be easily missed, depending on how long you took inside the ISR.
I suggest writing a simple test that saves somewhere what the flag is, upon entering the ISR, and check it is cleared already.
I wrote this test for the Uno (which is the same basic architecture):
volatile bool firstTime = true;
volatile byte PCIFR_copy = 0;
// handle pin change interrupt for D8 to D13 here
firstTime = false;
PCIFR_copy = PCIFR;
} // end of PCINT0_vect
void setup ()
pinMode (9, INPUT_PULLUP);
// pin change interrupt (for D9)
PCMSK0 |= bit (PCINT1); // want pin 9
PCIFR |= bit (PCIF0); // clear any outstanding interrupts
PCICR |= bit (PCIE0); // enable pin change interrupts for D8 to D13
} // end of setup
void loop ()
Serial.print ("First time is ");
Serial.print ((int) firstTime);
Serial.print (", Flag is ");
Serial.println ((int) PCIFR_copy);
} // end of loop
The PCIFR flag was always zero, even after triggering the pin-change interrupt, which shows that it was cleared upon entering the ISR.
will it generate another interrupt immediately following the one I am servicing?
So, based on the above, the answer is yes it will. Upon leaving the ISR one more instruction will be executed and then the next interrupt will be serviced (assuming a higher-priority interrupt doesn't get in first).
Another way of looking at it is that the pin change will always set that flag. Between instructions the processor would check that flag (and the flags for the other interrupts) and for the highest priority interrupt, if that flag is set, then it would clear that flag and then commencing processing that interrupt. That is really the only logical way it could work.
Also, it makes more sense from the design of the processor to clear the flag upon entering the ISR. Apart from the problem that interrupts could be missed if it didn't, when it enters the ISR the processor "knows" which interrupt it is servicing, because it would have checked the PCIFx flag, it would have checked the PCIEx flag (to see if the interrupt should be executed) and it would have then changed the program counter to the appropriate address for that interrupt, after pushing the current program counter onto the stack. This would be the logical time to clear that flag while all this information is in the processor's "head" so to speak.
At the end of the ISR the code simply executes a RTI (Return from Interrupt) instruction which doesn't have associated with it which interrupt it is returning from. Thus it would be hard to clear the flag at that point.