Lock Bits - Tiny45

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

I've noticed on the Tiny25/45/85 that if you enable the lock bits that it locks the EEProm as well. Is there anyway to protect the flash contents while still allowing the EEProm to be modified by the program?

This is a serious problem as I don't want my flash contents to be read by 3rd partys, but I need access to the EEProm to store some programming options.

If either of the lock bits are set my program is not able to store new EEProm values!

EDIT: I've only had this problem on the Tiny45, I've never tried used a 25 or 85.

Thank you,

--------------------------------
Kevin Pierson

Last Edited: Mon. Mar 12, 2007 - 03:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

still allowing the EEProm to be modified by the program?

Quote:

If either of the lock bits are set my program is not able to store new EEProm values!

If by "program" you mean your firmware, then that is simply not true. The firmware can read, write, and erase EEPROM cells at will regardless of the lock bit settings.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
I don't want my flash contents to be read by 3rd partys
...of course this is dependant on how valuable your code is to a 3rd party it seems...I don't use the T45 but it isn't a problem with the Mega8, I have mode 3 fuses set and can still modify EEPROM parameters, perhaps it is a new feature??

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The code might not have any value to a 3rd party, but it is intended to be used in a commercial application.

I don't have any lock problems with the Tiny12, but I have had this problem on multiple Tiny45 projects. I can lock the Tiny12 and still store stuff to the EEPRom.

The data sheet itself shows that if either Lock mode is programmed that the EEProm is locked.

From Data Sheet:

LB Mode 1 (LB2:1, LB1:1) No memory lock features enabled.

LB Mode 2 (LB2:1, LB1:0) Further programming of the flash and EEProm is disabled in High-voltage and Serial Programming mode. The Fuse bits are locked in both Serial and High-voltage Programming mode.

LB Mode 3 (LB2:0, LB1:0) Further programming and verification of the Flash and EEPROM is disabled in High-voltage and Serial Programming mode. The Fuse bits are locked in both Serial and High-voltage Programming mode.

Its strange to me though because it says that it should be locked only to external programming, yet I can NOT store my EEProm data in either Mode 2 or Mode 3.

In Mode 2 and in Mode 3 the program works perfectly, but the firmware can not change any programmable options that are stored in the EEProm. If I go back to Mode 1 the program works perfectly and the firmware is able to program data in the EEProm with out any issues.

Any ideas?

Thank you,

--------------------------------
Kevin Pierson

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

So, what does your data sheet show for Tiny45 errata? ;) You need to stop using these "spoiled" chips:

Quote:

30.2 Errata ATtiny45
The revision letter in this section refers to the revision of the ATtiny45 device.
30.2.1 Rev E
No known errata
30.2.2 Rev D
• Reading EEPROM at low frequency may not work for frequencies below 900 kHz
1. Reading EEPROM at low frequency may not work for frequencies below 900 kHz
Reading data from the EEPROM at low internal clock frequency may result in wrong data
read.
Problem Fix/Workaround
Avoid using the EEPROM at clock frequency below 900kHz.
30.2.3 Rev B and C
• PLL not locking
EEPROM read from application code does not work in Lock Bit Mode 3
• Reading EEPROM at low frequency may not work for frequencies below 900 kHz
• Timer Counter 1 PWM output generation on OC1B- XOC1B does not work correctly
1. PLL not locking
When at frequencies below 6.0 MHz, the PLL will not lock
Problem fix / Workaround
When using the PLL, run at 6.0 MHz or higher.
2. EEPROM read from application code does not work in Lock Bit Mode 3
When the Memory Lock Bits LB2 and LB1 are programmed to mode 3, EEPROM read does
not work from the application code.
Problem Fix/Work around
Do not set Lock Bit Protection Mode 3 when the application code needs to read from
EEPROM.
3. Reading EEPROM at low frequency may not work for frequencies below 900 kHz
Reading data from the EEPROM at low internal clock frequency may result in wrong data
read.
Problem Fix/Workaround
Avoid using the EEPROM at clock frequency below 900kHz.
4. Timer Counter 1 PWM output generation on OC1B – XOC1B does not work correctly
Timer Counter1 PWM output OC1B-XOC1B does not work correctly. Only in the case when
the control bits, COM1B1 and COM1B0 are in the same mode as COM1A1 and COM1A0,
respectively, the OC1B-XOC1B output works correctly.
Problem Fix/Work around
The only workaround is to use same control setting on COM1B(1:0) and COM1B(1:0) control
bits, see table 14-4 inthe data sheet. The problem has been fixed for Tiny45 rev D.

Not exactly your situation but close enough that I'd be suspicious. [NB: I had no probem with a Tiny25 app; I don't have any '45s to try.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
Any ideas?
:? :roll: not anymore than you do. Perhaps you have discovered an "undocumented feature", we will need input from other users of the T45 it seems.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Interesting, I didn't see that. Come to think of it, I don't beleieve I've ordered any Tiny45s in the past 6 months, so they are all older. I'll order a few new ones to play with and see if the problem fixes itself.

