MCF51Qx FlexNVM sector size?

[Lundin]

I'm looking at the Coldfire with this new FlexNVM. After reading the data sheet for one hour, I still don't understand what the minimum sector size is. I'm interested in updating eeprom/data flash contents in runtime, and thus it is vital for me to know the minimum sector size that needs to be erased before writing.

Has anyone managed to decipher this value from the manual?

[scifi · Accepted solution]

Apparently, you can choose to let the MCU emulate EEPROM. The manual says that the emulated EEPROM 'Supports FlexRAM aligned writes of 1, 2, or 4 bytes at a time'. Flash sectors will be erased automtically when needed. No need to know sector size in this case.

It appears that sector size is not stated anywhere in the manual. Indirectly, you could conclude that it's 1 Kbyte. Consider the following (taken from the manual):

- EEPROM backup data sector — The EEPROM backup data sector contains one EEPROM header and up to 255 EEPROM backup data records, which are used by the EEPROM filing system.

Elsewhere in the manual it says that an EEPROM header and backup data records are 32 bits in size. It means that an EEPROM backup data sector is 1 Kbyte in size.

It would be nice to have this information stated clearly in the manual. Perhaps, you should consider submitting a service request with Freescale support?

[kef]

MCF51QE128 MCU Series Reference Manual, Rev .3, page 71:

"

Flash size

— MCF51QE128: 131,072 bytes (128 sectors of 1024 bytes each)

— MCF51QE64: 65,536 bytes (64 sectors of 1024 bytes each)

— MCF51QE32: 32,768 bytes (32 sectors of 1024 bytes each)

"

[Lundin]

Thanks for your reply.

I suspected 1kb as well, though it isn't clearly stated anywhere. If that is true, then unfortunately this will make the MCU useless for my application, as I need to erase/write to eeprom in realtime.

[scifi]

Why useless?

You can get a glimpse of EEPROM operation timings from the preliminary datasheets for the Kinetis family. Maximum execution time for an EEPROM write operation is said to be in milliseconds (this does seem to contradict sector erase time of 20 ms typ / 100 ms max).

If that is too slow you can always implement your own EEPROM emulation algorithm. More RAM buffer space will allow you to store new data while a sector erase operation is in progress.

[Lundin]

Because the time to do a write is calculated from the following major time thieves:

The time to save one sector of the EEPROM contents to RAM +

The time to erase one sector +

The time to write back the whole contents from RAM to EEPROM

In high integrity applications, ie automotive/industry, you will also need to double up each value and store it twice, to fulfil relevant safety standards. Preferably in physically different memory chips inside the MCU. Meaning you'll double up the time twice.

Also, in high integrity applications you must also use CRCs, which will become increasingly burdensome the larger the segments are.

I have studied Freescale's app notes for how to write segmented memory access in detail, where they use the NVM as a kind of FIFO. These algorithms cannot be used in any real world application with the faintest hint of realtime requirements, the time to read a value from such a NVM will be O(n) where n is the number of bytes in one segment multiplied with the access time of one NVM cell.

[scifi]

Realtime doesn't mean much unless there are specific timing requirements. Obviously, you alone can judge wether the MCU is suitable for your application.

I'm not sure any other MCU would be any better since Freescale with their 20 ms typ / 100 ms max sector erase time seem to be among the leaders in high-performance flash memory technology.

[Lundin]

A certain Japanese MCU manufacturer has got pretty much identical timing specs, but with the enormous advantage that I don't have to shovel one whole bloody kilobyte onto the stack each time I want to update a single bit in the eeprom. Their data flash is stored in 32 byte segments.

Since I'm working with high integrity applications (automotive/industry), I store a CRC in each segment, and I store each segment twice. This is standard for any form of safety-related applications. Because of this, the update time of the eeprom will increase drastically the larger the segments are. We are talking about several hundreds of milliseconds lost per updated segment.

(And then the Japanese has got hardware support for industry standard CRC calculations on-chip, so it would be faster no matter.)

[scifi]

Sorry for making this discussion ridiculously long, I'm just trying to understand.

Isn't it possible to devise an EEPROM emulation scheme where:

a) new data can be stored quickly (have an extra sector always ready for this) and

b) the slow process of sector erase/initialization is done in the background (using a multitasking OS, if necessary)

Of course, such a scheme would be rather complicated which is a downside for safety-critical applications. But still it's doable, isn't it?

[Lundin]

a) If the data isn't stored at fixed addresses, there can be no deterministic access to the cells. You would have to go through some sort of heap, binary tree or lookup-table algorithm to find the data.

b) First of all, that kind of algorithm will require RWW (read while write). Some Freescale MCUs support this, some don't. On top of that, you would need to have some sort of RAM mechanism working as a "fake eeprom" replacing the segment currently being written to.

No matter how you do this, you will still need to slap the stack in the face with 1kb, or (preferably) reserve 1kb of RAM for this purpose only. And then you also slap the CPU with all the extra CRC calculations that come with it.

And why would I do all of this!? Writing to an eeprom cell is supposed to be something extremely fundamental. I shouldn't need to write myself a heap-based file system and a minor RTOS, just to be able to store things in the eeprom. Indeed, all this extra complexity adds notable hazards to the application. The procedure of using RAM as a temporary EEPROM is highly questionable in safety-critical applications, just as one example.

With a 32 byte segment, all of the fuss is gone, and I can focus on programming my application. Building huge sand castles around Freescale's clumsy eeprom segments is no high priority of mine. And don't come waving with the app notes with eeprom emulation algorithms, they are nonsense and can't be used in high integrity applications.