Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM * psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC Senior Engineer CSS ICW SW INT BFS SFW Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
Thanks Bohdan for reporting this.
Let me have a look and try to reproduce it.
Best regards, Nick
________________________________ From: Bohdan.Hunko--- via TF-M tf-m@lists.trustedfirmware.org Sent: 16 December 2025 20:54 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: Ivan.Kozemchuk@infineon.com Ivan.Kozemchuk@infineon.com; Hennadiy.Kytsun@infineon.com Hennadiy.Kytsun@infineon.com Subject: [TF-M] Race condition in SPM scheduler lock logic
Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM * psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
Hi Bohdan,
The sequence you provided seems reasonable, however "backend_abi_leaving_spm" and the subsequent "arch_release_sched_lock" execute with all interrupts disabled, so there are no interrupts that should change the scheduler_lock in between [1]. A pending interrupt would execute as soon as L:91, and then would correctly set the PendSV.
Can you please share a bit more about your interrupt configurations, priorities etc? Am I missing something else?
Thanks Best regards, Nick
[1] https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/...
________________________________ From: Nicola Mazzucato via TF-M tf-m@lists.trustedfirmware.org Sent: 17 December 2025 08:37 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com Cc: Ivan.Kozemchuk@infineon.com Ivan.Kozemchuk@infineon.com; Hennadiy.Kytsun@infineon.com Hennadiy.Kytsun@infineon.com Subject: [TF-M] Re: Race condition in SPM scheduler lock logic
Thanks Bohdan for reporting this.
Let me have a look and try to reproduce it.
Best regards, Nick
________________________________ From: Bohdan.Hunko--- via TF-M tf-m@lists.trustedfirmware.org Sent: 16 December 2025 20:54 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: Ivan.Kozemchuk@infineon.com Ivan.Kozemchuk@infineon.com; Hennadiy.Kytsun@infineon.com Hennadiy.Kytsun@infineon.com Subject: [TF-M] Race condition in SPM scheduler lock logic
Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM * psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
Hi Nicola,
* Can you please share a bit more about your interrupt configurations, priorities etc? We don’t do anything special, the IRQ priority is Normal, nothing unusual.
* Am I missing something else? Looking into the code one thing that comes to mind is that tfm_arch_thread_fn_call can be called from unprivileged partition thus interrupt masking will not take effect. I believe this explains the behavior described in previous mail. If so then not only this code is effected, but other multithread issues may occur in different places of tfm_arch_thread_fn_call.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC Senior Engineer CSS ICW SW INT BFS SFW Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Friday, 19 December 2025 11:59 To: Hunko Bohdan (CSS ICW SW INT BFS SFW) Bohdan.Hunko@infineon.com Cc: Kozemchuk Ivan (CSS ICW SW INT BFS SFW) Ivan.Kozemchuk@infineon.com; Kytsun Hennadiy (CSS ICW SW INT BFS SFW) Hennadiy.Kytsun@infineon.com; Anton Komlev via TF-M tf-m@lists.trustedfirmware.org Subject: Re: Race condition in SPM scheduler lock logic
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx to help you identify Phishing email.
Hi Bohdan,
The sequence you provided seems reasonable, however "backend_abi_leaving_spm" and the subsequent "arch_release_sched_lock" execute with all interrupts disabled, so there are no interrupts that should change the scheduler_lock in between [1]. A pending interrupt would execute as soon as L:91, and then would correctly set the PendSV.
Can you please share a bit more about your interrupt configurations, priorities etc? Am I missing something else?
Thanks Best regards, Nick
[1] https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/...
________________________________ From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 17 December 2025 08:37 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com> Cc: Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com <Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com>; Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com <Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Re: Race condition in SPM scheduler lock logic
Thanks Bohdan for reporting this.
Let me have a look and try to reproduce it.
Best regards, Nick
________________________________ From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 16 December 2025 20:54 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com <Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com>; Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com <Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Race condition in SPM scheduler lock logic
Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM
* psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
Thank you Bohdan,
I am still a bit confused about the setup, because that section in SPM always executes in privileged execution. If the calling partition is not privileged, then the SVC handler will take place to elevate execution.
Thanks Best regards, Nick
________________________________ From: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com Sent: 19 December 2025 10:31 To: Nicola Mazzucato Nicola.Mazzucato@arm.com Cc: Ivan.Kozemchuk@infineon.com Ivan.Kozemchuk@infineon.com; Hennadiy.Kytsun@infineon.com Hennadiy.Kytsun@infineon.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: RE: Race condition in SPM scheduler lock logic
Hi Nicola,
* Can you please share a bit more about your interrupt configurations, priorities etc?
We don’t do anything special, the IRQ priority is Normal, nothing unusual.
* Am I missing something else?
Looking into the code one thing that comes to mind is that tfm_arch_thread_fn_call can be called from unprivileged partition thus interrupt masking will not take effect. I believe this explains the behavior described in previous mail.
If so then not only this code is effected, but other multithread issues may occur in different places of tfm_arch_thread_fn_call.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Friday, 19 December 2025 11:59 To: Hunko Bohdan (CSS ICW SW INT BFS SFW) Bohdan.Hunko@infineon.com Cc: Kozemchuk Ivan (CSS ICW SW INT BFS SFW) Ivan.Kozemchuk@infineon.com; Kytsun Hennadiy (CSS ICW SW INT BFS SFW) Hennadiy.Kytsun@infineon.com; Anton Komlev via TF-M tf-m@lists.trustedfirmware.org Subject: Re: Race condition in SPM scheduler lock logic
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx to help you identify Phishing email.
Hi Bohdan,
The sequence you provided seems reasonable, however "backend_abi_leaving_spm" and the subsequent "arch_release_sched_lock" execute with all interrupts disabled, so there are no interrupts that should change the scheduler_lock in between [1].
A pending interrupt would execute as soon as L:91, and then would correctly set the PendSV.
Can you please share a bit more about your interrupt configurations, priorities etc?
Am I missing something else?
Thanks
Best regards,
Nick
[1]
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/...
________________________________
From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 17 December 2025 08:37 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com> Cc: Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com <Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com>; Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com <Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Re: Race condition in SPM scheduler lock logic
Thanks Bohdan for reporting this.
Let me have a look and try to reproduce it.
Best regards,
Nick
________________________________
From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 16 December 2025 20:54 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com <Ivan.Kozemchuk@infineon.commailto:Ivan.Kozemchuk@infineon.com>; Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com <Hennadiy.Kytsun@infineon.commailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Race condition in SPM scheduler lock logic
Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM
* psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
Hello All,
I wanted to run regression and PSA API tests before Upstreaming ST patches to community.
However I had issue with PSA API tests.
Note, that I can build Regression tests without any problem.
I use the main branch and latest SHA1 I 've the following error: $ build_L56_psa_gnu_s -- The C compiler identification is GNU 15.2.0 CMake Error at C:/TFM_L56/tf-m-tests/tests_psa_arch/fetch_repo/CMakeLists.txt:10 (include): include could not find requested file:
remote_library
CMake Error at C:/TFM_L56/tf-m-tests/tests_psa_arch/fetch_repo/CMakeLists.txt:15 (fetch_remote_library): Unknown CMake command "fetch_remote_library".
-- Configuring incomplete, errors occurred! ninja: error: loading 'build.ninja': The system cannot find the file specified.
The cmake command is : cmake -S $TFM_work_dir_L56/tf-m-tests/tests_psa_arch/spe -B $L56_build_s -GNinja -DTFM_PLATFORM=stm/stm32l562e_dk -DTFM_TOOLCHAIN_FILE=$L56_tfm_src/toolchain_GNUARM.cmake -DCONFIG_TFM_SOURCE_PATH=$L56_tfm_src -DTFM_PSA_API=ON -DTEST_PSA_API=PROTECTED_STORAGE;
c:\TFM_L56\tf-m-tests\tests_psa_arch\fetch_repo\CMakeLists.txt content is :
include(remote_library)
set(PSA_ARCH_TESTS_PATH "DOWNLOAD" CACHE PATH "Path to PSA arch test repository used for SPE build") set(PSA_ARCH_TESTS_VERSION "v24.03_API1.6_CRYPTO_1.1.0" CACHE STRING "The version of PSA arch tests to use")
fetch_remote_library( LIB_NAME psa_arch_tests LIB_SOURCE_PATH_VAR PSA_ARCH_TESTS_PATH LIB_BASE_DIR ${CMAKE_BINARY_DIR}/fetch_repo LIB_PATCH_DIR ${CMAKE_CURRENT_LIST_DIR} LIB_FORCE_PATCH PSA_ARCH_TESTS_FORCE_PATCH FETCH_CONTENT_ARGS GIT_REPOSITORY https://github.com/ARM-software/psa-arch-tests.git GIT_TAG ${PSA_ARCH_TESTS_VERSION} GIT_SHALLOW TRUE GIT_PROGRESS TRUE )
Note In case I use v2.1.3 TFM tag with associated tf-m-tests and mcuboot SHA1 I can build the PSA API binaries without this error.
Does someone can provide me ideas / tracks to solve my problem?
Thank you for your time, Ronan,
[Shape, rectangle Description automatically generated]
Ronan GABOU | Tel: +33 1 58 07 80 19 MDG / General Purpose Microcontroller Sub-Group / Wireless Business Line / Cellular
[cid:image002.png@01DC735C.C928EC00]https://www.facebook.com/STMicroelectronics.NV/ [cid:image003.png@01DC735C.C928EC00] https://twitter.com/st_world [cid:image004.png@01DC735C.C928EC00] https://www.linkedin.com/company/stmicroelectronics/ [cid:image005.png@01DC735C.C928EC00] https://www.instagram.com/stmicroelectronics.nv/ [cid:image006.png@01DC735C.C928EC00] https://www.youtube.com/user/STonlineMedia ST online: www.st.com online: www.st.com
Hi Ronan,
I think you may need to add -DPSA_ARCH_TESTS_PATH=<absolute-path-to-psa-arch-tests> to your build command.
Hope that helps, Best regards, Nick
________________________________ From: Ronan GABOU via TF-M tf-m@lists.trustedfirmware.org Sent: 22 December 2025 15:19 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] : PSA API test build issue on main branch TFM
Hello All,
I wanted to run regression and PSA API tests before Upstreaming ST patches to community.
However I had issue with PSA API tests.
Note, that I can build Regression tests without any problem.
I use the main branch and latest SHA1
I ‘ve the following error:
$ build_L56_psa_gnu_s
-- The C compiler identification is GNU 15.2.0
CMake Error at C:/TFM_L56/tf-m-tests/tests_psa_arch/fetch_repo/CMakeLists.txt:10 (include):
include could not find requested file:
remote_library
CMake Error at C:/TFM_L56/tf-m-tests/tests_psa_arch/fetch_repo/CMakeLists.txt:15 (fetch_remote_library):
Unknown CMake command "fetch_remote_library".
-- Configuring incomplete, errors occurred!
ninja: error: loading 'build.ninja': The system cannot find the file specified.
The cmake command is :
cmake -S $TFM_work_dir_L56/tf-m-tests/tests_psa_arch/spe -B $L56_build_s -GNinja -DTFM_PLATFORM=stm/stm32l562e_dk -DTFM_TOOLCHAIN_FILE=$L56_tfm_src/toolchain_GNUARM.cmake -DCONFIG_TFM_SOURCE_PATH=$L56_tfm_src -DTFM_PSA_API=ON -DTEST_PSA_API=PROTECTED_STORAGE;
c:\TFM_L56\tf-m-tests\tests_psa_arch\fetch_repo\CMakeLists.txt content is :
include(remote_library)
set(PSA_ARCH_TESTS_PATH "DOWNLOAD" CACHE PATH "Path to PSA arch test repository used for SPE build")
set(PSA_ARCH_TESTS_VERSION "v24.03_API1.6_CRYPTO_1.1.0" CACHE STRING "The version of PSA arch tests to use")
fetch_remote_library(
LIB_NAME psa_arch_tests
LIB_SOURCE_PATH_VAR PSA_ARCH_TESTS_PATH
LIB_BASE_DIR ${CMAKE_BINARY_DIR}/fetch_repo
LIB_PATCH_DIR ${CMAKE_CURRENT_LIST_DIR}
LIB_FORCE_PATCH PSA_ARCH_TESTS_FORCE_PATCH
FETCH_CONTENT_ARGS
GIT_REPOSITORY https://github.com/ARM-software/psa-arch-tests.git
GIT_TAG ${PSA_ARCH_TESTS_VERSION}
GIT_SHALLOW TRUE
GIT_PROGRESS TRUE
)
Note In case I use v2.1.3 TFM tag with associated tf-m-tests and mcuboot SHA1 I can build the PSA API binaries without this error.
Does someone can provide me ideas / tracks to solve my problem?
Thank you for your time, Ronan,
[Shape, rectangle Description automatically generated]
Ronan GABOU | Tel: +33 1 58 07 80 19
MDG / General Purpose Microcontroller Sub-Group / Wireless Business Line / Cellular
[cid:image002.png@01DC735C.C928EC00]https://www.facebook.com/STMicroelectronics.NV/ [cid:image003.png@01DC735C.C928EC00] https://twitter.com/st_world [cid:image004.png@01DC735C.C928EC00] https://www.linkedin.com/company/stmicroelectronics/ [cid:image005.png@01DC735C.C928EC00] https://www.instagram.com/stmicroelectronics.nv/ [cid:image006.png@01DC735C.C928EC00] https://www.youtube.com/user/STonlineMedia ST online: www.st.com
online: www.st.com
tf-m@lists.trustedfirmware.org