(Last modified 22 Sep 2010)
Sometimes I end up with
unresponsive ATmega microcontrollers (MCUs). By unresponsive, I
mean attempts to program them with an Atmel AVRISP mkII programming pod
give an error message that the device cannot switch to programming mode.
It seems that the device somehow gets one of its programmable fuses in an incorrect state that disables the chip's ability to generate a clock internally. This means the MCU doesn't create its internal RC oscillator nor does it provide drive for an external crystal. But changing that fuse requires that the device use some kind of clock.
The simplest way out of this bind is to provide an external square-wave on the MCU's XTAL1 pin. On the popular 28-pin DIP devices, such as the ATmega168, this is pin 9. The frequency and source of this signal isn't terribly critical, which means we can get by with something cheap and convenient, such as a 555 oscillator. I've created a schematic for just such a clock source; you can view a PDF of the schematic here. Note that the schematic shows an Atmel MCU; this represents the MCU you will fix.
The values shown create a nearly 50% duty-cycle square-wave at about 50 kHz. Driving this into the XTAL1 pin of a balky ATmega MCU will provide the needed signal to allow the programming pod to put the device into programming mode so you can change the fuses. Note that you must set the pod's ISP frequency to no more than 1/4 of the 555's output frequency. As shown, you need to select a pod ISP frequency of less than 12.5 kHz, so use a suitable value from the pulldown menu in AVRStudio4's Main tab in the AVRISP mkII programming window.
Here is an obligatory photo of my unit. Because the ciruit is so simple, I just built it up on a prototyping board. I've installed a ATmega168 that needed fixing, and I've hooked up my AVRISP mkII ribbon cable.
I can now fire up AVRStudio4 and connect to the MCU using my AVRISP mkII. When I read the MCU's signature in the Main tab, AVRStudio4 correctly reports an ATmega168. Switching to the Fuses tab, I can now read the programming fuses. For the SUT_CKSEL fuse, I select the 8 MHz internal RC oscillator with 65 msec delay. I also make sure the CKDIV8 fuse is NOT checked. Clicking the Program button updates the fuses and my ATmega168, once destined for the bin, is fixed and useable again.
Here is the view in AVRStudio4 of the fuses for the revived ATmega168 device.
Home
It seems that the device somehow gets one of its programmable fuses in an incorrect state that disables the chip's ability to generate a clock internally. This means the MCU doesn't create its internal RC oscillator nor does it provide drive for an external crystal. But changing that fuse requires that the device use some kind of clock.
The simplest way out of this bind is to provide an external square-wave on the MCU's XTAL1 pin. On the popular 28-pin DIP devices, such as the ATmega168, this is pin 9. The frequency and source of this signal isn't terribly critical, which means we can get by with something cheap and convenient, such as a 555 oscillator. I've created a schematic for just such a clock source; you can view a PDF of the schematic here. Note that the schematic shows an Atmel MCU; this represents the MCU you will fix.
The values shown create a nearly 50% duty-cycle square-wave at about 50 kHz. Driving this into the XTAL1 pin of a balky ATmega MCU will provide the needed signal to allow the programming pod to put the device into programming mode so you can change the fuses. Note that you must set the pod's ISP frequency to no more than 1/4 of the 555's output frequency. As shown, you need to select a pod ISP frequency of less than 12.5 kHz, so use a suitable value from the pulldown menu in AVRStudio4's Main tab in the AVRISP mkII programming window.
Here is an obligatory photo of my unit. Because the ciruit is so simple, I just built it up on a prototyping board. I've installed a ATmega168 that needed fixing, and I've hooked up my AVRISP mkII ribbon cable.
I can now fire up AVRStudio4 and connect to the MCU using my AVRISP mkII. When I read the MCU's signature in the Main tab, AVRStudio4 correctly reports an ATmega168. Switching to the Fuses tab, I can now read the programming fuses. For the SUT_CKSEL fuse, I select the 8 MHz internal RC oscillator with 65 msec delay. I also make sure the CKDIV8 fuse is NOT checked. Clicking the Program button updates the fuses and my ATmega168, once destined for the bin, is fixed and useable again.
Here is the view in AVRStudio4 of the fuses for the revived ATmega168 device.
Home