Do I have to use external clock for ATmega ISP programming after changing fuse bits?

Question

After programming an ATmega microcontroller via ISP (SPI) interface and changing the clock-related fuse bits, I'd like to reprogram it again. Will I have to connect it to an external clock now to do so, or will I always be able to program it by clocking just via SPI's SCLK line, without external clock (like in image below)?

(in the image below, the programmer is a Raspberry Pi)

Answer 1

Hmh, found an answer to other similar question:

You do not need any crystal circuitry in place for programming a blank off the line AVR (as they come running off the internal oscillator), but if trying to reprogram a chip that is fused for an external crystal, you will need a comparable crystal and load capacitors in circuit (unless you use a high voltage programming mode).

so for now I understand that the answer is I can't use the above simple circuit after changing the fuse bits, I have to extend it with a clock matching the fuse bits configuration.

Answer 2

It depends on just what you set the clock source fuse bits to. The default configuration is usually to run off an internal 8MHz oscillator divided down to 1MHz; other configurations include external clock (typically on XTAL1 pin) and various crystal modes (with a crystal resonator across XTAL1 and XTAL2). In each of these modes, clock rates down to DC are supported, so the chip will be effectively frozen if it doesn't receive a clock input. However, in oscillator mode XTAL2 is essentially an inverted amplification of the XTAL1 input just to get the resonator swinging, and you could therefore simply feed a clock into XTAL1 in all cases. It will simply be ignored if the internal oscillator is used.

The two combinations that cause trouble are:

1. If you're not currently programming the chip, and it runs from internal oscillator, it could configure the XTAL1 pin as an output. If you're also driving it externally this conflict can fry I/O buffers.
2. The clock rate in the AVR must be faster than the SPI clock. This can mean the XTAL1 input needs to be considerably faster (for instance, as much as 3*512 times in an ATmega644).