To me, software and tools are by far more important than the microcontroller. Because the silicon is a ‘one time kind of thing’, where the software has to be maintained and working over a longer time. And at least my software usually needs to be ported to a new device, so portability and available software and tools are critical to me.

The combination of MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is unfortunately not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible :-).

Outline

If you are not using Processor Expert or the NXP MCUXpresso SDK v2, then you can move on. Otherwise…. and if you are still curious about how things work in Eclipse: read on and I’ll tell you how to something like this in Eclipse: Using Processor Expert in a MCUXpresso SDK project which is supposed not to be possible 🙂 :

OK, to be 100% correct: It is not the ‘full’ or ‘native’ support of Processor Expert in a MCUXpresso project. But I show a way how the benefits of Processor Expert (code re-use, graphical configuration, software component packaging and redistribution) can be used even in a MCUXpresso SDK Eclipse project which are not natively supported by Processor Expert.

How to use FRDM-KL27Z Boards?

I believe one of the best-selling NXP Freedom boards is the FRDM-KL25Z:

It is inexpensive (~USD 15), has reasonable speed (48 MHz) with decent FLASH (128 KByte) and RAM (16 KByte). The students at my university love that board too. And a distributor at the Embedded World show in Nürnberg told me that he thinks this is because of Processor Expert and all the tutorials on McuOnEclipse :-).

But recently the university ordered FRDM-KL27Z boards for student projects instead of FRDM-KL25Z, because this should not make any difference, right? Well, it actually does: The FRDM-KL27Z is supported by the MCUXpresso SDK v2 only, and the MCUXpresso SDK v2 projects are not supported by Processor Expert. When students realized that, they wanted to return the boards because with Processor Expert it is much easier, simpler and faster to use the FRDM boards. So I offered that they can exchange the FRDM-KL27Z boards with the FRDM-KL25Z ones I have in my classroom inventor.

With the result that very fast I had a pile of FRDM-KL27Z boards which students did not want to use:

That triggered the idea: maybe there is a way to make these board usable with Processor Expert, so students would again love to have them in their projects?

Approach

In “Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects” I presented an approach how to use Processor Expert with the NXP/Kinetis SDK (now MCUXpresso SDK). That approach used two projects: a master and a slave project. I have now found a way which uses a single project: enabling Processor Expert for a SDK project and having the ProcessorExpert.pe XML file in a single project:

This article describes how to use Processor Expert for NXP SDK projects for which Processor Expert is not supported by NXP. Using that approach, it is possible to use ‘generic’ or ‘non-cpu’ components for the SDK. This approach allows carrying over many of the good aspects of Processor Expert as code re-use and power software configuration and distribution. In this article I’m using the NXP FRDM-KL27Z board with Kinetis Design Studio V3.2.0. I’m using Processor Expert components from the McuOnEclipse project.

The approach uses the following steps:

1. Create a new SDK project or use an existing one
2. Copy a Processor Expert .pe file into the project
3. Ignore a few files generated by Processor Expert
4. Use Processor Expert to configure the project and to generate the software and drivers.

Prerequisites

In this article, I’m using NXP Kinetis Design Studio v3.2.0 with the MCUXpresso SDK for the FRDM-KL27Z board, but certainly any other Eclipse version or SDK version could be used too. You need:

• Kinetis Design Studio V3.2.0 (or any other Eclipse enabled with Processor Expert)
• FRDM-KL27Z board (or any other board supported by the SDK)
• MCUXpresso SDK for that board. You can create and download an SDK from https://mcuxpresso.nxp.com/en/welcome.
• Have the SDK support installed into the Eclipse IDE, see “Tutorial: Blinky with NXP Kinetis SDK V2.0 and Processor Expert“
• Installed McuOnEclipse components from SourceForge, for the latest version available at the time of this article, see “McuOnEclipse Components: 12-Mar-2017 Release“

Creating a Project

You can use an existing NXP SDK project for Kinetis Design Studio (KDS) V3.2.0. Or create a new one. To create a new project, us the menu  File > New > Kinetis SDK V2.x project.

Create a normal project. I recommend to turn on all drivers, but not enabling FreeRTOS as the Processor Expert component for FreeRTOS is more capable. So have it set to ‘all drivers’ (so we do not need any drivers afterwards) and ‘none’ for RTOS (as we can use Processor Expert for this later).

Adding Processor Expert

Next, add a Processor Expert .pe file to the project. For this I create a ‘dummy’ project just to have a ProcessorExpert.pe file available.

I usually create a new (empty) Processor Expert project using the menu File > New > Processor Expert project. Select a processor which is supported by Processor Expert (e.g. KL25Z).

Select from the list of Processors (not from the list of Boards):

Select ‘none’ for SDK and turn on ‘Processor Expert’:

then copy the .pe file from the SDK project into the SDK project:

After that, the ‘dummy’ project is not used any more and can be deleted.

The .pe file is recognized by Eclipse as Processor Expert: We have enabled Processor Expert for the NXP SDK v2 project: 🙂

About the Processor

