Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

The long run effect of storing data in code memory and its comparison with EEPROM

Status
Not open for further replies.

ucsam

Advanced Member level 4
Joined
Oct 12, 2010
Messages
119
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,298
Location
kathmandu,nepal
Activity points
2,058
Hi,

I want to develop a system, where user can enter number of username and password. Since, I use 89S52 and i want to store it in the code memory and retrieve it, but some of my colleges say that storing in CODE memory would bring problem in long run. Is that what happens? Is there anyone who has faced the same problem and got the solution. Since, I want the system for LONG run and i want it to be stable. Please let me know of any good solution.


Thank you!
 

Writing to code memory will reduce the life of the mcu, (may be the memory), it will be around 10,000 write/erase cycle for flash(depends on the endurance specified in the data sheet).
For eeprom, it will be around 100,000 write/erase cycles. (that also specified datasheet)
If you try write/erase in an infinite loop, u can see both flash and eeprom will get damaged.... May be I think this will be the reason you colleges told like that...
 

But i don't think i will be writing and erasing again and again. I will make the circuit, and the system will check the key that i entered with some key and decides other things. By WRITE do u mean, the action that microcontroller does to retrieve the data or the programmer does to download the firmware?
 

May be I missed something. Since when does 89S52 support flash self-programming?

So you won't be able to write data to code memory other than by an external programmer. In this case, there's unlikely a risk of extensive flash wear.
 
As FvM pointed out the AT89S52 does not support In-Application Programming (IAP) nor does it offer EEPROM storage.

Therefore, to implement a Read/Write storage for your passwords you will need to utilize external R/W storage of some type.

One option would be to implement a I2C (TWI) Serial EEPROM, they are relatively inexpensive and the I2C or TWI interface is well supported by the AT89S52.

Interfacing 8051 MCUs with I2C™ Serial EEPROMs

Interfacing AT24CXX Serial EEPROMs with AT89LP Microcontrollers


BigDog
 

I want the save the password in the code memory, but i want to know about the long run effects, I mean will there be any memory leaks.

FVM: Sorry bro, I didn't get what you mean too. We were talking about WRITE/ERASE not self programming. I was confused that everytime the system edits the varaible ie string in cide memory, will it effect the storage of variable in long run ?

bigdogguru: I want to minimize the cost as much as possible, thank you but, I don't
 

I didn't get what you mean too. We were talking about WRITE/ERASE not self programming. I was confused that everytime the system edits the varaible ie string in cide memory, will it effect the storage of variable in long run ?

I believe what both FvM and I are attempting to convey to you is the following:

You can store the password in Code Memory (FLASH), however you will NOT be able to change/alter the password, unless you change the password within your program code, recompile and then reprogram the device.

In other words the password will be a constant and unalterable from within the program during runtime.

I believe your confusion stems from the fact the variable you refer to in the above quote is stored in volatile RAM, NOT in nonvolatile FLASH (Code Memory). And of course, any variable stored in volatile RAM, will be LOST when power is lost or the system reset.

The main point, both of us are attempting to convey, is the AT89S52 does not support modification of Code Memory (FLASH) from within the program, otherwise known as In Application Programming (IAP).

If you require a nonvolatile read/write storage for the password, then the use of an external device, like a Serial EEPROM, will be necessary.

Or change the design to utilize a different MCU which does support IAP or has built-in EEPROM.


BigDog
 
  • Like
Reactions: FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
We were talking about WRITE/ERASE not self programming.
Self programming or in application programming (IAP) are different words for the same thing: Writing to the code memory while the processor is executing code, done by the processor itself. It's essentially a processor hardware feature, AT89S52 doesn't have it.

AT89S52 has in system programming (ISP), writing the code memory through a simple serial interface, but you need a second processor or computer to do it.

Because AT89S52 code memory can't be modified without connecting an external programmer, there's little risk to wear it somehow.
 

If, however, your concern is security of these passwords and wanted them to remain in the chip, then you'll have to find a part that supports writing to internal NVM. Or implement an encryption algorithm prior to sending it offchip.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top