iac exception on stm32mp257f.ev1 using SFRs on CubeIDE to inspect HPDMA3 registers

[MBassi]

Hello,

on a stm32mp257f-ev1 board I'm developing a non secure M33 firmware using hpdma3.

I configured hpdma3 on optee RIF DT to be used only by M33 (CID2) for all channels as follow

&hpdma3 {
	st,protreg = <
		RIFPROT(RIF_HPDMA_CHANNEL(0), RIF_UNUSED, RIF_UNLOCK, RIF_NSEC, RIF_NPRIV, RIF_CID2, RIF_SEM_DIS, RIF_CFEN)
.........................................................................................
.........................................................................................
		RIFPROT(RIF_HPDMA_CHANNEL(15), RIF_UNUSED, RIF_UNLOCK, RIF_NSEC, RIF_NPRIV, RIF_CID2, RIF_SEM_DIS, RIF_CFEN)
	>;
};

When I debug the firmware on CubeIDE if I try to inspect HPDMA3 registers using "SFRs" tab I get on linux console iac exceptions of this type:

E/TC:0   stm32_iac_itr:192 IAC exceptions [159:128]: 0x200000
E/TC:0   stm32_iac_itr:197 IAC exception ID: 149
E/TC:1   stm32_iac_itr:192 IAC exceptions [159:128]: 0x10000000
E/TC:1   stm32_iac_itr:197 IAC exception ID: 156
E/TC:1   stm32_iac_itr:192 IAC exceptions [159:128]: 0x200000
E/TC:1   stm32_iac_itr:197 IAC exception ID: 149

 I think there is something wrong with HPDMA3 RIF configuration, but I cannot understand the whole messages:

- Which's the difference between "E/CT:0" and "E/TC:1"?

- Where I can find the meaning of hex codes at the and of each message?
I tried reading the "How to analyze IAC & SERC errors" guide but I don't found informations on points above.

Last question is: how can I update RIF configuration to avoid these iac excepections?

Regards

Marco.

[VishalC]

Hi Marco 

1. Log Prefix Meaning
The log prefix E/TC:0 is from OP-TEE (Open Portable Trusted Execution Environment).

E stands for Error log level.
TC means Trusted Core (the main OP-TEE secure world component).

NOte: These are prefix set for error messages during OPTEE panic logs with thread ID and etc. (not very important for the time being, lets try to understand first how the exception occured)

2. Hex Codes in Messages (Panic Logs)

The hex value (e.g., 0x200000) indicates the register bit position of the peripheral for which the IAC (Illegal Access Controller) exception occurred.
The exception ID (e.g., 149) corresponds to the peripheral ID for which the illegal access has been triggered. For example, 149 is HPDMA3 and 156 is RCC.
You can refer to the STM32MP25 reference manual, chapter 9 ("Resource isolation framework security controller (RIFSC) and Illegal access controller (IAC)") for register-level details and peripheral IDs.

3. Why SFR Access Causes IAC Exceptions
HPDMA3 is a RIF-aware IP. While some channels are allocated to CID2 (M33), not all are.
When you use the SFRs tab in the debugger, it tries to read all registers in the HPDMA3 instance from the M33 NS core. This causes illegal access exceptions for registers not accessible by M33 NS.

Recommendation:
To avoid these exceptions, only access and configure the allowed HPDMA3 channels through your code or the debugger’s expression window, rather than opening the entire SFR instance.

4. To address how you can update the RIF configuration to avoid these IAC exceptions:

First, I’d like to understand in detail how you are configuring HPDMA3 channel or using it within the Cube firmware you are developing. The way resources are accessed and configured in your firmware can directly impact whether illegal access exceptions (IAC) are triggered by OP-TEE.

As you mentioned, opening the HPDMA3 instance through the SFRs tab in the debugger perspective will almost certainly cause IAC exceptions, since it attempts to access all registers in the peripheral, including those not permitted for M33 NS. I recommend using the previously suggested methods—accessing only the allowed channels via code or the debugger’s expression window—to avoid these exceptions during development.

Once you confirm your access pattern and configuration, we can better determine if the issue is with the RIF configuration itself or with how the peripheral is being accessed. Please share more details about your Cube firmware setup and resource usage, and we can proceed to analyze and adjust the RIF configuration as needed.

Hope this clarifies your questions!

Regards

Vishal.

[MBassi]

Thank you @VishalC for the extensive and deepened reply. It helps me a lot on better understanding the exceptions

Going on with the firmware tests, I can confirm that IAC exceptions appear only when reading hpdma3 registers through SFRs tab, except from that firmware run well, so I think the solution you recommended in point 3 suits for debugging my firmware, and there isn't any misconfiguration on hpdma3 RIF access rights.
Anyway about hpdma3 configuration on A35 side: every channel in RIF DT is configured as written in my previous post.

On M33 firmware hpdma3 is configured for using channels 12, 13, 14 for memory-to-memory transfers: Channel 12 is used to transmit data of different size from M33 data structure to a shared buffer with an A35 application, channel 13 is used for receiving data from a second shared memory buffer, filled by A35 application; aim is implementing a loopback test between M33 and A35. On A35 application for now a simple memcpy is used instead of hpdma for reading data from the first shared buffer and write it back to second; IPCC is used to know when a processor could read/write from/to a shared buffer. The time spent for data exchange is computed by M33, and transmitted to another A35 application through a third shared buffer using channel 14, for saving measured times in .csv files. 

hpdma3 channels configuration details are in attached files.

Regards

Marco.