Dear all,
I've searched the forum without luck. Is there a quick explanation between the different modes of lockbits. What do they do?
SPM
SPM and LPM
LPM
Basically I only what to protect my code from being read.
Thanks!
/Bjorn
bjornhi 
Lock bits
Author
Message
bjornhi 
curtvm You may have to be more specific, but if you want protection from reading you want to program LB1 and LB2 for LB Mode 3 ('external' protection).
(Notice the 'and verification' phrase added to the LB Mode 2 description to get to Mode 3)
If you have to protect the app/boot sections from each other ('internal' protection), then the BLB bits come into play.
zbaird
Level: Raving Lunatic
Joined: Sun. Aug 13, 2006
Posts: 7438 View posts
Location: Bellingham, WA - USA
The LPM and SPM refer to the assembly language opcodes used to access flash memory - Load Program Memory, or read, and Store Program Memory, or write. The relevant lock bits determine if and when the two instructions are allowed.
zhpaul 1.The FLASH security is based on two Memory Lock bits, LB2 and LB1 for the application section and BLB12 and BLB11 for the boot loader section, if your chip has a boot loader section.
2.When LB1 is programmed, all write accesses to the application section are denied. When both LB2 and LB1 are programmed, all write and external read accesses to the application section are denied. The similiar settings for the BLB12 and BLB11 bit applies to the boot loader section. When none of the Lock bits are programmed, there are no memory lock features enabled.
(Please note that “1” means unprogrammed and “0” means programmed.)
3.You can secure your firmware against external inspection by programming the Lock Bits.
4.You need read the datasheet in the 'Memory Programming' section for you specific chips for more specific information.
split63
I found the whole section in the data sheet on lock bits and especially the Application and Boot section locks bits to be less than clear.
I have 99.1% of flash consumed and I have no boot section. I found that when I set the lock bits, suddenly the code was corrupted. Upon trial and error I found that the BLB1 fuse if set to "LPM prohibited in the Boot section" was the source of the issue. I assume that this setting carved out a boot section and prevented reads... Why would you ever want to prevent reads (LPM)?
Writes (SPM) I get
To protect the code from prying eyes and to avoid potential power event corruption, I had to set the bits to:
LB: Further Programming and verification disabled
BLB0: LPM and SPM prohibited in App section
BLB1: SPM prohibited in Boot Section.
Does this seem right given no boot section?
If I set BLB1 to: SPM and LPM prohibited in boot section, code fails.
clawson 
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105140 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Quote:
I have 99.1% of flash consumed and I have no boot section
If you aren't using a bootloader then why on earth would you touch the lockbits anyway? You don't have to DO anything to use the flash space a bootloader might otherwise have occupied. If you have a 16K AVR (for example) that has 2K/1K/0.5K/0.25K potential BOOTSZ sections then unless you plan to set the BOOTRST fuse ignore that completely. You app can grow to 16K and just span the boundary with impunity.
rberger
Quote:
To protect the code from prying eyes and to avoid potential power event corruption, I had to set the bits to:
LB: Further Programming and verification disabled
BLB0: LPM and SPM prohibited in App section
BLB1: SPM prohibited in Boot Section.
LB: This is the fuse to program to protect against code reading.
BLB0: LPM and SPM prohibited in App section
This fuse will cause problems if you need to access tables etc in the flash memory. Just set the SPM fuse to prevent corruption of your flash memory unless you use the SPM instruction.
BLB1: SPM prohibited in Boot Section. I don't use a bootloader so i just program this to block SPM.
Ron.
Michael_from_SA
zbaird ... from this simple post you made, almost 9 years ago... I 100% understand the lock bits... thanks!
I take it you have some experience working in assembly? ... that's rare these days! 
Michael_from_SA
I can think of a use for the bootloader write protection.
Correct me if I'm wrong but say Im a hacker trying desperately to steal your code (supposedly because I lack the imagination and skills to write it myself)
I can always see the fuses with my atmel-ice (or similar) so I can tell if you are using a bootloader, and where it starts.
If you do not protect your application from the bootloader, I could write a "pseudo-bootloader" that simply reads each memory address in the application and fires it off down the serial port, effectively reading your application in some terminal.
Theoretically of course... 
Brian Fairchild
Michael_from_SA wrote:
...I could write a "pseudo-bootloader" that simply reads each memory address in the application and fires it off down the serial port, effectively reading your application in some terminal.
And how would you get your "pseudo-bootloader" into the AVR?
clawson
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105140 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Michael_from_SA wrote:
Sad to report that Chuck is no longer with us. He's probably watching from Heaven though ;-)
zbaird ... from this simple post you made, almost 9 years ago... I 100% understand the lock bits... thanks! I take it you have some experience working in assembly? ... that's rare these days!
JohanEkdahl 
Brian Fairchild wrote:
And how would you get your "pseudo-bootloader" into the AVR?
Why.. With a pseudo-pseudo bootloader, of-course! ;-)
Mostafa2942
God bless him. 
Cer_Matt
Hi,
I would like to prevent my arduino nano from being cloned.
Is this correct procedure:
First uploading sketch using Arduino ISP via usb cable.
Then using AVR-ISP-MK2 programmer in Atmel Studio
to set lock bits to:
LB: to Further Programming and Verification Disabled
bLB0: to LPM and SPM prohibited in Application Section
BLB1: to LPM and SPM prohibited in Boot Section
Thanks for the answer!