Allocate Secure context

Hi Gaurav !

I found the next. That Fault is visible in case when privileged task call NSC API and this API really execute SVC call on secure side. ( This call set new MCU clock and have typical BOARD_BootClockPLL150M() context.)
Setting new clock require atomic execution of one API and better ta have it as SVC call.

If nonprivileged task call this NSC API - no problem.

It means privileged secure context cause problems with SVC call on secure side for privileged tasks. Is this have sense ?

I have tried other sequence and from privilege task on non-secure side arise SVC and it call NSC function ( without SVC on secure side) what set new clock. It works, but next simple NSC call from nonprivileged task cause other type of fault :

Entering HardFault interrupt!

SAU->SFSR:INVEP fault: Invalid entry point to secure world.
Another secure bus error.

What I can’t say for sure today if both type of SVC calls are legal.
But I think there are.
nonsecure/nonprivileged task side can call NSC and it arise SVC call asap for have privilege/atomic execution of something.

nonsecure side can arise own SVC and it call regular NSC API.

May be nonsecure SVC call can’t arise NSC what arise SVC on secure side.

It means privileged secure context have some effect for secure side.


Thanks for the additional info Eugene. It is a bit difficult to make a guess here and I need to repro it. I will write a project with similar setup as yours and share my findings.

We are addressing some of the other issues you pointed out in this PR:

Thank you very much for all the valuable inputs.


Hi Gaurav !

Thank you !

So better to wait when your changes appear in master branch and try after that. or it take long time because of your internal testing ?
On my side I also use linker map file where put explicitly code and/or data of file to relevant section. Like this for example :

*heap_4.o(.text* .rodata* .*constdata) 
 *list.o(.text* .rodata* .*constdata) 
*heap_4.o(.data* *bss.*)
 *list.o(.data* *bss.*)

It help for count files and be sure if all context allocated to expected section.
It seems to me linker file have more priority than attribute/section definition inside source code. Files what contains function/variables for different section are not included to linker file and parsed as usually.
But I try to keep separate in separate source files for privileged and nonprivileged data/code.

About SVC calls. Due those security MCUs they start to be important as never ever. Looks like it is only one way to clearly separate code for privileged/nonprivileged parts and have some atomic execution of some APIs ( secure and nonsecure interrupts should be disabled).
Also due limited amount of MPU sections, may be all peripheral drivers should be accessible in SVC only in privileged mode.
But I think all type of SVC calls are legal.
Secure and nonsecure sides can arise SVC be in privileged/nonprivileged modes and from SVC call APIs what are pass control ( and return) to secure or nonsecure side.
Is this so ?


I can see asterisk sign is missing in my linker file fragments sometimes.May be I should insert code not as text.

Hi Eugene,

I should be able to merge the PR soon and then you should be able to give these changes a try. For the SVC calls, all the scenarios you mention seem correct and should not result in a fault. I am still working on setting up a project for secure MPU and then I will be able to look into why is it causing a fault.

Regarding the formatting, you can put your enclosed code in three backticks to format it. I updated your post above to correctly format the linker script portion.


Hi Eugene,

The changes have been merged into master:

Please give them a try and let us know your feedback.


Hi Gaurav !

I have taken master branch up to today and I can’t see any problems with privileged heap and other changes.
Thank you !

But may be few variables need reallocation as well.

static void prvTaskExitError( void ) PRIVILEGED_FUNCTION; ?

void vPortAllocateSecureContext( uint32_t ulSecureStackSize ) attribute (( naked )) FREERTOS_SYSTEM_CALL; ?

static const size_t xHeapStructSize = ( sizeof( BlockLink_t ) + ( ( size_t ) ( portBYTE_ALIGNMENT - 1 ) ?

I think it is good idea to have all possible SVC and Secure type of calls ( + mpus_s) as part of short example in baseline. It looks as good test for Secure context routines and also this is minimal setup for secure code nowadays.


Hi Eugene,

Thank you for trying out those changes and providing feedback. These are all good suggestions and I will look into them.