2012-01-11 02:08 AM
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-ccm2012-01-11 04:41 AM
.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¤tviews=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
2012-01-11 05:34 AM
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!2012-01-11 08:08 AM
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.2012-06-04 04:34 AM
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).2012-06-04 07:38 AM
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)
}
}
2012-06-05 04:17 AM
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.)2012-06-05 04:18 AM
2012-06-05 06:39 AM
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.2013-06-20 01:41 PM
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.