Today
Looks like this was caused by the push operation, and it was caused by accessing an address out of ARM_LIB_STACK.
Yesterday
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
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.
Thu, Jan 23
Wed, Jan 22
Sun, Jan 19
Fri, Jan 17
Changes for this issue had been merged.
Thu, Jan 16
Wed, Jan 15
Mon, Jan 13
Remove log.sh/log.bat from code base:
Change for this issue had been merged
Fri, Jan 10
Patch is uploaded to https://review.trustedfirmware.org/c/trusted-firmware-m/+/3107.
The root cause is:
- When building SPRTL, arch type is fetched from GNUARM cmake file since SPRTL CMake file is included with add_subdirectory() instead of include().
- 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.
- 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.
Thu, Jan 9
Tue, Jan 7
Change for this issue had been merged as a hotfix
Change for this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/3051/
Mon, Jan 6
Patch link:
Sat, Jan 4
The problem is solved.