Looks like this was caused by the push operation, and it was caused by accessing an address out of ARM_LIB_STACK.
Needs Triage (15)
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().
PSP = 0x300001000 PSPLIM = 0x30000800
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.
Thu, Jan 23
Wed, Jan 22
In preparation, the Mbed Crypto config file is updated to the latest version which contains the proper flags needed to enable persistent keys: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3176/
yes, we are using UART in core to print some info like protection status and boot progress.
For the hw initialization, SystemInit called from startup code is not sufficient enough as it cannot pass status and data to the rest of the platform code written in C. This was the main reason for adding post init function.
Tue, Jan 21
Sun, Jan 19
Fri, Jan 17
Changes for this issue had been merged.
Thu, Jan 16
Wed, Jan 15
Hi @RobertRostohar ,
All issues are closed. The crypto header issue should follow up in mbedcrypto changes, not in TF-M as we have aligned.
So I'm going to close this root issue.
Please let me know if you have any question.
Had the workshop and aligned the solution for this issue.
The changes are made and verified locally for CMSIS Pack.
Next step is to upstream the solution to mbedCrypto.
As it's not TF-M issue anymore, so close this issue.
Tue, Jan 14
Nerver mind :) Glad if it works now. Cheers, Olivier.