27
\$\begingroup\$

I've just come across some macros for my microcontroller compiler to force (or suggest) a function be executed from RAM.

https://siliconlabs.github.io/Gecko_SDK_Doc/efr32mg1/html/group__RAMFUNC.html#gac6abbc7f869eec9fb47e57427587c556

http://processors.wiki.ti.com/index.php/Placing_functions_in_RAM

https://www.iar.com/support/tech-notes/linker/controlling-placement-of-the-section-where-__ramfunc-functions-reside-ewarm-5.x--6.x/

https://community.nxp.com/thread/389099

In what cases is this valuable? Why wouldn't I just always execute from RAM if the benefit is only increased speed? Does this generally cause higher current draw?

\$\endgroup\$
  • 13
    \$\begingroup\$ Executing code from RAM draws less current (I am not sure if it is true for all CPU/SoCs). I have once made a project where we put most of the code to RAM because it was battery device and we wanted it to live as long as possible. If you can execute code only from RAM you can even power off flash blocks on some SoCs and save even more power. \$\endgroup\$ – Al Bundy Sep 6 '17 at 17:29
  • 4
    \$\begingroup\$ @pipe - I imagine the reason for making it a comment rather than an answer is that it doesn't answer the actual question, which is why you wouldn't want to always use RAM for executing your code. \$\endgroup\$ – Jules Sep 6 '17 at 20:18
  • 1
    \$\begingroup\$ @Jules Yes, I imagine it is meant as a "helpful anecdote". The things Stack Exchange is designed to prevent, for very good reasons. \$\endgroup\$ – pipe Sep 6 '17 at 20:28
  • 1
    \$\begingroup\$ Because you don't have enough registers to execute from register. (I have that chip.) \$\endgroup\$ – Joshua Sep 6 '17 at 20:39
  • \$\begingroup\$ In addition to everything: executing code from dynamic RAM specifically could be part of an elaborate software hack to perpetrate DRAM refresh. :) \$\endgroup\$ – Kaz Sep 7 '17 at 6:54
32
\$\begingroup\$

In addition to the speed & other features which others have already mentioned, executing code from RAM can be useful in bootloaders where you need to reprogram your micro's flash - you can't execute code from flash which you're in the middle of erasing & reprogramming.

\$\endgroup\$
  • 4
    \$\begingroup\$ depends on how many flash blocks you have and which ones your bootloader allows to be modified, how much ram you have left to stage the data for the next block, etc. but true to trampoline off the flash so you can modify the flash ram is good for that... \$\endgroup\$ – old_timer Sep 6 '17 at 18:08
  • 1
    \$\begingroup\$ This only seems to answer half the question (the titular part). OP also asked "Why wouldn't I just always execute from RAM if the benefit is only increased speed?", and this answer does not explain why one might not want to execute from RAM. \$\endgroup\$ – Doktor J Sep 7 '17 at 18:04
  • 2
    \$\begingroup\$ So far so good, but what happens if you lose power (and thus RAM) in the middle of rewriting flash? This can be solved, but just like any other design for a bootloader, it must be considered. \$\endgroup\$ – AaronD Sep 7 '17 at 21:45
19
\$\begingroup\$

I didn't look at the datasheet for that micro. However, it is often the case in this situation that fetching from RAM is faster than fetching from the flash the program memory is implemented from.

The advantage of flash is that large amounts can be relatively cheap. Microcontroller manufacturers therefore sometimes put a lot of flash on a chip, then provide a more limited RAM space that code can execute from. This allows copying time-critical routines into RAM, then executing them from there.

The compiler switch you refer to probably works with the linker and flags that section of flash to be copied to RAM by the compiler run-time code that runs from reset. Different implementations will vary on the details.

\$\endgroup\$
17
\$\begingroup\$

When you want to execute in RAM because it is faster, it's usually because that RAM is on-chip SRAM. This is a scarce resource, which you will probably want for data that requires read/write access.

Using it for code when you already have the code in ROM/flash means that you need X amount of flash and an additional X amount of RAM.

It also requires an extra copying stage at boot or when you want to run it, although it is mostly insignificant.

Traditionally this is solved with an instruction cache, but in a microcontroller it may make more sense to keep the internal SRAM generic, because you don't use a microcontroller because you want the fastest execution speed.

There is also a reliability issue - code executing in actual ROM is hard to modify by buggy code.

