ATmega88A/88PA/168A/168PA/328/328Pprovides six Lock bits. These can be left unprogrammed (“1”) or can be programmed (“0”) to obtain the additional features listed in Table 28-2. The Lock bits can only be erased to “1” with the Chip Erase command.
Bits 1, 0 of the Lock Byte protect the flash.
1, 1 No memory lock features enabled.
1, 0 Further programming of the Flash and EEPROM is disabled in
Parallel and Serial Programming mode. The Fuse bits are
locked in both Serial and Parallel Programming mode.(Note 1)
0, 0 Further programming and verification of the Flash and EEPROM
is disabled in Parallel and Serial Programming mode. The Boot
Lock bits and Fuse bits.
Note 1: Program the Fuse bits and Boot Lock bits before programming the LB1 and LB2.
I've never had any code get corrupted in 4+ years of programming sketches and just yanking power away by pulling out the USB power or the barrel jack or turning off a power strip, all without setting any lock bits for anything other than "No memory lock features enabled".
OK, let me explain what happens. I've got a little plastic enclosure for an IR remote trigger for my DSLR camera. It has an ATtiny25, an 8 mhz crystal, a 2N4401 BJT (IR led driver) and a high power IR led.
Upon powering up, the code initializes the timer interrupt (for making the 40 khz IR signal) and a hardware interrupt to detect a pushbutton to bring it out of sleep mode.
Press the button, it wakes up, sends out the code burst and goes back to sleep. That's it.
Physically, the PC board and IR LED are in the box, the 3 AAA cell battery holder and the pushbutton are on the cover. A small 4 wire plug in connects the top part to the bottom (or I can also plug a custom cable into the bottom part and then program the tiny with my ISP.
Once in a while, I will flash in a new version of the code and test it "opened up". Works fine. Then I disconnect the programmer and plug in the battery/button cable and screw it together. SOMETIMES when I do this, it won't work!
So I re-connect the ISP and read out the flash contents. They are corrupted. The dump mostly matches the original, but quite a few bytes are different.
Now, maybe this is just a bad AVR chip. I actually found it in the bottom of a pile of electronic parts that were being thrown out. I saw the little 8 pin chip and thought "yeah, probably another 555", but when I saw it was an ATtiny25, I said "cool - maybe I'll make something with it" and stuck it in my pocket.
Then, several years later, after the chip was sitting in my "junk parts" box, I spotted it again and decided to build the IR remote with it. I don't even HAVE any others to try to be sure if it's a beat up chip or some other problem.
In the Makefile, I set the 3 regular fuses, but now I've tried setting the "lock" fuse to 0xFC which is all 1 except for the two lower bits (LB2 and LB1).
SO FAR, the little board hasn't gotten corrupted by handling, but since it's random I'll need to wait a LOT longer before I can be sure if the chip is "fixed and locked" or if there's another problem.