CCM section & "section `.bss' will not fit in region `ram'"

[russian]

My fields do not fit in the primary RAM region and I am trying to put part of the fields into CCM but I wonder if I am missing something.
For instance, if I have

Code: Select all

static char pendingBuffer[OUTPUT_BUFFER] __attribute__((section(".ccm")));

my binary links successfully and I see that 'pendingBuffer' is not present in the .map file as the other fields are and that makes me thing that 'pendingBuffer' was moved somewhere else, hopefully into CCM.

Now, if I change this line to

Code: Select all

static char pendingBuffer[10000 + OUTPUT_BUFFER] __attribute__((section(".ccm")));

Suddenly the binary does not link anymore, the error message is

c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: rusefi.elf section `.bss' will not fit in region `ram'
c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: region `ram' overflowed by 6408 bytes

Why ram and not ccm ram? Probably because bss goes to ram, but what do I have to detach myself from .bss?

My linker script is https://svn.code.sf.net/p/rusefi/code/t ... 7xG_CCM.ld - it's the default script with stack pointed into ram.

[jscott]

It looks like you are overeflowing the region by 6408 bytes.

RAM is 112K
CCM is 64K

How big is OUTPUT_BUFFER?
What other large memory allocations are you doing?

Can you provide a copy of the .map file?
That will tell just what is going where and how big it is.

-John Scott

[russian]

The full source code is available @ https://svn.code.sf.net/p/rusefi/code/trunk/firmware/
My make file is https://svn.code.sf.net/p/rusefi/code/t ... e/Makefile
map file is https://svn.code.sf.net/p/rusefi/code/t ... rusefi.map

I also have a script which makes the .map file a bit more readable - the result is @ https://svn.code.sf.net/p/rusefi/code/t ... report.txt

#define OUTPUT_BUFFER 9000

It looks like the fields with the ccm attribute are not making it to the map file, I would love to have them in the map file so that I can get a better picture. I have a feeling that none of my fields are actually in the CCM segment and my total memory consumption is probably 110K exactly.

[jscott]

OK....
Here is your memory map

Code: Select all

Memory Configuration

Name             Origin             Length             Attributes
flash            0x08000000         0x00100000
ram              0x20000000         0x0001c000
ethram           0x2001c000         0x00004000
ccmram           0x10000000         0x00010000


OUTPUTBUFFER is located in normal ram.
You can search the .map file and you find it at:

Code: Select all

...
 .bss.logger    0x200130b4      0x104 build/obj/tunerstudio.o
 .bss.outputBuffer                                                             <--- name of object
                0x200131b8     0x2328 build/obj/datalogging.o   <--- location, size, source     
 .bss.intermediateLoggingBufferInited
                0x200154e0        0x1 build/obj/datalogging.o
...


You are using CCM, just not getting what you want into it...
You can see that things like _idle_thread_wa are being placed
at 0x10000050 which is in the CCM ( refer to the memory map above
if needed... )

Code: Select all

.ccm            0x10000000      0x220
                0x10000000                PROVIDE (_cmm_start, .)
                0x10000000                . = ALIGN (0x4)
 *(.bss.mainthread.*)
 .bss.mainthread.4841
                0x10000000       0x4c build/obj/chsys.o
                0x1000004c                . = ALIGN (0x4)
 *(.bss._idle_thread_wa)
 *fill*         0x1000004c        0x4 00
 .bss._idle_thread_wa
                0x10000050      0x178 build/obj/chsys.o
                0x10000050                _idle_thread_wa
                0x100001c8                . = ALIGN (0x4)
 *(.bss.rlist)
 .bss.rlist     0x100001c8       0x1c build/obj/chschd.o
                0x100001c8                rlist
                0x100001e4                . = ALIGN (0x4)
 *(.bss.vtlist)
 .bss.vtlist    0x100001e4       0x10 build/obj/chvt.o
                0x100001e4                vtlist
                0x100001f4                . = ALIGN (0x4)
 *(.bss.endmem)
 .bss.endmem    0x100001f4        0x4 build/obj/chmemcore.o
                0x100001f8                . = ALIGN (0x4)
 *(.bss.nextmem)
 .bss.nextmem   0x100001f8        0x4 build/obj/chmemcore.o
                0x100001fc                . = ALIGN (0x4)
 *(.bss.default_heap)
 *fill*         0x100001fc        0x4 00
 .bss.default_heap
                0x10000200       0x20 build/obj/chheap.o
                0x10000220                . = ALIGN (0x4)
                0x10000220                PROVIDE (_cmm_end, .)



The only remain issue is sorting out why OUTPUTBUFFER is not being placed
where you want it... I will take a look through your code when I get time and
see what I find. Not sure when, may be a few days.... But this give you
more information to work with. Post if you make any progress...

-John Scott

[jscott]

OK, pendingBuffer is not in your being placed in you memory map..

It may be because you have optimization turned on, and the compiler thing you are not using it and removed it.

in you linker file you need to change the optimization level from -O1 to -O0

Code: Select all

# Compiler options here.
ifeq ($(USE_OPT),)
  USE_OPT = $(RFLAGS) -O1 -fgnu89-inline -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -Werror-implicit-function-declaration -Werror -Wno-error=pointer-sign -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=sign-compare -Wno-error=unused-parameter -Wno-error=missing-field-initializers
endif


optimization during development is a big no-no and will drive you and everyone
else crazy trying to figure out what is happening because it will move things around and delete code that you need, but the compiler does not thing you need.

Do that and post your status then...

-John Scott

[russian]

I've just tried with optimization off (-O0) but the error messages are exactly the same I've checked in new version of the .map

As I've mentioned - interesting thing, 'pendingBuffer' is not mentioned in the .map file at all.

[jscott]

Ok, this is starting to stump me...

I looked over some code that I have that uses CCM and I only see one real difference.
It may be related to me using ChibiStudio, so this is a poke in the dark...

Try changing the section name from .ccm to .ccmbuf

Also, can you provide the full compile report? I want to see what other warnings you are getting. CCM does generate a couple of information messages and I want to see just what you are getting...
I am using

Code: Select all

#define intoCCM  __attribute__((section(".ccmbuf")))  __attribute__((aligned(4)))


In a header file, and

Code: Select all

volatile framebuffer_t framebuffer[16][60] intoCCM;


to allocate my buffer. So I end up with:

Code: Select all

 *(.ccmbuf)
 .ccmbuf        0x10000968      0xf00 build/obj/lightshow.o
                0x10000968                framebuffer
                0x10001868                PROVIDE (_cmm_end, .)


in my .map file

-John

[fred]

In his map file (https://svn.code.sf.net/p/rusefi/code/t ... rusefi.map) why is there an association between .ccm and the 0x20000000 address base?

Code: Select all

.ccm            0x200016a0     0x8358 load address 0x0802c8dc
 .ccm           0x200016a0     0x4a38 build/obj/datalogging.o
 .ccm           0x200060d8      0xd60 build/obj/flash_main.o
                0x200060d8                flashState
 .ccm           0x20006e38     0x1388 build/obj/wave_chart.o
 .ccm           0x200081c0      0xe20 build/obj/trigger_central.o
 .ccm           0x20008fe0      0xa18 build/obj/trigger_emulator_algo.o
                0x20008fe0                configuration


.bss.outputBuffer comes from build/obj/datalogging.o which points at 0x200016a0

That makes sense because ...

Code: Select all

    .bss :
    {
        . = ALIGN(4);
        PROVIDE(_bss_start = .);
        *(.bss)
        . = ALIGN(4);
        *(.bss.*)                                <==============
        . = ALIGN(4);
        *(COMMON)
        . = ALIGN(4);
        PROVIDE(_bss_end = .);
    } > ram                                    <==============


So couldn't he just explicitly add outputBuffer to the linker?

Code: Select all



    .ccm :
    {
        PROVIDE(_cmm_start = .);
        . = ALIGN(4);
        *(.bss.outputBuffer)             <======================
        . = ALIGN(4);
        *(.bss.mainthread.*)
        . = ALIGN(4);
        *(.bss._idle_thread_wa)
        . = ALIGN(4);
        *(.bss.rlist)
        . = ALIGN(4);
        *(.bss.vtlist)
        . = ALIGN(4);
        *(.bss.endmem)
        . = ALIGN(4);
        *(.bss.nextmem)
        . = ALIGN(4);
        *(.bss.default_heap)
        . = ALIGN(4);
        PROVIDE(_cmm_end = .);
    } > ccmram


Edit:

or add a "*(.ccm)" instead of "*(.bss.outputBuffer)" to catch everything.

[russian]

On my.st.com forum I was advised to add

Code: Select all

        *(.ccm)
        *(.ccm.*)

into the ccm section

this has helped - the binary does build now! The fields are still not appearing in the .map file

Will try the ccmbuf approach in a bit, have to run now

[jscott]

Ok, we are dealing with different versions of the _ccm linker file...

Code: Select all

    .ccm :
    {
        PROVIDE(_cmm_start = .);
        . = ALIGN(4);
        *(.bss.mainthread.*)
        . = ALIGN(4);
        *(.bss._idle_thread_wa)
        . = ALIGN(4);
        *(.bss.rlist)
        . = ALIGN(4);
        *(.bss.vtlist)
        . = ALIGN(4);
        *(.bss.endmem)
        . = ALIGN(4);
        *(.bss.nextmem)
        . = ALIGN(4);
        *(.bss.default_heap)
        . = ALIGN(4);
        KEEP(*(.ccmbuf))
        PROVIDE(_cmm_end = .);
    } > ccmram


In mine, at the end of this section I have a line that says:
KEEP(*(.ccmbuf))

This will put anything that is declared like:
volatile framebuffer_t framebuffer[16][60] __attribute__((section(".ccmbuf")));

into the CCM

Simply adding __attribute__((section(".my_section_name"))) will create a section named .my_section_name but unless the linker has instructions to place it in .CCM it will simply place it in .BSS as we have seen.

Russian's linker script does not have specific instructions as to what to do to a section named .CCM. So we either need to edit the linker script for each variable we want to add to CCM ( yuck... ), or add something like the KEEP(*(.ccmbuf)) line once and then just add __attribute__((section(".ccmbuf"))); to any declarition that we want put in .CCM.

I know this is kind of mind bending, but the idea is to have a "standard" linker file and be able to choose where we want variables stored by changing how we declare them in the our source file, without having to also change the linker scripts.


I still don't know why pendingBuffer is missing....

One mystry solved ( i hope...), one to go ( only one! I hope.... )

-John Scott