Make use of the 64k CCM

[jorgen2]

Posted on January 11, 2012 at 11:08

I've spent (too many) hours trying to figure out how to use the CCM for something useful.

And with useful I mean easy access from my code written in C. I use GNU GCC, etc (the Yagarto toolchain). At first I thought that putting some variable, array into a specified section, let's call it .ccm, (and of course the appropriate lines in the linker script) would be the solution. For example: uint8_t test[1024] __attribute__ ((section(''.cmm''))); Well, it works... Kind of... :\ I compiles and links nicely. Checking the memory map/dump of the generated ELF-file I see that the array is located @0x1000 0000 However, producing a binary image produces a LARGE 100+MB file. Doing a hex-file makes it smaller but will not load into ST-Link Utility (file too large to fit, it says) Now... That's probably due to the gap between 0x1000 FFFF and 0x2000 0000 The part in the linker script is something like (under the SECTIONS part) .ccm : {   .= ALING(4);   *(.ccm)   .= ALIGN(4); } >CCMRAM And CCM is defined under MEMORY as   CCRAM    (rwx)      : ORIGIN = 0x10000000, LENGTH = 64K Also tried to use NOLOAD to make it NOBITS instead of PROGBITS but it still takes up space in the binary or hex-file. Removing the section with objcopy and --remove-section .ccm does nothing to help either. Isn't there anyway of makeing your own section behave like the .bss section and not taking space in the image? I hope I make sense with my problem/question. Best regards // J�rgen #stm32-stm32f4-ccm-linker-section #gcc-linker-ccm

[atomassini]

Posted on September 02, 2014 at 10:16

Hello Clive,

i checked the map file and the array was allocated to CCM with or without the NOLOAD bit set. The final executable works wonderfully. I was fooled because with the NOLOAD bit set, it seems that the length of what i'm going to put in CCM ram adds up in the final bss length indication, while not actually being allocated there. Indeed now the bss occupation is more than 128K and no memory overflow error is generated. I checked all symbols going to bss and the large array i have is only allocated on CCM. I'm not a gcc guru , so i'm asking  if there is something wrong or, if it should go like this, there is a way to have a clean bss size indication with no ccm size adding up. Many thanks. 

[Tesla DeLorean]

Posted on September 29, 2014 at 04:01

I'm going to cross-link with this Keil related post for the F427 (2MB Flash, 256KB RAM - 192/64)

https://community.st.com/0D50X00009XkgpJSAR

 

Edit: Fixed DEAD LINK, original post from Sep 28 2014

[jdcowpland]

Posted on February 04, 2016 at 16:09

Hey folks,

I'm trying to write data to the CCM RAM on my STM32F4, and as far as I can tell, I've implemented the suggestions here, but as far as I can tell it's not working. I've added the following to my linker script:

.ccm (NOLOAD) :
{
. = ALIGN(4);
*(.ccm)
*(.ccm.*)
. = ALIGN(4);
} > ram1

where ram1 is defined:

MEMORY
{
rom (rx) : ORIGIN = 0x08020000, LENGTH = 0x000dFFFF
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00020000
ram1 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x00100000
}

In my function I then have

uint8_t CCM[1024] __attribute__((section(''.ccm'')));
CCM[0]= 0xFF;

But I see no change at location 0x10000000 in my debug memory browser. Anyone point out what I'm doing wrong?

[carmine]

Posted on February 04, 2016 at 17:02

If CCM array is defined in a function, then you need to define it as static if you want to place in CCM. Otherwise, you have to ''move'' the whole stack in CCM.

[jdcowpland]

Posted on February 04, 2016 at 17:04

Sorry, CCM array is actually declared as a global at the top of the c file.

[Radosław]

Posted on February 04, 2016 at 17:28

 remove post

[carmine]

Posted on February 04, 2016 at 17:37

Too few informations. Where do you call the ''

CCM[0]= 0xFF;

'' instruction? What about compiler optimization levels? (Try to use -ON as optimization level).

[jdcowpland]

Posted on February 04, 2016 at 17:42

Sorry will try to provide more info. Optimization is turned off. I am using CooCox CoIDE. I am have a large amount of code, but at the moment am just testing trying to write to CCM, so I just have a function which is called in the main function which then attempts to write that byte to CMM.

[carmine]

Posted on February 04, 2016 at 17:59

The only issue I can see (which, however, I think is not related to the your) is the LENGTH of CCM memory which is wrong (remove one zero, or write LENGTH=64K).

If you have semihosting of you can print something to an UART interface, try to printout the address of CCM array. It could be an issue related with the debugger or the memory viewer. Define also two symbols in liker script:

.ccm (NOLOAD) :
{
. = ALIGN(4);
 _sccm = .;
*(.ccm)
*(.ccm.*)
. = ALIGN(4);
 _eccm = .;
} > ram1

and see what is contained in _sccm and _eccm.

[Radosław]

Posted on February 04, 2016 at 18:10

Don't say wrong information. Optimization level is no important. Garbage colector will remove this variable if it isn't used or will be optimized.

Define this variable as volatile and use it. This linker section that you create is half of solution, becose you must remember that variable will be not initialized even if you will initialize them in code. In second hand C standard says that non initiazed variable should be '0'.