CM33 secure heap gets optimzed out

Hello, 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 portALLOCATESECURECONTEXT( configMINIMALSECURESTACK_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?

CM33 secure heap gets optimzed out

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
__attribute__((used))
qualifier to the ucHeap variable.

CM33 secure heap gets optimzed out

Hello, 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. Greetings Theo