Chip Erase to Clear Lock bits--Serial or Parallel (HV)?

Log in or register to post comments
Go To Last Post
11 posts / 0 new
Author
Message
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
#1
Posted by davethomaspilot: Sun. Mar 22, 2015 - 05:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm thinking about using some lock bits on an Atmega 328p.   For some of them, the spec states they can only be cleared via a chip erase

 

A chip erase can be done using either serial or parallel programming, so I assume I can always do a chip erase to reprogram the device over SPI, as long as I didn't change the SPIEN fuse.  

 

Is this correct?  I can always clear everything over SPI, as long as SPI is enabled?  I just want to make sure before I "brick" some boards.

 

Also, it seems I can't quite get the protection I'd like on the 328p.

 

 I'd like to keep self-programming enabled so my boot-loader could load new code but have memory read over SPI disabled.  It looks like the only way to have SPI read disabled is to disable SPI entirely.  Which means I can no longer program the chip, since the cards don't have the hardware for parallel programming.

 

Is this a correct understanding?  Also, please no comments about the futility of trying to protect Atmega firmware.  There are plenty of posts elsewhere, and that's not the intent of the protection anyway.

 

 

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29156 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Sun. Mar 22, 2015 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The lock bits get cleared with either programming method. They get cleared after Flash and EEPROM are erased by the erase function, you don't even need to do anything special.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Sun. Mar 22, 2015 - 08:29 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply.

 

Am I right including there's no way to disable read by SPI without disabling SPI entirely.  It would be nice if the Chip Erase SPI command would work, but not the memory access commands....

 

Also, I think "disabling SPI" doesn't disable communication between the atmega and any SPI peripherals.  It just doesn't recognize the SPI commands, right?

 

Thanks!

Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Sun. Mar 22, 2015 - 08:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It just doesn't recognize the SPI commands, right?

 I should have said something like:

 

The SPIEN fuse only disables in system programming of the Atmega via the SPI interface.  It does not affect the ability of the Atmega to communicate using SPI to a peripheral on the SPI bus.

 

Is this correct?

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29156 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Mon. Mar 23, 2015 - 02:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am I right including there's no way to disable read by SPI

Not right smiley that's exactly what the lock bits do.  If the chip is locked then you can still "read" the chip but you get rubbish not real code.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97919 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Mar 23, 2015 - 10:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the chip is locked then you can still "read" the chip but you get rubbish not real code.

Further to that. Actually wire up your ISP to an AVR. Program it, set the lock bits then use ISP to read it back. Sure you will get a .hex file but it won't show what you programmed into the AVR. I seem to remember you get a .hex file that is the low byte of the word address of each location so you will see:

 

00 00 02 02 04 04 06 06 08 08 0A 0A 0C 0C 0F 0F

...

 

in the .hex file. Clearly this is NOT code for an AVR and is of no use to the "hacker" who might have tried to read it out of your design.

 

In theory there's no way they can get access to the actual opcodes in there - the only ISP operation that would make any sense to them is either erase or program (which includes erase) so your code is safe inside.

 

Having said that - if you send the chip and $500 to some places in the Far East they will send you back a hex file of what was in it. They are able to break the lock bits. I believe the way they do this is use fluoric acid to melt off the top of the chip then I thin kthey use a laser to change the charge on the gate of the lockbit transistor and hence unlock the flash contents that can then be read out normally.

 

So lockbits are protection against idle snoopers but if a commercial competitor wants to clone your million selling design they are only ever $500 away from achieving that. So don't put too much faith in lockbit protection.

Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Mon. Mar 23, 2015 - 11:20 AM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, that's perfect, but that's sure not obvious from the datasheet.  

 

I saw this:

 

The user can select:

 

 To protect the entire Flash from a software update by the MCU.

 To protect only the Boot Loader Flash section from a software update by the MCU.

 To protect only the Application Flash section from a software update by the MCU.

...

and figured the phase  "by the MCU" was key.  I was thinking ISP using an SPI connected device was different.

 

Also, the BLB lock bits referenced in table 27-5 in the Atmega328p datasheet restrict access of SPM (Store Program Memory) and LPM (Load Program Memory) instructions.  It says nothing about them restricting access via ISP commands.

 

I guess if one assumes the MCU is using LPM and SPM instructions to implement ISP, then it makes sense, but I couldn't find anywhere in the spec where it explictly says ISP over SPI can be disabled while preserving the ability to "start over" with an ISP chip erase. 

 

 

 

 

Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Mon. Mar 23, 2015 - 11:42 AM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll try reading back after setting BLB lock bits!  Thanks!

 

 

 

Thanks!

 

 

Last Edited: Mon. Mar 23, 2015 - 06:10 PM
Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Mon. Mar 23, 2015 - 07:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, on the Atmega 328p the BLB (Boot Lock Bits) seem to have NO affect on ISP programming using SPI.  I could read flash back with no issues.

 

However, I'd missed that two additional lock bits (LB) exist, LB1 & LB2.  These are the ones that deal with limiting access in Serial and Parallel programming modes.  

 

When verify is disabled using lock bit LB2, 0xFF is read for every flash location, not the low byte of the address.

 

So, this is EXACTLY what I need to protect the  keys that are used to validate paid subscription updates. 

 

Thanks!

 

 

Top
david.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 29424 View posts
Location: Wormshill, England
Posted by david.prentice: Mon. Mar 23, 2015 - 07:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, on the Atmega 328p the BLB (Boot Lock Bits) seem to have NO affect on ISP programming using SPI.  I could read flash back with no issues.

Think about it.    Avrdude and many other programming software will erase the AVR first,   before programming the flash.

 

Look at AS4 or AS6 defaults.    However,   you can generally disable the "erase first" behaviour.    A bit pointless.    If the lockbits are set,  you can't program or verify.    If the lockbits are not set,   a dirty flash will prevent the 'new program' leaving a clean image.

 

David.

Top
davethomaspilot
davethomaspilot's picture
Level: Hangaround
Joined: Tue. Dec 22, 2009
Posts: 442 View posts
Location: Raleigh, NC
Posted by davethomaspilot: Mon. Mar 23, 2015 - 07:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you missed my last point.  My initial question was about the BLB bits and asking if my assumption about how they worked was correct and how I couldn't do what I wanted with them.

 

What I assumed was actually TRUE, but I missed the existance of the additional LB1 and LB2 lock bits, which were what I really needed (in addition to the BLB bits).

 

I don't really care whether or not the chip is erased before programming via ISP, but I understand  I have to do the chip erase to undo lock bit setting.

Top