Note: This blog post partly contains some new content, and partly some content from blog posts I’ve written in the past. It is a consolidation, to make information relevant to FRDM boards and mbed available at one convenient location.

Note 2: February 2020: Updated with information on how to set up the boards to work with the latest Windows 10 operating systems.

Introduction

FRDM boards are a range of compact (slightly larger than credit-card sized) boards with a microcontroller. They are great for prototyping projects.

The FRDM boards and the mbed platform (described later) are designed to make users concentrate on coding their application, and not worry about intricate hardware or low-level driver code detail on day 1. It is about the smoothest experience for those interested in creating hardware and software projects.

In some ways it could be compared to Arduino. The Arduino project is also extremely popular; it allows people to rapidly create microcontroller-based projects. In the past, it was a fairly complex process to write code, compile it (i.e. translate it into machine instructions) and get it programmed into the microcontroller. With Arduino the process was greatly simplified and all the user needed to do was to download a single application for the PC, called the Arduino IDE (Interactive Development Environment), write the code there in a single file, and click a couple of buttons on the screen to build the code and program it into a low-cost Arduino board using a standard USB cable.

Although Arduino is still popular, there are also other exciting microcontroller boards out there and coding/compiling environments that are as easy or easier to use as the Arduino system. This blog post describes a coding/compiling environment called mbed, and as mentioned, the range of boards known as FRDM boards. The boards have a Kinetis microcontroller on them. Kinetis is the brand name of microcontroller chips made by NXP/Freescale, and they internally all contain an ARM Cortex based microcontroller core and some additional features. I love using these boards, I feel very productive with them and I thought it could be worthwhile to document how to use them.

Kinetis Microcontroller Family and FRDM Board Introduction

Freescale’s (now NXP) Kinetis microcontroller series is based around the popular ARM Cortex-M range of cores along with Flash and data memory and integrated peripherals all wrapped up as a low-cost integrated circuit. The Kinetis series is nice because of the wealth of documentation (Motorola Semiconductor which became Freescale always had comprehensive documentation and the philosophy has been followed through over the years), and also because of the ease-of-use and very low cost to get started using the FRDM board range. I also like that the integrated peripherals inside the microcontrollers have Motorola heritage; it is apparent from some register names that some integrated peripheral designs were translated from earlier Motorola microcontrollers so if one is familiar with those then the learning curve is naturally lower with Kinetis.

The range is very good and it is actually fun to use these devices to solve problems. Perhaps the one to start off with is the FRDM-KL25ZFRDM-KL25Z because that is the first FRDM board that was released, and a lot has been written about it online. It has 128kbytes flash memory, 16kbyte of RAM and a Cortex-M0+ core running at 48MHz.

An ultra-high performance board is the FRDM-K64FFRDM-K64F, with 1Mbyte of flash memory, 256kbyte RAM and a 120MHz Cortex-M4 core.

There is also an mbed Application Shieldmbed Application Shield available which contains a display, small joystick and several sensors. I tried it with the  FRDM-K64FFRDM-K64F board but it would work with other boards too.

There are plenty of other models in the series and it just keeps growing. In the diagram below, the entire range is split up into a few categories each with their own strengths and benefits. The diagram is possibly already outdated; new interesting FRDM boards come out all the time it seems.

The designers of the range have taken the effort to introduce different sensors and connections on each FRDM board so that the user can explore beyond just the microcontroller The  FRDM-K64FFRDM-K64F for instance has an on-board accelerometer and magnetometer IC. Some of the FRDM boards have a built-in 4-digit LCD.

(Note: Not all FRDM boards are supported with the online mbed platform, so if you definitely wish to use mbed, confirm by examining the mbed website Boards page and check the Target vendor NXP Semiconductors selection on the left to make it easier to search. If the desired FRDM board is present then it is supported! If it is not present, then a conventional local compiler will need to be used).

What is mbed?

Ordinarily developing applications for a microprocessor or microcontroller entails setting up a PC or server with many tools such as a compiler, Flash memory programmer, software versioning control, interactive development environment (IDE) and so on, and then repeating all that again for all the physical places you wish to work and for all users. It doesn’t encourage rapid prototyping for new projects if all this needs to be done each time. ARM’s mbed platform solves these issues in one fell swoop. The mbed project is essentially all these tools for free online as Software-as-a-Service (SaaS). You can access it with any web browser from any PC.

