Hi RyunHyeon,
Thanks for raising this, your understanding is correct.
On RSE with ECC-protected SRAM, partial writes (e.g. 32-bit stores) cannot update ECC atomically. When SAM partial-write detection is enabled, the firmware must perform a read–modify–write of the full ECC granule (64 bits) to recompute and restore a valid ECC value. Doing this in software for every partial access would indeed be prohibitively expensive, especially for stack and heap usage where 32-bit accesses are very frequent on Cortex-M55.
To avoid this overhead while keeping SAM enabled, the recommended approach is to place a cache between the Cortex-M55 and the SRAM. The CPU can continue to issue 32-bit accesses, while the cache aggregates them and performs aligned 64-bit transactions toward SRAM. From the SRAM/SAM point of view, accesses are full-width and generate valid ECC, so SAM partial-write events are avoided in the common case.
With this setup, SRAM can safely be used as a normal data region, without the performance penalty you described. Disabling SAM or avoiding SRAM for data is not the intended solution.
I hope this clarifies the design intent.
Regards, Amjad
Amjad Ouled-Ameur
Senior Software Engineer
amjad.ouled-ameur@arm.com 110 Fulbourn Rd, Cambridge CB1 9NJ
[A black letter r with white background Description automatically generated]https://www.arm.com/
[A black letter f on a white background Description automatically generated]https://www.facebook.com/Arm
[A black and white logo Description automatically generated]https://www.linkedin.com/company/arm
[A black and white logo Description automatically generated]https://www.instagram.com/arm/
[A black x with white lines Description automatically generated]https://x.com/Arm
[A black and white play button Description automatically generated]https://www.youtube.com/user/Armflix
________________________________
Date: Fri, 9 Jan 2026 14:40:45 +0900 (KST) From: 김륜현 winxp4333@adtek.co.kr Subject: [TF-M] Handling the SAM partial write To: tf-m@lists.trustedfirmware.org Message-ID: 1299976795.188898.1767937245869@gwsrv Content-Type: multipart/alternative; boundary="----=_Part_64610_764352995.1767937245794"
Hi all,
I'm developing the RSE Firmware based on rdv3r1.
I have a concern about the SAM(Security Alarm Manager).
Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value,
it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address.
After that, it clears the SAM captured address register and SAM event.
In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap.
Because 32bit access frequently occurs in 32bit architecture.
Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like?
Best Regards RH Kim
