How to program ATmega with fuses set to 32.768kHz clock?

Question

I've been programming my ATmega328P's using USBasp programmer for a while. For my new project, I wanted to use 32.768kHz oscillator as an external clock, so I programmed the ATmega to appropriate fuses. Unfortunately, from this point on, I cannot communicate with the chip at all - avrdude tells me that target doesn't answer (rc=-1 error). After some research, I found some tips telling me to connect the oscillator (and capacitors) to chip's XTAL inputs, and then program the chip. I tried that, to no avail. Note that I also used avrdude's -B 2000 switch, that slows down the programming as much as possible - to 500Hz, so programming speed shouldn't be an issue.

In a desperate attempt to rescue chip, I tried Arduino as ISP, but the results were pretty much the same.

Questions:

1. How to rescue this particular ATmega? Is high voltage programmer the only way out of this? I don't have one, so other options are welcome.

2. For the future: how should I program slow clock fuses so that I avoid this problem? It doesn't make sense for me - if programmer doesn't work with such fuses, why is there such a fuse setting in the first place?

Answer 1

Even when fused to use a crystal, the ATmega328P will accept a clock signal injected into XTAL1 when being programmed by ISP. The USBasp does not provide such a signal so you will need to set up another circuit to generate a clock signal fast enough for programming.

The programmer should work with such a slow clock assuming the programmer uses a slow clock as well. Verify that the crystal operates normally.

Answer 2

OK, I got this.

It was much more stupid than I thought - I'm using a self-made programming board. Since I'm quite cheap, the same one is used for 28-pin ATmega's and 8-pin ATtiny's - they have MISO, MOSI and SCK in the same place (if I shift the chip two pins upwards), and the other pins (RESET, GND and VCC) don't conflict with each other. The thing is, I had modified my board to suit ATtiny's only recently, and this is the first time, I programmed an ATmega since then. It turns out, in my board, ATtiny's RESET does conflict with ATmega's oscillator input - so my oscillator, even if connected, was shorted to RESET, so it was unable to produce meaningful signal.

After desoldering that connection, everything works fine. I guess I'll just add a jumper for ATtiny programming and that's it.