MPC5644A_0M14X Errata - Erratum e3659 Flash Erase Suspend/Resume

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5644A_0M14X Errata - Erratum e3659 Flash Erase Suspend/Resume

2,003 Views
ziomocci
Contributor IV

Hi all,

I am working both with MPC5642A (ECU target) and with MPC5444A (Demo board target) and I am using a callback during flash erase operation like this:

uint8_T resumeState;
uint8_T suspendState;
uint8_T suspendFlag = TRUE;
/* Try to suspend the current erase operation */
((pFLASHSUSPEND)FuncPointerSuspend)(&ssdConfig_BK0A0,&suspendState, &suspendFlag);
if(suspendFlag == FALSE)
{
((pFLASHRESUME)FuncPointerResume)(&ssdConfig_BK0A0,&resumeState);
return;
}

/* DO SOMETHING */

((pFLASHRESUME)FuncPointerResume)(&ssdConfig_BK0A0,&resumeState);

I have no problems with ECU target, whereas I notice that using EVB target, erase operations exit with failures

Could this problem be related to the erratum ID e3659? what kind of workaround could be implemenented (to be honest, one described in the Errata is not enough clear/simple for me, expecially about "erase timeout").

Any suggestion would be very appreciated!

Best regards,

Andrea Mocci

Labels (1)
19 Replies

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Hi, e3659 is not present with MPC5642A, Rev 2.1 and higher but it is present with MPC5644A, thus it could be the reason.

For "erase timeout" I would use worst cases stated in the datasheet:

pastedImage_1.png

I will try to find out some details.

0 Kudos

1,492 Views
ziomocci
Contributor IV

Yes David,
In fact, as written in the first post, I got out flash suspend/resum problems only using the MPC644A.
Same source code that works correctly with MPC642A, does not work with MPC644A (erase is not performed!!!) 

0 Kudos

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Hi, could you explain more is detail how actually the problem manifest? Which kind of problem happens in case FlashResume operation? Is the issue happening always or sometimes?

0 Kudos

1,492 Views
ziomocci
Contributor IV

Hi David,
The problem happens ALWAYS while executing the callback (note that ssd drivers and the same callback are first copied in RAM and then executed from RAM) with the MPC5644A.
The same callback (but with different ssd drivers, of course) is correctly executed by the MCP5642A; flash erase ends correctly (I can test it with a Lauterbach debbuger) and, moreover, suspend/resume are correctly executed (a simple counter is incremented between a suspend/resume)!!!
Could it be related with SSD drivers? Which is the lastest version for the target MPC5644A?

0 Kudos

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Could you prepare short example code allowing me to replicate the issue here or to report it to someone? Thanks

0 Kudos

1,492 Views
ziomocci
Contributor IV

I have forgotten to tell you erase params 

start address: 0x30000,

size erase: 0x10000 in case of CALIB area re-programming, 0x180000 in case of CALIB+APPLICATION re-programming.

callback: EraseCallback.

No problem wit SSD driver 1.0.3 and MPC5642A, a lot of problems with same code and SSD driver 1.0.4 and MPC5644A

0 Kudos

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

As I understand the erratum (and I guess your issue could be caused by this), I would rather don't use erase suspend/resume at all as it seems dangerous to me because it is stated that "Note: The cycle count of the sector is increased by this abort and restart operation." thus sector endurance could be early achieved.

Otherwise if erase resume operation is not successful within specified max erase time, then it is needed to manually abort the erase operation (by clearing FLASH_MCR[EHV] bit) and start the whole erase sequence from the beginning. This is not included in SSD drivers and it needs to be added by user code.

0 Kudos

1,492 Views
ziomocci
Contributor IV

Hi David,

 

 Do you have good news after two weeks?

0 Kudos

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Hi, haven't you tried to implement proposed solution?

1,492 Views
ziomocci
Contributor IV

Hi David,

No news after all that time? Have you or your team colleagues find out any workaround? At the moment we have internally decided to avoid callback usage during flash erase, considering that the at the SOP, system will be released with an MPC5642A.

Anyway, maybe in the future we could re-use an MPC5644A and the problem will occur again.

0 Kudos

1,492 Views
ziomocci
Contributor IV

Hi,

  Your suggestion is less or more one described in the errata addendum. But, to be honest, I do not have any idea where I have to put hand on code; opcodes on the SSD drivers (oh my god....)? Flash APIs? when have I to clear this bit? How could I estimate max erase time?

0 Kudos

1,492 Views
ziomocci
Contributor IV

Hi David,

 Have you tested the sample code? Have you good news for me?

Andrea

0 Kudos

1,492 Views
ziomocci
Contributor IV

Thus all my suspicions were correct. My callback replicates the strange, but well note, behaviour of the errata.
In your second assertion it seems that with a workaround on FLASH_MCR[EHV], not included in the SSD, the problem could be resolved.
To be honest, I do not have any idea where I have to put hand on code; opcodes on the SSD drivers (oh my god....)? Flash APIs? when have I to clear this bit? How could I estimate max erase time? Is it enough?

0 Kudos

1,492 Views
ziomocci
Contributor IV

I have just sent you an email with sample code.

Keep me informed,

Regards

0 Kudos

1,492 Views
ziomocci
Contributor IV

Hi David,

You can find attached files that I am actually using with MPC5642A/4A.

Some considerations:

1) SSD drivers, in our project, ARE ALWAYS EXECUTED FROM SRAM,

2) Erase Callback is copied and executed from SRAM, of course,

3) Callback works well with the MPC5642A, that is, each 2.7/8 seconds I am able to see a CAN message sent inside the callback (it functions as a KeepAlive message

for an external diagnostic tester).

4) FlashErase exits with error code 0x0300, C90FL_ERROR_BUSY, as I have written few seconds ago directly in the post.

Contact me if you need more details.

Regards,

Andrea Mocci

0 Kudos

1,492 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

As I know latest driver for MPC5644A is REV 1.0.4, for MPC5642A it is REV 1.0.3?

Which kind of error it returns to you?

0 Kudos

1,492 Views
ziomocci
Contributor IV

Yes David, I can confirm that ssd versions in use are ones you listed (MPC5644A is REV 1.0.4, for MPC5642A it is REV 1.0.3).

Returned error code by FlashErase is:

C90FL_ERROR_BUSY              0x00000300   /* New program/erase cannot be preformed while previous high voltage operation in progress */

as stated on ssd_c90fl.h header

0 Kudos

1,492 Views
ziomocci
Contributor IV

Two weeks later post publication, none could help me??

0 Kudos

1,492 Views
ziomocci
Contributor IV

Directly extracted from MPC5644A_0M14X, Mask Set Errata, Rev. August 2017

""If the suspend feature (including disable and sleep modes) of the flash is used, then software
should ensure that if the maximum time allowed for an erase operation occurs without a valid
completion flag from the flash (FLASH_MCR[DONE] = 1), the software should abort the erase
operation (by first clearing the Enable High Voltage (FLASH_MCR[EHV] ) bit, then clearing the
Erase read/Write bit (FLASH_MCR[ERS] bit) and the erase operation should be restarted.""

Using MPC5644A,  we have both FLASHA_MCR and FLASHB_MCR, each one with its own subregs (PEG, ERS, ESUS, EHV, etc etc); which one is involved in the workaround? Only FLASHA_MCR ? Only FLASHB_MCR? Both?

0 Kudos