The project now shows the Processor Expert components and settings, although it is for the ‘wrong’ microcontroller/processor (e.g. KL25Z instead of the KL27Z).

Processor Expert thinks it is for the KL25Z, but we want to use it for the KL27Z SDK project. The ‘Cpu’ component kind of represents all the knowledge about the device (memory map, vector table, peripherals like UART, I2C, SPI, etc). So with such a Processor Expert enabled project, I use all components which do not depend on that information. So that works for pure software components like the RingBuffer or Utility component, or for any of the McuOnEclipse components I have enhanced with the capabilities to work with the SDK v2 API. This includes components like SDK_BitIO, Shell,  FreeRTOS. And the number of supported components is growing with the goal to port as many existing projects to the SDK v2 and beyond.

Ignoring Files

So I have a Processor Expert project for the KL27Z, and I can generate code for it, like for any normal Processor Expert project:

However, the non-matching files need to be ignored for the SDK project.

Processor Expert creates the following folders:

• Documentation: here documentation files are generated.
• Project_Settings: this contains the linker file and the startup code. The SDK comes with its own files, so we can ignore them.
• Sources: this has the application event files (Events.c, Events.h) and the application main file (main.c). The SDK comes with its own files, so they should not be compiled.
• Static_Code: contains low-level macros for the wrong microcontroller, so this folder has not be compiled with the SDK (should be ignored)
• Genereated_Code: here all the driver source files are placed. Here most of the things apply to the SDK v2 project, but not all.

To exclude files from the build (so they are not part of the SDK project), use the context menu on the file/folder and enable ‘Exclude resource from build’ (menu Properties > C/C++ build > Settings > Exclude resource from build, see “Exclude Source Files from Build in Eclipse“):

Do this for the following folders:

• Project_Settings
• Sources
• Static_Code

Alternatively, the generation for the ‘Project_Settings’ can be turned off in the Build options of the Cpu component:

Generated_Code

In the generated code, there are three files which are not matching the device of the SDK project. Exclude the following files from the build:

• Cpu.c
• PE_LDD.c
• Vectors.c

Build and Next Steps

I can now generate code, build and debug the application:

So this is not much different from any other project. But now I have the power of Processor Expert enabled for the SDK v2 project, which is what I’m doing next: Using Processor Expert to extend the project to blink a LED (‘blinky’).

McuLibConfig Component

Using Processor Expert components with that project, they need to know that they shall work with the NXP MCUXpresso SDK. For this the McuLibConfig is added to the project: From the ‘Components Library’ add the component to the project and configure it to use the MCUXpresso SDK:

LED Component

Next, add a LED component to the project:

SDK_BitIO Component

By default, the LED component uses the normal Processor Expert BitIO component. Change it to use the SDK_BitIO component, available in the drop down for the ‘Pin’ settings:

This now uses a generic BitIO component which uses the SDK API:

Checking the schematics of the board, I can see that the Red LED is on PTB18 (GPIOB, PORTB, Pin 18):

With turning on the ‘Do Pin Muxing’ option, I don’t have to care about the muxing.

Enable the Clocks

The component cares about the muxing, but not about the clocks. So I have to add the following inside BOARD_InitPins(), otherwise I will run into a hard fault:

CLOCK_EnableClock(kCLOCK_PortB);

Wait Component

Because I want to delay the blinking of the LED, I add the Wait component which allows me to burn CPU cycles:

Initialization Code

In normal Processor Expert projects, the components get initialized in PE_Low_Level_Init(). For the SDK project, I have to call the Init functions in my code.

I include the component header files:

/* component header files */
#include "WAIT1.h"
#include "LED1.h"

Inside my code, I initialize the components:

/* initialize components */
LED1_Init();
WAIT1_Init();

Followed by the blinky code:

for(;;) { /* Infinite loop to avoid leaving the main function */
  LED1_Neg(); /* negate the LED */
  WAIT1_Waitms(500); /* wait for the given number of milliseconds */
}

Generate again Processor Expert code, build and debug the project, and I have a added a ‘blinky’:

🙂

Summary

While Processor Expert is not supported with NXP MCUXpresso SDK v2 projects, there is a way to add Processor Expert code generation to such projects. It adds re-use of software components and a way to graphically configure software and drivers. It works with ‘software’ components or components of the McuOnEclipse projects which have been enabled to be used with the SDK v2. With this, this approach closes a gap the NXP SDK v2 has created with no graphical driver or peripheral configuration.

An extended example project used in this article can be found on GitHub: https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/FRDM-KL27Z/FRDM-KL27Z_McuOnEclipseLib. It shows as well the subset of currently supported components and drivers which is growing and growing:

I hope you find them useful.

Happy SDKinging 🙂

Links

• NXP MCUXpresso Software and Tools with Clocks Tool
• Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects
• Overview: Processor Expert
• Exclude Source Files from Build in Eclipse
• Tutorial: Blinky with NXP Kinetis SDK V2.0 and Processor Expert
• Tutorial: FreeRTOS with NXP Kinetis SDK V2.0 and Processor Expert