Hey Will,
thanks for the background - much appreciated.
I did indeed need the additional memory to store a time series
generated at high frequencies, so offloading wasn't an option. I solved
it by storing some of the time series in CCM memory, which is probably
the better solution anyway.
Given the constraints around CCM and DTCM, it might actually be better
if the OS doesn't use it. I guess I got confused, misled by the "core"
in the section name, which in retrospect probably applies to the MCU and
not the OS.
Thanks for all the input,
Markus
On Mon, 2 Apr 2018 10:54:32 -0700
will sanfilippo <wi...@runtime.io> wrote:
> Markus:
>
> I presume you are referring to these definitions:
>
> #define sec_data_core __attribute__((section(".data.core")))
> #define sec_bss_core __attribute__((section(".bss.core")))
> #define sec_bss_nz_core __attribute__((section(".bss.core.nz")))
>
> As far as I know there is no real magic here but I am sure there is
> some degree of inconsistency.
>
> The reason sec_bss_nz_core was added was to get around a HW problem
> with early nordic chips (you can see the reference in nrf52.ld) so I
> do not doubt that this is no longer used. Personally, I think the
> idea of having a “non-zeroed .bss” is pretty cool. I guess one could
> simply call that the heap but sometimes you just like allocating a
> global variable and not allocating it from the heap. I realize that
> the only real reason to do this is save time in the startup code
> zeroing out memory (but still; that is cool!) :-) Not quite sure why
> “core” was added to that defintion. Maybe because there was some
> conflict with naming it bss.nz?
>
> I should probably look at the STM startup code to be sure of this but
> I presume they use sec_data_core for both code and data they want to
> locate in CCM. This is basically a .data section in that the startup
> code needs to copy this from flash (whether it be code or initialized
> data).
>
> I guess sec_bss_core is used to store variables in CCM that just need
> to get zeroed by the startup code.
>
> btw, I am no STM CPU/memory architecture expert but I was reading up
> on it and they do not suggest putting both code and data into CCM. Of
> course, if you need the RAM you need the RAM… Is that why you want to
> move a stack there? I guess if all your code is executing from flash
> then putting data into CCM is fine (maybe faster is SRAM is slower?).
>
> Seems to me it would be nice to differentiate “core text” from “core
> data”. No real reason I guess but seems a bit more intuitive. Might
> be nice to come up with a set of “standard” section definitions (if
> they do not already exist somewhere) that we can apply across all
> BSPs/MCUs.
>
>
> > On Mar 31, 2018, at 4:02 PM, markus <mar...@bibi.ca> 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?
> >
> > Have fun,
> > Markus
>
