Hi Thomas,

According to TF-M's design, an RTOS is meant to be started/run in NS.

If a non-secure SVC handler is called from thread mode (PSP, no FP, default stacking), the value of LR should be 0xFFFF_FFBC on exception entry. In my experience some v7-M RTOS implementations don't save the EXC_RETURN value on SVC entry but have a default value hard-coded at SVC exit. In a v7-M system the default EXC_RETURN value (assuming no SVC from handlers, and PSP used for thread mode) would be 0xFFFF_FFFD as you describe below, but that's not the case for a NS RTOS in v8-M. (The two bits that are different are EXC_RETURN.S (bit [6]) to indicate NS stack, and EXC_RETURN.ES (bit [0]) to indicate that the Exception was taken to NS)

A recommended and future-proof solution is for the RTOS to save the EXC_RETURN value stored in LR on SVC entry, and when returning from the SVC, to restore that and branch, or, if a switch is needed from MSP to PSP, to set EXC_RETURN.SPSEL as needed, but leave the rest of the EXC_RETURN value unchanged.

Let me know if this helps, or please provide further details if I failed to catch the root cause.

Regards Miklos

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 25 February 2019 16:34 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] SecureFault when starting the OS

In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code.

I'm now running into an issue where I get a SecureFault when attempting to start the OS.

The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault.

SFSR indicates that it is an INVER (Invalid Exception Return): --- Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: 0 Error has not occurred. 1 Error has occurred. --

LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception.

What am I missing here?

Is the OS supposed to be started from NS mode?

I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.

Thanks, /Thomas

*Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com mailto:thomas.tornblom@iar.com Website: www.iar.com http://www.iar.com Twitter: www.twitter.com/iarsystems http://www.twitter.com/iarsystems -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.