Look up tables, Flash or SRAM?

A STM32F4 platform is used, which has 192kBytes SRAM, which is sufficient for me.

I am trying to build a look up table. The LUT will be used in calculation several times. And I want to put it in SRAM in the process of calculation, instead of FLASH, since reading SRAM is faster than reading FLASH for the core.

And I read this post mentioning putting the LUT in flash, which confuses me.. What should I do to burn the data into flash for the first load and the data will be kept in RAM afterwards for following calculations?

And if anyone knows CCM, is it a good idea to put the LUT in CCM during computation?

• How big is the LUT? – Damien Jun 10 '14 at 8:23
• How would the size matter? In my application, only 32 float numbers. – richieqianle Jun 10 '14 at 13:01
• Presumably (IANA embedded systems developer) if the Core Coupled Memory capacity is underutilized, placing the LUT there will avoid any contention and provide predictable timing. Copying the LUT from the main SRAM to CCM at each use might be useful if other components will be actively using SRAM concurrently and the number of lookups is reasonably large (e.g., if only half the SRAM bus cycles are available to the core, copying 32 values might add 80 cycles [1.5 to load from SRAM, 1 to store to CCM], making 160 lookups break-even at 1.5 cycles each for SRAM vs. 1 each for CCM). – Paul A. Clayton Jun 10 '14 at 22:15
• So, my conclusion: if you need to fetch something from a LUT stored only in flash, and that part of the LUT is not currently in cache, then you'll almost certainly get a processor stall, because it hasn't been pre-fetched by the ART accelerator. This very strongly favours having the LUT in SRAM, assuming (of course) there is sufficient room. – Damien Jun 11 '14 at 7:02
• @Damien Is the 0 wait state for RAM under the condition of no contention from other accesses (i.e., 1 cycle latency)? Otherwise it would have to be dual ported or always give the core priority and possibly starve other users (e.g., DMA). This blog post seems to indicate that contention is an issue and a reason for using CCM. – Paul A. Clayton Jun 11 '14 at 14:04

Simply defining the table without a const keyword will cause the table to be copied from Flash to RAM when your program starts up; e.g.

const short ax [] = { 1, 2, 3, 4 };      // stays in Flash
short bx [] = { 5, 6, 7, 8 };            // starts in Flash, copied to RAM


You can verify this behavior with the following two lines of code:

bx[0] = ax[0];    // allowed, since you are modifying a RAM variable
ax[0] = bx[0];    // not allowed, ax is const


I checked this out using the IAR compiler for the STM32F10 family. I don't know what CCM is, sorry.

It's not uncommon for embedded programmers to define a large initialized table, forgetting the const keyword, and then wonder why they are running out of RAM.

• CCM is Core Coupled Memory. "This tight coupling of the CCM memory to the core, leads to zero wait states, in other words, the core has exclusive access to this memory block, so for example, while other bus masters are using the main SRAM the core can access the CCM." (source) – Paul A. Clayton Jun 10 '14 at 21:39
• The keyword "const" does not guarantee that the data will be in SRAM only - the behaviour will be compiler-specific. See, for example, avr-libc. – Damien Jun 11 '14 at 7:05
• Note also to C++ users: regarding const-ness. A const_cast will remove the const keyword, so if you are relying on the "const" keyword to embed data in flash, be careful of this behaviour. – Damien Jun 11 '14 at 7:08