, , , ,

In my previous post, I started out on a journey to program the FRDM-KL25Z.  I documented how I:

  • got OpenOCD talking to the FRDM-KL25Z
  • integrated OpenOCD with Eclipse
  • “got to blinky” by loading and running a binary on the FRDM-KL25Z and
  • installed the mbed library

The Goal

The goal of this post is to step through a simple C program running on the FRDM-KL25Z from within Eclipse through the OpenOCD interface to the GDB debugger.

Thanks To Those That Went Before

A special shout out to the OpenOCD mailing list (openocd-user@lists.sourceforge.net)  It amazes me that such gifted folks as Paul and Tim are there to answer my questions!  So far I have been impressed with the quality of people and their passion behind the OpenOCD effort.

  • Paul Ferster – through the OpenOCD mailing list –  yet again came to my rescue when I could not get the GDB debugger to connect to the FRDM-KL25Z.  THANK YOU.
  • Tim Wescott provided me with insights on interacting with OpenOCD as well his thoughts on documentation.  I agree with his thoughts. The one thing I might consider for the OpenOCD effort is to move from a mailing list to StackExchange/StackOverflow (I am not sure about the difference). It is my experience as a passionate learner of electronics/programming that we’ve moved from RTFM learning to asking peers via a search that lands us on StackExchange/StackOverflow.  In doing so, the community becomes the documentation.  A mailing list to me is more about a few experts answering questions.  Which doesn’t scale as well because these poor experts are taken away from improving the code base to answer questions from clueless folks (um…like me 🙂 ).  THANK YOU Tim.
  • Ron Sousa  of HDE for providing guidance and direction as I sorted out what he is teaching us within the embedded systems section of Contextual Electronics.

The Code

Ron has us using the FRDM_SERIAL example project that is available on mbed’s developers web site.  As I searched, I stumbled across this post which walked me through the steps to download/prepare the FRDM_SERIAL example from mbed’s developer site.  I found the post easy to follow.  Please check it out. 

 The post uses the FRDM-K64F.  But as the image above shows it is easy to select the FRDM-KL25Z.  Selecting a platform is also a simple way to see which mbed boards are supported the most.

I found this online method of getting familiar with mbed programming/building/debugging/running code on the FRDM-KL25Z to be simple and unique.  My knowledge level about mbed in the previous post assumed I would need to download the mbed sdk and create an mbed library.  And I did this.  The mbed library created running the python scripts created the mbed library: /Applications/mbed/build/mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/libmbed.a

The mbed library build steps I went through that were documented in this post were not necessary.  Starting off with an Exported project from the mbed developer web site brings in the libmbed.a linked for the specified chip, in my case the FRDM-KL25Z.  However, running the tests using make.py was very useful because it helped me confidently know mbed was working with the FRDM-KL25Z and familiarized me with sending/receiving data from the FRDM-KL25Z to my Mac.  As in the journey is the reward :-).  Or what I’m finding – the journey is where I actually learn stuff.


FRDM_SERIAL is a simple mbed app.  As pointed out in the post: “You’ll see it doesn’t do much , it makes a serial connection over the USB port using Serial pc(USBTX, USBRX);it sends “Hello World” to the pcit then loops toggling the LED and sending  the loop counter to the pc.”  Here’s the code:



DigitalOut myled(LED_GREEN);

Serial pc(USBTX, USBRX);


int main()


    int i = 0;

    pc.printf(“Hello World!\n”);


    while (true) {

        wait(0.5f); // wait a small period of time

        pc.printf(“%d \n”, i); // print the value of variable i

        i++; // increment the variable

        myled = !myled; // toggle a led



Prior to unzipping the FRDM_SERIAL bundle that I exported from mbed’s compiler web site, I had created an Eclipse workspace.  I briefly discussed Eclipse workspaces in this post.  I then unzipped the bundle and copied the files within a subdirectory of the workspace.

The project includes a makefile.  The makefile means we can build within Eclipse with all the dependencies and variable definitions set.  If I was to grow the project with additional code/libraries, I would consider moving the makefile into a project with a managed make file as I did for the nRF51822 projects.  Managed make is – as the name implies 🙂 – easier to manage within Eclipse.

Source Line Debugging

I’ve got my project set up in Eclipse with the Eclipse settings I discussed in the previous post.  Source line debugging involves integrating the latest stable version of OpenOCD within Eclipse.  I’ve got the openOCD environment variables set up:

 The debug configuration needs to be set up:

Config Options

All should be filled out except for the all important Config options.  Make sure to have a path to the KL25Z.cfg file.  Note: I’ve seen different config files on the net for the KL25Z.cfg.  It is best to stick to the one that comes with the “official” OpenOCD software.

Explained in the OpenOCD Project Setup documentation: “To use OpenOCD with your development projects, you need to do more than just connect the JTAG adapter hardware (dongle) to your development board and start the OpenOCD server. You also need to configure your OpenOCD server so that it knows about your adapter and board, and helps your work. You may also want to connect OpenOCD to GDB, possibly using Eclipse or some other GUI.”

-f <path to KL25Z.cfg>

As explained in the OpenOCD documentation under configuration basics, passing in the correct config file is super important.  

-c “init;reset halt” 

When I didn’t give these additional options, I would get the following from the gdb server:

GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.9.0-00073-gdd34716 (2015-05-19-12:55)

Licensed under GNU GPL v2

For bug reports, read


Info : only one transport option; autoselect ‘swd’

srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : add flash_bank kinetis kl25.flash

adapter speed: 1000 kHz

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

cortex_m reset_config sysresetreq

Started by GNU ARM Eclipse

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x0bc11477

Info : kl25.cpu: hardware has 2 breakpoints, 2 watchpoints

Info : MDM: Chip is unsecured. Continuing.

Info : accepting ‘gdb’ connection on tcp/3333

Warn : Cannot communicate… target not halted.

Error: auto_probe failed

Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.

Error: attempted ‘gdb’ connection rejected

The GDB Server finds the OpenOCD service running on the FRDM-KL25Z but can’t connect to it.

The “helpful hints” (i.e.: Consider setting…) were not helpful.  I could not debug this without asking the OpenOCD mailing list .  Like last time, this mailing list was quick to respond with the right solution.  

I plan to use this command string any time I set up a debug configuration for OpenOCD.

Once the command was included, The YIPPEE! moment occurred.  I was able to walk through the code as well as see the output within a CoolTerm session (I discussed using CoolTerm in the previous post):



 Thanks for reading this far.  Please find many things to smile about.