RAM Target with Kinetis Design Studio and FRDM-K64F

Newer microcontroller have increase RAM areas, making it suitable to run the application from RAM instead of FLASH. For the FRDM-K64F board and the Kinetis Design Studio (V1.1.1), I have explored how to run the application out of RAM instead of FLASH memory, both for P&E and Segger connections.

Why a RAM Configuration

My engineering principle is: an engineer should develop in an environment which is used later in production (see “Debug vs. Release?“). Simply because if you develop and debug what the product will be, you have a better chance to catch errors early. The same thing applies to RAM or FLASH targets. With RAM targets the code and application runs in RAM, while with FLASH it runs out of FLASH memory. In the early days of microcontroller FLASH technology, the FLASH erase-program cycles were limited: my first microcontroller allowed to reprogram the FLASH only 50 times! So it made sense to start developing in RAM first, not to wear out the FLASH memory too early. Another advantage (in the past) was that downloading to RAM was faster than to FLASH. But with the faster FLASH and debugging probes this is not much a need any more. Other than that: running the program out of RAM memory might be faster, to increase the application performance.

The K64F on the FRDM-K64F board has 256 KByte of RAM, so it is possible to run rather large programs out of RAM.

The memory on the Freescale Kinetis-K devices is *not* continuous! There is a memory barrier at 0x2000’0000 which segments the memory, so you cannot use that memory in one single piece! See “FreeRTOS Heap with Segmented Kinetis K SRAM“.

Downloading and debugging a RAM target is rather easy with Kinetis Design Studio and projects created with Processor Expert.

256 KByte RAM of K64F

Using a RAM Configuration

The wizard creates a project with both a RAM and a FLASH configuration, with the FLASH set as the default (see “Configurations with Processor Expert“):

Processor Expert Project for FRDM-K64F

To switch the configuration, I select it and use the context menu:

Selecting Configuration

This makes the RAM configuration active. Note that a different CPU is now selected in this configuration:

Selected RAM Configuration

The difference to the FLASH target is that in the Build options of the CPU all the code and data gets placed in RAM areas:

Code and Data Placed in RAM

Therefore, the generated linker file is using RAM areas too, and places code and data in RAM, with the exception of the FLASH configuration and protection area (CFMPROT):

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x20000000, LENGTH = 0x00000198
  m_text  (RX) : ORIGIN = 0x20000198, LENGTH = 0x0002FE68
  m_data  (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

Debugging in RAM

P&E

Debugging a RAM configuration with the P&E connection is the same as using the FLASH configuration, no other changes needed:

Debugging in RAM with P&E

Segger

If using the Segger J-Link connection, then have to disable the ‘Pre-run reset and halt’ in the debug/launch configuration:

Segger Debugger Launch Configuration to Debug in RAM

With this, I can download and debug in RAM:

Debugging in RAM with Segger

OpenOCD/CMSIS-DAP

Same for the OpenOCD connection: I need to disable ‘Pre-run reset’ in the debugger lauch configuration:

Debug Configuration for Debugging in RAM with OpenOCD

With this, debugging in RAM works:

Debugging in RAM with OpenOCD

Summary

If you have enough RAM, it *might* make sense to run your application and to debug it in RAM. This means that in the linker file the code and data needs to be placed into RAM. I’m of the opinion that you should debug what you intend to build, but if you insist on debugging in RAM, hopefully this article helps you. And do not forget: if you power off the target, your application in RAM is gone ;-)

Happy RAMing :-)