A free mbed account provides storage space for source code, software versioning, online compiling (saving the need for having a powerful PC) and a wealth of high quality libraries ranging from I2C and SPI to audio and FFT. Prototyping applications with mbed is quicker and is far smoother and simplified experience compared even to Arduino. Application functionality can be extremely rich due to the vast array of libraries. Since I started using mbed a couple of years ago I’ve got around 30 projects in the cloud and when I’m prototyping for an ARM based device it is the first development platform I often pick up. It is hard to overstate just how fun and easy-to-use the FRDM board and mbed ecosystem is. It is worth obtaining an mbed-compatible board and log on to mbed.com to try it out.

How do the Boards Work?

Each FRDM board actually contains two microcontrollers. One is the target device where the applications you create will run. It is shown in orange in the diagram below. The other microcontroller (shown in dark blue) behaves as a debugger/programmer. It connects via USB to the PC, and can program the target device.

No additional power supply is needed to run the FRDM board; power is derived from the USB 5V source, although if desired, once the board has been programmed, the USB connection is unnecessary and power can be supplied using pins on the board.

The diagram here shows the typical base functionality on all FRDM boards. Most boards will have extras too, such as on-board LEDs, switches, touch sensors and so on. This is great because it means no soldering is needed for experimentation. One can directly start coding and have input/output using the on-board devices, until extra hardware is connected up to the input/output (I/O) pins.

The Kinetis microcontrollers have some pins that are used for debugging and programming; they are often used in a mode called Serial Wire Debug (SWD). If the microcontroller was used in production equipment, then an external programmer would connect to the SWD pins and program the chip as part of the production process. With the FRDM board, there is no need to have an external programmer because the debugger microcontroller on-board (shown in dark blue) is used to manipulate the SWD pins for programming and debug purposes.

The USB port is used to transfer compiled code from the PC to the blue microcontroller. It then toggles the SWD pins appropriately to load the code into the target microcontroller’s flash memory.

Many microcontrollers have UART pins; these are great for connecting to a PC for control purposes. With FRDM boards, the UART pins are by default connected to the debugger microcontroller so that the data can be passed through the same USB connector. When the USB connection is made to the PC, several virtual connections are made and one of these looks like a communications (COM) port. So, your application code on the orange target microcontroller could have print statements that send the text via the UART through to the PC, using the USB connection.

To install a program into the flash memory of the target microcontroller, all that is needed is a drag-and-drop operation from the PC file system into the USB mass storage device that appears when the USB connection is plugged in. In other words, the FRDM board also looks like a memory stick to the PC, and you can just place the compiled code there. The debugger will take the code, and program it into the target device automatically, using the SWD pins.

What Runs on the Debugger Microcontroller?

Since the FRDM board has two microcontrollers, (debugger microcontroller and the target microcontroller) it can get confusing to understand what code runs where. Three pieces of code are used. The table here gives names to the different pieces of code, and indicates where the code runs.

So, as can be seen, two bits of code run on the debugger microcontroller.

Both of these bits of code are already pre-installed (they can be upgraded). The first part is called a ‘bootloader’ which is activated when the reset button on the FRDM board is held down and the USB connection made to the PC. The bootloader is responsible for programming software onto the debugger microcontroller, and nothing else.

When the bootloader is activated, it will appear as a mass storage device to the connected PC, and will allow for either the bootloader itself to be upgraded, or for the second bit of software (the OpenSDA application) to be loaded to run on the debugger microcontroller. That second bit of software is what in normal debugger operation (i.e. when the reset button is not held down before inserting the USB cable into the PC) allows for the target microcontroller to execute its user application code or be programmed or debugged.

All that could sound a bit confusing (it was difficult for me to understand initially) so to put it another way, in normal use, when you plug the FRDM board into your PC (without holding down the reset button) then the debugger microcontroller OpenSDA application executes and appears to the PC as a mass storage device (like a USB memory stick) with a drive name like “MBED” or “FRDM-KL25Z” (it varies depending on the specific board and software version) and in this mode, the debugger microcontroller will allow the target microcontroller to run whatever program is on the target microcontroller flash memory, but at any time if desired the user can drag a new user program onto the mass storage, and the debugger microcontroller OpenSDA application will automatically take over, it will put the target microcontroller into a programming mode, and will transfer the user program to it.

