topic Re: MC9S12XEP100 Emulate EEPROM in S12 / MagniV Microcontrollers

MC9S12XEP100 Emulate EEPROM

eric92 — Tue, 04 Aug 2015 13:41:46 GMT

Hi,

I use the Library IEE1.C generate by PE to write and read in the Emulate EEPROM.

At the beginning there is no problem.

But after several months writing becomes impossible.

I send you the file

The date to store are in the SAUV_RAM segment in RamEEProm.c

The procedure char sauv_config() in Eepromx.c

The procedure for retrieving data is bool rappel_config() in Eepromx.c

I use the version 5.9.0 of Code Warrior

Mask 5M48H

Have you an idea about the problem ?

Best regards

Original Attachment has been moved to: 0330&Boot_V1.prm.zip
Original Attachment has been moved to: IEE1.h.zip
Original Attachment has been moved to: IEE1.c.zip
Original Attachment has been moved to: RamEEprom.c.zip
Original Attachment has been moved to: Eepromx.c.zip

Re: MC9S12XEP100 Emulate EEPROM

RadekS — Wed, 05 Aug 2015 13:55:40 GMT

Hi Eric,

I guess that problem could be in partially partitioned D-Flash (Partition command was interrupted).

Could you please try read word at global address 0x107F00?

At address 0x107F00 starts the last D-Flash sector.

Each sector starts with a header field containing two words that define its status and erase count. The sector header format is designed to allow:

• All state transitions to be achieved using single programming operations

• Effective use of the D-flash ECC

• Detection of EEE reset condition

• Basic tracking of the sector erase count (up to 65534)

When we start with partitioning, DFPART and ERPART are written as first. After that MCU continue in formatting part of D-Flash which are reserved for EEE (depends on DFPART and ERPART values).

If there is any unexpected interrupt during this time (e.g. power down), D-Flash will stay formatted only partially.

From this point of view, reading DFPART and ERPART cannot sign whether D-Flash was partitioned successfully or not.

From beginning everything works correctly, but after some time, formatted D-Flash is consumed for EEE data updates and the next D-Flash sector is not correctly formatted. In this point EEE stops storing new values.

I would like to recommend test last header field at address 0x107F00 for information whether partitioning was successful.

For example:

if(*(unsigned int *far)0x107F00 == 0xFFFF) err = FORMAT_ERROR; //Was D-Flash correctly formmated?

//err signalize format error

//partitioning was interrupted

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: MC9S12XEP100 Emulate EEPROM

eric92 — Thu, 06 Aug 2015 07:49:01 GMT

Hi Mr Radeks,

Thank you very much for your analysis.

When I read in memory 0x10700'G (or with pointer (*(unsigned int *far)0x107F00) , I read 0xFACF. This value is close to 0xFFFF. Do you think the problem comes from there?

Is there a way to unlock the DFLASH. Either DFLASH is blocked permanently?

Is my application should hide interruptions before starting the sauv_config () procedure?

Thank you sincerely for your help

Re: MC9S12XEP100 Emulate EEPROM

RadekS — Thu, 06 Aug 2015 12:09:47 GMT

Hi Eric,

I would like to apologize, but I didn’t read your code carefully.

Possible issue in my previous reply doesn’t have any direct connection with your code. Please ignore it.

According your reading address 0x107F00, D-Flash part for EEEPROM is correctly formatted.

I looked again on you code and I discover that you used driver which emulated EEPROM by software.

This is quite strange solution due to fact, that S12XE family already has emulated EEPROM solved on hardware side. So, finally you have two independent emulated EEPROMs.

In fact, your code divided 32kB of D-Flash into two parts (DFPART=0x40, ERPART=0x08). So, upper 16kB of D-Flash is used for hardware EEEPROM and lower 16kB you used for software EEEPROM.

Function IEE1_Partition() partitioned D-Flash into two part during first run and it also enable hardware EEEPROM after every reset (when we call IEE1_Init).

Issue1: Function IEE1_Partition() use Full Partition D-Flash command (0x0F). This function erases whole D-flash and partition that. Unfortunately this command cannot be used in normal mode (it works only in special mode). So, correctly you should during first run erase D-Flash by command loop with Erase D-Flash Sector command (0x12) and call Partition D-Flash command (0x20).

Note: I would like to recommend also add testing address 0x107F00 for check whether D-flash part dedicated for hardware EEEPROM was formatted correctly.

Unfortunately I am not sure what could be reason for software EEEPROM failure on your side. It may be some software issue or you simply reach maximum number of write cycles into D-flash. Could you please estimate how many times you called sauv_config() function until first issue? Also information about amount of stored bytes could help to estimate whether reach maximum number of write cycles into D-flash.

Anyway, I would like to recommend use built-in hardware emulation of EEPROM. You can simply write and modify your data into Buffer RAM (0x13F800- 0x13FFFF in your case) and all these changes will be applied to nonvolatile memory on background without any CPU or XGATE intervention.

In attachment you can find short description of hardware emulated EEPROM at S12XE, and example codes.

Note: If we want wait until data are stored into D-Flash (for example prior reset), we could use command like: while((ETAG > 0) || (FSTAT_MGBUSY == 1)); //we can wait till data are stored to D-Flash

I hope it helps you.

Have a great day,
RadekS

Re: MC9S12XEP100 Emulate EEPROM

eric92 — Fri, 07 Aug 2015 09:41:34 GMT

Hi Mr Radeks,

Thank you for these precious information

The bytes number written to each call of sauv_config call () function is 210 (decimal).

The number of function call before problems occur can be estimated at 55 000 (decimal) or more.

Thank you for code examples.

The IEE1.c module was generated by Processor Expert. I do not know why he did not use the hardware emulation.

I had already seen the AN3743 application note. I was completely lost because I did not understand the link with the IIE1.c. Module.

I realize I should not have used the PE function

Have a good day

Re: MC9S12XEP100 Emulate EEPROM

RadekS — Fri, 07 Aug 2015 13:25:42 GMT

Hi Eric,

Thank you for these details.

16kB D-Flash has 64 sectors. In you code it also presents 64 virtual pages. I didn’t analyze sauv_config() deeply, but I see that this function contains write function on more than one place. I will now calculate with 3 writes per sauv_config() function execution as worst case.

So, if all data was written subsequently it presents approximately 55000*3/64 cycles = 2578 write cycles on page. From this point of view, it is possible that D-Flash is not damaged yet.

Anyway, if you want fix code and use this MCU again, I would like to recommend mass-erase of MCU (it erases also partition configuration, you could use unsecure procedure for that) and test whole D-Flash prior using it (write zeros and ones and read whether all bits are OK, of course we should check also ECC flags during/after reading).

I thing, that EEEProm driver in PE isn’t so bad, but rather "too universal" (we are still not sure if this stop works due to error in driver or due to hardware limitation in number of write cycles). Driver was written for work both ways (hardware and software) and it probably just depends on some configuration which approach will be used. Anyway, for using it at hardware emulated EEPTOM, it is unnecessary complicated tool.

Code related to hardware emulated EEPROM could be detect by testing memory range IEE1_EEE_START…IEE1_EEE_END and it presents approximately 5% of IEE driver only…. Therefore it could be simply overlook.

I hope it helps you.

Have a great day,
RadekS