topic Re: EEPROM - 1.56%, not 50% in 8-bit Microcontrollers

EEPROM

albertvv — Wed, 21 Feb 2007 04:12:26 GMT

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?]

Re: EEPROM

Lundin — Wed, 21 Feb 2007 15:52:55 GMT

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.

Re: EEPROM

peg — Wed, 21 Feb 2007 19:39:12 GMT

Hi,

The sales blurb gives the reason as cost.

I guess if you just split the FLASH this doesn't cost very much and doesn't really affect the user who doesn't require the EEPROM. If they put EEPROM in and you don't use it, it is a waste of money.

Also may be due to the lack of any licencing agreement with any EEPROM manufacturers like there is with the FLASH. Or the FLASH ones don't cover EEPROM.

Just testing some Ramtrom FRAM yesterday!

Re: EEPROM

Lundin — Wed, 21 Feb 2007 19:50:32 GMT

The competition has got either EEPROM or even better: flash that you can actually use to store data in. How exactly is Freescale saving money when the customers abandon their whole microcontroller family just because it has no EEPROM?

Re: EEPROM - 1.56%, not 50%

Alban — Wed, 21 Feb 2007 20:30:18 GMT

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.

Re: EEPROM

albertvv — Thu, 22 Feb 2007 03:05:42 GMT

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

Re: EEPROM - Don't compare PIC and S08!

Nabla69 — Thu, 22 Feb 2007 04:21:25 GMT

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.

Re: EEPROM - 1.56%, not 50%

bigmac — Thu, 22 Feb 2007 10:44:26 GMT

Hello,

For the lowest level S08 devices, the QG4 and QG8 the picture is somewhat different. With a page size of 512 bytes, there are only 8 and 16 pages, respectively, representing 12.5% or 6.3% of capacity. By comparison, the S08 family generally has smaller page sizes. For example, the QY4 has 64 pages of 64 bytes.

If only a few bytes of data need to be saved, there is little problem with either device, provided the reduction of program space can be accommodated.

The main difficulty is when the whole page needs to be used (perhaps multiple pages) for data storage. We may be changing only one byte, but we need to store the whole page in RAM. Since these low level devices only have a single flash array, we also need some additional RAM for programming purposes. With a total RAM size of only 512 bytes, this poses a significant difficullty.

Even with the AW32 device, with 2K RAM, the allocation of 512 bytes as a buffer (temporarily or otherwise) is possible, but could be disruptive to RAM usage in some cases.

So the primary issue, seems to be the relationship between flash page size and RAM size.

I am currently considering use of a AW32 device, with the application requiring 8K of data storage (in 32 byte records). With the added coding complication of maintaining a 512 byte buffer (probably in addition to a 32 byte buffer for a single record), I am currently tending towards using a SPI serial EEPROM.

With regard to providing dedicated internal byte erasable EEPROM, I guess it is either superfluous, or there is never enough.

Regards,

Mac

Message Edited by bigmac on 2007-02-2201:03 PM

Re: EEPROM - RAM is limited and buffer uses too much

Alban — Thu, 22 Feb 2007 17:09:47 GMT

Hello,

I now understand better where the problem lies.

This excellently explained reason was sent to the Systems team.

Systems designs the requirement of tomorrow's devices, along with Marketing.

I see an easy way to reduce partially the RAM impact by putting E²PROM routines is mask-ROM (like on small HC08).
But this won't change the buffer consideration.

Alban.

Re: EEPROM - 1.56%, not 50%

Lundin — Thu, 22 Feb 2007 20:37:36 GMT

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.

Re: EEPROM - Don't compare PIC and S08!

Lundin — Thu, 22 Feb 2007 20:57:08 GMT

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.

Re: EEPROM

albertvv — Fri, 23 Feb 2007 03:06:17 GMT

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!

Re: EEPROM

P_EMark — Fri, 23 Feb 2007 04:25:08 GMT

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

Re: EEPROM

Encoder — Fri, 23 Feb 2007 09:46:51 GMT

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.

Re: EEPROM - 1.56%, not 50%

bigmac — Fri, 23 Feb 2007 12:17:46 GMT

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

Re: EEPROM - 1.56%, not 50%

Lundin — Fri, 23 Feb 2007 15:42:10 GMT

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.

Re: EEPROM

Lundin — Fri, 23 Feb 2007 15:45:15 GMT

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.

Re: EEPROM - 1.56%, not 50%

bigmac — Fri, 23 Feb 2007 21:03:40 GMT

Hello Lundin,

As a matter of curiosity, how long does it take to write 512 bytes to Renesas EEPROM? This will determine the liklihood of data corruption, and whether a mirror segment process would be necessary for the EEPROM case.

The additional overhead figure of 250 - 300 ms for the manipulation of 512 bytes of data does appear somewhat excessive. I assume some of this processing would also be necessary, including the check sum calculations, for the EEPROM case. I do not quite understand what you mean by "alignment checks". Was the code written in C or assembler?

Regards,

Mac

Re: EEPROM - 1.56%, not 50%

Lundin — Mon, 26 Feb 2007 15:41:00 GMT

I don't have the equipment needed to measure that right now.

With alignment, I guess I ment to check how much of the data in one segment that is used. With every segment I write down a size and a checksum at the end of it. The algorithm is like this (it was written in C):

- Verify that both segments are equal before starting. This means checking various flags and calculating checksum for two segments to compare with the checksum in each segment. I also run memcmp() between the both segments, just in case the CRC failed to detect an error (very small chance but still possible).

- If one segment is corrupted but one is valid, the program will copy the valid to the corrupted. And then verify them both again.

- If both segments are corrupted, the program will do some error handling (hang and wait for wdog etc).

- Both segments are valid: copy flash contents to temporary RAM segment.

- Set the size of the data stored in the segment. This will optimize the code slightly but I will still have to run CRC calculation on the whole segment, to detect changes in the flash caused by aging etc.

- Bytes not containing data will be filled with 0xFF.

- A new checksum will be calculated on the RAM segment.

- The RAM segment is written to the flash.

- After writing, I check once again that the flash is valid.

Since the data is of safety-critical nature, I really can't remove any of the above checks. So the code will be incredible slow. Doing the above with the S12 EEPROM is of course way faster since you only need to write 4 bytes data + [2 or 4] bytes of CRC.

Re: EEPROM

freegeek — Tue, 27 Feb 2007 22:13:33 GMT

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.