ATmega168 Lock Bits???

Forum 2005-2010 (read only) General Frequently-Asked Questions
1

I spent three to four hours spread out over he last couple of days trying to figure out Fuse and Lock Bits on the '168.

I am doing some work for a client who will ultimately be burning the code into 50 chips on 50 boards going into 50 black boxes going out to 50 places. For any number of good reasons, plus a little paranoia, he doesn't want the chips reprogrammed or readable.

I have been told that in my old PIC parlance there is a lock bit setting that essentialy turn the 168 into an "OTP" - one time part, not reflashable and also 'not verifiable' which essentially means not readable ... I just cannot make sense of the Atmel documentation.

Can anyone give me a push in the right direction? Please don't say read pp350-380 in the datasheet, I HAVE and it doesn't make any kind of clear statement that I can wrap my thick Irish skull around!

thanks in advance for any help .... cheers ... BBR

2

I think you just want to set the two lock bits (LB2 and LB1) to 0. According to the datasheet, in this mode: "Further programming and verification of the Flash and EEPROM is disabled in Parallel and Serial Programming mode. The Boot Lock bits and Fuse bits are locked in both Serial and Parallel Programming mode." Of course, you don't want to have a bootloader that can rewrite your application, so if you're using one, you'd want to remove it or set the bootloader lock bits accordingly.

3

Brian, I just flashed my NG (m168) to Diecimila last week, this is the command I used (found elsewhere on this forum):

tools\avr\bin\uisp -dpart=ATmega168 -dprog=dapa -dlpt=0x378 --wr_lock=0x3F
tools\avr\bin\uisp -dpart=ATmega168 -dprog=dapa -dlpt=0x378 --wr_fuse_h=0xDF --wr_fuse_l=0xC7 --wr_fuse_e=0xF8
tools\avr\bin\uisp -dpart=ATmega168 -dprog=dapa -dlpt=0x378 --erase --upload if=bootloader168\ATmegaBOOT_168_diecimila.hex -v
tools\avr\bin\uisp -dpart=ATmega168 -dprog=dapa -dlpt=0x378 --wr_lock=0xCF

In this instance I used 0x3F and 0xCF, respectively. Is that any help?

Tim

4

OK, so I see lock values being written at the start and end of burning a bootloader ... 0x3F at the start and 0xCF at the end.

Now 0x3F means BLB11 and BLB12 are 00 (programmed) and SPM cannot write to bootloader section ... then 0xCF has BLB11 and BLB12 unprogrammed and it means SPM can write to Bootloader .... if you are burning a Bootlader isn't that backwards????

I just looked in preferences.txt for Arduino 0009 and it says the "unlock bits" for ATmega 168 are 0x3F .. and we know that works ... so the question remains, can someone re-explain this so it makes sense.

... while I am still on a roll, clearing (making 0) the bottom two bits gives me my write protect, read lock, so 0x3F becomes 0x3C and /or 0xCF becomes 0xCC. the question is when I setup an AVRDUDE run to burn the sketch, when do set LB1 and LB0 to what I want, at the end in the "lock" stage?

And ultimately what do I do to burn a sketch, sans bootloader? How do I tell teh Ateml to run the sketch, don look for the Bootloader?

5

Hi,
never tried it but for

And ultimately what do I do to burn a sketch, sans bootloader? How do I tell teh Ateml to run the sketch, don look for the Bootloader?

http://www.arduino.cc/en/Hacking/Programmer
Eberhard

6

Hi,
never tried it but for

And ultimately what do I do to burn a sketch, sans bootloader? How do I tell teh Ateml to run the sketch, don look for the Bootloader?

http://www.arduino.cc/en/Hacking/Programmer
Eberhard

OK, I went there an read that, and it says at the end

AVRISP mkII

If you have an AVRISP mkII, you'll need to burn your sketches outside the Arduino environment. You can use a program like avrdude, avrstudio, or winavr. To generate the .hex file that you'll be burning, press the upload button in the Arduino environment. The .hex file will be saved in the applet sub-directory of the sketch's directory (which you can find by selecting Show Sketch Folder from the Sketch menu of the Arduino environment).

So what do I do, generate an avrdude sequence like I was burning a Bootloader with unlock, set fuse bits, burn program, and lock??? Do I achieve my 'no further programming and no verifying' by writing the Lock Byte as 0xCC instead of 0xCF ??

Another thing puzzles me it says that if you burn the Sketch directly you ge all 16K instead of the 14336 ... how do you tell the chip that the sktech owns all the real estate ... that there's no bootloader ... are there additional bits to be set/unset

7

That sounds right, but I've never tried it.

8

That sounds right, but I've never tried it.

what about the sketch part of it, do I have to tell it anything to get the sketch to execute, or if I wanted a larger (than 14336) sketch do I need to tell it to use Bootlaoder space somehow?

BBR

9

what about the sketch part of it, do I have to tell it anything to get the sketch to execute, or if I wanted a larger (than 14336) sketch do I need to tell it to use Bootlaoder space somehow?

I should have taken better notes on a project I did a couple of months ago.

The bootloader is at the top of program memory (so all programs start at 0). IIRC, the Arduino IDE doesn't want to overwrite the topmost memory so as to not overwrite the bootloader. When using avrdude and a programmer (I used the avrispmkII), avrdude doesn't care. I clicked "upload" in the IDE, then used avrdude to flash the resulting .HEX file to the ATmega. avrdude happily overwrote the space where the bootloader would have been.

I think there are fuses for the bootloader (so that an apporpriate jump occurs at startup?), but I don't remember what I did about those fuses. Like I said, I should have taken notes, but I ran into a serious snag and ran out of time on the project, so documentation was the first thing to go. :expressionless:

-j

10

I don't think you need to worry about the fuse settings (at least I don't remember changing them). I've uploaded the .hex files created by the Arudino IDE with the standard fuse settings and not had any problems. I may try it again later if I get some time.

When the chip is powered it will simply start your sketch immediately.

11

I dont figure out if this thread is still open and the first question was really andwered.
I had the same problem to protect the software in an arduino to prevent reading the sketch.
And this is what i do:

  • i burn the sketch into the arduino board and test it.
  • if it works, i set the lock bits from 0xCF to 0xCC (which sets the lock bits to 0) with:

tools\avr\bin\uisp -dpart=ATmega168 -dprog=dapa -dlpt=0x378 --wr_lock=0xCC

I tried to download the FLASH content before and after setting the lock bits. Before setting them,
i could read the sketch. But afterwards, it returns "artificial" content. So it is protected!
And it is NOT possible, to "reset" the lock bits.
That means if i need to burn a new sketch, i have to throw away the 168 and take a new one...
But the Arduinos go to customers and i dont hope i will see them again :wink:
Regards,
Bernhard

12

And it is NOT possible, to "reset" the lock bits.
That means if i need to burn a new sketch, i have to throw away the 168 and take a new one...

I was under the impression that if you did a full chip erase then the lock bits were reset (but obviously the whole chip is erased)?

I had a very quick look online for something that said this, but didn't find anything.

--Phil.

13

Anyway to just make it so you can't read... I still want to be able to write.