What is preferable for storing parameters FLASH or on-chip EEPROM ?

Hi All, Where it is preferable to store log/history parameters: in FLASH or in on-chip EEPROM ?

I am using AT89C51ED2 8-bit MCU from Atmel. It has 2k EEPROM on-chip and 64kB Flash. EEPROM programming features:

1) On-chip 2048 Bytes EEPROM. 2) Supports only Byte programming ( no page programming). 3) Programming of each byte 10msec-17msec(Atmel says). 4) 100K write cycles.

Flash programming features:

1) 64Kb Flash, organized in 512 pages of 128 bytes. 2) Byte or Page erase and programming (10msec) 3) 100K write cycles.

My code takes about 30kB in Flash.So half of Flash is empty. The parameters which should be maintained in non-volatile memory take about 30bytes.

It seems to me that using Flash for storing log data is preferable in this case than using EEPROM. The main reason is that programming 30 bytes in EEPROM takes more than 300 msec whereas programming 30 byutes in Flash takes only 10 msec! And if data grows up to 128 bytes it still remains 10 msec when using Flash.

The only disadvantage is that care must be taken when programming Flash to not erase the log area. And except this I don't see any problem using Flash.

What do you think of it?

Reply to
yossi_sr
Loading thread data ...

Generally it is better to use EEPROM when you need to modify bytes individually or in small groups because they can be erases that way. If you want to save a single block of about 30 bytes in one go, as you say, then writing to Flash is a good idea. Normally with flash you'll erase a large block then write updates marching up the block. In this case you only need to erase the Flash when the block is exhausted. It does mean that you need to scan for the latest block. The big advantage is the you can write many more times because your not reusing the same addresses very often.

Peter

Reply to
Peter Dickerson

I can't speak for the Atmel, but most processors can't execute from the flash while they are programming or erasing it. In the case of thge MSP4309, it just executes NOPS until the flash is ready. Others might be different. If you need to keep on working while the flash is being updated, you'll have to run a patch from RAM.

Paul Burke

Reply to
Paul Burke

Hi Peter, My approach is to be flexible whether I want to update all 30 bytes or just some of them or even one byte.As most log parameters are int ( 2 bytes) , updating only one parameter will result in writing

2 bytes.If using EEPROM any byte writing will result in factor *10msec. Data log array ends with checksum on all data, so updating any of parameters in the block results that the checksum must be recalculated and updated too.

Reading the Flash bytes is very quickly, I think it is the same as reading from EEPROM so reading log data is not the issue.

In case when using Flash,'read modify write' method may be performed by reading even all 30 bytes, changing whatever needed and then writing back all data in 10 msec.

Important to note that log data holds errors which occured in the system,they are not so frequent so there is no question of reaching the 100k write cycles limit at all.

In the supplied by Atmel write_flash(address, buffer , size) function,the size parameter is how many bytes to program. If size=1 only one byte is programmed leaving all remaining bytes of the same page in Flash unchanged. I hope that Atmel's programming algorithm does not reprogram the remaining bytes of this page with the same data. So lifetime and 100k write cycles limit is the same regarding page or byte writing.

I am still thinking that using FLASH is preferable than using EEPROM in this case.

What do you think?

The question is whether there exist any other problems in using Flash which I currently don't see.I didn't make the coding yet so your advice may be helpful to me. Regards.

Reply to
yossi_sr

In general, flash is very suitable in a case like this, when only block writes are necessary.

For example, in automotive engine controllers there are "freeze frames" of diagnostic information which are written to flash memory each time the driver switches the key off (this is required for OBDII, on-board diagnostics). All freeze frames combined can be several kB long.

A double-buffer strategy is used for the freeze frames, i.e. there are two areas reserved in flash. The freeze frames are alternately written to each area. Ex: key-off 1 -> flash A; key-off 2 -> flash B; key-off

3 -> flash A; key-off 4 -> flash B; ...

I'm not sure how robust you're code needs to be, so maybe you don't need the double buffer.

The RAM comment was a good one too. You'll have to copy your flash programming algorithm to RAM and jump into it before you can program flash.

One other word of caution: check the lifetime write cycles supported by your flash memory. Sometimes internal flash memory can't handle a high number of writes before it starts to fail (only 100 writes on an MPC565 for example). External flash memory often has write cycles in the

100k's.

Tony Barrett

Reply to
tbarrett

Atmel's AT89C51ED2 cannot be operative when programming the code which is in Flash, but when programming byte or page as part of data the software waits 10msec meaning that no other code can be executed. No need to run a patch from RAM.

EEPROM has an advantage over Flash in that you can write the byte to EEPROM and continue to execute the code(the next write will have to check the BUSY flag and if busy to wait until programming is done).

Nothing critical in my system if for writing log parameter from time to time the system will be disabled for 10 msec. Not so nice, but tolerable. Still I think the Flash has advantage over EEPROM to hold data.

Yossi

Reply to
yossi_sr

It should be noted that during Flash programming(byte/page

- takes 10msec),the 89C51ED2 MCU interrupts are disabled.

So this is the first major disadvantage which I find when comparing FLASH or EEPROM choice for storing log parameters in favor to EEPROM.

If someone doesn't care loosing interrupt during Flash programming,then Flash for storing log data may still be preferred over EEPROM. In my system most of log parameters cause the system to shutdown, updating in log the parameter which caused shutdown so loosing interrupts in this case is meaningless.

Yossi

Reply to
yossi_sr

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.