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

[russian]

Can you do a rebuild and post the build reports?
I would still like to the the compiler output that lists warning and
errors.

Here you are - https://svn.code.sf.net/p/rusefi/code/trunk/temp/
Is this about trying to find out why 'pendingBuffer' is not in the .map file?

[jscott]

russian,

Yes, I am trying to figure out why pendingBuffer[] seems to missing completely...

I have usually tracked this down to uncalled code that is removed by having optimization set to something other then -O0 and the the optimizer removing code and variables from the output. But you changed that, and it still seems to be missing....

You have a LOT of warnings, which can sometimes cause odd problems, but I don't see anything that seems to relate to this...

At this point in weird problems, I usually resort to voodoo debugging... this is where we stick pins in it and see what happens....

A couple of things to try one at a time include...

add a new variable declared the same as pendingBuffer with a size of 4660. This is 0x1234. then search the .map file for 1234 and see if showed up as you expect in case something weird is going on with the name or the allocation....

try changing pendingBuffer to pendingBuffer_rus. this will help catch some sort of name conflict...

make real sure the code dealing with pendingBuffer is being called. Even if you have to add a temporary call from main() to make sure the compiler knows that this is active code

create a small test program that calls this module and see if it does the same...

try cleaning up some of the warnings... long shot but good in the end...

It seems somewhere along the line I saw a way to have the linker generate a report of code and variables that it removed. I wish I could figure out how to do that now...

This continues to be a real stumper....

[jscott]

Russian,

Ok, I did some testing on a sample program of mine...

The *_ccm.ld file that Giovanni updated works! ( not that that is a surprise!!)

While I don't think I have done exhaustive testing, I found two things that need
to be done.

1. Declare your variable such as:

Code: Select all

volatile uint16_t zaudio_samples1[ 9000 ] __attribute__((section(".ccm")));

2. make REALLY SURE that you use your variable somewhere that the compiler
will find it. Otherwise, It looks like it will remove it from you code. Sometimes WITHOUT A TRACE!!!!

This seems to allow it to work without problems

Code: Select all

  zaudio_samples1[493] -= 34;
  zaudio_samples2[493] -= 34;

If I remember your code correctly you are doing a memcpy

Code: Select all

  memcpy( zaudio_samples1, zaudio_samples2, sizeof(zaudio_samples1));

Seems to work, but throws warnings,

Code: Select all

myADC.c:225:3: warning: passing argument 1 of 'memcpy' discards 'volatile' qualifier from pointer target type [enabled by default]
In file included from myADC.c:4:0:
c:\chibistudio\tools\gnu tools arm embedded\4.7 2013q2\bin\../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/include/string.h:24:8: note: expected 'void *' but argument is of type 'volatile uint16_t *'
myADC.c:225:3: warning: passing argument 2 of 'memcpy' discards 'volatile' qualifier from pointer target type [enabled by default]
In file included from myADC.c:4:0:
c:\chibistudio\tools\gnu tools arm embedded\4.7 2013q2\bin\../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/include/string.h:24:8: note: expected 'const void *' but argument is of type 'volatile uint16_t *'

Give this a try and let me know what you find.
-John Scott

[russian]

Sorry for the late response.

I guess my fields are already declared like that, aren't they?

Code: Select all

static char pendingBuffer[OUTPUT_BUFFER] __attribute__((section(".ccm")));
PwmConfig triggerSignal __attribute__((section(".ccm")));
static char WAVE_LOGGING_BUFFER[5000] __attribute__((section(".ccm")));

I am pretty sure that all of them are used

Code: Select all

int curLength = strlen(pendingBuffer);
triggerSignal.outputPins[0] = TRIGGER_EMULATOR_PRIMARY;
initLoggingExt(&chart->logging, "wave chart", WAVE_LOGGING_BUFFER, sizeof(WAVE_LOGGING_BUFFER));

Still, somehow all of them are not making it to the .map file

[russian]

PS: while we are on improving the default CCM.ld file:

Should we do 'AT > flash' for the ccmram region? Do I understand it right that this would allow static initializes for these methods?

[jscott]

Russian,

Try declaring pendingBuffer volatile.

They if that does not do it, try adding a simple pendingBuffer[0] = 1;
and see what that does...

It seems to be a very fussy problem...

-John

[russian]

Just tried with volatile and pendingBuffer[0] = 1; (I had to comment out some other lines since they were conflicting with 'volatile' since that's the warning level I am on)

Nope. These fields are not in the .map file

I was curious what are other options and I've tried arm-none-eabi-objdump.exe -x rusefi.elf
Sure thing all my fields are there:
100002e0 l O .ccm 00002328 pendingBuffer
10002608 l O .ccm 00001388 WAVE_LOGGING_BUFFER

So at least for plan B I can start parsing objdump report instead of .map file

[Giovanni]

Note that the CCM section is not initialized in any way, you should not even assume it contains zeros.

Giovanni