Electronic – Brown-out detection with an external clock ATmega1280

As noted, enabling the brown-out circuit will often increase current consumption. Further, because manufacturers generally want to ensure that the brown-out circuit will trip on any voltage that might be low enough to cause other parts of the chip to function, many parts will be able to operate at a lower voltage with brown-out disabled. For example, a controller might work most of the time down to 1.5 volts at room temperature but, under certain stressful conditions (such as elevated temperature) could malfunction at 1.99 volts. To ensure that the device would reset under any condition where a malfunction might occur, the brown out circuit might be designed to trip at 2.1 volts +/- 100mV.

If a device with such a controller were powered from two alkaline AA batteries, enabling the brownout circuit may cause the device to become unusable with a battery voltage of 1.1 volts per cell, and would likely cause it to cease operation by the time the voltage reached 1.05 volts per cell. Disabling the brownout circuit would likely extend operation down to at least 0.9 volts per cell, and possibly even 0.75 volts per cell. If no plausible malfunction that could occur at low voltage could cause any harm beyond increased drain on junk batteries, disabling the brownout circuit would be a simple way of improving battery life, even if it didn't reduce the current draw from usable batteries.

The brown out detector will put the chip into reset mode if the voltage on the Vcc pin drops below the threshold. When in reset, all GPIO pins go into high impedance mode and no code executes. When the supply voltage again rises back above the threshhold for a minimum period of time, the chip will come out of reset and start executing code at the reset vector, similar to a normal start up.

Keep in mind that many Arduino boards have extra power circuitry like a voltage regulator. This means that the voltage that you supply to the Arduino board might not be the voltage the actual chip sees on its Vcc pin. You can use a volt meter to check the actual voltage seen on that pin so see if it matches what you expect.

Also keep in mind that AVR chips have clamping diodes on their inputs, so if a GPIO pin is connected to a higher voltage than the Vcc pin, then the chip can continued to be powered from the input pin. I ran into a very interesting bug due to this...

https://wp.josh.com/2014/03/03/the-mystery-of-the-zombie-ram/

How are you making your serial connection to the chip? Is it possible that power could be coming in though that connection?

Just to keep things simple while figuring this out, you might want to try pulling the chip out of the Arduino and putting it alone on a bread board so you can control the power directly. You might also want to get rid of the serial connection and instead use a blinking LED to indicate if the program is running or stopped.

Finally, I'd verify the assumption that the fuses are getting set as expected during your programming process. You could either use avrdude to read the fuses back from the programmed chip to see if they are what you want, try reading the fuses at runtime via software, or just try changing the clock speed via fuses, programming the chip up with your blinking code, and then verifying that the blink rate has changed to be consistent with the new fuse settings.

Once you get the expected BOD working as expected, you can start adding complexity back in to find the problem.