Initialising variables in priviledged data when using MPU

Kernel
1

I am porting the MPU example for ST32L475 to ST32F401, making changes as necessary and using the linker script. However I have a problem that none of the variables declared as priviledged data are being initialised, eg
PRIVILEGED_DATA static volatile UBaseType_t uxCurrentNumberOfTasks = ( UBaseType_t ) 0U;
PRIVILEGED_DATA static volatile BaseType_t xSchedulerRunning = pdFALSE;
Rather they are left at their cleared value of 0xffffffff.
This causes problems when these values are then tested, giving incorrect results and thus the software freezes with an error.
Where is this corrected?

2

That should be handled in the startup code (which will be in assembly). For a ‘simple’ processor without the privileged mode, there will be one loop to copy initialization data from flash to the data segment, with a privileged processor (or any setup with two different types of data segment) you will need two loops to fill these.

You probably should look at the vendor provided code for the new MPU to see how such code was done (assuming they support this mode).

3

I can see the loader copies from sidata to _sdata, but the variables are set to 0xffffffff, such as

PRIVILEGED_DATA static volatile UBaseType_t uxSchedulerSuspended = ( UBaseType_t ) pdFALSE;

which stops the code

/* FreeRTOS kernel data. /
.privileged_data :
{
. = ALIGN(4);
_sdata = .; / Create a global symbol at data start. */
(privileged_data)
. = ALIGN(4);
FILL(0xDEAD);
/ Ensure that non-privileged data is placed after the region reserved for
* privileged kernel data. /
/ Note that dot (.) actually refers to the byte offset from the start of
* the current section (.privileged_data in this case). As a result, setting
* dot (.) to a value sets the size of the section. */
. = privileged_data_region_size;
} >RAM AT> FLASH

/* Initialized data sections into “RAM” Ram type memory /
.data :
{
. = ALIGN(4);
(.data) / .data sections /
(.data) / .data sections */

. = ALIGN(4);
_edata = .;        /* define a global symbol at data end */

} >RAM AT> FLASH

4

Here is the problem and solution. The LOADADDR() needs changing to
_sidata = LOADADDR(.privileged_data);

As below in the link script.

/* Used by the startup to initialize data */
_sidata = LOADADDR(.privileged_data);

/* FreeRTOS kernel data. /
.privileged_data :
{
. = ALIGN(4);
_sdata = .; / Create a global symbol at data start. */
(privileged_data)
. = ALIGN(4);
FILL(0xDEAD);
/ Ensure that non-privileged data is placed after the region reserved for
* privileged kernel data. /
/ Note that dot (.) actually refers to the byte offset from the start of
* the current section (.privileged_data in this case). As a result, setting
* dot (.) to a value sets the size of the section. */
. = privileged_data_region_size;
} >RAM AT> FLASH

5

You can place the privileged data within the normal .data section so the startup code will initialise it. Here is an example: https://github.com/FreeRTOS/FreeRTOS/blob/V10.4.1/FreeRTOS/Demo/CORTEX_MPU_M33F_NXP_LPC55S69_MCUXpresso/Projects/MCUXpresso/NonSecure/FreeRTOSDemo_ns.ld#L128

6

This mostly depends on the variables needed by your startup code to correctly initialize the data section. We do have the same in our samples wherever needed - https://github.com/FreeRTOS/FreeRTOS/blob/b1b3a0a3e98b226e7fe59a6db84bd3f3e2179967/FreeRTOS/Demo/CORTEX_MPU_STM32L4_Discovery_GCC_IAR_Keil/Projects/GCC/STM32L475VGTX_FLASH.ld#L183

Another method, as mentioned by Richard, is to use the data section in the Linker script. An example for Cortex-M4 is here - https://github.com/FreeRTOS/FreeRTOS/blob/b1b3a0a3e98b226e7fe59a6db84bd3f3e2179967/FreeRTOS/Demo/CORTEX_MPU_LPC54018_MCUXpresso/Projects/MCUXpresso/FreeRTOSDemo.ld#L205

Please let us know if problem exists in any of our samples.

Thanks.

7

Thank you for such rapid and helpful advice. This was my fault for not copying all the required sections. Correcting _sidata = LOADADDR(.privileged_data); resolved my issues, and checking, this is correct in all the FreeRTOS examples. However the suggestions put me on the correct track to determine the issue and along the way I learnt more about the initialisation code and the linker scripts. Nice to hear from Richard, with whom I first had contact in 2005.