# How can I isolate an ATTiny from an I2C slave so ICSP will work?

I'm building a small circuit to blink some LEDs with an ATTiny. I'm planning to use a 16-channel LED driver and talking to it with an ATTiny over I2C.

I'd like to use a SMD ATTiny and add some test pads for programming the microcontroller. I'm concerned that the I2C interface with the LED driver may prevent the ICSP from working correctly.

I'm considering putting a diode on the ICSP power pin so that it won't power the LED driver. I'm thinking that without power, the I2C pins are probably high-z.

I could also use a transistor to turn off the LED driver.

First, would this even work? Second, should I use a diode or a transistor? Third, what kind of diode or transistor should I use?

Here's where I'm headed . . .

Basically, I was thinking I could use the 4th test pad and a transistor to switch power off to the rest of the circuit.

Thanks a lot!!

• No, depowering the LED driver won't work, as it will load the I2C (/SPI/ISP) pins trying to re-power itself through its internal protection diodes. If you want to use de-powering as a solution, you need something like an I2C level shifter with the de-powered side wired as the lower voltage side. Apr 6, 2019 at 20:39
• @ChrisStratton, thank you. This is probably a dumb question, but how does the I2C level shifter help me? It looks like the level shifter is to let, say, 5V devices talk with 3.3V devices. How does that keep the ICSP logic from being sunk (can I say that) through the I2C slave on the same wire? Apr 8, 2019 at 5:59

## 1 Answer

When programming the chip over the ISP, just make sure you only update the MOSI line while SCK is LOW.

Any valid i2c message must begin with a start condition of a rising edge on the data line while clock line is high.

The i2c slave state machine on the LED driver will never see a start and therefore should ignore all of the ISP programming operations happening on those pins.

So for this to work, you need the programmer that is driving the ISP MOSI and SCK lines to obey this "no i2c start" rule. My guess is that programmers do this naturally since it doesn't make sense to change the MOSI line while the SLK line is high in the AVR serial programming protocol since the chip could be sampling the data value during that time. But easy enough to confirm empirically!

For example, the ArduinoISP sketch (which is a software ISP programmer) only changes the MOSI line when the SCK line is low...

    uint8_t transfer (uint8_t b) {
for (unsigned int i = 0; i < 8; ++i) {
digitalWrite(PIN_MOSI, (b & 0x80) ? HIGH : LOW);
digitalWrite(PIN_SCK, HIGH);
delayMicroseconds(pulseWidth);
b = (b << 1) | digitalRead(PIN_MISO);
digitalWrite(PIN_SCK, LOW); // slow pulse
delayMicroseconds(pulseWidth);
}
return b;
}


https://github.com/arduino/Arduino/blob/master/build/shared/examples/11.ArduinoISP/ArduinoISP/ArduinoISP.ino#L201

My guess is that it is no accident that this happens to work. The serial programming protocol was likely intended to be compatible with i2c slaves that happen to be hanging off these same pins.

• If one wants to try this the Arduino-as-ISP sketch bit-bangs and so would offer finely detailed control. Apr 9, 2019 at 3:43
• @ChrisStratton Great place to look.... and, in fact, that sketch does not change the MOSI level when SCK is high! Thanks! Apr 9, 2019 at 3:53
• Oh, hmm. So the problem isn't that the programmer doesn't have enough power to program the microcontroller when the other I2C device is on the line but that the other device may think it's an I2C message and will try to respond to it? I put together another circuit that had a potentiometer as a voltage divider on one of the programming pins and it only works if I set it about half way. :) I just assumed I'd have the same issue with an I2C device on the programming wires. Sounds like I do have an issue, but it's different? Apr 10, 2019 at 15:10
• Oh, hmm. If the other IC is powered, the I2C pins are high impedance so I don't have the issue of my programming signals not having enough power to program the microcontroller. If it's depowered, then it's low impedance to ground and I do have that problem. But, if it's powered, then I need to make sure that my programmer isn't sending commands to the IC. Is that about right? Apr 10, 2019 at 15:11
• @D.Patrick Yes, you want the LED controller chip to be powered for many reasons. An i2c input on a powered slave can only pull to ground - it will never drive- and it should only look like a high impedance input unless it specifically see a well formed i2c message directed to its address. Apr 12, 2019 at 16:53