Thanks!

theusch wrote:
So, what does your data sheet show for Tiny45 errata? ;) You need to stop using these "spoiled" chips:
Quote:

30.2 Errata ATtiny45
The revision letter in this section refers to the revision of the ATtiny45 device.
30.2.1 Rev E
No known errata
30.2.2 Rev D
• Reading EEPROM at low frequency may not work for frequencies below 900 kHz
1. Reading EEPROM at low frequency may not work for frequencies below 900 kHz
Reading data from the EEPROM at low internal clock frequency may result in wrong data
read.
Problem Fix/Workaround
Avoid using the EEPROM at clock frequency below 900kHz.
30.2.3 Rev B and C
• PLL not locking
EEPROM read from application code does not work in Lock Bit Mode 3
• Reading EEPROM at low frequency may not work for frequencies below 900 kHz
• Timer Counter 1 PWM output generation on OC1B- XOC1B does not work correctly
1. PLL not locking
When at frequencies below 6.0 MHz, the PLL will not lock
Problem fix / Workaround
When using the PLL, run at 6.0 MHz or higher.
2. EEPROM read from application code does not work in Lock Bit Mode 3
When the Memory Lock Bits LB2 and LB1 are programmed to mode 3, EEPROM read does
not work from the application code.
Problem Fix/Work around
Do not set Lock Bit Protection Mode 3 when the application code needs to read from
EEPROM.
3. Reading EEPROM at low frequency may not work for frequencies below 900 kHz
Reading data from the EEPROM at low internal clock frequency may result in wrong data
read.
Problem Fix/Workaround
Avoid using the EEPROM at clock frequency below 900kHz.
4. Timer Counter 1 PWM output generation on OC1B – XOC1B does not work correctly
Timer Counter1 PWM output OC1B-XOC1B does not work correctly. Only in the case when
the control bits, COM1B1 and COM1B0 are in the same mode as COM1A1 and COM1A0,
respectively, the OC1B-XOC1B output works correctly.
Problem Fix/Work around
The only workaround is to use same control setting on COM1B(1:0) and COM1B(1:0) control
bits, see table 14-4 inthe data sheet. The problem has been fixed for Tiny45 rev D.

Not exactly your situation but close enough that I'd be suspicious. [NB: I had no probem with a Tiny25 app; I don't have any '45s to try.]

Lee

--------------------------------
Kevin Pierson

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

I did some searching in the Errata and found my exact problem - 29.2.3/2: EEPROM read from application code does not work in Lock Bit Mode 3. Problem Fix/Work Around: Do not set Lock Bit Protection Mode 3 when the application code needs to read from EEPROM.

This is for Rev B and C chips, Rev E has no known issues. How do I know what Rev my chip is? How do I make sure I get Rev E chips when I reorder? There is a 4 digit number on the top of the chip (0532) and a bunch of numbers/digits on the bottom of the chip (C1, 1P, 5G3, 792, 05, 32).

Thank you again,

--------------------------------
Kevin Pierson

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

Hello!

 

I would also like to lock the tiny45, but only, if the user "from outside" wants to change the e2prom value, indeed, I want the e2prom to be preserved, but not only by the fuse in case of deleting...

 

I am working in AVRDude and it seems that my call does not work, because I can still upload a new program, change the fuse, etc. no matter, if I apply "further programming and verification disabled": 

avrdude -p t45 -c usbasp -U lock:w:0xFC:m

 

The return from AVRdude in terminal is as follows:

 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9206
avrdude: reading input file "0xFC"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xFC:
avrdude: load data lock data from input file 0xFC:
avrdude: input file 0xFC contains 1 bytes
avrdude: reading on-chip lock data:

Reading |                                                    | 0% 0.00savr_read(): error reading address 0x0000
    read operation not supported for memory "lock"
avrdude: failed to read all of lock memory, rc=-2

avrdude: safemode: Fuses OK (H:FF, E:D7, L:E2)

avrdude done.  Thank you.

I would understand that reading after locking is not working, possible... I do also understand that the e2prom is left unchanged due to the fuse (preserve the e2prom) however, I do not understand that I can change the value if e2prom via AVRdude terminal, which means I can fiddle with the value , namely inside the avrdude in terminal: 

avrdude> write eeprom 0 1

and that would change my e2prom that the firmware inserted, recorded while working...

 

Indeed, my program works and writes the number into the e2prom, however, I would like to keep this number safe, without being changed, etc. Of course, I can preserve it from deleting with the fuse, but how to protect the e2prom from being changed from outside and not by my firmware ?

 

Sorry, if what I am saying is rubbish, need to start somewhere.

 

Thanks in advance.

 

 

 

 

 

 

 

 

Bravo!!!