Lock bits

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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! yes

you never know until you try - (or read countless forum posts)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

you never know until you try - (or read countless forum posts)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michael_from_SA wrote:
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!
Sad to report that Chuck is no longer with us. He's probably watching from Heaven though ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
And how would you get your "pseudo-bootloader" into the AVR?

Why.. With a pseudo-pseudo bootloader, of-course! ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

God bless him. sad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!