lobaro wrote on Wednesday, May 08, 2019:
i try to use the FreeRTOS V10.2.0 cm33 ARMv8-M demo code in a real world scenario and gcc. I try to compile the the secure and non-secure firmware separately.
Meaning with “real world” that i am not using the simulator and a “multi project”. If the secure image is compiled the “ucHeap” buffer gets optimized out since there is no direct call from the secure firmware to pvPortMalloc(). I asume that this is incorrect and the non-secure firmware will fail when it tries to call portALLOCATE_SECURE_CONTEXT( configMINIMAL_SECURE_STACK_SIZE );
Whats your comment on this? Should i include a dummy call to pvPortMalloc on the secure side to avoid the optimization? Should i call SecureContextInit also on the secure side although the demos does not do this?
rtel wrote on Wednesday, May 08, 2019:
Thanks for letting us know you are facing this issue. We will be
releasing an update soon so we will look to see what we can do in a
portable way to avoid this happening. In the mean time you will be able
to either do what you say below, and use a dummy function call, or
alternatively use whatever extensions (i.e. not portable) your compiler
or linker provide to tell the optimiser not to remove the heap. For
example, if you are using GCC, you can add the
qualifier to the ucHeap variable.
lobaro wrote on Thursday, May 09, 2019:
thanks for your fast reply.
Upon further investigation i can say that the FreeRTOS secure portable code works fine without discarding the CMSE related functions including their local dependencies (like ucHeap), when you link the object files directly into the secure project. If you use a archive (.a) for the freeRTOS cmse code and then link this into the secure project the (naturally) unused CMSE entry functions and ucHeap get optimized out, unless the archive gets linked with the --whole-archive option.
I am unsure if this the wanted GCC behaviour or a bug, but as it seams it is not a problem of the cm33 secure portable code.