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

[Tesla DeLorean]

Posted on January 11, 2012 at 13:41

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

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Adding an uninitialized data section to a GCC build&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=83]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FAdding%20an%20uninitialized%20data%20section%20to%20a%20GCC%20build&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=83

[jorgen2]

Posted on January 11, 2012 at 14:34

Thanks clive1!

I searched the forum before posting and did not find that topic. :D

Strange though, as I tried just the thing you say yesterday and it made no difference when using objcopy then. And readelf said my .ccm was NOBITS.

Anyway, works now so I am happy!

Many thanks!

[Tesla DeLorean]

Posted on January 11, 2012 at 17:08

I don't know, I think the consensus is that the linker script parser is very sensitive. It is certainly a complex/messy topic area, and I usually try to fashion them from examples that work.

Actually the ELF to HEX application I wrote looks for the Program Header records with the type PT_LOAD to determine if there is physical data to be emitted. This seems to work effectively for GCC, Atollic and Keil.

The STACK would be a very good thing to put in the CCM, or anything else you want that's fast and un-contended by DMA.

It is hard to find things on the forum, a lot of things get lost in the titles, or terms people use to describe things. I knew it was there, and I also use Google in many cases to find posts here. A lot of the old links often fail because the forum crashed destroying the original content, and the new mirror has a different index.

[flyer31]

Posted on June 04, 2012 at 13:34

Hi Clive,

sorry if I am a bit late coming to this post.

Is there an easy way to put the Stack into the CCM memory? (e. g. just some more or less basic change in startup_stm32f4xx.s, or some compiler settings? - I use Keil compiler together with STM32F407).

[Tesla DeLorean]

Posted on June 04, 2012 at 16:38

Is there an easy way to put the Stack into the CCM memory? (e. g. just some more or less basic change in startup_stm32f4xx.s, or some compiler settings? - I use Keil compiler together with STM32F407).

You want to set up a scatter file, and in the Linker tab under options, uncheck the ''Use Memory Layout from Target Dialog'' and then select your ''Scatter File'' foo.sct foo.sct looks like this, but other options/possibilities are possible

; *************************************************************
; *** Scatter-Loading Description File for STM32F4 ***
; *************************************************************
LR_IROM1 0x08000000 0x00100000 { ; load region size_region
ER_IROM1 0x08000000 0x00100000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00020000 { ; RW data
.ANY (+RW +ZI)
}
RW_IRAM2 0x10000000 0x00010000 { ; CCM
startup_stm32f4xx.o (STACK)
}
}

[flyer31]

Posted on June 05, 2012 at 13:17

Would you expect a significant increase of speed if a typical uC program puts the stack into CCM?

(above you spoke of 40% speed increase - but I think for this you would need to put ALL variables into CCM? As I see, the Keil in standard mode does not use CCM at all - it seems to be necessary to use this scatter file (or do manual relocating of variables) to support the CCM.)

[flyer31]

Posted on June 05, 2012 at 13:18

[Tesla DeLorean]

Posted on June 05, 2012 at 15:39

Not sure I mentioned 40% here. The memory is single cycle as I recall, and uncontended. It is Closely Coupled (aka Tightly Coupled) to the core. It would be good for anything not being used/accessed via DMA.

You'd need to set up Keil's Linker/Target pane to know about the RAM areas, I don't think the default projects set it up. You'd also need to steer variables/sections into the appropriate areas.

[Bill Lewis]

Posted on June 20, 2013 at 22:41

I tried to shuffle things around, move stuff (like the stack) into CCM so I could have full use of the main RAM for a big data object.  Ran into endless trouble with things I didn't realize beforehand.

Example: Chan FatFs and using DMA SDIO.  Some buffer was on the stack, didn't work.  Stuff like that was sprinkled all over my code.

[Tesla DeLorean]

Posted on June 20, 2013 at 23:09

It's not a silver bullet.

I could describe the joys of virtual memory, where you have to pin and lock physical memory before you can DMA to it, or writing kernel mode drivers. If you even get an IRQL_NOT_LESS_OR_EQUAL blue screen, it's because some fool tried to DMA into, or access, a user memory context that switched out before the transfer completed/started.

Generally it's inadvisable to DMA on the stack, due to it's transient nature, and the potential for the DMA controller settings to out live the current activity. Much hilarity ensues when the stack gets trashed by a lingering transfer.