MPC5554 Internal Flash Error (when erasing)

[fbdog]

Hello, 

I am coming across a "bus error" in my Trace32 debugger (and subsequent data exception) when a portion of my code is trying to erase the high address block (0x80000) of the internal flash on the MPC5554.  

This only occurs with two examples of my hardware.  Many other cards (hundreds) running the same code does not experience this problem.  Just wondering if anyone has come across this situation and if there was a fix/explanation for this?  

I've come across another thread that is somewhat related:

https://community.nxp.com/message/482746?q=MPC5554%20internal%20flash 

My first instinct was a bad MMU setting etc, but the overwhelming majority of hardware we have come across have no issues, so I tend to believe my code is OK and think this is a unique situation isolated to these cards.

Appreciate any help.  Thanks in advance,

Jerry

[fbdog]

Hi Lukas,

Thanks for your response.

- I dumped the register settings (incl. MMU setup and everything looks normal per my code). 

- I still see bus errors (via Trace32 debugger) in the high address block (0x80000), but everything is OK up to 0x7FFFF.

- This is a new board with a new MPC5554, so I don't believe an erase has ever been performed on the chip before.

- I went ahead to use Trace32 and erase the chip (without any errors) and no more bus errors were shown at 0x80000.  I still have one more "bad" example of this hardware, but I'm still left wondering what caused the flash to be in this state in the first place. 

Thanks

[lukaszadrapa]

Hi Jerry,

if it is brand new chip, whole flash should be fully erased. This is guaranteed state when shipped from factory. There definitely shouldn't be ECC errors on new chip.

ECC errors can occur if erase or program operation is terminated by unexpected reset, during overprogramming (programming area which is not fully erased) or due to wear-out. Flash can be recovered by erase (except wear-out when the flash is already damaged).

So, it depends on history of the chip and also on storage conditions (spec can be found in the datasheet).

By the way, it's recommended to erase the chip when programming an application in factory to achieve max data retention (data retention is counted from last erase).

Or if you feel it's quality incident, then I would recommend to go back to your sales point and ask for failure analysis.

Regards,

Lukas

[lukaszadrapa]

Hi,

just a couple of hints:

- I would place a breakpoint at begging of exception handler which is triggered by the bus error. Once the code stops here, I would double-check the MMU settings.

- Then you can try to check the memory block in Trace32 using memory window. Can you see any bus errors here?

- How many times have you erased/programmed the block? Is it possible that you exceed guaranteed number of cycles?

Regards,

Lukas