EEE error handling

[adelantesey]

Hi,

I've got a question regarding the EEE error handling. What should be done when facing the errors reflected by in FSTAT (ACCERR, MGSTAT0, MGSTAT1) and FERSTAT (especially ERSVIF0 & ERSVIF1) registers? The AN3490 (page22) explains that some of them (i.e. ERSVIF0 & ERSVIF1) are a limp home condition for EEE but it doesn't give a strategy or solution when facing these error. Can anybody please help me what should be done in these cases? I really appreciate your help.

BR,

[lukaszadrapa]

Hi,

most of the errors that will set ACCERR or MGSTAT bits are clear, I think (referring to description in AN3490). All of them are caused by wrong initialization and you should catch them already during developing and debugging the application.

If ERSVIF bits are set, the application itself cannot recover the EEE. It just says it is time to turn on the red light and ask for service. In normal single chip mode it is not possible to re-format the EEE, so it is necessary to connect BDM device and execute Full Partition D-Flash command. If it still doesn't work then we probably exceeded lifetime of the flash (number of program-erase cycles) and it is necessary to replace the device.

Best Regards,

Lukas

[adelantesey]

Hi,

Thank you Lukas for your answer.

I want to know what about EPVIOLIF? How can it get set while I surely do not set any protected area for buffer RAM EEE partition?

Also generally what leads to setting of the flags in FERSTAT (especially ERSVIFs and EPVIOLIF), and what should be done in software to prevent this to happen?

And what’s the solution, if these flags are set despite all the efforts we make to avoid it? I mean, for instance, is making the MCU to be reset by COP useful in this situation or something else should be done?

[lukaszadrapa]

Hi,

sorry for delay, I was not able to reply earlier.

EPVIOLIF should be set only if protection is enabled. Could you check the content of EPROT register if it really gets set?

ERSVIF flags are set when the memory controller is unable to re-format sector or change the state of sector. All you can do is power-off and power-on and then see if the EEE works. If not, it is necessary to reformat partition via BDM or replace the device.

And how to avoid this problem? Main reason is too many write cycles - i.e. wear out of the flash. So, it is necessary to carefully calculate the lifetime of EEE. Here is the calculator that could help to estimate the lifetime:

https://www.freescale.com/webapp/Download?colCode=S12XE_EEE_CALCULATOR&location=null&fasp=1&WT_TYPE=...

Regards,

Lukas

[adelantesey]

Thank you for spending your time on this.

When the EPVIOLIF is set, the EPROT value is equal to 0x70. However, surely I do not protect the EEE RAM (EPROT value is equal to 0xFF). This violation happens rarely (after a software reset) but is out of my control. What do you think can be the source of protection violation error?

About ERSVIF, by “re-formatting” do you mean “repartitioning” or something else?

[lukaszadrapa]

Hi,

I can't see any reason why the EPROT should be changed. I did a lot of tests with the EEE in the past but I have never seen something like that.

EPROT is loaded from flash during reset (global address 0x7F_FF0D). If the phrase at this address is corrupted by double bit fault ECC error then the EEE RAM is automatically fully protected - EPROT is set to 0x7F. In normal single chip mode the EPROT can be written only to protected state. To write the EPROT to unprotected state it is necessary to use special single chip mode. There are no other options.

I would try to set watchpoint at EPROT to catch accidental write or maybe I would check the EPROT before each write to EEE RAM in order to find possible bug in SW. Unfortunately I do not have other ideas now.

Yes, I mean "repartitioning".

Regards,

Lukas

[adelantesey]

Hi,

As you mentioned before and is written in AN3490, ERSVIF0 is set when the memory controller is unable to reformat an EEE NVM sector and ERSVIF1 is set when it is unable to change the state of an EEE NVM sector; so what is the difference of these two (I mean reformatting and changing the state of a sector)? Besides, how can memory controller understand that a sector cannot be reformatted or change its state?

I also recently read the user manual “the EEPROM Emulation Driver for 0.18um SGF Flash in 12XS, S12P, and S12HY” and the related demo code. Is this the code on which the EEE unit of the MC9S12XEG128 is based? Are there any other manuals that explain the MC9S12XEG128 EEE functionality in details?

BR,

[lukaszadrapa]

Hi,

that means the memory controller is unable to either erase the flash or program the flash - that can be easily recognized, of course.

“the EEPROM Emulation Driver for 0.18um SGF Flash in 12XS, S12P, and S12HY” - this has nothing to do with Emulated EEPROM feature that is implemented on S12XE family. On S12XE family, there's internal memory controller that executes firmware (not visible for user) that takes care about the EEE process.

Mentioned driver is something similar but it is pure software solution - that's user software running on CPU. This is not firmware that is running in memory controller on S12XE.

Only AN3490 is available.

Regards,

Lukas