FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [November 2016 Threads] MPU port BSS segment initialization for FreeRTOSPosted by jgreen on November 29, 2016 I'm working on creating a Cortex-M4 project using the MPU version of FreeRTOS. The target processor is the STM32F303RE.
To summarize the issue I'm having: global BSS data in FreeRTOS privileged areas is not being cleared to 0 on init.
I'm using a linker script based on FreeRTOS/Demo/CORTEXMPUSimulatorKeilGCC/GCC_Specific/sections.ld but with the proper ROM and RAM areas for this MPU:
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
The startup assembler file is the ST CMSIS startup file which comes with their standard peripheral library. Stepping through the Reset_Handler code, I see that it does a BSS init to zero for my application data. But this does not include variables in FreeRTOS privileged areas. This results in crashes when I start creating tasks, since structures like pxReadyTasksLists are essentially uninitialized.
My guess is that the startup assembler code needs to initialize a second BSS area and possibly also copy initialized data from ROM to RAM for another area for FreeRTOS. Or maybe there is something wrong with the linker map, where these areas should somehow be combined but still marked as privileged? Is there a startup assembler file I can look at for an MPU port? Any other ideas?
Best regards,
Element
MPU port BSS segment initialization for FreeRTOSPosted by jgreen on November 29, 2016 I have implemented a hack to get things to work for now, until I can fix this properly. In main() I have the following code:
~~~
extern uint32t __privilegeddatastart__[];
extern uint32t privilegeddataend[];
int
main(void)
{
// Hack to initialize privileged data areas to 0
// FIXME - How does this usually happen with the FreeRTOS MPU port?
memset (&privilegeddatastart, 0, ((uint8t *)(&__privilegeddataend__)) - ((uint8t *)(&privilegeddatastart)));
~~~
Would like to know how this SHOULD work.
Best regards,
Element
MPU port BSS segment initialization for FreeRTOSPosted by rtel on November 29, 2016 This is not really a FreeRTOS question.
The start up routine (the function that the reset handler calls) is
dependent on the linker script. It uses information from the linker
script, normally linker variables, to know the start and end address of
the RAM that needs to be cleared to 0, and the start and end address of
the data to copy and where to copy it to to initialise variables. If
you edit the linker script to add in new sections that need
initialisation then you also need to update the start up routine
accordingly.
MPU port BSS segment initialization for FreeRTOSPosted by jgreen on November 29, 2016 Seems pretty related to me. FreeRTOS MPU sets up specific regions of memory for different purposes. Knowing that it's own BSS section is not initialized by run of the mill default startup code, is critical to getting the MPU port working on any platform. I did not see anything in the Keil simulator demo project showing this (perhaps it starts with a zeroed memory space by default), which seems to warrant at least some mention of this somewhere (which I could not find). The names of these sections and their purpose is defined by FreeRTOS. Regardless, as outlined in my other post, I'm just using memset() in main().
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|