When using an uno (atmega328p based) as an Arduino as ISP device to perform in-situ circuit programming of another AVR, is there a risk of the ISP programmer arduino driving a pin high while the target device drives it low (or vice-versa) therebey wrecking pins on both with an over-current condition?
If one has a target AVR with code already running on it, and this code toggles, between output high and output low, any of the pins used for ICSP programming it, while the programmer is connected can this cause a problem?
I know that once the programmer takes the RESET pin of the target LOW, then all the target's pins go to high impedance (input) states. But looking at the Arduino-as-ISP code it seems that the SPI pins of the programmer get set as outputs BEFORE reset has gone LOW? Have I misread the code? It certainly looks like there is no explicit arduino or AVR command called to keep the programmer's pins as high impedance inputs until such time as RESET has already gone low.
This would mean that before the RESET of the target goes LOW, the target is running code normally, and if it is using its ICSP SCK/MOSI/MISO pins as low impedance outputs these are directly connected to low impedance outputs on the programmer which may, at any given time, be outputting the opposite state.
When designing a customised board, is one supposed to put say 1K of resistance between the MOSI/MISO/SCK pins of the target AVR and the ICSPing header then? Enough to limit the current to safe levels if the same pins of the target and programmer are both driving opposite ways?
Also: when making dual use of the ICSP pins on a target device, is there any condition, in terms of what states wires connected to the ICSP pins, where the ICSP pins are used as inputs, are allowed to be in during times when the device is being reset? If you have an AVR acting as an I2C slave, and its reset pin is broken out so it can be reset by the I2C master device without power cycling, then are there conditions one must follow to ensure that a perfect-bad-combination of signals does not arrive on the slave AVR's ICSP pins (lets say they are connected to voltage levels it is reading from circuitry it is managing) during a period when the AVR is being held in reset? That is to say, does one have to do anything to prevent accidental activations of ICSP programming mode during periods where an AVR is held in reset, but circuitry around it is still powered and may be feeding changing signals in to its ICSP pins?
I suspect that the problem will be that when clocking the target AVR, the SPI peripheral will also be clocked. So you will have to keep the SPI peripheral disabled (not selected) else the data from the peripheral will confuse the programmer. Depending if the peripheral's CS is active LOW or active HIGH you need a pull-down or pull-up resistor.
Personally I would put a 2x3 jumper block to disconnect the SPI of the peripherals; 3 dipswitches would also work. Alternatively use a tri-state buffer that you van enable/disable with a jumper/dipswitch.
Thankfully I'm thinking more about situations where the "MOSI"/"MISO"/"SCK" pins (as named when used for ICSP) are being used, when the program is running, as PWM emitting digital outputs. Rather than when they are actually acting as MOSI, MISO and SCK on an actual SPI bus with SPI slaves attached.
Coding_Badly: what version number is in the Arduino as ISP code which looks right to you for this? I was looking at:
// ArduinoISP
// Copyright (c) 2008-2011 Randall Bohn
included in the v1.8.5 arduino IDE.
I see lines 407 to 410 doing
reset_target(true);
pinMode(RESET, OUTPUT);
SPI.begin();
SPI.beginTransaction(SPISettings(SPI_CLOCK, MSBFIRST, SPI_MODE0));
but don't see a command which makes the programmer's MOSI,MISO and SCK in to outputs, nor one which keeps them as inputs beforehand. and "reset_target(true)" looks to set the reset line HIGH not LOW? So the target's reset gets set high, then made an output, then the "SPI" (the means by which ICSP data is transferred) starts without the target's reset pin having been taken low by the programmer setting it's relevant pin (10 when a 328p uno is programmer) to LOW?
// AVR devices have active low reset, AT89Sx are active high
rst_active_high = (param.devicecode >= 0xe0);
Set pin 10 to be input / no pulllup...
Switch pin 10 to an output driving it low...
The target is now held in reset.
MISO should never be an output.
Enabling SPI...
...overrides the pin settings (the values in the DDR registers) to be correct for SPI.
Only for AT89Sx devices. Otherwise low.
Incorrect. For AT89Sx devices the first clause applies (reset && rst_active_high). For AVR devices the second clause applies (!reset && !rst_active_high).