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.

MSP430F2617: faulty RAM bit influenced by neighborhood

Part Number: MSP430F2617

We have found a MSP430F2617 microcontroller with faulty bits in the RAM memory. After a lot of debugging, it appears that the faulty bits are influenced by the values of their neighboring bits (as described below).

The batch is the following:
76ARXZTG4

Going into detail, the faulty bit occurs at address 0x1A6A, where bit6 does not retain the value that is attempted to be written:
After writing 0x10, we read 0x30
After writing 0x20, we read 0x00
... and so on. It appears that bit5 is copying from bit4. We found exceptions to this rule, apparently with a certain dependence on the adjascent WORD. There is also a faulty bit at address 0x1A6C with a similar behavior.

Testing some pieces of code that should detect the fault, we came across some stranger behavior. The following assembler code writes value 0x5555 at address 0x1A6A (&p), and next compares the content of 0x1A6A precisely with 0x5555 (to check the retention).
\ 000008 1D42.... MOV.W &??p, R13
\ 00000C 8D930000 CMP.W #0x0, 0(R13)
\ 000010 BD4055550000 MOV.W #0x5555, 0(R13)
\ 00001C BD9055550000 CMP.W #0x5555, 0(R13)

Watching at address 0x1A6A in the debugger we see that after the writing instruction, the value recorded at 0x1A6A is 0x7555 rather than 0x5555, because of the faulty bit. We expected to catch this fault with the subsequent comparison, but the comparing instruction returns true, as if 0x5555 were recorded at 0x1A6A. Is it not fetching the value from the RAM but rather from a buffer?

We found a way around it by inserting a dummy memory access (to address 0x1100) in between the writing and the comparing instructions:
\ 000008 1D42.... MOV.W &??p, R13
\ 00000C 8D930000 CMP.W #0x0, 0(R13)
\ 000010 BD4055550000 MOV.W #0x5555, 0(R13)
\ 000016 B24005000011 MOV.W #0x5, &0x1100
\ 00001C BD9055550000 CMP.W #0x5555, 0(R13)

With this code the failure is detected (comparison of 0x5555 with the content at address 0x1A6A returns false), though there is no logical difference from the previous code. What could be the reason which makes the first code not detect the failure?

I appreciate if you can answer these questions:
1. Have you had particular RAM faults with this batch, or other batches? Do you have a percentual estimation of faulty RAMs released in the MSP4302617 line?
2. Can you list which tests you do to the RAMs and what is the percentage of coverage?
3. Can you explain the behavior described, especially why the first code does not detect the fault?

Thanks in advance

  • Hi Alberto,

    thanks for your detailed message.
    I feel this will require further investigation on our side and this is why I'll loop in our Quality Team to check if we are aware about any issues with regards to RAM or the batch you've mentioned.

    I might need to get you in contact with the Quality Team directly so I'll add you as a contact to exchange e-mail details via personal messages instead of the forum.
    Please excuse any delay resulting from TI internal investigation of this issue.

    Best regards,
    Britta
  • Hi Alberto,

    as per request by our Quality Team please get in contact with your distributor and make him aware of your issue.
    The distributor will then get in contact with TI and trigger the official investigation of your issue.
    Please let me know in case this process is not feasible for you but notice that it is the official procedure in place for those cases.

    Thanks and best regards,
    Britta
  • Hi,

    as I didn't hear back from you in a while I assume that this procedure will work for you.
    Note that I'll go ahead and close this thread here for now to have this followed up offline.
    Please reply back to this or open up a new thread in case further assistance is needed.
    Thanks.

    Best regards,
    Britta