Urgent Technical Inquiry – M95320-A125/A145 ECC Behavior, Write Endurance and Data Integrity in Field-Deployed Products

[Rabia DOĞAN]

Dear STMicroelectronics Support Team,

We are currently investigating a potential EEPROM data integrity issue involving the M95320-A125/A145, and we would appreciate your urgent technical guidance.

Our product is already deployed in the field, making this issue particularly critical.

1. Application and Write Scenario

Our application uses the M95320 EEPROM, and we repeatedly write data to address 0x1CF.

The relevant ECC group is 0x1CC–0x1CF, as described in the Error Correction Code (ECC × 4) section of the datasheet.

Our SPI trace confirms that the application sends a single data byte when writing to address 0x1CF. We do not explicitly write to the other three addresses in this ECC group.

The relevant SPI transaction is:

MOSI: 02 01 CF F8

Where:

• 0x02: WRITE instruction

• 0x01CF: Starting address

• 0xF8: Single data byte

According to the datasheet, although a single byte can be written independently, the other three bytes in the same ECC group are also affected in terms of write cycling.

2. Application-Level Data Protection

Our application does not implement any additional data protection specifically for the ECC-related behavior described above. In particular, we do not have an independent mechanism that can guarantee the integrity or recovery of neighboring bytes if their stored data becomes corrupted.

We would therefore like to understand how the IC behaves internally when repeated writes consume the endurance budget of an ECC group.

Could you please clarify the following points?

1. Behavior when the ECC group endurance limit is reached

If repeated writes to 0x1CF exhaust the write endurance budget of the 0x1CC–0x1CF group, what behavior should we expect from the IC?

• Will subsequent write operations continue to be accepted?

• Can the IC report any status or error indicating that the endurance limit has been reached?

• Can write operations appear to complete successfully while the stored data is no longer reliable?

2. Integrity of neighboring bytes

If the endurance of the ECC group is exhausted, can the other three bytes (0x1CC, 0x1CD, and 0x1CE) become corrupted or unreadable, even though the application does not explicitly write to those addresses?

Could this affect data stored in other logical NvM blocks that share the same ECC group?

3. ECC correction capabilities and limitations

The datasheet states that ECC can detect and correct a single-bit error within a four-byte group.

If the memory cells become degraded due to repeated write cycling:

• Can ECC still guarantee correct data retrieval?

• What happens if the errors exceed the correction capability of ECC?

• Is an uncorrectable error reported to the application, or could incorrect data be returned without an explicit error indication?

4. Read behavior after endurance degradation

If the ECC group's write endurance limit has been exceeded, can read operations return incorrect data even if no additional write operation is performed?

Can the IC distinguish between valid data, corrected data, and uncorrectable data through any status register or other interface?

5. Recommended mitigation

Given that our product is already deployed in the field, what mitigation strategies would ST recommend to reduce the risk of data corruption or loss?

In particular, we would appreciate guidance on:

• Repeated single-byte writes within an ECC group.

• Managing write endurance when frequently updated and rarely updated data share the same ECC group.

• Any recommended operating limits or diagnostic procedures for identifying potential degradation.

4. Request for Urgent Assessment

Since the product is already deployed in the field, we need to determine whether this behavior could lead to data corruption or loss during normal operation.

We would appreciate a detailed technical explanation of the IC's behavior under these conditions, including any limitations of ECC and the expected behavior after the write endurance budget of an ECC group has been consumed.

We can provide the relevant SPI traces and the exact EEPROM configuration for further investigation.

Thank you for your support. We look forward to your urgent technical feedback.

Best regards,

[TDK]

(I’m not ST and this forum is not a direct line to them. If you want to submit a ticket, do so here: https://ols.st.com/s/)

 

If more than 1 bit is corrupted, the chip has no way of knowing this, so you have no way of being notified. That is the nature of ECC. Bit errors of 2+ are interpreted as bit errors of 0-1. There are ECC schemes that can correct more bytes, but this one is explicitly correcting for single bit errors among a group of 4 bytes.

If the memory cell is degraded to where 2+ bit errors are occurring, obviously there is no way to ensure it still operates correctly. The chip doesn’t know.

To mitigate issues you should avoid hitting the endurance limit. Either by writing less, or spreading out writes, or some other method.