AVR Dragon vs slow clock rates

I am using the Atmel AVR Dragon board for debugging. For $50, its a great tool. The AVR Dragon supports virtually all AVR devices, and works with AVR Studio to support Atmel assembler and GCC C code and in-circuit debugging.  It also works with other tools, such as the command line AVRDUDE utility. 



To do in-circuit debugging, AVR Dragon uses something Atmel calls "debugWIRE". This uses the RESET pin to communicate serially with the AVR. To make this work, you must NOT have any capacitor hooked to RESET. You are allowed to have a resistor on RESET, but it should be 20K ohms or higher.  Of course, no active circuit can be driving REST.

It can be a little tricky to bring up the AVR Dragon and your target board. The problem is that the AVR Dragon's ISP interface senses the target's AVR voltage, but does not intend to drive power to the MCU. However, some small amounts of power can reach your AVR processor through the signal pins. Just enough voltage to get it to come up in a bad way so that the target AVR processor will "hang". Thus, it is important to power the target board separately, and power it up BEFORE plugging in the AVR Dragon.

What I do is power up the target with the AVR Dragon attached via the 6-pin ISP interface, but the USB cable not plugged into the AVR Dragon. Then I plug in the USB cable. This seems to work reliably.

Another thing to note is that when you debug code, the AVR Dragon will first write the code into the AVR's Flash. This has a "side effect" that later when you try to start up a debugging session, and you plug in power to the target board, it will begin executing its code. This can be a problem.

The real problem is that the AVR Dragon does not like AVR's that are running below 1MHz. This can confuse the debugWire serial interface on the RESET pin in the AVR. If the clock rate in the AVR is below 1MHz, it becomes very difficult to bring up debug mode. The slower the clock rate, the more problematic it can be. At 32KHz, the AVR processor is essentially "bricked". You have to find a way to re-program the Flash.

For my project, I am trying to conserve battery power. So my program lowers the clock rate, then puts the AVR (an ATtiny44A) into the IDLE sleep mode. The AVR wakes up on an input change or in 10 minutes via TIMER1. It changes the clock rate back to 4MHz, processes the input or timer event, then returns to sleep. So 99% of the time, the clock rate is low.

This works fine. And you can even debug it using AVR Dragon as long as the Flash code doesn't come up and immediately put the AVR into low clock rate sleep mode.

I learned all this after "bricking" my board by loading and debugging a version with the lowest clock rate, 8M/256 = 31.250KHz.

So now my sleeping clock rate is not a #define, but rather a variable in RAM. The variable is initialized to "clock_div_8" which is 8MHz/8=1MHz. This results in my code starting up with a default of a 1MHz clock during sleep. I manually change the variable to 256 during debug to see what happens at 31KHz. Now when I try to debug with AVR Dragon, the Flash code will start off with 1MHz, and everything works.

I was able to un-brick my board. I wrote a very tiny, do-nothing program and, after a couple tries, got the AVR Dragon to re-program the Flash. There is another solution I found on LadyAda's wiki that uses AVRDUDE to erase the part, but I didn't have to resort to that.