If on the other hand the reset button was held down when powering up the FRDM board by plugging in the USB connector, then the OpenSDA application does not execute, and the debugger microcontroller activates the bootloader in a mode where it still looks like a mass storage device, but with a different name “BOOTLOADER”, and in this mode if a program is dragged onto the drive, it will be programmed onto the debugger microcontroller. It follows that the program should be either an updated bootloader program, or an updated OpenSDA application.

(Note: to complicate the story slightly, there are different code trains of bootloader and OpenSDA application, because some are closed source by third party suppliers, and some are open source; it doesn’t really matter for the purposes of this blog post, but it does matter if you wish to use specific tools for certain functionality like debugging).

The chances are high that a purchased FRDM board will have outdated software on the debugger microcontroller, so the first steps would be to obtain newer code, put the board into the bootloader mode by using that reset button procedure, and dragging the updated bootloader code onto the drive. Next, the board can be disconnected and reconnected and it should still appear as “BOOTLOADER” to the PC (it will now be the updated bootloader however), and then the OpenSDA application code can be dragged onto the drive. Unplugging and re-inserting the USB cable should now show the mass storage drive name to be something like “FRDM-KL25Z”, and this means the OpenSDA application is now running (the target microcontroller will also be running whatever is in its flash memory.

The upgrade process and how to use the board are covered in more detail further below.

Getting Started: What is Needed?

To get started a  FRDM-KL25ZFRDM-KL25Z board is a good choice. As alternative or additional suggestions, a  FRDM-KL05ZFRDM-KL05Z board is great for simpler projects, and a  FRDM-K22FFRDM-K22F or  FRDM-K64FFRDM-K64F where high performance is needed.

Unfortunately most of the boards do not come with pin or socket headers, so these need to be purchased separately and soldered on. Some of the FRDM boards use single-row headers, and some use double-row ones. The connections are physically compatible with the Arduino board layout (the FRDM boards have 3.3V input/output however, and some Arduino boards use 5V logic so that could cause issues).

Some of the FRDM boards come with a USB cable, but others may require this to be purchased separately. All the FRDM boards have a USB socket which is labelled SDA and this is used to program the board (there may be an additional USB socket on some of the FRDM boards, that connects directly to the target microcontroller, and doesn’t play a role in programming the board).

Also, a PC is required. I used Windows, but I did test the drag-and-drop operation with Linux too, and that functioned. I unfortunately was unable to test with a Mac.

The PC doesn’t have to be a high-performance one as mentioned earlier, because all the heavy lifting is done in the cloud. All you need is a web browser to access the mbed online development environment. The code will be compiled in the cloud and downloaded to your PC. Then it can be dragged onto the drive (mass storage device) that appears when the FRDM board is plugged into the PC USB connection.

SIL and DIL pins and sockets

Not all of these are needed, you might want to get a selection. A longer connector can be cut into smaller ones. For the dual-in-line socket versions (which are harder to cut) I tend to buy 6-way and 10-way, because they can be assembled into 12-way, 16-way and 20-way by pairing them up in different combinations.

Personally I often solder pins instead of sockets on the FRDM boards simply because it is cheaper, but that is the opposite convention to Arduino, and would make any plug-on boards incompatible if they come with pins soldered on them.

SIL Pins and Sockets

DIL Pins and Sockets

Upgrading the FRDM board Bootloader and OpenSDA Firmware

The FRDM board as mentioned looks like a USB memory stick to the PC, and can be programmed using a drag-and-drop procedure. The FRDM board achieves this through two pieces of software which are pre-installed as shipped on the board’s debugger microcontroller; a bootloader and a debug application known as OpenSDA. Both are usually old and need upgrading. This only needs to be done once when you first receive the board.

Note that for the first upgrade, the upgrade procedure is smoother with Windows version 7 or a Mac and may work with Linux. If you have a more recent version of Windows, then there are some initial extra steps that I found on the excellent mcuoneclipse website. The extra steps might not work with some editions of Windows. I tested on the Windows 10 Pro edition, and it worked. After the upgrade is complete for the first time, any version of Windows can be subsequently used.

Extra steps for recent Windows versions (Version 8 upward)

The steps are detailed in the screenshots below. Follow these steps, and continue with the upgrade, and once you’re done, you can undo these steps to get the PC back to its normal state.

Basically, click on the Windows Start icon, and type gpedit.msc and launch that application. In the left pane of the application, scroll down to Computer Configuration -> Administrative Templates -> Windows Components -> Search and then in the right pane select Do not allow locations on removable drives to be added to libraries and click on Edit policy setting. Enable it, and click on OK.

Next, for the latest Windows 10 releases you will also need to disable the Storage Service. To do that, click on the Windows start bar, and type 'services' to select the Services tool. Within that, search for Storage Service and then click on Stop as shown in the screenshot below.

Upgrade Steps

Note: this section refers to the KL25Z board, but it applies to the other FRDM boards too. Substitute the text KL25Z for the board you're using.

The procedure is:

1. Go to the PE micro website and download the OpenSDA Firmware (MSD & Debug) 'Firmware Apps' zip file (you will need to either register, or supply an e-mail address to get a one-time download link to the firmware bundle)
2. Unzip it, and also unzip the ‘OpenSDA Bootloader Update App’ zip file that is within the first zip file.
3. Hold down the Reset button on the FRDM board and plug the board to the PC. There are two USB sockets on the FRDM board. You need to use the one marked ‘SDA’. Release the button. The board should appear on the PC as a USB memory drive titled ‘BOOTLOADER’.
4. In the extracted and unzipped files, find the file titled ‘BOOTUPDATEAPP_Pemicro’. Drag that to the memory drive. Wait a few seconds for the transfer to complete, wait ten seconds more for good luck, then unplug and re-plug the FRDM board into the PC. No need to use the Reset button this time, it is not needed from now on. The board should appear as BOOTLOADER again.
5. In the extracted and unzipped files, find the file titled ‘MSD-DEBUG-FRDM-KL25Z_Pemicro’. There are many with near-similar names so it is important to find the one that explicitly has FRDM and KL25Z (or whatever the name of your FRDM board is!) in the title.  Drag that to the USB memory drive. Wait a few seconds for the transfer to complete, then wait ten seconds more just to be certain it is all programmed..
6. Unplug and re-plug the FRDM board into the PC. The board should now appear as a USB memory drive with the name MBED or FRDM-KL25ZFRDM-KL25Z and not 'BOOTLOADER'. The upgrade process is complete!

Working with the Online Tools

Go to os.mbed.com and set up an account, and then in the top menu select Hardware -> Boards and find the NXP  FRDM-KL25ZFRDM-KL25Z board. Click on it to bring up an entire page about the board and then look on the right side about half-way down the web page for an orange button with the text 'Add to your mbed Compiler’ and click on that too.

Next in the top menu select ‘Compiler’ to bring up a complete development environment in your web browser.

The development environment looks like this:

To create a new program, click on New and in the New Program pop-up window select the  FRDM-KL25ZFRDM-KL25Z board to be the platform, leave the Template at the default ('Blinky LED Hello World') and if you like, change the Program Name to whatever you fancy.

In the source code pane you’ll see a main.cpp file. Double-click on it to open it, and there will be a short program there that blinks an LED. If you click on Compile then the software will be built and automatically downloaded to your PC file system as a file called mbed_my_program_name_KL25Z.bin.

You can test it by dragging it over the USB memory if the FRDM board is plugged in. After a few seconds the software will be transferred and will automatically start running on the FRDM board. This demo program will make the RGB LED on the board blink red. The code is now in Flash memory and so unplugging and re-plugging the board into the PC will retain the code and the LED will continue to flash. Changing the program on the board is simple, just drag another file onto the USB memory file system.

Features and Documentation

The functionality available in mbed is excellent, and the mbed documentation  is really good too. Some of the functions have similar names to Arduino functions like DigitalIn and DigitalOut, so for those already familiar with Arduino, coding with mbed should be fairly smooth.

An Example Project

For a complete project with source code, one example is the USB keypad project. It uses a single component (a 4x4 keypad4x4 keypad) and eight wires, to make the shortcut keypad for PCs. It could come in handy when using CAD software packages with many shortcuts.

Advanced Use: mbed real-time operating system (RTOS)

Besides providing friendly APIs that make creating diverse applications easy, there is also real-time operating system (RTOS) functionality within mbed which greatly expands program structure possibilities and allows for users to simplify complex applications and allow them to run reliably. The OS allows for application tasks to be split into separate bits of code that can run whenever CPU capacity and other resources are available. Often in microcontroller projects there is the temptation to write everything in one large loop which can work fine but becomes very complicated quickly. Code can be untangled into separate processes or tasks using a real-time operating system.

The OS within mbed is based on Keil RTX and it appears to be free to use for all personal and commercial applications although this is worth confirming with ARM for commercial scenarios.

The diagram here shows just a small taste of the capabilities that can be enabled by using an OS for applications. Here a large single-loop program has been split up into three smaller tasks called A, B and C. The arrows show dependencies where each task needs to rely on sending or receiving information to another process. As an example process A might read analog sensor values, process B may filter them for noise, and process C could send sensor data to the cloud.

The horizontal execution flow shows that each process gets a portion of CPU time to run and then the next process gets some time and so on. However if there is noise in the sensor data then the data could be filtered out and there would be no need to send the noisy data to the cloud to conserve resources. It can be seen at the point marked ‘a’ that process C halts and waits during the period that perhaps noisy data is being filtered out. Only after an event at point ‘b’ does process C become ready again to run when it receives some CPU time.

It was decided to try out the mbed OS task handling capability. Using the  FRDM-K64FFRDM-K64F board and the mbed Application Shield, a short program was written that measured the temperature every second and averaged it. If the average changes by more than +-5% then an alert is activated. The program displays the temperature every second on the display but only issues an Alert message if the average exceeds the threshold. This program was created as two tasks. The first task is responsible for obtaining the temperature measurements and calculating the average. If the average differs from the limits then it sends a signal to a second task.

The second task sits and waits (i.e. consumes no resources) until it receives the signal from the first task. The second task is responsible for issuing the alert.

The averaging settings and temperature and alert display times can all be varied as desired; this is a level of flexibility that would be awkward to achieve in a single thread of execution. The code below exercises thread creation, signals and mutual exclusion (mutex) functionality.

#include "mbed.h"
#include "rtos.h"
#include "C12832.h"
#include "LM75B.h"




#define NUMSAMP 10
#define SIGDATAALERT 1




C12832 lcd(D11, D13, D12, D7, D10);
LM75B sensor(D14,D15);




double degc[NUMSAMP];
double avgmin, avgmax;




Mutex lcd_mutex; 
Thread *cloud_handler_thread;




// read the temperature periodically
void
temp_task(void)
{
  int i;
  double avg=0.0;
  while(1)
  {
    for (i=1; i<numsamp; i++)<br="">    {
        degc[i-1]=degc[i];
        avg+=degc[i];
    }
    degc[NUMSAMP-1]=sensor.read();
    avg+=degc[NUMSAMP-1];
    avg=avg/NUMSAMP;
    if ((avg<avgmin) |="" (avg="">avgmax))
    {
      avgmin=0.95*avg;
      avgmax=1.05*avg;
      // send a signal
      cloud_handler_thread->signal_set(SIGDATAALERT);
    }
    lcd_mutex.lock();
    lcd.locate(0,15);
    lcd.printf("%.1f deg C", degc[NUMSAMP-1]);
    lcd_mutex.unlock();
    Thread::wait(800);
    lcd_mutex.lock();
    lcd.locate(0,15);
    lcd.printf("          ");
    lcd_mutex.unlock();
    Thread::wait(200);
  } // end while
}




// display an alert whenever the filtered data exceeds a threshold
void
cloud_handler_task(void)
{
    while(1)
    {
        Thread::signal_wait(SIGDATAALERT);
        lcd_mutex.lock();
        lcd.locate(0,0);
        lcd.printf("ALERT");
        lcd_mutex.unlock();
        Thread::wait(1000);
        lcd_mutex.lock();
        lcd.locate(0,0);
        lcd.printf("          ");
        lcd_mutex.unlock();
    }
}




int
main(void)
{
    int i;
    lcd.cls();
    
    // initialize the bucket of readings
    degc[NUMSAMP-1]=sensor.read();
    for (i=0; i<numsamp-1; i++)<br="">    {
        degc[i]=degc[NUMSAMP-1];
    }
    avgmin=0.95*degc[NUMSAMP-1];
    avgmax=1.05*degc[NUMSAMP-1];
    
    // create threads
    cloud_handler_thread=new Thread(cloud_handler_task);
    Thread temp_thread(temp_task);
    
    while(1)
    {
        wait(1.0);
    }
    
    return(0); // expect warning on this line
}

Advanced Use: mbed CLI

Code written with mbed is compiled in the cloud, but it is possible to compile code locally too if the cloud option isn’t desirable for any reason; everyone has different needs, and some may not wish to use the online mbed platform. Although I prefer using the online tools, I decided to briefly test a local compiler option too.

The local compiler offering is called ‘mbed CLI’ and it is a set of scripts that together with a locally installed toolchain (e.g. ARM-GCC) provide the ability to retain mbed features while being able to work offline using your local computer/server.

Mbed CLI is available for Windows, Mac and Linux; I chose to install it on Linux and the CLI instructions were straightforward to create a project and build it all ready for installing on the FRDM board. Mbed CLI relies on Python (there is no need to know how to use Python though) so Python (and Python-dev) need to be installed first. For the build toolchain I used GCC-ARM version 4.9 available here and added GCC_ARM_PATH and MBED_GCC_ARM_PATH environment variables (pointing to the /usr/local/gcc-arm-none-eabi-4_9-2015q3/bin path) in my command shell startup file (.bashrc).

Following the instructions at the earlier link, the blinking LED ‘hello world’ type code was downloaded and built using the following commands (scroll through to see the commands and output). This was great because it means prototype code can be developed into a product with developers having full control of the toolchain.

shabaz@ubuntu:~/development/mbed/test1$ mbed import https://github.com/ARMmbed/mbed-os-example-blinky
[mbed] Importing program "mbed-os-example-blinky" from "https://github.com/ARMmbed/mbed-os-example-blinky" at latest revision in the current branch
[mbed] Adding library "mbed-os" from "https://github.com/ARMmbed/mbed-os" at rev #a6f3fd1a60d5
[mbed] Auto-installing missing Python modules...
shabaz@ubuntu:~/development/mbed/test1$ cd mbed-os-example-blinky/
shabaz@ubuntu:~/development/mbed/test1/mbed-os-example-blinky$ mbed compile -m K64F -t GCC_ARM
[mbed] Auto-installing missing Python modules...
Building project mbed-os-example-blinky (K64F, GCC_ARM)
Scan: .
Scan: FEATURE_CLIENT
Scan: FEATURE_UVISOR
Scan: FEATURE_BLE
Scan: FEATURE_COMMON_PAL
Scan: FEATURE_STORAGE
Scan: FEATURE_IPV6
Scan: FEATURE_IPV4
Scan: mbed
Scan: env
Compile [  0.4%]: main.cpp
Compile [  0.7%]: greentea_serial.cpp
Compile [  1.1%]: test_env.cpp
...
Compile [ 99.3%]: rt_Time.c
Compile [ 99.6%]: rt_Timer.c
Compile [100.0%]: test_env.cpp
Link: mbed-os-example-blinky
Elf2Bin: mbed-os-example-blinky
+-------------+-------+-------+------+
| Module      | .text | .data | .bss |
+-------------+-------+-------+------+
| Fill        |    62 |    0 | 2221 |
| Misc        | 27014 |  2208 |  88 |
| hal/common  |  1504 |    4 |  277 |
| hal/targets | 10004 |    12 |  188 |
| rtos/rtos  |    22 |    4 |    0 |
| rtos/rtx    |  5721 |    20 | 6786 |
| Subtotals  | 44327 |  2248 | 9560 |
+-------------+-------+-------+------+
Allocated Heap: 65536 bytes
Allocated Stack: unknown
Total Static RAM memory (data + bss): 11808 bytes
Total RAM memory (data + bss + heap + stack): 77344 bytes
Total Flash memory (text + data + misc): 47615 bytes
Image: ./BUILD/K64F/GCC_ARM/mbed-os-example-blinky.bin
shabaz@ubuntu:~/development/mbed/test1/mbed-os-example-blinky$

Summary

There is a huge selection of FRDM boards with various interesting peripherals on-board. The online mbed development environment is easy to use, and it is possible to rapidly create new applications with the very rich set of functions. There is also real time operating system (RTOS) capability for simplifying application creation.