DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > RAM Target with Kinetis Design Studio and FRDM-K64F

RAM Target with Kinetis Design Studio and FRDM-K64F

Erich Styger user avatar by
Erich Styger
·
Nov. 11, 14 · Java Zone · Interview
Like (0)
Save
Tweet
3.52K Views

Join the DZone community and get the full member experience.

Join For Free

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.

MK64FN1M0VLL12

MK64FN1M0VLL12

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

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

Processor Expert Project for FRDM-K64F

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

Selecting Configuration

Selecting Configuration

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

Selected RAM 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

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

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

Segger Debugger Launch Configuration to Debug in RAM

With this, I can download and debug in RAM:

Debugging in RAM with Segger

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

Debug Configuration for Debugging in RAM with OpenOCD

With this, debugging in RAM works:

Debugging in RAM with OpenOCD

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 :-)

Design Memory barrier application

Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How the TypeScript ReturnType Works
  • Create a Self-Service Customer Support Chatbot Without Code
  • Usage of Java Streams and Lambdas in Selenium WebDriver
  • Conducting Sprint Retrospective Meetings

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo