S12X EEPROM emulated?

Started by joshcurtz January 18, 2006
So I've been using the S12XDP512 for quite some time and someone told
me that the Freescale folks said the EEPROM is not "real" EEPROM but
is actually an "emulated" EEPROM. He says this is the case because the
S12X's EEPROM is not byte eraseable and is based on "flash
technology". Does one really call this "emulated EEPROM"? I'm not sure
of the formal distinction between EEPROM and Flash if there is one so
I wanted input from others.

Thanks.



You've just run across another confusion in the historical progression of
"Read Only Memory", a subject that seems unnecessarily confusing.

The Answer to Your Question
---------------------------

Some of the Freescale documentation explains that the resource called
"EEPROM" in the HCS-12 data sheets is, in fact, the same technology used
for the resource called "flash". The design of the EEPROM resource is
optimized for many erase-write cycles, while the design of the "flash"
resource is optimized to take much less die area per bit at the expense of
fewer erase-write cycles.

If you look at the controller descriptions for these two resources, you
will see that they are nearly identical.

This is the origin of what you were told. I'm not sure that there is much
hope for getting precision in this area, see below. Another Confusion
-----------------

For additional confusion in HCS-12 parts, Freescale AN2400/D "HCS12 NVM
Guidelines" says:

>Most HCS12 microcontrollers also incorporate EEPROM that may be used to
>store data variables. HCS12 microcontrollers that do not have EEPROM may
>use Flash to emulate EEPROM, refer to application note AN2302/D for
>details and example software.

When it is referring to using the flash to store changing data on parts
without a separate "EEPROM" resource.

Which is a different kind of "EEPROM emulation". The History
-----------

This is merely the latest in a long line of confusions in naming this
technology progression.

It started with "Read Only Memory" (ROM), which was originally programmed
in manufacture and could not be changed.

Then the technology for making the memory write once was developed, and
these devices were called "Programmable Read Only Memory" (PROM) rather
than the self-contradictory and cumbersome "Write Once Read Only Memory".

Then the technology for erasing a programmed part with a strong dose of UV
light was developed, and was naturally called "Erasable Programmable Read
Only Memory" (EPROM).

Then the technology for electrically erasing the part appeared, giving us
the "Electrically Erasable Programmable Read Only Memory" (EEPROM).

Than the slow writing time was recognized as a problem and a faster write
and erase technology was called initially "Flash EEPROM", but this was too
long and it got shortened to "flash".

Now we have a marketing war of words about "nand flash" and "nor flash".

In spite of the layers of marketing hype, what we actually have is a large
variety of "slow, complicated write, simple, fairly fast read" (SCWSFFR ?)
memories to choose from, each with a different set of specifications.

I expect that we will continue to see new technologies, new layers of
marketing hype and new confusions in the future. Its traditional!

Steve Russell
Nohau Emulators At 06:53 PM 1/18/2006, "joshcurtz" <joshcurtz@josh...> wrote:
>So I've been using the S12XDP512 for quite some time and someone told
>me that the Freescale folks said the EEPROM is not "real" EEPROM but
>is actually an "emulated" EEPROM. He says this is the case because the
>S12X's EEPROM is not byte eraseable and is based on "flash
>technology". Does one really call this "emulated EEPROM"? I'm not sure
>of the formal distinction between EEPROM and Flash if there is one so
>I wanted input from others.
>
>Thanks. >
>Yahoo! Groups Links >
>




The term "emulated EEPROM" does not relate to the MC9S12XDP512. Without
going into details, It relates to a future S12X family.

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 02:53 19/01/2006 +0000, you wrote:
>So I've been using the S12XDP512 for quite some time and someone told
>me that the Freescale folks said the EEPROM is not "real" EEPROM but
>is actually an "emulated" EEPROM. He says this is the case because the
>S12X's EEPROM is not byte eraseable and is based on "flash
>technology". Does one really call this "emulated EEPROM"? I'm not sure
>of the formal distinction between EEPROM and Flash if there is one so
>I wanted input from others.
>
>Thanks.




--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote:
>
> The term "emulated EEPROM" does not relate to the MC9S12XDP512. Without
> going into details, It relates to a future S12X family.

Well, good thing we won't go into details because it says the same
about the EEPROM in my 9S12DP256. It's not unique to 9S12X, but
started apparently with Star12 or S12 or whatever they called it.

I don't know if it's easy to extract the simple explanation out of the
previous answers, but any explanation is pointless. If there is a
point, it is that EEPROM means used as ROM but is electronically
erasable, and that does not say anything whatsoever about how it does it.

Freescale's point is apparently that they make their EEPROM different
now than they did with HC912 and earlier. Of course, that did make it
harder for me since I had to erase 4 bytes (the small sector size)
instead of one word size (2 bytes on the HC912)


--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote:
> For additional confusion in HCS-12 parts, Freescale AN2400/D "HCS12 NVM
> Guidelines" says:
>
> >Most HCS12 microcontrollers also incorporate EEPROM that may be
used to
> >store data variables. HCS12 microcontrollers that do not have
EEPROM may
> >use Flash to emulate EEPROM, refer to application note AN2302/D for
> >details and example software.
>
> When it is referring to using the flash to store changing data on parts
> without a separate "EEPROM" resource.
>
> Which is a different kind of "EEPROM emulation".
>

Thanks for the reply. I read that AN too and that makes sense to be
called EEPROM emulation because they propose a software solution that
makes the flash look like it has a much smaller erase size. To me the
difference between EEPROM and flash has always been the erase size;
the Freescale engineer apparently implied based on his answer that if
the erase size is greater than a word then it is flash but to me a 4
byte sector size would qualify as EEPROM.

Anyhow, thanks for the thoughts.



Jefferson Smith wrote:

[...]

> Freescale's point is apparently that they make their EEPROM different
> now than they did with HC912 and earlier. Of course, that did make it
> harder for me since I had to erase 4 bytes (the small sector size)
> instead of one word size (2 bytes on the HC912)

Ack, the 4 byte erase sector size is bad. Especially because it's
hard to sort/align data to 4 byte boundaries.

Oliver
--
Oliver Betz, Muenchen


--- In 68HC12@68HC..., "Oliver Betz" <list_ob@g...> wrote:
>
> Jefferson Smith wrote:
>
> [...]
>
> > Freescale's point is apparently that they make their EEPROM different
> > now than they did with HC912 and earlier. Of course, that did make it
> > harder for me since I had to erase 4 bytes (the small sector size)
> > instead of one word size (2 bytes on the HC912)
>
> Ack, the 4 byte erase sector size is bad. Especially because it's
> hard to sort/align data to 4 byte boundaries.

In the files area on the board here is posted my solution to the EE problem, it does a logical sort and allows 1, 2, or 4 bytes to be stored, it aligns on boundaries etc.

Penalty is more work for the EE if you store one or two bytes or across boundaries, benefit is never having to worry about aligning.

Cheers,

Theo


"theobee00" <yahoodump2@yaho...> wrote:

[...]

> > Ack, the 4 byte erase sector size is bad. Especially because it's
> > hard to sort/align data to 4 byte boundaries.

> In the files area on the board here is posted my solution to the
> EE problem, it does a logical sort and allows 1, 2, or 4 bytes to
> be stored, it aligns on boundaries etc.

> Penalty is more work for the EE if you store one or two bytes or
> across boundaries, benefit is never having to worry about aligning.

That's the problem and what I meant - the program should arrange data
on suitable boundaries to avoid data crossing a erase sector
boundary. A compiler could do so by grouping different sized EEPROM
"variables" and aligning them.

Oliver

Oliver
--
Oliver Betz, Muenchen