ATTiny85 pin-change interrupt on pin 3 makes pin 2 go high

I’m trying to use pin change interrupts on the ATTiny85 for use with the RC switch library to make a little 315MHz RC decoder unit. Two pins are being used for my A/B channel outputs (0,1), one for a LED out(2), the RX data pin(3), and a program button (4) input.
I worked the code out on a 328 using pin change interrupts and everything worked fine, then I modified the register and pin values appropriately for the ATTiny85, and uploaded the code to my board. The curious thing is that the pin change interrupt (not the handler!) seems to be making the LED pin (PB2) go HIGH (and quite possibly other pins as well I suspect).

I commented out all of the RCSwitch code and through process of elimination determined that simply enabling the interrupt, without even attaching my handler allows the “bug” as described below to be reproduced.

My RX module is mounted on a socket so I can unplug it. Doing so makes PB2 go LOW again and everything seems normal (button/led programming works fine sans RC functionality). Attaching a floating jumper wire to the interrupt enable pin (PB3) causes PB2 to go HIGH, Connect the jumper to +5 or GND and PB2 goes LOW again!

Here’s my sample code:

#include <avr/io.h> 
#include <avr/interrupt.h> 

#define REM_DOWN   0
#define REM_UP     1
#define RSET_LED   2
#define RX_PIN     3
#define PGM_BUTTON 4

//commenting this whole  thing out has no effect
ISR(PCINT3_vect) {  // Interrupt Function
//  mySwitch.handleInterrupt();
}// end ISR

void flashLED(byte n)
{
  for (byte i=0;i<n;i++) {
    digitalWrite(RSET_LED,HIGH);
    delay(100);
    digitalWrite(RSET_LED,LOW);
    delay(100);
  }
  digitalWrite(RSET_LED,LOW);
}// end flashLED

void setup()
{
  pinMode(RSET_LED,OUTPUT);
  pinMode(RX_PIN,INPUT);
  pinMode(PGM_BUTTON,INPUT);
  digitalWrite(PGM_BUTTON,HIGH);
  
// read comments below about these lines
  digitalWrite(RSET_LED,LOW);
// somehow a pin change event on THIS pin (PB2), triggers the subsequent buggy behavior from  PCINT3
  digitalWrite(RSET_LED,HIGH);
  digitalWrite(RSET_LED,LOW);

  GIMSK  |= (1<<PCIE);	// enable Pin Change interrupts
  PCMSK |= (1<<PCINT3); // enable PB3 which PCINT3 is on
  sei();		// set Enable Interrupts

//  flashLED(1);
}

void loop()
{
}

The interesting thing about this sample code is the the effect of changing the RSET_LED pin (PB2). As show above with the “quick” low-high-low again status of PB2 , it ends up noticeably flickering in response (presumably) to the random voltage fluctuations on PB3. Uncomment the flashLED call at the end and PB2 ends up continuously lit, with no noticeable flicker (even though it should just be LOW).

Any help with these Gremlins is greatly appreciated!

PCINT3_vect

Does an ATtiny85 processor have three I/O ports?

No it doesn't, and that should clearly be PCINT0_vect. Thank you, thank you, thank you. Problem solved! My what strange behavior from this! I kind of expected to get a compiler error from an invalid vector id.

My what strange behavior from this!

The default interrupt service routine reboots the processor. Knowing that, does the behaviour now make sense?

I kind of expected to get a compiler error from an invalid vector id.

The avr-gcc folks keep the compiler ignorant of such things. Doing that is mostly advantageous. You've encountered the one disadvantage.

In other words, the compiler sees "ISR(PCINT0_vect)" and "ISR(PCINT3_vect)" as functions that need a special epilog / prolog but are otherwise not noteworthy.