MPC5643L Emulated EEPROM

[sagarmahajan]

Hi Guys,

I am using Emulated EEPROM on MPC5643L. I am using Freescale driver for the same. Facing issue as follows:

- Whenever I am trying to write Emulated EEPROM while my program is running micro resets.

- Reset is not consistent that it happens every time. May be once in an hour.

Is it seems to be timing issue?

Is it because of frequent writing to Emulated EEPROM?

Is it because page swapping?

I will ready to provide more inputs if required.

What could be wrong? Need comments/recommendations.

Thanks

Amar

[lukaszadrapa]

Hi,

my guess is that it is caused by read-while-write error.

Read-while-write is supported only between partitions. It is not possible to access partition which is being programmed/erased. Such access is terminated by bus error.

Are you sure that you don't access partitions allocated for the EEPROM during flash operation? Which blocks have you used?

Do you handle IVOR1 exception? Have you tried to put a breakpoint to IVOR1 handler to catch that issue? My guess is that it could fall to IVOR1...

And the last thing - what is the content of RGM_FES and RGM_DES after reset? These registers show the source of last reset.

Regards,

Lukas

[sagarmahajan]

Hello,

First of all thanks for your response in details and asking questions.

My understanding is we do not do read while write. (I will check in more details).

We are using Low Address Space block L4 and L5. (0x00020000 & 0x00030000). So we are using partition 2 only. Also to add we are using freescale ee driver to deal with EEPROM. My understanding is as we only use one partition so there is no question of accessing  partition. Please correct me here if my understanding is incorrect.

Since this issue, I configured IVOR and wrote my functions in All IVOR to get information on CAN to know which IVOR it had been to as soon as reset occurred. I am not getting any thing out on CAN as of now. May be it is not getting time to through out on CAN by the time reset happen. I did not tried with debugger, i will try that. Also struggled with IVOR configuration as there is no sample code available anywhere at least i did not saw any where. (Please share if you have any.) The sample code i did to configure IVOR as below:

***********************************************************************************

asm void ivor_branch_table_p0(void) {
nofralloc
.align SIXTEEN_BYTES
IVOR0trap: b SafeRTOS_ApplicationErrorHook1 /* Critical Input interrupt handler */

.align SIXTEEN_BYTES
IVOR1trap: b SafeRTOS_ApplicationErrorHook2 /* Machine check / (NMI) interrupt handler */

.align SIXTEEN_BYTES
IVOR2trap: b SafeRTOS_ApplicationErrorHook3 /* Data Storage interrupt handler */

*****************************************************************************************************************************************

I tried reading register RGM_FES and RGM_DES but not getting any content. Looks like getting cleared while restart. This section I need to understand in more details.

However I see some functions which clears those register by writing 1 (FF's) using function __clearFaultFlags() inside file MPC5643L_HWInit.c. I am working on that to stop clearing this. 

Please provide your comments if any on this changes and how to handle it.

Looking forward to your response.

Thanks

[lukaszadrapa]

Hi Amar,

regarding partition - yes, your understanding is correct. This should be ok.

SW example can be found in this application note:

https://www.nxp.com/docs/en/application-note/AN5200.pdf

https://www.nxp.com/docs/en/application-note-software/AN5200SW.zip

There's example directly for MPC5643L:

..\AN5200SW.zip\Example_4_MPC5643L-2b_RAM+2b_FLASH_ECC_error_injection-CW210\

See exceptions.c and main.c files and search for "IVOR1_handler" keyword.

ivor_branch_table_p0 is supposed to be used on e200z0 cores where the IVOR offsets are hardwired.

If RGM_FES and RGM_DES are cleared somewhere in your projects, try to change this code or log the values before clearing.

If you can run the application with debugger connected, the easiest option (for beginning, at least) is to put a breakpoint to IVOR handlers, so you can easily check the core registers to find the root cause.

Regards,

Lukas

[sagarmahajan]

Thanks Lukas. Your reply is really useful.

Thanks again.