This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSC1210y5 Flash Memory Failure

Hi guys,


I'm handling the customer return of our product. Usually it is pertaining single or double bit flipped. The most recent one is quite unusual, from the memory dump, the entire code is gone! I'm seeing the entire memory as "0xFF" only.


Is it likely that the flash decoder or the charge pump is damaged? Is there anyway (not by re-programming) to verify what type of failure on the chip? Do you provide memory forensic service? Thanks.


Rgds,

Teik Eng

  • Hi Teik Eng,

    It is unlikely that the Flash would be entirely erased unless the MSC1210 was commanded to do so with the mass erase command.  About the only thing we can do to analyze the memory is to run pattern tests.  I'm not sure that we are facilitated to run further testing as the Flash is initially tested at the TSMC foundary with wafer probe.

    Have you been able to see if non-program memory is erased?  One way to do this is to issue 'F70' in serial programming mode from a console terminal prompt.

    Best regards,

    Bob B

  • Hi Bob,

    I'm getting the following:
    >F70
    FF FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF

    Actually the first byte of program memory is 0x03:
    >CR0000
    03 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    The rest are all 0xFF.
    What's a pattern tests?

    While analyzing this unit, I've got another controller return which the Boot ROM is failed.

    Rgds,
    Teik Eng
  • Hi Teik Eng,

    I've discovered that there is possibility for device erasure, but I still don't know the mechanism that is causing the issue.  I think it is related to specific POR conditions and transient events so it is a little hard to find the precise cause and I'm still searching.

    Pattern tests cycle various combinations through memory to look for faults related to specific row/column combinations or for cells that stick to one particular value.  This is more commonly done with RAM, but can also be done with the flash.  I think that in your case we hit the issue that I mentioned above.

    A boot ROM failure sounds like a catastrophic EOS event.  Can you send me the markings on top of both the MSC1210 devices so I can do some further checking as to the device history?

    Thanks,

    Bob B

  • Hi Bob,

    From last May till now, we are having 4 memory corruption cases, The first two indicates bit flipped, we think it is common, hence, didn't further pursue it. The recent two, one with all bytes except one in erased state (0xFF), while the second one demonstrates boot ROM failure. I could not get the marking right away as all controllers are in ceramic MCM. I'm tracing it from MCM supplier and will give you once I've them.

    Are you able to perform pattern test on MCM?
    Thanks.

    Rgds,
    Teik Eng

  • Hi Teik Eng,

    I believe your erasure is due to the issue I mentioned in the earlier posting.  You could try writing the program back into the part and reading it back.  That is the easiest pattern to check first.

    For the device you suspect as having a boot rom failure, how did you determine that the boot rom is the issue?  It is possible that pin settings and the communication lines themselves are potential problems.

    Best regards,

    Bob B

  • Hi Bob,

    These are my findings.
    1) The Erasure Unit:
    The controller is partially good, as I could read back the exact content I flashed in, but I could not execute the test program. The test program supposed to output strings on the same serial port used for flashing.

    2) No Communication Unit (BootROM):
    I've checked ALE, PSEN, RST, TXD, RXD and DVdd. All is well. However, still I could not communicate with the Boot ROM routine.

    I think I would have to remove the controllers and try them on other board. BTW, could I have more any info specific to TI flash memory failure that you could gather? Thanks.

    Rgds,
    Teik Eng
  • Hi Teik Eng,

    Sorry for the delayed response as I'm still investigating the problem.  I'm not sure why your test program is not working.  Have you tried the test program in a known working device to make sure that you have no issues with the test program?  Sometimes the autobaud() function is not called and the MSC1210 will not know which baud rate is being used.

    For the device that is showing the boot rom failure, have you checked to make sure you also have a valid AVDD?  The device will remain in a POR condition until all supplies are considered valid.

    So far in my testing I see issues related to POR where the flash can be corrupted.  I am still trying to define the exact mechanism, but I believe a transient event occurs that partially resets the system but doesn't hold all the control signals in a reset state.  If the flash controller receives an invalid signal at a time when the flash address is being decoded a byte may change values, a page can be erased, or the whole flash can be erased.  The conditions where I was able to make this happen all occured when I forced conditions that exceeded the absolute maximum ratings for the device.  I will give you more specifics as I am able.

    Best regards,

    Bob B