attiny85: ISR not triggering for PCINT2?

Question

I am using an attiny85 to read the fan speed reported by a pair of 4-wire fans. I had planned to attach the TACH output from the fans to pins 1 and 2, but I ran into a problem: I was able to handle interrupts on pin 1 without a problem, but I can't get the ISR to trigger for changes on pin 2. Code demonstrating the problem looks like this:

#define PIN_LED 0
#define PIN_TACH2 2
void setup() {
 cli();
 pinMode(PIN_TACH2, INPUT_PULLUP);
 pinMode(PIN_LED, OUTPUT);
 GIMSK |= _BV(PCIE);
 PCMSK |= _BV(digitalPinToPCMSKbit(PIN_TACH2));
 sei();
}
void loop() {
 digitalWrite(PIN_LED, 1);
 delay(2000); 
}
ISR(PCINT0_vect) {
 byte tach2;
 tach2 = (PINB & _BV(PIN_TACH2));
 if (! tach2) {
 digitalWrite(PIN_LED, 0);
 }
}

If I replace the definitions of PIN_TACH2 and PIN_TACH2_INT with pin 1, such as...

#define PIN_TACH2 1
#define PIN_TACH2_INT PCINT1

...it works just fine (interrupts also works for pins 0 and 3).

Why can't I handle pin change interrupts for pin 2?

for @chrisl

This is just testing code. The LED remains on until the ISR fires, at which point it will go out for up to 2 seconds. With interrupts attached to pins 1 or 3, it works as expected: a falling edge on the pin causes the LED to go off.

On pin 2, the ISR never triggers.

• chrisl: I don't quite understand, what your code should do. You are only turning the LED on every 2s. Explain further what you expect, what happens instead and what can you see using pins 1 or 3
• Majenko: PCINT should turn LED off. Within 2 seconds it will come on again. Simple testing code. With PCINT1/3 it apparently works (LED can be turned off) but not with PCINT2. Looks to me like it should work, but what do I know?
• Majenko: I assume there is a 1:1 mapping between pin numbers and PORTB bits?
• larsks: @majenko it looks like it based on the datasheet.
• Majenko: You won't find that in the datasheet. You'll only find it in the source code or documentation for whatever core / board definition you are using.

Answer 1

So, it turns out that it was a really stupid problem and entirely my fault, but I'm going to leave this question here in the hopes that it will prevent someone else from running into the same issue.

The answer is...

DISCONNECT THE PROGRAMMER BEFORE TESTING YOUR SKETCH

That's it. With the programmer disconnected, it all behaves as expected.

• chrisl: Since this is the solution for your problem, please accept your answer as the correct one, so that others can see, that this was right
• larsks: @chrisl, you have to wait for two days to accept your own answer.
• frogstair: I think 2 days passed already, its time