MPC5554 Flash Erase Problem

cancel
Showing results for 
Search instead for 
Did you mean: 

MPC5554 Flash Erase Problem

Jump to solution
694 Views
mehmet_karadeni
Contributor II

Hi,

I am working on MPC5554. And I use eeprom emulation functions. I fill all of the flash block. Then I want to erase block(address: 0x60000) on flash, but after erase, some other datas (except 0xFFFFFFFF) can be random in block. After erase, yes most of the flash area are 0xFFFFFFFF but some area can be random data. And FSL_FlashCheckStatus() functions return EE_OK after erasing. how that happens? And why some area don't erase?

The following images are taken after deleting the flash block.

erase_1.png

erase_2.png

and I use FSL_FlashCheckStatus which is below. that function return EE_OK.

UINT32 FSL_FlashCheckStatus(UINT32 flashRegBase)
{
UINT32 returnCode; /* return code */
/* Initialize return code */
returnCode = EE_OK;
/* Check if MCR DONE is set */
if (READ32(flashRegBase + FLASH_MCR) & FLASH_MCR_DONE)
{
/* Check the operation status */
if (!(READ32(flashRegBase + FLASH_MCR) & FLASH_MCR_PEG))
{
/* high voltage operation failed */
returnCode = EE_ERROR_PE_OPT;
}
/* End the high voltage operation */
CLEAR32(flashRegBase + FLASH_MCR, FLASH_MCR_EHV);
/* Check for program operation */
if (READ32(flashRegBase + FLASH_MCR) & FLASH_MCR_PGM)
{
/* Finish the program operation */
CLEAR32(flashRegBase + FLASH_MCR, FLASH_MCR_PGM);
}
else
{
/* Finish the erase operation */
CLEAR32(flashRegBase + FLASH_MCR, FLASH_MCR_ERS);
}
return (returnCode);
}
return (EE_INFO_HVOP_INPROGRESS);
}

Best Regards.

Labels (1)
1 Solution
502 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

the most common reason for such behavior is cache memory. The cache memory should be disabled or the areas used for EEE should be configured as cache inhibited (using MMU) or it's necessary to invalidate the cache after erase operation.

The fastest way to confirm that it is caused by cache is to set CINV bit in core register L1CSR0 via debugger. This will invalidate the cache and you should see that erased blocks are '0xFFFF' only...

Regards,

Lukas

View solution in original post

5 Replies
502 Views
mehmet_karadeni
Contributor II

Thank you Lukas,

I could not set CINV bit. I dont know why am I could not set CINV bit via debugger? but I set/clear CE bit in the same register. And it works. Thank you your interest. 

0 Kudos
502 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

this is expected behavior:

pastedImage_1.png

Because the invalidation takes about 134 cycles, it looks like the bit is still 0.

Regards,

Lukas

0 Kudos
502 Views
mehmet_karadeni
Contributor II

Hi Lukas,

I set CINV  with mtspr, mfspr in assemly code and I called that function in my c code. I couldn't see CINV value at 1 but yes it is works and after erasing, all of my flash block area is 0xFFFF. (Also I checks CABT bit, and there is no abort.)

But in this situtaion I have a new problem. When I set CINV , my CAN interrupt doesn't work for a little time and my can messages don't transmit in that time.

Why this situation is occurs? And How can I fix this problem? I don't want to any latency or interrupt in my interrupts when doing flash invalidate.

Thank you for your interest.

Regards.

0 Kudos
502 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

this looks like some performance issue. When the cache is invalidated, physical memory needs to be read now to fill the cache again. This will slow down the operation, of course. If you have a lot of other interrupts, you may see some performance degradation. This must be solved on application level. You can try to change the priorities, for example.

Regards,

Lukas

503 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

the most common reason for such behavior is cache memory. The cache memory should be disabled or the areas used for EEE should be configured as cache inhibited (using MMU) or it's necessary to invalidate the cache after erase operation.

The fastest way to confirm that it is caused by cache is to set CINV bit in core register L1CSR0 via debugger. This will invalidate the cache and you should see that erased blocks are '0xFFFF' only...

Regards,

Lukas

View solution in original post