Thanks for reminding me. Miss it. All patches had been merged, close it.

@edison-ai , both patches were merged. Is this task done?

This page lists cmake versions available in different Linux distributions.
https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros

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

By using this patch, the test will stop at test case 4 by the hardware flash bug, which is not related to this defect.
After the test fails, the system cannot boot up anymore except we erase the flashes again.

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

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

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

Enable memory protection for PSA FF test: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3526

Isolation level 2 peripheral MPU config:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3524
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3525

NSPE parameter checking of iovecs, With also checking all missed patch. These missed patched are used to take https://www.ukbestessay.net/assignment-writing look, When you decided to check all the mention informative material you understand how and in which way it important to share.

Switch SST FS from flash to RAM: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3523

Fix the isolation level issue related with ACK test
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3516

Add lifecycle API
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3465/1

Fix the PROGRAMMER ERROR issue
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3464

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3886
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3887
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3433
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3514
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3888

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3098
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3350/9
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3360/8

All patches had been merged into the master branch.

Hi Andrej,

Hi Ken,
Yes, the final patch has fixed the issue.
It works now without our workarounds.

Hi Andrej,
I have updated patch and test with FP enabled in my side and it works. Can you take a try on your side?
Thanks.

Thanks. I just found the patch missed something, I will re-create a patch to update that.

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

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