5

Let's suppose that I have two AVRs connected to one ISP connector.

enter image description here To programm only one MCU in this configuration I neet to break one (or mayby several) lines goes to the MCU I don't want to be programmed in this moment.

The first line comes to mind is VCC, which would be great as I'd save power. But as we know - power will go through digital lines wich have protection diodes to VCC and GND.

So I'd choose RESET line. Any other ideas?

Jeroen3
  • 21,976
  • 36
  • 73
Roman Matveev
  • 2,942
  • 7
  • 32
  • 75

2 Answers2

6

break MOSI because that's an output back to the host and break SCK so the other MCU can't see the programming commands.

edit - this still won't work as reset will be pulsed on and off during the programming. ther other data lines also need to be broken, or reset for the other MCU(s) held low.

I guess that's why most designs use a separate programming header for each MCU.

2

I think that in order to do this, you have to keep the other chip in reset to make the IO high-Z (not driven).
Usually the CS (chip select) does this, but there is no chip select available here. See reset as !CS (not chip select).

Update: This concept will not work for atmel parts. Keeping reset low only enters the programming mode. You could keep reset high on the part that you do not want to program. But you have to make sure the program does not use the SPI pins.


However, I would not go this route. I'd compare the costs of an operator changing the cable, using two programmers or using multiplexers.

Jeroen3
  • 21,976
  • 36
  • 73
  • 1
    Holding reset low while ISP-like cycles are performed on the SPI lines can result in corrupting the flash memory of the non-targeted ATmega. – Chris Stratton Apr 01 '18 at 17:31
  • 1
    @ChrisStratton - How is this possible? Holding reset low must be absolute protection. Are you talking about some bug? – Egor Skriptunoff Apr 01 '18 at 18:34
  • @EgorSkriptunoff not for ISP it isn't. Reset is low pretty much the whole time. This can be a "gotcha" when using an Arduino as an ISP adapter to program a target AVR that itself runs an SPI peripheral. Think you'll just hold the programmer in reset to "get it out of the way" without disconnecting while trying out the target program, and you can de-bootloader your held-in-reset programmer Arduino when it misinterprets the SPI traffic as ISP operations. – Chris Stratton Apr 01 '18 at 18:44
  • @ChrisStratton - This should not happen. You have to send a correct signature (which works like a password) to enter AVR programing mode. Did Atmel confirm this behavior? – Egor Skriptunoff Apr 01 '18 at 20:07
  • @EgorSkriptunoff - in this case the undesired traffic *is* ISP operations another ATmega, presumably the same model. But I've also personally seen it happen twice with uncorrelated SPI traffic. – Chris Stratton Apr 01 '18 at 20:13
  • @ChrisStratton You are right, updated the answer. Atmel contradicts itself in the datasheet about pin state during reset. – Jeroen3 Apr 01 '18 at 21:01