topic EEPROM usage 9S08DZ32 for byte-wise writes in 8-bit Microcontrollers

EEPROM usage 9S08DZ32 for byte-wise writes

Cantalis — Sat, 11 Jul 2009 16:34:23 GMT

Hello,

in a software migration project 68HC05X16 to 9S08DZ32 I have to

implement a scheme for 'byte-wise' writes to EEPROM (as it was

possible with HC05, which had 256 byte of EEPROM).

9S08DZ has 1024 bytes of EEPROM with an erase size of 8 bytes

at once. To write to an individual byte I first have to erase 8 bytes

and then restore 7 of them because only 1 byte needs to be changed.

Now my question:

Is it possible to program a (already programmed) byte without a prior

8-byte-erase if I only want to reduce the number of 1-bits in that byte?

(example of what I would like to do: after erase the byte is 0xFF, then I

program it with 0xC3, then I program it with 0x82h, which is a 1->0 transition

for bit 6 and for bit 0)

Data sheet (MC9S08DZ60 Series Rev.4, page 54) says:

"NOTE Before programming a particular byte in Flash or EEPROM,

the sector in which that particular byte resides must be erased

by a mass or sector erase operation"

This looks like the 1-->0 transition requires in all cases a

previous erase operation.

Does anyone have experience with this issue?

Regards

-Roland

Re: EEPROM usage 9S08DZ32 for byte-wise writes

kef — Sun, 12 Jul 2009 15:31:34 GMT

Is it possible to program a (already programmed) byte without a prior
8-byte-erase if I only want to reduce the number of 1-bits in that byte?
(example of what I would like to do: after erase the byte is 0xFF, then I
program it with 0xC3, then I program it with 0x82h, which is a 1->0 transition
for bit 6 and for bit 0)

It is possible, but programming erased byte to 0xC3, then programing it with 0x82 IS NOT writing more zero bits, but programming bits 1 and 7 from '1' to '0' AND STRESS OVERPROGRAMMING bits 3-6! This can kill your eeprom, even on your old HC05.

Re: EEPROM usage 9S08DZ32 for byte-wise writes

Cantalis — Sun, 12 Jul 2009 17:16:33 GMT

Kef, thanks for your answer.

We did not do that even in HC05. It only came to my mind as a *possible* way to reduce the number of total erases. I remember in the 'old days' we did that with EPROMs (without having to UV erasing them through the window) or OTPs.

I conclude from your answer that the way of "least stress" is indeed erasing the 8-byte-sector prior to any programming (no matter what the bit transitions are). The steps for programming a byte are then in any case:

1. Backup 8 bytes

2. Ersase 8 bytes

3. Update the new byte into the backup-buffer

4. Write backup buffer to original (now erased) 8 byte sector

(The only special case would be the value 0xFF, which does not need to be written to a freshly erased byte)

Is this the way you would do it?

Regards

-Roland

Re: EEPROM usage 9S08DZ32 for byte-wise writes

kef — Sun, 12 Jul 2009 19:46:46 GMT

Indeed I miscalculated bit numbers, sorry. I meant "but programming bits 0 and 6 from '1' to '0' AND STRESS OVERPROGRAMMING bits 2-5!"

Writing more '0' bits should work on DZ32, though it's highly not recommended. Like datasheet says, "NOTE Before programming a particular byte in Flash or EEPROM, the sector in which that particular byte resides must be erased by a mass or sector erase operation"

But if you can't resist not trying to write without erase, then write more '0' bits should can be done in two steps:

1) check if you can program to desired state. if((desired & actual) != desired) then erase is required

2) value to be programmed to EEPROM has to be calculated like this:

data_to_write = ~(desired ^ actual);

For example actual value in EEPROM is 0xC3. Desired value is 0x82. data_to_write is 0xBE. As you may see, 0xBE has only two '0' bits, only in those bit positions, which must be reprogrammed in 0xC3 from '1' to '0'.

Since DZ , as you say, has 1kB EEPROM, you may try to sector align every data item.

EEPROM = NO_INIT aaaa TO bbbb ALIGN 8;

That's up to 1024/8 = 128 8-byte-sector aligned items. To update single item, you erase and reprogram just this single item.

Updating all 8 bytes at once isn't the best approarch, but it is very simple and thus may save precious code space.