STM32MP257F-EV1 The program of the new project of STM32CubeIDE CM33 is not working properly

[OKN]

I am programming the coprocessor (CM33) of STM32MP257F-EV1.

I prepared this with reference to Develop on Arm® Cortex®-M33  .

I built the sample program with MP32CubeIDE, transferred it to the target board (STM32MP257F-EV1), and it worked.

Next, create a new project in STM32CubeIDE for your target board.

[File -> New -> STM32 Project]
Select STM32MP257F-EV1 in the Board Selector of Target Selection.

I built the completed project and converted the resulting .elf to a binary file in OP-TEE? format using a python script.

[properties -> Setting -> Build Step]

arm-none-eabi-objcopy -S ${BuildArtifactFileBaseName}.elf ${BuildArtifactFileBaseName}_stripped.elf; python ../../../../Utilities/optee_os/scripts/sign_rproc_fw.py --in ${BuildArtifactFileBaseName}_stripped.elf --out ${BuildArtifactFileBaseName}_sign.bin --key ../../../../Utilities/optee_os/keys/default.pem --plat-tlv BOOTADDR 0x80100000

Copy the .bin to /lib/firmware on the target board and execute it.
Then, OpenSTLinux on the target board will HALT.

... # cat /sys/class/remoteproc/remoteproc0/firmware
rproc-m33-fw
... # echo hoge_oka_CM33_NonSecure_sign.bin > /sys/class/remoteproc/remoteproc0/firmware
... # cat /sys/class/remoteproc/remoteproc0/firmware
hoge_oka_CM33_NonSecure_sign.bin

