STM32 Core Coupled Memory (CCM)

Written in front

• Today, when I was working on STM32F4, I used a special memory called CCM. I searched the Internet but didn't find much introduction, so I just looked it up in the manual.

Basic Architecture

  Without further ado, let's take a look at what is special about this memory. The official basic architecture is as follows: 
  The main system consists of a 32-bit multilayer AHB bus matrix that interconnects:

• Eight masters: 
  – Cortex® -M4 with FPU core I-bus, D-bus and S-bus 
  – DMA1 memory bus 
  – DMA2 memory bus 
  – DMA2 peripheral bus 
  – Ethernet DMA bus 
  – USB OTG HS DMA bus

• Seven slaves: 
  – Internal Flash memory ICode bus 
  – Internal Flash memory DCode bus 
  – Main internal SRAM1 (112 KB) 
  – Auxiliary internal SRAM2 (16 KB) 
  – AHB1 peripherals including AHB to APB bridges and APB peripherals 
  – AHB2 peripherals 
  – FSMC

  The bus matrix provides access from a master to a slave, enabling concurrent access and efficient operation even when several high-speed peripherals work simultaneously. The 64-Kbyte CCM (core coupled memory) data RAM is not part of the bus matrix and can be accessed only through the CPU. This architecture is shown in The 

  architecture is quite different from the previous STM32F1x. As can be seen from the above, CCM has a total of 64KB and is directly hung on the D-bus. No one can access it except the CPU (i.e., the Cortex-M core). In addition, since CCM is not part of the BusMatrix, it cannot be accessed by other components, such as the DMA controller. 
  For CCM, the CPU can read data or code from CCM with the maximum system clock and the minimum waiting time. The official document explains some advantages of using CCM: for example, putting frequently read data in CCM and putting interrupt functions in CCM can speed up the execution of the program.

how to use

Usage method 1

  Now that we know this special memory, how do we use it? People who often use Keil should know that in its configuration, there are the following options: 
 
  By default, IRAM2 is not selected. Now we can select this part. In this way, when Keil generates code, it will automatically allocate variables to this part of RAM. For details, you can open the .map file generated by Keil.

    Execution Region RW_IRAM2 (Base: 0x10000000, Size: 0x00005ce4, Max: 0x00010000, ABSOLUTE)

    Base Addr Size Type Attr Idx E Section Name Object

    0x10000000 0x00005ce4 Zero RW 16003 .bss ram2.o

    Execution Region RW_IRAM1 (Base: 0x20000000, Size: 0x0001b360, Max: 0x00020000, ABSOLUTE, COMPRESSED[0x000000c8])

    Base Addr Size Type Attr Idx E Section Name Object

    0x20000000 0x00000001 Data RW 264 .data pbuf.o

    0x20000001 0x00000001 Data RW 909 .data api_msg.o

Notice: 

1. If you only define a few variables, Keil may not put them in the RAM. 

2. When I was using it, I did not select RAM2, but Keil still put part of the memory into RAM2. I don’t know why!

However, there is a problem: since it can only be accessed by the kernel, once Keil puts the memory used for DMA into this part of RAM, DMA will not work! So how to use it more appropriately?

Usage 2

As mentioned before, it seems inappropriate to let the compiler automatically allocate memory, so we can specify the memory to be allocated by ourselves. There are two ways to do this. 

The first method relies on the scatter-loading file (.sct), which is more powerful. It directly defines a file (for example, named RAM2.c), puts all the variables to be placed in this file, and then modifies the scatter-loading file as follows.

LR_IROM1 0x0800C000 0x00100000 { ; load region size_region

  ER_IROM1 0x0800C000 0x00100000 { ; load address = execution address

   *.o (RESET, +First); interrupt vector table

    *(InRoot$$Sections)

   .ANY (+RO) 

  }

  RW_IRAM1 0x20000000 0x00020000 { ; RW data

   .ANY (+RW +ZI)

  }

  ; Specify the use of CCM

  RW_IRAM2 0x10000000 0x00010000 {

   RAM2.O (RAM2,+RW +ZI)

  }

}

Another way is to use the compiler directive: __attribute__+at directly. When defining a variable, you can do the following:

UINT32 EventNum __attribute__((at(0x10000000))) = 0;

Of course, this approach can also be slightly modified to use __attribute__+section to assign a section name to the variable, and then specify the section location in the scatter-loading file. 

After compiling as above, you can view the allocation of variables in the corresponding part of the map file.

About the system

When I was working on this part, I happened to use FreeRTOS. Since this part can only be accessed by the kernel, in order to make reasonable use of memory, can I give this part of memory directly to the system, and the rest can be used as I want? And the 64KB memory allocated to FreeRTOS just meets my design needs! 

After understanding the above scatter-loading files, it is very simple to put FreeRTOS into RMA2. ​​According to the FreeRTOS files used, only the following scatter-loading files are needed.

RW_IRAM2 0x10000000 0x00010000 {

  port.o (+RW +ZI)

  queue.o (+RW +ZI)

  tasks.o (+RW +ZI)

  heap_4.o (+RW +ZI)

  ; Other FreeRTOS .o files used

}

This brings up another problem. If dynamically requested memory is used, the memory is still in RAM2. If it is passed to DMA, an error will occur!

Notice: 

1. Some files in FreeRTOS only have code but no data (RW and ZI), such as list.c, so they cannot be put into the above scatter-loading file

Precautions

You need to understand ARM's scatter-loading files.

Requires knowledge of individual compiler directives

Reference Documentation

STM32F407 Reference manual