According to Pete: Extreme Underclocking with the ProMini

It seems that the watchdog time may be on and causing a timeout.

Did Bob ever get back to you on the low Freq issues?

I couldn't help myself, I just had to try it. My ATMEGA328p works like a charm on 0.2 Hz. That's as low as my equipment will allow me, one clock pulse every five seconds. No jitter, no hanging, just flawless operation. Current consumption at 3.3V fluctuates between 80uA and 170uA. This is how I programmed it.

#define F_CPU 8000000UL

#include <avr/io.h>

int main(void)
{
    DIDR0  |= (1 << ADC5D) | (1 << ADC4D) | (1 << ADC3D) | (1 << ADC2D) | (1 << ADC1D) |(1 << ADC0D);
    ACSR |= (1 << ACD);
    ADCSRA &= ~(1 << ADEN);
    PRR |= (1 << PRTWI) | (1 << PRTIM2) | (1 << PRTIM1) | (1 << PRTIM0) | (1 << PRSPI) | (1 <<  PRUSART0) | (1 << PRADC);

    DDRB |= (1 << PB5);

    while (1)
    {
        PORTB |= (1 << PB5);
        PORTB &= ~(1 << PB5);
    }
}

Simple question, did you disable interrupts?

Pete,

It is possible that you are reading the current state of the output pin, inverting that state, then outputting that state to the pin. This can and does work at high clock frequencies, but can, and will fail under lower frequencies in some circumstances. I have not looked at the code library to see if they shadow the value that is last written to the port in a register, so this may not be what you are running into. If they don't shadow the port. this may be what you are experiencing:

The output node has an impedance and some amount of capacitance. When the pin is being driven as an output, this capacitance is charged to the voltage the pin is driven to. If the pin is then switched to be an input, (to read its current state) the output register is no longer driving the pin. The voltage is sampled that is currently on the pin which depends on the amount of capacitance in the circuit connected to the pin, the resistance of the load connected to the pin, and any stray leakage paths on the PCB. If, due to the slow clock speed, you give the leakage paths enough time to change the charge on the capacitance at the pin to a different logic level, the value read will be different than that written. It is most likely to be of a nature that tends to either drift to one of the power rails. Lets say it wants to drift to a high for argument sake. If the port wrote a low to the pin, but the pin drifted to a high before it was read due to the slow clock, the code would then invert that high state to a low and write that low state to the pin. However, that was the same state that was previously written to the pin, so the pin is no longer toggling, even though it is still running. The slower the clock is ran, the more sensitive to this problem the system will be in this circumstance. (You are giving the leakage paths present at the pin more time to modify the charge on the capacitance at the pin).

This can be avoided by toggling a register in the processor and outputting the current state of the register to the pin. The pin then always stays in output mode, but just follows the state of the register which is toggled in code. The ATMEGA 328P is specified to be entirely static in nature, so you should be able to clock it at any slow clock speed you desire while maintaining the clock stability spec.

One practical reason to do this could be to minimize power consumption for a micro controller while allowing it to wake up on external events where it would briefly switch to high speed for moments when an important event occurs. You are correct that such a design needs to be fully analyzed to minimize other losses so that such techniques actually achieve the desired results. Many processors for this use case exist with the ability to turn off unused peripherals to further reduce the quiescent power required.

It would be interesting to see if this is what is causing your system to stop toggling the LED.

It occurs to me that if there were any floating pins going into, say, interrupts, that 1msec is a plausible timeconstant for charging of a pin's capacitance by PCB leakage current: 10pf / 10nA = 1msec/v. Maybe it would be informative to define all unused pins as outputs, in the setup section of the program, and run it again...

When you got down to 3 and 4 clocks per loop, were you using "|=" or "&=" operators?

I would assume raw registers (ports) are declared as volatile for the compiler. The volatile keyword would force a read-modify-write for "|=" and "&=" operations. A read-modify-write would take 3 clock cycles each plus 1 for a jump which is consistent with your observation. Looking at the disassembly would also confirm if a read-modify-write is occuring.

Changing to a direct assignment "=" could eliminate the read and modify leaving only a "write-write-jump" loop, 3 clocks. If so, that would be as good as assembly could get while still living at the high level C :). Super blinky.

I haven't researched this (I haven't read the datasheet recently) but my gut feeling says that I would start reasearching it by looking at the clock generator section. You haven't changed the crystal/resonator oscillator settings, so it still thinks that it's driving a crystal/resonator. In my experience, these crystal oscillator circuits often have a phase locked loop (PLL) to track the frequency. These take some large number of clock cycles to lock onto the frequency. Since you're running it so far out of spec, it's virtually assured that it won't lock. After a while (2^14 clocks seems reasonable) it may give up and reset. That reset will take a certain number of clocks, during which time your LED is not changing state.

At the very low speeds, you say it just stops. Could it be that the number of clock cycles it takes to re-initilize is longer than you are waiting to see if it restarts?

I think it would be interesting to retry this with the clock settings updated for an external clock, making sure that any PLL is disabled.

There are a few things (like the serial port) that are handled when the code exits loop(), so if you never do (your internal forever loop), those things won't get taken care of. I suspect that what you and wpmcnamara alluded to, setting the clock bits to "external" might improve things. Now I'm tempted to try this myself. I don't have that fancy signal generator, but I have a tube of 555s (and a "three fives" kit). I remember clocking an old KA-50 at about that speed, and trying to do so with a 6800, but it has more complex clock requirements.