Fix reviewed and merged:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333/

Changes reviewed and merged:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3334/
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3335/
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3336/

Should to confirm, that after the patch the issue is still present.

Patch created:

Thanks for your input, that helps much. I will create fixes when I back to office.

Hi Ken,
after farther testings, PSA Test application still goes to the memory fault.
So I have returned all my two workarounds, which work for all applications:

1. .stack_top = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Limit) - 0x48,
2. Disable if (stacked_ctx_pos != p_cur_sp->runtime_data.sp_thrd.sp_btm)

Hi Ken,
Also, it should be done something with the check in tfm_svcalls.c, tfm_core_validate_caller() line 1001:

Hi Ken,

BTW, can you update other tfm_arch_*.h as well?
We can help verify the changes not covered in your side.

Hi Andrey,

So my workaround, to avoid psa_panic(), is to disable the check:

So I have returned to the RESET issue.

After the following fix - 0x48, the applications does not have the memory fault:

{
    .stack_bottom         = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Base),
    .stack_top            = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Limit) - 0x48, //NXP
    .rw_start             = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Base),
},

Hi Ken,

Related change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3328

Related change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3288

More hints for you:

Sorry for the late response and thanks for the findings. Could you share your image binary so that I could take a try? I got a board but not set up the environment yet.

I have tried to workaround it. Current steps:

1. Updated to the latest TFM commit.
2. Reverted changes related to:
   1. 5248af2d7b86775364a0e131eb80ac0330bc81fb
   2. 490281df3736b11b62e25bc98d3e2c6e4e10478c
   3. 483da6447e4360c514538807275904be68395dff

After that, PSA Test application starts working.
But the regression test application still goes to the Memory fault during the first App ROT partition initialization, on the first SVC call.

3. Switched App ROT partitions to PSA ROT, in tfm_spm_db.inc => after that regression tests are OK.

Change for this issue had been merged

Fix for this issue had been merged

FYI:
For ARMClang/Keil

1. Functional API and TFM_LVL=1, all applications/tests are OK!!!
2. IPC API and TFM_LVL=1 => repetitive reset.
3. IPC API and TFM_LVL=2 => goes to the mentioned memory fault.

Another experiment. Switching to Armasm V5 from v6 did not help, the same result - goes to the Memory fault.
So, for this moment only GCC (for PSA tests) is OK.

BTW: At the same time the TFM Regression Tests application (using GCC) goes to infinite reset on test_app()=>tfm_secure_client_run_tests()=>psa_connect(TFM_SECURE_CLIENT_SFN_RUN_TESTS_SID,TFM_SECURE_CLIENT_SFN_RUN_TESTS_VERSION)=>tfm_ns_interface_dispatch()=>fn()=>causes reset

Hi Ken,

Hi Ken,

Looks like this was caused by the push operation, and it was caused by accessing an address out of ARM_LIB_STACK.

After tfm_core_svc_handler() returns, the execution jumps to tfm_nspm_thread_entry().
Strange is, that during this jump PSP is changed from 0x30000FE0 to 0x30001048.

So the PSP, during main() has following values:
PSP = 0x300001000 PSPLIM = 0x30000800

Hi Ken,
Thank you by taking care about it.
Guess, the issue may be caused by the way we are using TFM. We have to compile TFM Secure in one project (instead of separate libraries). Guess, it may cause that some parts of data/code may be placed to unwanted memory sections.
I will try to analyze the generated map file.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3216/1

Changes for this issue had been merged.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3154

https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/3133/

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3130

Remove log.sh/log.bat from code base:

Change for this issue had been merged

Patch is uploaded to https://review.trustedfirmware.org/c/trusted-firmware-m/+/3107.

The root cause is:

1. When building SPRTL, arch type is fetched from GNUARM cmake file since SPRTL CMake file is included with add_subdirectory() instead of include().
2. The CM0+ arch type should be "armv6s-m". However, it is set to "armv6-m" in GNUARM cmake file, which stands for CM0. CM0 doesn't support SVC. Thus the build failed.
3. Previously, the psa_client.c and` psa_service.c` were not in SPRTL folder. When building the both files, cpu type is fetched which is correct.

Patch had been merged.

All patches had been merged to the master branch.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3094

Change for this issue had been merged as a hotfix

Change for this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/3051/

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2448

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2966

Patch link:

The problem is solved.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2966

SPRTL memcmp
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2959/

Patch for the task:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2953/1

Patch to fix:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2952