EEPROM

[albertvv]

AN3404, How to do EEPROM Emulation Using Double Flash Array

This brings back a question I've had for many years: these workarounds show the widespread need for EEPROM. So instead of now providing 2 flash arrays, so that one can write to the other, why not finally (or better from the beginning) implement a bit of EEPROM. Especially because many Microcontrollers have not much ram to put code in.
For this very reason we've abandoned using these series of microcontrollers; all our other chips simply have EEPROM onboard. These chips needing external EEPROM are just a big nuisance.

[this might not be the right place to moan, but where else?]

[DustyStew]

Lots of ranting here.

"my 2 cents":

I have been emulating EEPROM on an HC08 for several years, it is basically transparent, with a few gotchas.

The first gotcha is that you are stuck using the ROM routines for writing the FLASH, because you cannot execute out of FLASH while writing FLASH, and on the small chips (like the Q's) you don't have enough RAM to put the erase/program routine in RAM.

So while programming, you have to turn off the interrupts, and entrust your system timing to the ROM routines. Of course, odds are your system timing will be shot to [expletive deleted], which it is in my case. But if you have 20 milliseconds or so to spare, then it is completely A-OK. For a human user it is invisible. If you are trying to deal with a real-time machine or comm or such, then it will blow your system to [expletive deleted once again]

Next problem is that you probably don't have enough RAM laying around to buffer a FLASH page (64 bytes on the HC08), so you need to use another FLASH page as a buffer. This of course doubles the time required to do everything.

Next problem is that on the HCS08, the page size is 512 bytes. So now to change one byte, you need to change 1024 bytes. That is time consuming, and I am so far at a loss as to what to do about it. On the QD4, you have only 4K to start with, but if you want EEPROM emulation, you will only have 3K!

It you look at the competitors chips which have EEPROM onboard, the programming time is still in the millisecond range (4 ms I think), so real EEPROM isn't really a performance enhancer, time-wise. However presumably one can maintain system interrupts while programming it.

The main problem's Freescale has to solve:

1. Page size must be small, and ideally considerably smaller than the RAM size (say, 8-to-1 ratio of RAM size to FLASH page size, as a minimum)

2. Make the FLASH erase and program routines interruptable, so that system processes can continue to run while erasing and programming FLASH. This may just be a matter of documentation. For instance, it may be that I could erase a page by "pulsing" it, ie, not turning on the erase function for one 4 ms period, but turning it on and off 100 times or so, between interrupts. But I have not tried it, and it would have to be characterized by Freescale to be truly usable.

Best Regards
Tom

[Alban]

Hi Tom,

On S08, you can have much smaller pages. It seems customer passion on the subject paid off :smileyhappy:

Also, as you use a state machine and not hand made delays as on HC08, you can interrupt your main code and do something else while the command is being executed.

Alban.

[DustyStew]

Hi Alban

Smaller pages on the S08? Please elaborate. I'm a newbie . A really really OLD newbie.

The problem with interrupting the FLASH programming process, as far as I can tell, is

1. You would have to copy the interrupt handler into RAM, as execution from FLASH is not possible while erasing/programming.

2. As well you would have to change the vector to point to RAM

3. The interrupt vector is in FLASH, and I don't know that it is accessible during an erase/program cycle. Now maybe I am wrong on that point, but I have not seen specific documentation about this. I have followed an HC08 app note from several years back, and in it, interrupts are disabled when calling into the monitor routine to erase or program FLASH. Have I missed something?

Now how about this idea. I have a periodic interrupt going, say, every 100 microseconds, and the interrupt takes, say, 30 microseconds. So I have 70 microseconds of foreground every 100 microseconds. In the foreground, I sync to the interrupt with a WAIT instruction, then execute a routine of say, 50 microseconds, which turns on the erase function then turns it off again. Would the FLASH page eventually get erased? Or am I missing something essential? (I have not studied the FLASH algorithm timing too closely as it is taken care of by the monitor routine)

TIA
Tom

[Alban]

Hello,

The S08DZ60 has some sector of 8 bytes only, instead of 512 bytes.
See MC9S08DZ60.pdf

That's true, as you cannot use the block of Flash you are programming, you need to execute some other code.
To use interrupt, you need to program a block which does not include the interrupt vector table and does not include the code you want to execute.
Blocks are model specific, I don't know on which model this is authorized today, if any.

Alban.

[bigmac]

Hello Alban,

For single flash array devices, such as the QG8, this does raise the issue on whether interrupts must be disabled whilst the  erasing or programming of a flash block is in progress, from within code residing in RAM.

Assume interrupts were not disabled, and a hardware initiated interrupt event were to occur.  The internal hardware would attempt to fetch the interrupt vector - that would not currently be accessible.  The question is whether the device would behave gracefully, and simply wait until the vector was accessible, or go off into never never land.

I guess the safe approach is to disable interrupts.

Regards,

Mac

[DustyStew]

Alban

I've answered my own question...referring back to the original post, AN3404. So Freescale has changed it's ways. Good on you. Now, when do I get a double flash array on a 4K or 8K chip?

[DustyStew]

Alban

I'm looking at page 32 of the QB8 datasheet Rev 1, and there is a note that says "Programming and erasing of FLASH locations cannot be performed by code being executed from the FLASH Memory". I assume that to mean, "any FLASH memory", not "the FLASH memory page which is being programmed or erased".

Can you please clarify this point.

Thanks
Tom

[albertvv]

Thanks for better explaining than myself what the problem is. Not just no-e2, but needing ram for buffers and CODE space !!! because you can only write flash from ram. We don't replace 08-family functionality with PIC, just an example of cheap chips with e2. We now use ATmega for the real work.
Another thing this discussion has reminded us of: how extremely important it is to perform a complete analysis of the projects needs before you start designing!

[P_EMark]

Hey all:

I believe that all these concerns are addressed with the "D" family of HCS08 microcontrollers.

http://www.freescale.com/files/microcontrollers/doc/fact_sheet/BRS08DFAMILY.pdf?fsrch=1

Regards,
Mark

[Lundin]

Now that is exactly what I'm looking for. I've been asking both Freescale and their retailers for info regarding this secret, upcomming S08 but with no success so far.

Seems P&E saved the day, since we were going to decide which micro to use for our upcomming project 30 minutes from now, and S08 wasn't on the list. Well, it is now.

[albertvv]

Cost??
All our Microchip PICs have flash, eeprom, ram, timers, ports for 1 dollar!

[Nabla69]

Hi,

!RANT MODE ON.

Don't get me started on PIC... If they were that good they would be used in Automotive.
Be assured Albert that Cost is not the only point, the microcontroller has got to work.
And here I'm not talking dreams, I'm talking real hard facts, Auto manufacturers are the most demanding people in term of quality.

Still, it would be nice to look if it EEPROM or Flash Emulated EEPROM.
EEPROM is an expensive process that not many CUSTOMERS are ready to pay for.
Thinking that the silicon manufacturers decide prices on their own is like thinking that Wallmart doesn't discuss prices with the potatoes growers.

An S08Qx is also sub-dollar with all the same functionalities. As Alban said, all the code is available.
Plus the memory is characterized for ALL the temperature range and does keep the data.

Alfred.

!RANT MODE OFF.

[Lundin]

Well, I wouldn't mention PIC as a serious alternative, but there is however another competitior who's micros are widely used in automotive and their 8-bit micros cost about as much as S08, but come with "data flash".

And no, S08 doesn't have the same functionality as mentioned PIC since it doesn't have eeprom. The flash cannot replace eeprom in all applications, see my other post for details.

[Lundin]

I totally agree. My company has given up on the S08 family, because we need a small 5V MCU with EEPROM and CAN. Freescales tiniest micro that has these minimum requirements is, as far as I know, the S12 D32, which is too powerful for our needs. It takes up too much space as well. The 48 pin C32 would have been perfect if it had EEPROM.

If you have a need to configure settings in realtime, flash is out of the question. Since you need to tear down half the flash or so to program one byte.

External EEPROM is indeed a big nuisance.

[Encoder]

I totally agree with Albertvv and Lundin. It is incredible the difficulty to have some EEPROM on HC08 or 9S08.

Lundin has widely explained why it is often impractical, time consuming and unsafe to use FLASH to emulate EEPROM. I add another world: complex.

I am using 68HC705B16 since 5 years. I am happy with it but now it's old, too limited and incredibly more costly than other HC08 or S08 much more powerful. But, whilst there are an exagerate number of HC08, very few of them incorporate some EEPROM. And after shored to 9S08 I will hardly revert to HC08 and MONO8.

I think that 9S08AW16-60 are awesome small mpu but, for some tasks of mine they lack of a simple EEPROM. The late addition of 9S08DZ and 9S08DN (better: I do not need CAN) seemed to fill up that gap: unfortunately they are "automotive" mpu and are not available to simple mortals like me. We are not able even to know if, when and at which price they will.

It close resembles the story of the HC08QC, another small wonder in its own which was never released to the general public (strange enough the demoboard is available through Digi-key, the chip is not).

Perhaps I will resign to use some external EEPROM chip, perhaps I will win my sloth and I will search on some other mcu family to find a better suit. But I cannot understand the Freescale policy of making available an enormous number of mcu with a lot of overlapping which makes difficult to chose from, but (essentially) with no EEPROM.

[freegeek]

---

Encoder wrote:

I totally agree with Albertvv and Lundin. It is incredible the difficulty to have some EEPROM on HC08 or 9S08.

Lundin has widely explained why it is often impractical, time consuming and unsafe to use FLASH to emulate EEPROM. I add another world: complex.

I am using 68HC705B16 since 5 years. I am happy with it but now it's old, too limited and incredibly more costly than other HC08 or S08 much more powerful. But, whilst there are an exagerate number of HC08, very few of them incorporate some EEPROM. And after shored to 9S08 I will hardly revert to HC08 and MONO8.

I think that 9S08AW16-60 are awesome small mpu but, for some tasks of mine they lack of a simple EEPROM. The late addition of 9S08DZ and 9S08DN (better: I do not need CAN) seemed to fill up that gap: unfortunately they are "automotive" mpu and are not available to simple mortals like me. We are not able even to know if, when and at which price they will.

It close resembles the story of the HC08QC, another small wonder in its own which was never released to the general public (strange enough the demoboard is available through Digi-key, the chip is not).

Perhaps I will resign to use some external EEPROM chip, perhaps I will win my sloth and I will search on some other mcu family to find a better suit. But I cannot understand the Freescale policy of making available an enormous number of mcu with a lot of overlapping which makes difficult to chose from, but (essentially) with no EEPROM.

---

FYI the QC16 is now available from distributors and can be found on the freescale web and it is likely that the DZ parts will also be avaialble within a few months via distribution.

[Alban]

Good Afternoon,

I like exageration and do use it often.

However, "half of the flash for one byte" is quite pushing it

Let's take a small S08, like the AW32. The datasheet says

   "MC9S08AW32 — 32768 bytes (64 pages of 512 bytes each)"

It is 1.56%, not 50%. Of course it goes down as the device memory grows as page size stays the same.

In the HC08 family, the AZ60A does include EEPROM, Flash and CAN.

Also, for all these devices, flash memory drivers are available. And Application Notes show how to use flash as E²PROM with attached software.

There is no need to add external memory, really.

Regards,

Alban.

[Lundin]

Perhaps I should have been more clear what the main issue is. I need an application that can configure memory in real time.

If we continue on your example with the S12. If I want to change the contents of some bytes in the flash, I need to copy it to RAM. 512 bytes, it will take time. Then I alter the contents and write it back, it will take even more time since writing 512 bytes to the flash takes an eternity. I will also need to copy the code to RAM which takes additional time.

And this data I plan to write is of a safety-critical nature. If there is a power loss or external reset during programming, the change is lost. And even worse, the original 512 bytes are lost as well. So you have to erase the whole flash and start over from scratch, ie the product can't be used anymore unless the customer sends it back for repair.

I actually once wrote a code to solve this where I used an identical "mirror segment" of 512 bytes, making sure that at least one of two identical segments is valid no matter what. The code worked well, but was incredible slow since I had to deal with 512x2 bytes. It couldn't be used in the time-critical product.

---

The HC08 micros with CAN and 60k flash cost just as much as, if not more than S12 D32. Further, HC08 has no flash security and I wonder who is going to add a HC08 to a new design while it still has the incredible annoying and error-prone "monitor mode". Personally, I'm not going to touch anything without BDM.

[bigmac]

Hello Lundin,

In safety critical applications, I might suggest you would need to use your "mirror segments" concept whether you were using EEPROM or flash for data storage.

A quick look at the Microchip data reveals a EEPROM erase/write cycle period of up to 8 ms per byte.  I do not have this data for the Atmel devices, but I assume it will be of similar order of magnitude.  Using the above figure, the update of say 16 bytes may take up to 120 ms to complete (typically 60 ms).

For the S08 devices, it takes 20 ms to erase a sector, but only 20-45 us to program a byte (using a typical clock rate).  For a small amount of data, the setup and programming time will be much less significant than the sector erase time.  The total update time will depend on the size of the data block (assumed to be somewhat less than a full flash page).  For example, if the total data block size was 100 bytes, this would take a worst case period of about 25 ms.

With the programming of data into either EEPROM or flash, this will take a significant amount of time, with increased risk of corruption in the event of disruption.  The "mirror segments" concept previously described would appear to provide detection of corruption in either case.  Another possibility for critical applications is to provide early warning of loss of power.

The above assumes small amounts of data to be saved.  For more extensive data storage the mirror segments appears to become more difficult to apply.  I would possibly consider external "fast write" serial devices, such as FRAM (a few microseconds per byte).

The low end Microchip devices (with up to 8K instructions) seem to provide EEPROM of either 128 or 256 bytes.  Presumably when this is exceeded, an external memory must be used anyway.  The concept of alternative "data flash" doesn't seem to fit the Microchip architecture - probably why they needed to include some EEPROM.

Regards,

Mac

[Lundin]

Heh, I'm not using Microchip, so I wouldn't know. I was actually referring to Renesas but thought it would be a bit rude to advertise for the competitors on Freescale's own site...

Anyway, for the mirror segment project on the S12, the maximum prescale clock I could use for the flash with my oscillator is 192kHz. A sector erase with a 192kHz clock will take 20.83ms. Writing one word of data will take 2.5us. So it will take

20.83ms + 512 * 2.5us = 22.11ms

and that's just the hardware restrictions.

300-340ms is what I ended up with in the end. I was copying data + code to and fro RAM, writing 1k flash, calculating checksums on every 512 segment, alignment checks etc etc. Suppose I could optimize that a bit, but not much.