On Mon, 02 Apr 2018 14:16:54 -0300
Fabio Utzig <ut...@apache.org> wrote:

> Both
> 
> hw/mcu/stm/stm32f7xx/stm32f767.ld
> hw/mcu/stm/stm32f4xx/stm32f407.ld
> 
> already define the stack on CCM (called DTCM on the F7xx). Am I
> missing something here?

It might be me who's missing something (most likely scenario). The
linker scripts do indeed define the DTCM and CCM memory regions and
gives them names, ".stack" and ".data.core" depending on the linker
script. What I'm missing is that those sections aren't used anywhere in
the code.

The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in
os_task.h, which sets the alignment but not the section. Looking at the
generated memory map from an stm32f7 app all the sections are there but
I cannot identify anything actually placed in there.

But then the linker has always been a bit of a dark art to me so I
might just not be looking at the right things, or properly interpret
what I'm seeing.



> 
> On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote:
> > Hi Markus,
> > 
> > On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote:  
> > > I looked into moving the stack into the CCM memory of the stm32
> > > mcu's - and although almost every linker script defines
> > > ".data.core" sections and there are some defines in bsp.h's for
> > > section attributes they don't seem to be used.
> > > 
> > > Is there some hidden magic going on or is the CCM reserved for
> > > application code?  
> > 
> > No hidden magic; CCM is mostly unused and is up for grabs.  I think
> > there was some attempt to use this memory intelligently a while
> > back, but as the number of supported BSPs increased, it became
> > impractical.
> > 
> > When you say "the stack", do you mean the interrupt handler stack?
> > That sounds like a reasonable use of CCM (though you and others
> > probably have a better sense of this than I do).  If this is
> > something that users will want to do, it might be good to create a
> > syscfg setting to control whether the stack gets put in CCM or
> > normal RAM.
> > 
> > Chris  

Reply via email to