32-bit MCU with eeprom updates in realtime?

Lundin · ‎02-16-2011

For quite a while I have been doing extensive research for an MCU that fulfils the following requirments:

32 bit.
Suitable for automotive/safety-critical appliactions in tough environments with heavy EMI. In my experience, all Freescale MCUs perform well in such environments.
Updates of eeprom/data flash must be done in runtime, and done in realtime. The MCU must be able to erase/write to an NVM cell during execution, without losing values in adjacent cells. The access time must be fast and deterministic, and the algorithm should have a minimum of complexity.

Does any such beast exist with the Freescale logo on it?

The application is a very typical automotive/industrial data logger. I am looking for an eeprom/data flash with roughly the same characteristics as you can find on S08D or S12D microcontrollers, ie small erase sectors. Unfortunately they are 8- and 16-bit and I want to use a 32-bit MCU. External eeproms is not an option because of EMI.

MPC56 has 16k erase sectors and needs horribly slow, obfuscated algoritms because of it. Coldfire seems to have 1k erase sectors, which is far too large as well.

Is there any hope to find a Freescale MCU living up to my requirements? I have found countless MCUs of a certain Japanese brand living up to my spec, but none from Freescale yet. I would like to use Freescale if possible, because they have proven to perform very well immunity-wise.

rocco · ‎02-16-2011

Hi Lundin,

Do you like ARM? Freescale has the MAC7xxx family of Arm-based automotive processors. Some MAC7xxx members have 32K data flash separate from the program flash. But there are two issues:

First, for the sake of ERASE, the pages are 1K words. You indicated that was too large for you. But a WRITE can be individual words.

Second, the word width is 16-bits, rather than 32-bits. That may or may not be important.

I doubt that Freescale has any flash implementations that have page-sizes smaller than 1k.

Lundin · ‎02-17-2011

That's the same problem as with Coldfire then, too large segments. Only the erase segment size matters, how it writes data doesn't matter.

I have decided to use a non-Freescale MCU.

melissa_hunter · ‎02-18-2011

Hi Lundin,

Have you looked at the new Kinetis family processors? These new ARM Cortex-M4 based devices have a new FlexMemory feature that allows you to configure certain portions of your flash as traditional data flash or as enhanced EEPROM (EEE). When configured as EEE the memory is accessible as byte, word, or longword and has much faster access times than a traditional external EEPROM (worst case write cycle is 1.5ms). One of the main application uses for this is data logging. So I think these parts might be able to solve your problem and still provide the 32-bit architecture and the environmental performance you want. Here's the link to the main landing page for the Kinetis family:

http://www.freescale.com/webapp/sps/site/homepage.jsp?code=KINETIS&tid=VANKINETIS

The Kinetis portfolio section of the page is probably the best place to start. It gives a high level overview of the different Kinetis families, so that should help you to figure out which families you are interested in based on feature set.

Hope this helps,

Melissa

Lundin · ‎02-25-2011

I can't bother to read yet another manual of a MCU I won't use. Maybe if Freescale actually wrote down the flash erase size (sector size) among non-volatile memory characteristics in the manual, I would. Instead, this information is found between the lines at a well-hidden place somewhere deep inside the manual.

I have spent a lot of time researching this, reluctant as I have been to give up on Freescale. My company has been a loyal Freescale/Motorola customer for 30 years. But as we are working with modern realtime-applications for automotive/safety-critical, we cannot use these flash memories.

Maybe the hardware people who design these chips should consult someone with actual knowledge about safety-critical realtime software? If Freescale have such a person employed, it is certainly not the person who wrote the app notes about flash eeprom emulation.

Freescale currently seems obsessed over making flash memories at as tiny nanometer as possible. If the memories are actually useful in typical automotive applications seems to be less important. The competition don't have the same nanometer-prestige, which makes it possible for them to design memories that can actually be updated during runtime.

rocco · ‎02-25-2011

Hi Lundin,

My understanding is that Freescale has no flash technology of their own, but license their flash from a third party.

That is no excuse for the poor documentation, though.

Lundin · ‎02-28-2011

Then maybe they could dig up the eeprom they used in 68HC11 and put it in their new chips. If they could manage to fit that eeprom into a PLCC52 back in 1985, they should be able to fit it into a LQFP year 2011.

TomE · ‎03-18-2011

> Then maybe they could dig up the eeprom they used in 68HC11 and put it in their new chips

I guess you're joking there. The processes needed to make chips at one "generation" aren't necessarily compatible with the previous generations, so they can't "cut and paste" at that level.

I was forced to migrate from a nice ST72 series chip that had internal EEPROM to the next generation that didn't. I heard the EEPROM one needed an extra "Nitride layer" processing step that they wanted to remove, probably so the line that made the next generation of chip could be used to make lots of different chips, all designed to exactly the same process.

What's wrong with an external serial EEPROM. Those things take only two pins (I2C) or three and are tiny. They're also deterministic.

Tom

rocco · ‎03-18-2011

Hi Tom,

I can't speak for Lundin, but one concern is EMI.

I do use an external I2S eeprom, but at a cost. An external eeprom, especially I2S, is many times more susceptible to errors from EMI when you are in a noisy environment. So I need to add CRC and verify operations to all of my eeprom transfers. And that was after very careful board-routing.

RobertSignum · ‎02-25-2011

We've ported our Flasher too to Kenetis so I know that the smallest erase size is 0x800 (2KB), while you can program each 32 bit word individually. In general any bit=1 may be changed to 0, but it is not suggested to re-program existing 0-s.

Kinetis flash is complex indeed. It may emulate an EEPROM, so user's code does not have to worry about flash wear leveling.

What is the requirement for typical automotive use?

Regards,

Robert

Lundin · ‎02-28-2011

Standard industrial/automotive requirements would be:

- CRC-based checksum. A CRC checksum could in theory cover a very large NVM segment, though to reduce compution time and to be kinder to the NVM cell. Therefore one typically adds a checksum to each and every NVM segment (IEC 61508-7 A.4.4). Whoever wrote the Freescale app notes about eeprom emulation is completely unaware of such a basic thing as this.

- Block replication / mirror segments. Each NVM constant in the eeprom must be saved twice, in different segments. These segments are compared with each other after writes to NVM, and also before the variable is used, to ensure data integrity (IEC 61508-7 A.4.5). This is particularly encouraged if the "mirror" segment is stored in a physically different memory area.

- Deterministic access time. When accessing a variable in NVM, you would expect next to no delay. With Freescale's eeprom emulation, you get a non-deterministic access time of "Big O(n)"where each n =(NVM_address - NVM_offset) * lookup_execution_time.

Needless to say, this access time is not acceptable. Especially not if n=1k (Coldfire), n=2k (Kinetis) or n=16k (MPC56) .

---

Conclusion:

If block replication is used with Freescale eeprom emulation, I will have to allocate 4 times the needed memory. Because the eeprom emulation algorithms assume there's a spare segment to use when the first one is full. So if I have for example a MPC56 application where I wish to store one byte in NVM at runtime, I will have to allocate 16k x 4 = 64k byte data flash. On a 68HC11 I would have to allocate 4 bytes of eeprom to store 1 byte with block replication.

68HC11 vs MPC56 = 1-0

When doing some worst-case calculations to amuse myself, I found out that my good old 68HC11 running at 8MHz were several thousand times faster at accessing NVM than a "eeprom emulation" MPC56 running at 100MHz.

68HC11 vs MPC56 = 2 - 0.

Apparently I'm the only one in the whole world finding it odd that a sluggish 8-bitter from the early eighties is devastatingly better than Freescale's newest 32-bit CPUs when it comes to eeprom storage.