How to lock flash after programming so it cannot get currupted?

Hi all,

I've looked at the datasheets and checked online - found quite a bit of data but just don't "get it" as well as I think I need to.

What I want to do is burn some stand alone code into an AVR (no bootloader - just flash code and no eeprom either) and then protect it from anything being able to corrupt it (like a low battery or a power source connected and disconnected).

I don't care if the flash contents can be READ OUT (i.e. not looking for security), but just lock the flash so that the ONLY way I can program it (or external gremlins can corrupt it) is via a chip erase.

Any info will be appreciated.

The only way I know how is to use a Programmer, and then Atmel Studio to set the Lock Bits.

The IDE can set the lock bits, you can see them in boards.txt. I don't know if/when the IDE does anything with those outside of burning the bootloader.
Or avrdude commands, I've not figured out how to do that myself.

protect it from anything being able to corrupt it (like a low battery or a power source connected and disconnected).

It already is - no need to do anything.

Mark

holmes4:
It already is - no need to do anything.

Mark

"It is already" how? What set it for me? Remember, I'm not using the IDE, nor am I using anything "Arduino". I'm writing code with a text editor, compiling and linking it with a Makefile and then uploading the resulting .hex file into the AVR part using an Atmel avrispmkii (real one, not a clone).

I know the part has "memory lock bits", but I don't exactly get WHICH bits to set or clear to get what I want.

That's what I'm asking.

CrossRoads:
The only way I know how is to use a Programmer, and then Atmel Studio to set the Lock Bits.

The IDE can set the lock bits, you can see them in boards.txt. I don't know if/when the IDE does anything with those outside of burning the bootloader.
Or avrdude commands, I've not figured out how to do that myself.

All I need to know (actually all I need to UNDERSTAND) is how to properly use the lock bits on an AVR part (which should, I assume, have nothing to do with what IDE or programmer I use)... as long as I know which bits to set or clear in the lock fuse, I can do it.

Your code is safe from corruption due to power on/off because that’s what the prom does and why it’s used. There are only two ways to change it Via an ISP or via the bootloader. Powering it off and on makes no difference!

Mark

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”.

CrossRoads:

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.