Using flash to store log information

[Giox79]

Hello everybody

I have a question related to how to manage a task that I think is quite easy for expert in MCU's programming but about which I have some doubts.

I'm programming a device HCS08 and I have to store a big amount of data (mainly log related) in non volatile memory (about 350 byte).

Part of this data should be updated each time I restart my board, but retained when the board is shutted down.

In order to avoid using RAM as a temporary storage for data I was thinking about using two page of Flash and using them as a ping pong buffer.

However I don't know if this is the better way or if I missing a better approach.

Can you provide a a feedback about my idea? Is there some example about this topic?

If this is a stupid question, please be patient, I'm a newbie!

[NickT · Accepted solution]

You're looking for "EEPROM Emulation"  Do a quick search and see if that can answer some of your questions.

• http://forums.freescale.com/t5/forums/searchpage/tab/message?location=Board%3A8BITCOMM&q=eeprom+emul...
• http://www.google.com/search?hl=en&q=site:freescale.com+eeprom+emulation

AN3824 might help as well (emulation on an HCS08 MCU) http://cache.freescale.com/files/microcontrollers/doc/app_note/AN3824.pdf?fsrch=1&sr=3

[Giox79]

Many thanks for your useful help. It seems that I ignored the right word :-D I will read the documents. I already integrated the doonstack.asm , .h and .inc files in my project. I hope it will works. Thanks again for your hint. Giovanni

[bigmac]

Hello, and welcome to the forum.

You do not mention which 9S08 device you are contemplating to use.  Most devices have 512 byte flash sectors within a single array.  This requires that some of the erase and programming code be run from RAM because flash memory is not accessible when the programming voltage is internally applied to the array.  The doonstack code uses the stack for this purpose.  It is also possible to use a fixed location in RAM, which requires somewhat simpler code.

However, you might also wish to consider the 9S08DNxx device, which contains EEPROM flash within a separate array from the program flash.  The EEPROM has a sector size of eight bytes, which may be erased and programmed directly from code residing in program flash, rather than RAM.

Providing primary and secondary copies of the NV data would be essential with a total data size of 350 bytes, if using large sector flash.  This would insure against data corruption due to loss of power part-way through the erase and programming process.  You will need to attach a CRC value to each copy so that NV data validity of both copies can be checked on each power up.

For the device with EEPROM, a similar approach remains desirable, even though the sector size is smaller.  Keep in mind that the sector erase period wll be in the vicinity of 20ms irrespective of the sector size.  Since the programming time for each byte is much shorter, the sector erase period will predominate the total erase and programming time.  If the updated portions of the NV data should occupy many EEPROM sectors, the use of EEPROM may actually be slower than using program flash, because of the multiple sector erases required.

With the two copy approach, the need for additional data storage in RAM will depend on whether byte-by-byte programming, or burst programming is used.  In the latter case, a further RAM buffer would be required of flash row size.  The use of burst programming would save about 25 microseconds per byte.

Regards,

Mac

[Giox79]

Hi, thanks for your reply, I'm currently involved in a project with a MC9S08QE8CTG device. So I'm using the RAM as a buffer. Using the byte by byte write method the system seems work , now I will try using the FlashProgBurst approach. Thanks again for your useful help.