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?

"yossi_sr" <YSrebrnik@kinetics.co.il> wrote in message
news:1121150722.999112.263590@g44g2000cwa.googlegroups.com...
> 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?

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

yossi_sr wrote:

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

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

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.

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

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

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