Hi,
Please note that CryptoCell-312 is capable of issuing AHB burst transactions, which can help mitigate this issue.
Specifically, the CC3XX AHB master supports INCR4 burst transactions, and this is automatically managed by the CC3XX DMA driver. You can refer to the following code in platform/ext/target/arm/drivers/cc3xx/low_level_driver/src/cc3xx_dma.c:
```
/* Force single transactions for restricted addresses */
if (is_addr_burst_restricted(remap_output_addr)) {
P_CC3XX->ahb.ahbm_singles = CC3XX_AHBM_SINGLE_TRANSACTIONS;
} else {
P_CC3XX->ahb.ahbm_singles = CC3XX_AHBM_BURST_INCR4_TRANSACTIONS;
}
```
When CC3XX_AHBM_BURST_INCR4_TRANSACTIONS is selected, the CryptoCell AHB master may issue INCR4 bursts, transferring data in 128-bit chunks. This results in full-width SRAM accesses and therefore avoids SAM partial-write events in the typical case.
There are, however, several important caveats:
- Even when INCR4 bursts are enabled, the AHB master may still fall back to single 32-bit transfers if address alignment requirements are not met.
- Depending on the system integration, downstream interconnects or bridges may not preserve burst transactions and may instead split them into single transfers. This behavior is outside CryptoCell’s control and depends entirely on the hardware topology.
If the issue cannot be resolved at the RTL or interconnect level, a software workaround is possible:
1. Temporarily pause the SAM partial-write event before starting any CryptoCell DMA operation.
2. Wait for the DMA transfer to complete.
3. Execute a DSB, then use the CPU to perform a 64-bit read–modify–write sequence to recompute ECC for the entire region written by the DMA.
4. Execute another DSB and re-enable the SAM partial-write event.
This workaround is clearly sub-optimal from a performance standpoint, but it may be useful as a fallback if the hardware cannot guarantee full-width writes.
Best regards,
Amjad
From: 김륜현 via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 14 January 2026 08:23
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Handling the SAM partial write
It seems that something issue occurs in mailing system.
Anyway, i checked Amjad's answer in "Re: TF-M Digest, Vol 87, Issue 11".
Also, i checked M-AXI that can issue 64bit transaction for normal memory in Cortex-M55 TRM.
As you mentioned, the core performs 32bit write-back and actual write to SRAM is performed as 64bit transaction using the cache and M-AXI between the 32bit core and the SRAM.
But, another issue remains
Crypto Cell-312 internal DMA has hardware fixed 32bit data width.
It raise partial write event when doing decryption to provisioning data.
Example for this issue can be founded in validate_and_unpack_encrypted_bundle()@bl1_provisioning.c.
To transfer decrypted output to SRAM, it uses internal DMA in CC312.
Should i apply any way to workaround such as no using CC312 DMA or modifying bus width in our situation?
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: 김륜현 <winxp4333@adtek.co.kr>
받는 사람: tf-m@lists.trustedfirmware.org
날짜: 2026-01-09 14:40:45
제목: Handling the SAM partial write
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