... # cat /sys/class/remoteproc/remoteproc0/state
offline
... # echo start > /sys/class/remoteproc/remoteproc0/state
[ 166.422954] remoteproc remoteproc0: powering up m33
[ 166.434271] remoteproc remoteproc0: Booting fw image hoge_oka_CM33_NonSecure_sign.bin, size 24852
[ 166.4E/TC:1 stm32_iac_itr:192 IAC exceptions [159:128]: 0x10000000
*E/TC:0 stm32_serc_handle_ilac:133 SERC exceptions [63:32]: 0x8000000
*E/TC:1 stm32_iac_itr:197 IAC exception ID: 156
*E/TC:0 stm32_serc_handle_ilac:139 SERC exception ID: 59
*E/TC:1 Panic at /usr/src/debug/optee-os-stm32mp/4.0.0-stm32mp-r1/core/drivers/firewall/stm32_iac.c:212 <stm32_iac_itr>
E/TC:1 TEE load address @ 0x82000000
E/TC:1 Call stack:
E/TC:1 0x82007ed8
E/TC:1 0x82041b44
E/TC:1 0x8202c2c0
E/TC:1 0x8203f678
E/TC:1 0x82013cf4
I/TC: Halting CPU 0

I get the same result if I create and start a debug session in STM32CubeIDE

Please let me know if there are any tips or tricks for running a newly created project program in STM32CubeIDE.

By the way, if you remove some of the initialization code in main.c, OpenSTLinux on the target board seems to run without halting.

== main.c ==================================

/* Initialize all configured peripherals */
// MX_GPIO_Init();
// MX_ADC3_Init();
// MX_I2C1_Init();
MX_ICACHE_Init();
MX_RTC_Init();
// MX_UART5_Init();
// MX_USART6_UART_Init();
MX_UCPD1_Init();
/* USER CODE BEGIN 2 */

Host OS : Windows 11 Pro 24H2
Target Board STM32MP257F-EV1
STM32CubeIDE Version: 1.18.1
STM32CubeMP2 package V1.1.1 (STM32CubeMP2-main)
OpenSTLinux:

... # cat /etc/version
20241204105645
... # cat /etc/build
-----------------------
Build Configuration:  |
-----------------------
BB_VERSION = 2.8.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = universal
TARGET_SYS = aarch64-ostl-linux
MACHINE = stm32mp2
DISTRO = openstlinux-weston
DISTRO_VERSION = 5.0.3-openstlinux-6.6-yocto-scarthgap-mpu-v24.12.05
TUNE_FEATURES = aarch64 crc cortexa35
TARGET_FPU =
MANIFESTVERSION = ostl-v6.0-5-g97ef328d50dfc240c92d5fd62f9281a982494bf3
DISTRO_CODENAME = scarthgap
ACCEPT_EULA_stm32mp2 = 1
GCCVERSION = 13.%
PREFERRED_PROVIDER_virtual/kernel = linux-stm32mp
-----------------------
Layer Revisions:      |
-----------------------
meta-python       = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-oe           = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-gnome        = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-multimedia   = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-networking   = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-webserver    = v6.0.xml:1235dd4ed4a57e67683c045ad76b6a0f9e896b45
meta-st-stm32mp   = v6.0.xml:aa388978a9264ae59d3481e043ddf542f3562981
meta-st-openstlinux = v6.0.xml:fd3ef2feb59ad51694464eaa058b5c8fb1e24111
meta              = v6.0.xml:236ac1b43308df722a78d3aa20aef065dfae5b2b
... #

 Best regards.
okuno

[Nisarg]

I had the same issue with M33. What I found is these exceptions are from op-tee about "illegal access of Peripheral". In my case it was RCC. because the code generated using MX / IDE puts "

__HAL_RCC_GPIOG_CLK_ENABLE" function to enable clock to gpioG port in my firmware. Now here is the catch, RCC is managed by op-tee and in RIF configuration RCC is assigned to Secure world access only (means op-tee & TF-A). Also not sharable resource. So My code tends to fail when going to access any clock related function.

The line in the log...

E/TC:1 stm32_iac_itr:197 IAC exception ID: 156​

 says that Exception ID: 156 - which you can tell from reference manual is RCC.

In the Github example of M33 firmware such calls are guarded by conditional checking if this clock is accessible or not. that's why those firmware works. What CubeMX generates is not same as M33 firmware repo on github (as well as getting built in "Software Distribution" Yocto). 

I haven't tried with Disabling Secure access to RCC, because CubeMX won't allow me to do so. and I didn't have much time to do it manually in op-tee's dtsi.

[Erwan SZYMANSKI]

Hello @OKN ,
The explanation of @Nisarg concerning the RIF are completely right. If you did not use CubeMX to generate your full device tree project and associate IPs to A35 cortex or M33 cortex, it means that you probably work with a pre-configured image generated by ST. Do not hesitate to tell me if this is not the case.

On ST side, to make it simple, we deliver 3 big kind of configuration concerning RIF. You can find it in the folder dedicated to TSV flashlayout:

• FlashLayout_sdcard_stm32mp257f-ev1-ca35tdcid-ostl-m33-examples-optee.tsv
• FlashLayout_sdcard_stm32mp257f-ev1-ca35tdcid-ostl-optee.tsv
• FlashLayout_sdcard_stm32mp257f-ev1-optee.tsv

I took above the example for the SDcard image of STM32MP257F-EV1 board.

• optee config is what we commonly call the "open" configuration. This is a default low restriction RIF configuration that let most of the IPs not associated with a core or another. This is the image I would personally recommend at the beginning of your project development, to let security part come in a second step.
• ca35tdcid-ostl-optee uses a RIF configuration given as example to associate the IP used by Linux to the A35 cortex, and IP used by M33 firmware to the M33 cortex. This is a way to show the user how to configure the RIF properly on the STM32MP257F-EV1 based on the feature we can use on it.
• ca35tdcid-ostl-m33-examples-optee uses a RIF configuration given as example to make a bit more examples running on M33 cortex. We so remove some IP from Linux to assign it to M33 environment.

To come back on your case, and as mentioned by @Nisarg , the highest probability is that somewhere in your firmware, you are using an IP that activates a clock through RCC that is protected by the RIF. You can use the debugger and breakpoints to detect who and where this IAC is happening. Then you will be able to target which RIF configuration is the wrong one.

If you find the code line that make this happen and have trouble to debug it, do not hesitate to share it here as well as the Flash Image you took for your project. You can also try to change for the "open" configuration as explained above.

Kind regards,
Erwan.