EEPROM access on locked tinyAVRs

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

On the xtiny datasheets memory access table (I'm seeing the attiny 402 datasheet DS40001969A, table 6-6), it shows that when the memory is locked (by fuse.lockbit) to disable reads over UPDI, the EEPROM is also locked for writing by the UPDI, which is fine. However, it shows that even the CPU cannot write to the EEPROM, which I find quite strange - why would the CPU writing to EEPROM be restricted, would it not make the EEPROM pretty pointless for storing non-volatile data in a code-protected chip if data could not be written, just read? I understand the USERROW is present and is writable, but what if that is not enough space, or if I need CHIPERASE to remove EEPROM data also?

-Sam

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

samay wrote:
why would the CPU writing to EEPROM be restricted,

Simple.  Lets say that during production the manufacturer loads the EEPROM with data they do not want written over inadvertently.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I've never considered the lock bits to be too useful...if someone really wants the code they will get it.  If they get the code, I don't care too much anyhow, there is too much other stuff (chips, circuits etc) needed to make it useful.  Maybe if someone was going to go all out and produce 5 million bed shakers, or shipwreck finders, then I'd be locking things down.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

At least, the lock bits protect my products locally. Around me, there are experts in duplicating the boards (hardware) if they get the code (firmware).

On the other hand, I doubt that any rich group abroad would be interested to trust the work of an unknown engineer as I and try to unlock my code smiley

And in case, the idea of a product is copied, this gives me a good reason to quickly update it by providing more functions for the same price or by finding a better design to lower its cost/price. 

 

Sometimes, since I have to use ATmega8, I lock its EEPROM bytes (not supposed being changed later by the user) in my code by sensing, for example, a pin shorted to ground at boot. In this case, all EEPROM writing functions are skipped.

 

    

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

Keep in mind the OP is asking why one would lock the CPU from WRITING to the EEPROM. Not code protection.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

@SAM,

 

Perhaps to protect a look up table.

Ross McKenzie ValuSoft Melbourne Australia

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

Or maybe an encryption key. Being able to set it to 0 defeats the purpose methinks..

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

I wouldn't take that table as a 'truth' table, as they can contain errors just like the rest of the datasheet.

 

The device can be locked so that the memories cannot be read using the UPDI. The locking protects both
the Flash (all BOOT, APPCODE, and APPDATA sections), SRAM, and the EEPROM including the FUSE
data. This prevents successful reading of application data or code using the debugger interface. Regular
memory access from within the application still is enabled
.

 

The table may end up being correct, but the above paragraph in the datasheet seems to indicate the purpose is intended toward UPDI access, and also indicates nothing changes on the cpu side. It seems curious and odd the only bit out of place in that table would be the eeprom write access on the cpu side.

 

I'm skeptical and actually would be a little surprised if you could not write to eeprom from the cpu, but a simple test would verify either way. Maybe I'll try.

 

edit-

go to a mega4809 datasheet and the eeprom is YES on cpu write in lock mode, some other tiny's don't even have a table and just indicate updi access is restricted

Last Edited: Sat. Dec 28, 2019 - 06:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Yes, I had thought as much - that the table might be wrong. 

On trying it practically, I can confirm that this does seem to be the case - CPU writes to EEPROM on a locked device (tiny402) are working as expected. 

As for locking being useful, company policy is that all embedded code in production must be protected, so that's that as far as I'm concerned.

Thanks, everyone.

-Sam