EEPROM usage 9S08DZ32 for byte-wise writes

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

EEPROM usage 9S08DZ32 for byte-wise writes

1,719件の閲覧回数
Cantalis
Contributor I

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

ラベル(1)
0 件の賞賛
返信
3 返答(返信)

612件の閲覧回数
kef
Specialist I

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.

 

0 件の賞賛
返信

612件の閲覧回数
Cantalis
Contributor I

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

0 件の賞賛
返信

612件の閲覧回数
kef
Specialist I

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.

0 件の賞賛
返信