nRF54L15: RRAMC - Error handling

[Radoslaw Koppel]

Hi,

I am developing a project where we wish to use part of the RRAMC memory for logging purpose. The documentation show that the data endurance of RRAMC in nRF54L15 chips is at the level of 1e4. That is surprisingly low giving that the ReRAM chips on the market gives us 5e5 up to 1e6 erase - write cycles. Is it tested value or estimated by the technology. What to expect after exceeding this number of writes. I get it that Nordic chooses the solutions that focuses on low power more than endurance. Just wont to know what I can expect. Would I get any error notification or memory can just fail silently and the value that I read back would not match the value written?

It makes us little nervous about properly implementing file system with wear leveling and marking bad blocks.

I am reading through the documentation: docs.nordicsemi.com/.../rramc.html

Could you please elaborate more about EVENTS_ACCESSERROR event and ECC.ERRORADDR and ACCESSERRORADDR as the documentation I can find is quite limited in that topic and I also cannot find any usage of this registers in the samples. Especially ECC.ERRORADDR seems to be implemented only on HAL level, not used then in the drivers.

As I wish to detect memory failing as soon as possible there are my questions:

EVENTS_ACCESSERROR

When would be generated. May I expect it to be generated if the write fails? Or would it be generated only if the memory cannot be read? Would it be generated if the ECC fails to recover?

ACCESSERRIRADDR

Would it also cover ECC errors or ECC errors are present only in ECC.ERRORADDR.

ECC.ERRORADDR

Is is connected with EVENTS_ACCESSERROR? Documentation says that the event ECCERROR is generated. I cannot find ECCERROR event in the documentation.

[Einar Thorsrud]

Hi,

I need to check internally on most of this as it is not publically documented, and will get back to you. Regardign the additional question, all writes to the 128 bit word line counts, even if you do not flip the same bit more than once.

[Radoslaw Koppel]

Thank you. I am designing the file system keeping this in mind. Still waiting for the response related to the events. The layout design is close to be ready - and I would really like to start coding it in the next week.

[Emil Lenngren]

If you are designing a file system, maybe you would like to know a few findings I made about the RRAM regarding power loss:

When RRAM is written to, it appears it first sets all bits to 1 in all the 128-bit words that are part of the buffered write, from low address to high address, that shall be 1 in the new value but was 0 before. Then, all bits are set to 0 that were 1 before in the old value but shall now be 0 in the new value, from low address to high address. Bits that are not modified are thus left untouched. This was observed by cutting the power in the middle of a write to RRAM and then inspecting the content after powering up again. During this test, I never observed any changes of the ECC.ERRORADDR register; it was always 0.

That is also why I wonder a bit how the ECC works, e.g. if it might impact what's said above, perhaps by flipping non-changed bits due to the ECC correction algorithm.

[Radoslaw Koppel]

Thank you for sharing your findings. I had expected that after power loss the whole line can be lost. But your analysis is very detailed. Basically I am treating single line as a single unit and designing the whole system in a way, if any of such units is lost, the whole file will keep the integrity.