Linker ld.exe cannot get *.o files...when using CCMRAM on a 32F303

Surely the star is just used in the .LD to match against object file level naming like foo.ccmram

Use

__atribute__((section (".ccmram")));

Thanks, I should have been more specific, my bad :

Application Note describe 3 ways to get code in CCMRAM :

·        function per function

·        all functions of a c.file

·        all functions of a lib

The first work ok, the second is the one I want to use and pop the linker error, the 3rd is not tested.

The first method is adding  _atribute__((section ("*.ccmram")))  in the function prototype. It  works fine but you have to change one by one all functions in the .h file

The second method should allow to move all functions of a .c file in the CCMRAM. It consist of adding in the .LD file the name of the object file corresponding to the .c. This .o file has to be added where described in page 22 of the AN. When this method is used there’s no need to modify the function prototype. In that particular situation, the linker produce the following message in the console :

c:/program files (x86)/atollic/truestudio for stm32 9.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/6.3.1/../../../../arm-atollic-eabi/bin/ld.exe: cannot find xxxx.o, and this is where I get stuck !

thanks

I'm assuming a CDT-generated make.

In the linker command file:

MEMORY
{
 myregion (rx) : ORIGIN = myregionstart, LENGTH = myregionlength
}
 
mysection :
{
 KEEP(*myobject.o (.text .text*))
} >myregion

The above moves the text sections of the object into mysection and maps them into myregion. The other sections of the object will go to their normal sections. The linker processes mappings as these in the order they occur in the command file. So assuming you wanted the text at a fixed address, this mapping must occur before your general mapping of text sections.

The .c file should be in your project explorer and compiled with the rest of your sources. The compiler puts its object's in a build configuration directory. You don't need to tell the linker where its object is.

The option #1 you'd mentioned can do the same, is preferred by most developers, and is implemented similarly in other toolchains.

Thanks to both of you, it’s now more clear :

Main issue was a path issue : the .o file should be preceded by it’s relative path, in my case it was Core\Src\myfile.o, the new CubeMX template.

But when using this method, all the functions of the c file, including the ones coming with includes directives, are moved to CCMRAM, thus quickly filling the area in an uncontrolled manner

This is a good reason to use first method.