\$\endgroup\$
14
\$\begingroup\$

In addition to all good answers:

Why wouldn't I just always execute from RAM if the benefit is only increased speed?

Because in an embedded system, usually you don't have the required amount of RAM. For example a STM32 having 32kB or RAM and 512kB of EEPROM. To be able to execute entire program in RAM you would need a RAM size bigger than EEPROM.

\$\endgroup\$
  • 5
    \$\begingroup\$ "Because in an embedded system, usually you don't have the required amount of RAM. " -- and because if you do have enough RAM to do this, you can almost certainly reduce costs by switching to a cheaper MCU with less RAM. Because if you're asking the question, there's always a cheaper MCU with less RAM (the smallest and cheapest MCUs use Harvard architecture so can't execute from RAM) \$\endgroup\$ – Jules Sep 6 '17 at 20:46
13
\$\begingroup\$

Other answers don't seem to have discussed power consumption much, which you specifically asked about.

The answer is that it depends somewhat on the microcontroller, but often execution from RAM can reduce power consumption because it requires less energy to read instructions from RAM than from flash memory.

A typical use would be to run a low power "sleep" function from RAM, with the flash memory powered down. Not only is power consumption reduced, but if the microcontroller needs to wake up quickly (e.g. in response to an external interrupt) there is no delay while the flash memory is powered up again.

Some parts, such as some of the Atmel SAM range, have special extra low power RAM that can be used for this purpose. This allows a small amount of code to be loaded to the special RAM, while the bulk of the available RAM and all of the other memories is powered down and the microcontroller enters a deep sleep mode.

\$\endgroup\$
7
\$\begingroup\$

Other than the potential speed benefits mentioned by others, RAM code is also dynamic and can be modified on the fly by some tailoring code in the FLASH as required.

This could be as simple as changing a few parameters or could be entire handler routines uploaded remotely.

\$\endgroup\$
  • \$\begingroup\$ Or the code in RAM can be loaded from disk (e.g. SD) or network \$\endgroup\$ – teambob Sep 7 '17 at 0:45
4
\$\begingroup\$

Executing code from RAM is significantly faster than executing it from flash memory. Most CPUs are heavily optimized for the fastest possible RAM access, and even the fastest flash memory only reaches a fraction of the speed of RAM.

However keep in mind that moving the code from flash to RAM also takes time. If code is executed only once, you only need to read it once, and therefore you would actually loose time for copying it into RAM first instead of executing it directly. If code is executed occasionally (so copying it into RAM would increase execution the second time it is called), but the system is generally idle, then you would execute that code faster by copying it into RAM, but no one cares, because the system has enough time to spent.

So such optimizations are only worth the effort, if the code is executed frequently, and you have measured it to be a choking point of the system.

On the other hand RAM needs to actively keep the data stored, while flash memory does not, so the total power consumption increases, if RAM needs to be kept active. This is however only relevant, if the RAM is otherwise not used at all, but most modern systems will - in one way or another - use the available RAM already and therefore already keep it active.

\$\endgroup\$
4
\$\begingroup\$

There are two very common reasons to execute code from RAM:

  1. Some microprocessors cannot execute from flash during flash programming - though many can do this as long as the code is in a different block from the flash being written. Flash writes might be reprogramming the application (boot-loader case), or when flash is used to store non-volatile program info (configuration, calibration, etc.)

  2. On many microprocessors, RAM is much faster than flash. For these devices, small speed-critical routines may be executed from RAM, though usually RAM is in much shorter supply than flash.

\$\endgroup\$
2
\$\begingroup\$

Another usecase for RAM only execution security against random bitflips. We use this model on our small cubesat because the main computer board has an ECC ram that tolerates bitflips due to radiation. The entire OS is loaded into ram as a ramdisk on startup runs completely in an ECC enviornment.

The flash is not ECC protected(standard off the shelf micro SD cards) however we have other methods to check for corruption(multiple images, checksums etc.)

\$\endgroup\$
  • \$\begingroup\$ I would have assumed that something like EEPROM or flash would be much "harder" to bitflip by radiation, that is, require more energy. \$\endgroup\$ – pipe Sep 8 '17 at 13:30
  • \$\begingroup\$ Indeed that is so, but since we just use standard flash with no special ECC features, using ram is much better for this purpose. \$\endgroup\$ – Tejas Kale Sep 8 '17 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.