RAM Target with Kinetis Design Studio and FRDM-K64F
Join the DZone community and get the full member experience.
Join For FreeNewer 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.
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“):
To switch the configuration, I select it and use the context menu:
This makes the RAM configuration active. Note that a different CPU is now selected in this 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:
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:
Segger
If using the Segger J-Link connection, then have to disable the ‘Pre-run reset and halt’ in the debug/launch configuration:
With this, I can download and debug in RAM:
OpenOCD/CMSIS-DAP
Same for the OpenOCD connection: I need to disable ‘Pre-run reset’ in the debugger lauch configuration:
With this, debugging in RAM works:
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 :-)
Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Five Java Books Beginners and Professionals Should Read
-
TDD vs. BDD: Choosing The Suitable Framework
-
Front-End: Cache Strategies You Should Know
-
How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication
Comments