Documents

[FRDM-KL46Z - PE - CW] Tutorial: Make it blink in just 5min

cstanton — Wed, 09 Aug 2023 12:14:14 GMT

Current Revision posted to Documents by cstanton on 8/9/2023 12:14:14 PM

This Project brings you with a quick step in blinking an LED on FRDM-KL46ZFRDM-KL46Z board using Processor Expert.

The Freescale Freedom development platform is a set of software and hardware tools for evaluation and development. It is ideal for rapid prototyping of microcontroller-based applications. The Freescale Freedom KL46Z hardware, FRDM-KL46ZFRDM-KL46Z, is a simple, yet sophisticated design featuring a Kinetis L series microcontroller, built on the ARM® Cortex™-M0+ core.

FRDM-KL46Z can be used to evaluate the KL46, KL36, KL26 and KL16 Kinetis L series devices. It features a MKL46Z256VLL4MKL46Z256VLL4, this device boasting a max operating frequency of 48MHz, 256KB of flash, 32KB RAM, a full-speed USB controller, segment LCD controller, and loads of analog and digital peripherals. The FRDM-KL46Z hardware is form-factor compatible with the Arduino™ R3 pin layout, providing a broad range of expansion board options. The on-board interfaces includes a 4 digit segment LCD, a 3-axis digital accelerometer, magnetometer, capacitive touch slider, and ambient light sensor.

The FRDM-KL46Z features the Freescale open standard embedded serial and debug adapter known as OpenSDA. This circuit offers several options for serial communications, flash programming and run-control debugging.

Refer to the link for more details on Freedom board.

The features of the FRDM-KL46ZFRDM-KL46Z include:

MKL46Z256VLLZ4MKL46Z256VLLZ4 MCU (48 MHz, 256 KB Flash, 32 KB RAM, Low power, 100 LQFP package)
Dual role USB interface with mini-B USB connector
Open SDA
4 digit segment LCD module
Capacitive touch slider
Ambient light sensor
MMA8451QMMA8451Q accelerometer
MAG3110MAG3110 Magnetometer
2 user LEDs
2 user push buttons
Flexible power supply options – USB, coin cell battery, external source
Battery-ready, power-measurement access points
Easy access to MCU I/O via Arduino ™ R3 compatible I/O connectors
Programmable OpenSDA debug interface with multiple applications available including:
- Mass storage device flash programming interface
- P&E Debug interface provides run-control debugging and compatibility with IDE tools
- CMSIS-DAP interface: new ARM standard for embedded debug interface
- Data logging application
- Arduino R3 compatibility

Before we start on our project make sure the board is in Debug mode (refer to the blog how to load in Debug mode using OpenSDA)

Now that our board is loaded in Debug Let’s start on creating a CodeWarrior project to quickly demonstrate blinking LED on KL46 board.

A free version of Codewarrior can be downloaded following the link below in the Downloads section:

www.freescale.com/cwmcu10

The Evaluation version is a 30 days Limited version and the Special Edition is Code Size Limited version (64KB for Kinetis MCUs with an ARM Cortex-M0+ core and 128KB for the Kinetis MCUs with an ARM Cortex-M4 core).

Follow the below steps for creating the CW project:

Select File->New->Bareboard Project

Provide Project Name “Blink it using PE-KL46” then click Next

Now select the MCU exist on our KL46 board it is “MKL46Z256”

Kinetis L Series-> KL4x Family->KL46Z(48 MHz) Family->MKL46Z256

then Click Next

Select OpenSDA option to connect for this board for debugging and programming, then click Next

Then click Next to proceed further

Select ‘Processor Expert’ option as we are creating the project using Processor Expert then click ‘Finish’

I have created the project by name “Blink it using PE-KL46” as shown below are the component inspector showing CPU with default settings:

First we need to configure CPU parameter settings as shown below:

Under clock Settings->

System Oscillator: Enabled

Clock Source: External Oscillator

Clock Frequency: 8 MHz (as this board is connected to external crystal oscillator )

Under clock source settings-> clock source settings 0-> MCG settings->

MCG mode: FEI (FLL engaged internal)

FLL settings->FLL output[MHz] : 47.972352

Then automatically MCG output[MHz] gets selected to 47.972352

Then under Clock configurations->Clock configuration 0->System clocks->

Set

Core clock: 47.972352 MHz

Bus clock: 23.986176 MHz

Then all other parameters which were highlighted in RED gets cleared which means the settings are correct. These settings are as shown in above figure.

Since now our project skeleton is ready (i.e no component module peripherals has been added to our project) we need to add the required peripheral component module as per our requirement.

Our requirement here is to blink the LED present in KL46 board; refer to below schematic there are two LED’s exist on board Red and Green connected to Port-E 29^th bit (PTE29) and Port-D 5^th bit (PTD5).

LED	KL46
Green (LED1)	PTD5
Red (LED2)	PTE29

We now need to add two component modules for these two led’s those are as shown below

Now select under Component Library-> categories sub window

Click on Logical Device Drivers->Port I/O-> BitIO_LDD

Right click and select ‘Add to Project’ twice since we need two LED component in our project.

Now we are adding software generated ‘wait’ component in order to add delay routine to our project.

Under Component Library-> categories sub window

Click on SW->User Components->Wait component, Right click and select ‘Add to Project’

Rename the components (LED_RED, LED_Green, WAIT1)as shown below:

Make the ‘LED_RED’ BitIO settings as shown below: assigned to output pin ‘PTE29’

Make the ‘LED_Green’ BitIO settings as shown below: assigned to output pin ‘PTD5’

And default settings for ‘Wait1’ component as shown below:

Now click on ‘Generate Processor Expert code’ radio button as shown below:

You can see the tool generates required code as shown below:

All the required header files will get generated under ‘Generated_Code’ folder as shown below:

Now select ‘ProcessorExpert.c’ from project window

Add below lines of code in ‘ProcessorExpert.c’ file

int main(void)

/*lint -restore Enable MISRA rule (6.3) checking. */

{

/* Write your local variable definition here */

/*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/

PE_low_level_init();

/*** End of Processor Expert internal initialization. ***/

LDD_TDeviceData *Led_RPtr, *Led_GPtr;

Led_RPtr = LED_RED_Init((LDD_TUserData *)NULL);

Led_GPtr = LED_Green_Init((LDD_TUserData *)NULL);

/* Write your code here */

/* For example: for(;;) { } */

while(1)

{

LED_RED_ClrVal(Led_RPtr);

LED_Green_ClrVal(Led_GPtr);

WAIT1_Waitms(1000);

LED_RED_SetVal(Led_RPtr);

LED_Green_SetVal(Led_GPtr);

WAIT1_Waitms(500);

}

/*** Don't write any code pass this line, or it will be deleted during code generation. ***/

/*** RTOS startup code. Macro PEX_RTOS_START is defined by the RTOS component. DON'T MODIFY THIS CODE!!! ***/

#ifdef PEX_RTOS_START

PEX_RTOS_START(); /* Startup of the selected RTOS. Macro is defined by the RTOS component. */

#endif

/*** End of RTOS startup code. ***/

/*** Processor Expert end of main routine. DON'T MODIFY THIS CODE!!! ***/

for(;;){}

/*** Processor Expert end of main routine. DON'T WRITE CODE BELOW!!! ***/

} /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/

/* END ProcessorExpert */

The functions related to LED_RED, LED_Green can be explored from the Generated code folder in “LED_RED.c”, “LED_Green.c” and defined in LED_RED.h, LED_Green.h files as shown below:

Its functions can also be seen from components window as shown:

As per the code instruction we are turning on LED for 1000 ms and turning off the LED’s for 500 ms and looping forever.

Now it’s time to clean and Build the project as shown:

You can then see project starts building as shown:

Now Run the project as shown:

Now you can see the blinking of Red and Green LED on KL46 board

Created Project folder and output video file is attached in this tutorial for quick reference.

Happy Blinking LED on PE.....

Attachments:

community.element14.com/.../Blink-it_2D00_kl46-using-PE.rar

players.brightcove.net/.../index.html

Tags: freedom-board, kl46, kinetis-l

[FRDM-KL46Z - FRDM-KL25Z - PE] Tutorial: Migrate your code easily

cstanton — Wed, 09 Aug 2023 12:10:03 GMT

Current Revision posted to Documents by cstanton on 8/9/2023 12:10:03 PM

What if i have a processor expert project of my older freedom board and want to migrate or work on the same existing project on newer version of any freedom board? Do need to create from scratch till end: let’s see in this tutorial how to migrate between FRDM-KL25FRDM-KL25 to FRDM-KL46ZFRDM-KL46Z freedom board using Processor Expert tool.

Processor Expert provides an efficient development environment for rapid application development of the embedded applications. You can develop embedded applications for a wide range of microcontrollers and microprocessor systems using Processor Expert.

Processor Expert is integrated as a plug-in into the CodeWarrior IDE. You can access Processor Expert from the CodeWarrior IDE using the Processor Expert menu in the CodeWarrior IDE menu bar. The Processor Expert plug-in generates code from the embedded components and the CodeWarrior IDE manages the project files and compilation and debug processes.

Processor Expert generates all drivers during the code generation process. The generated files are automatically inserted into the active (default) target in the CodeWarrior project.

As a pre-requisite to work on this one should have sample code of KL25Z you can download this from HERE (alternately I have attached the project for quick reference) And your new Freedom board, as in my case I am having FRDM-KL46ZFRDM-KL46Z and latest version of Code Warrior tool.

A free version of Codewarrior can be downloaded following the link below in the Downloads section:

www.freescale.com/cwmcu10

Before we start here are the features of our New FRDM-KL46ZFRDM-KL46Z board stating which all the peripherals available are on board to work on: Refer to the link for more details:

MKL46Z256VLLZ4MKL46Z256VLLZ4 MCU (48 MHz, 256KB Flash, 32 KB RAM, Low power, 100LQFP package)
Dual role USB interface with mini-B USB connector
Open SDA
4 digit segment LCD module
Capacitive touch slider
Ambient light sensor
MMA8451QMMA8451Q accelerometer
MAG3110 MAG3110 Magnetometer
2 user LEDs
2 user push buttons
Flexible power supply options – USB, coin cell battery, external source
Battery-ready, power-measurement access points
Easy access to MCU I/O via Arduino ™ R3 compatible I/O connectors
Programmable OpenSDA debug interface with multiple applications available including:
- Mass storage device flash programming interface
- P&E Debug interface provides run-control debugging and compatibility with IDE tools
- CMSIS-DAP interface: new ARM standard for embedded debug interface
- Data logging application
Arduino R3 compatibility

Before we start on our project make sure the board is in Debug mode (refer to the blog how to load in Debug mode using OpenSDA)

Now let’s start on migrating the available sample code of KL25Z, I have selected the “pwm_led” project which is located in folder “~\Downloads\KL25 Sample Code\kl25_sc_rev10\klxx-sc-pex\projects\pwm_led\cw”

Open this project in code warrior in current workspace (you can drag and drop the “.project” present in pwm_led project folder).

I have rename the project as “pwm_led-KL25” and saved a copy in my current workspace to differentiate the original one.

You can see from above snap shot i have opened the project it has kinetis family MCU ‘MKL25Z128VLK4’ running at 8 MHz connected to external crystal, PEE(PLL engaged external) as MCG mode and core clock is 48 MHz, Bus clock is 24 MHz.

The components present in this project are module "PeriodicInterrupt" (component TimerUnit_LDD), Module "PWMTimerRG" (component name ‘PWMTimerRG’ of type TimerUnit_LDD ), and Module "PWMTimerB" (component name PWMTimerB of type TimerUnit_LDD).

Now create a new project for KL46Z board following below procedure (refer to the blog link for “how to create project using processor expert” )

In the CodeWarrior, click File menu and select New > Bareboard Project in order to create a new project. The Project Wizard appears. Enter the name of the project “pwm-led migrate-kl46” and click Next.

Now select the MCU exist on our KL46 board it is “MKL46Z256”

Kinetis L Series-> KL4x Family->KL46Z(48 MHz) Family->MKL46Z256 then Click Next.

Select OpenSDA option to connect for this board for debugging and programming, then click Next.

Select ‘Processor Expert’ option as we are creating the project using Processor Expert then click ‘Finish’

I have created the project by name “pwm-led migrate-kl46” as shown below is the component inspector showing CPU with default settings:

First we need to configure CPU parameter settings as shown below:

Under clock Settings->

System Oscillator: Enabled

Clock Source: External Oscillator

Clock Frequency: 8 MHz (as this board is connected to external crystal oscillator )

Under clock source settings-> clock source settings 0-> MCG settings->

MCG mode: FEI (FLL engaged internal)

FLL settings->FLL output[MHz] : 47.972352

Then automatically MCG output[MHz] gets selected to 47.972352

Then under Clock configurations->Clock configuration 0->System clocks->

Set

Core clock: 47.972352 MHz

Bus clock: 23.986176 MHz

Then all other parameters which were highlighted in RED gets cleared which means the settings are correct. These settings are as shown in above figure.

Since now our project skeleton is ready (i.e no component module peripherals has been added to our project) we need to add the required peripheral component module as per our requirement.

Copy all the three components present in KL25Z project as shown:

Paste the copied 3 components to our created project folder “pwm-led migrate-kl46” under ‘Components’ window as shown below:

Now select the first component ‘PeriodicInterrupt’ and change the settings as shown:

This is a Periodic interrupt timer module with counter direction as Down count, it uses internal clock source of 24 MHz as counter frequency. Make sure the interrupt is enabled and the period of the counter is set to 50 us (i.e this PIT will generate an interrupt on every 50us)

Note: there is an RGB LED connected to port pins in KL25Z board but in KL46Z board only 2 LED’s are connected no RGB is present in this. RED connected to PTE29 and Green is connected to PTD5, in order to connect the third LED i.e blue we need to connect it manually.

The second component is “PWMTimerRG” of type “TimerUnit_LDD” which is connected to RED and GREEN LED of KL25Z board its setting are as shown below:

This module is connected to TPM0 Flex Timer Module which runs in ‘UP” counter direction with period of 2.7306 ms with its interrupt disabled.

Further to this timer module we are taking 2 outputs by connecting them to two channels, one is connected to channel-2 (TPM0_C2) of timer module which leads to o/p port pin PTE29 and another connected to channel-5 (TPM0_C5) of timer module which in turn connects to PTD5 port pin.

We have selected these channel output port pins because the physical LED’s are connected in the board to particular GPIO pins i.e

Refer to below schematic there are two LED’s exist on board Red and Green connected to Port-E 29^th bit (PTE29) and Port-D 5^th bit (PTD5).

LED	KL46
Green (LED1)	PTD5
Red (LED2)	PTE29

We should run this timer as PWM to do so it has to run in ‘compare’ mode. As this module is 16 bit timer running counts from 0000 to FFFF (0 to 65535 timer-ticks) and initial offset is given as ‘0’ timer-ticks so that the PWM starts from 0% of dutycycle. We access this ‘offset’ variable during programming and continuously change its value varying the duty cycle to 100%.

Next coming to third module “PWMTimerB” it is connected to ‘Blue’ LED in KL25Z board we need to connect this manually in case of KL46Z board and we are connecting it to PTE23 port pin which internal connected to TPM2- channel-1, its period is 2.7306 ms and ‘offset’ is set to ‘0’.

The PWM waveform will look like the below picture:

Now all our module settings have been done and we can now ‘generate’ the project to generate Processor Expert code, which creates all supporting header files and API’s required.

Now it’s time for us to write our application code, since RGB LED is not present in KL46Z board i am going to write my own application where i will be varying the brightness of LED present in KL46Z (i.e Red and Green) through varying the PWM duty cycle.

The place where i need to write my code is file “ProcessorExpert.c” located in ‘sources’ folder in my project folder which is shown in below picture.

Since we are writing fresh lines of code i delete all its content by pressing Ctrl-A and Delete then paste below line of code.

/* ###################################################################

** Filename    : ProcessorExpert.c

** Project     : ProcessorExpert

** Processor   : MKL46Z256VMC4

** Version     : Driver 01.01

** Compiler    : GNU C Compiler

** Date/Time   : 2014-06-06, 08:06, # CodeGen: 0

** Abstract    :

**         Main module.

**         This module contains user's application code.

** Settings    :

** Contents    :

**         No public methods

**

** ###################################################################*/

/*!

** @file ProcessorExpert.c

** @version 01.01

** @brief

**         Main module.

**         This module contains user's application code.

*/

/*!

** @addtogroup ProcessorExpert_module ProcessorExpert module documentation

** @{

*/

/* MODULE ProcessorExpert */

/* Including needed modules to compile this module/procedure */

#include "Cpu.h"

#include "Events.h"

#include "PeriodicInterrupt.h"

#include "PWMTimerRG.h"

#include "PWMTimerB.h"

/* Including shared modules, which are used for whole project */

#include "PE_Types.h"

#include "PE_Error.h"

#include "PE_Const.h"

#include "IO_Map.h"

volatile bool PeriodicEvent = FALSE; // interrupt for every 50us to write each inc timer value (0 to 65535 timer value)

LDD_TDeviceData *PWMTimerRG_DeviceData, *PWMTimerB_DeviceData;

LDD_TDeviceData *PeriodicInterrupt_DeviceData;

const int RedChannel = 0;

const int GreenChannel = 1;

const int BlueChannel = 0;

/******************************************************************************/

int main(void)

{

            LDD_TError Error;

            int PulseOffset = 0;

            int dir = 0;

            /*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/

            PE_low_level_init();

            /*** End of Processor Expert internal initialization.                    ***/

            /* Intialize the timers */

            PWMTimerRG_DeviceData = PWMTimerRG_Init(NULL);

            PWMTimerB_DeviceData = PWMTimerB_Init(NULL);

            PeriodicInterrupt_DeviceData = PeriodicInterrupt_Init(NULL);

            /* Set initial compare value */

            PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, RedChannel, PulseOffset);

            PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, GreenChannel, PulseOffset);

            PWMTimerB_SetOffsetTicks(PWMTimerB_DeviceData, BlueChannel, PulseOffset);

            /* Turn on the timers */

            Error = PWMTimerRG_Enable(PWMTimerRG_DeviceData);

            if (Error != ERR_OK)

                        PE_DEBUGHALT();

            Error = PWMTimerB_Enable(PWMTimerB_DeviceData);

            if (Error != ERR_OK)

                        PE_DEBUGHALT();

            Error = PeriodicInterrupt_Enable(PeriodicInterrupt_DeviceData);

            if (Error != ERR_OK)

                        PE_DEBUGHALT();





            PulseOffset = 0;



            while (1)

            {

                        if (PeriodicEvent) {



                                    if(dir == 0) //incremental intensity

                                    {

                                                PulseOffset = PulseOffset + 1;

                                                if(PulseOffset >= 65535)

                                                {

                                                            dir = 1;

                                                }

                                    }

                                    else // dir == 1 decrementing intensity

                                    {

                                                PulseOffset = PulseOffset - 1;

                                                if(PulseOffset == 0)

                                                            dir = 0;

                                    }



                                    PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, RedChannel,PulseOffset);

                                    PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, GreenChannel, PulseOffset);



                                    PeriodicEvent = FALSE;

                                    }

            }



            /*** Don't write any code pass this line, or it will be deleted during code generation. ***/

/*** RTOS startup code. Macro PEX_RTOS_START is defined by the RTOS component. DON'T MODIFY THIS CODE!!! ***/

#ifdef PEX_RTOS_START

PEX_RTOS_START(); /* Startup of the selected RTOS. Macro is defined by the RTOS component. */

#endif

/*** End of RTOS startup code. ***/

/*** Processor Expert end of main routine. DON'T MODIFY THIS CODE!!! ***/

for(;;){}

/*** Processor Expert end of main routine. DON'T WRITE CODE BELOW!!! ***/

            return 0;

} /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/

/* END ProcessorExpert */

/*

** ###################################################################

**

** This file was created by Processor Expert 10.0 [05.03]

** for the Freescale Kinetis series of microcontrollers.

**

** ###################################################################

*/

Code explanation:

First initialise the timer as shown below line of code:

PWMTimerRG_DeviceData = PWMTimerRG_Init(NULL); // initialise timer concern to Red and Green LED

PWMTimerB_DeviceData = PWMTimerB_Init(NULL); // initialise timer concern to Blue LED

PeriodicInterrupt_DeviceData = PeriodicInterrupt_Init(NULL);// initialise the Periodic interrupt timer

Next we are giving initial value to the PWM output channels (Red channel, Green channel, Blue channel)

Function "PWMTimerRG_SetOffsetTicks()" does this job

'PulseOffset' = 0 initially so PWM starts from 0 value

PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, RedChannel, PulseOffset);

PWMTimerRG_SetOffsetTicks(PWMTimerRG_DeviceData, GreenChannel, PulseOffset);

PWMTimerB_SetOffsetTicks(PWMTimerB_DeviceData, BlueChannel, PulseOffset);

Next we need to turn on the timers this is done using the function "PWMTimerRG_Enable()"

In while(1) loop we are writing PWM value from 0 to 65535 and again from 65535 to 0 using the function "PWMTimerRG_SetOffsetTicks()". this is done every periodically 50 us. 'PulseOffset' is variable which will take care of writing the PWM cycle value

As mentioned earlier the Periodic interrupt timer module will be generating an interrupt for every 50 us we need to create a variable “PeriodicEvent” as shown below in the file “Events.c”

extern volatile bool PeriodicEvent;

Add below lines of code inside a function as shown

“void PeriodicInterrupt_OnCounterRestart(LDD_TUserData *UserDataPtr)”

void PeriodicInterrupt_OnCounterRestart(LDD_TUserData *UserDataPtr)

{

/* Write your code here ... */

PeriodicEvent = TRUE;

}

Save all the files then clean and Build the project as shown below:

The build progress is shown below:

Now connect the board to USB through OpenSDA port of the board and Run the project as shown below:

You can see Run progress bar as shown below:

Below is the console window which shows the status of execution process

You can see the output which shows 2 LED’s Red and Green intensity is increased from 0% to 100% and again coming back from 100% to 0%. You can see the output waveform on CRO by connecting at led terminal as shown:

The output waveform seen through oscilloscope is as shown below along with setup:

Watch the video output which is attached in this blog. Created supporting project files have been enclosed too for quick reference.

So it is concluded that by using the processor expert migration of the project from different Freedom platform boards made easy.

Happy Migrating .....

Attachments:

community.element14.com/.../pwm_5F00_led_2D00_kl25.rar
community.element14.com/.../pwm_2D00_led-migrate_2D00_kl46.rar

players.brightcove.net/.../index.html

Tags: freedom-board, freescale, kl46, frdm-kl25z

[FRDM-KL46Z - CW] Tutorial: Make it blink in 15min

cstanton — Wed, 09 Aug 2023 12:07:07 GMT

Current Revision posted to Documents by cstanton on 8/9/2023 12:07:07 PM

This Project brings you with a quick step in blinking an LED on FRDM-KL46ZFRDM-KL46Z board using CodeWarrior.

Refer to the link for more details on Freedom board.

The features of the FRDM-KL46ZFRDM-KL46Z include:

MKL46Z256VLLZ4MKL46Z256VLLZ4 MCU (48 MHz, 256 KB Flash, 32 KB RAM, Low power, 100 LQFP package)
Dual role USB interface with mini-B USB connector
Open SDA
4 digit segment LCD module
Capacitive touch slider
Ambient light sensor
MMA8451QMMA8451Q accelerometer
MAG3110MAG3110 Magnetometer
2 user LEDs
2 user push buttons
Flexible power supply options – USB, coin cell battery, external source
Battery-ready, power-measurement access points
Easy access to MCU I/O via Arduino ™ R3 compatible I/O connectors
Programmable OpenSDA debug interface with multiple applications available including:
- Mass storage device flash programming interface
- P&E Debug interface provides run-control debugging and compatibility with IDE tools
- CMSIS-DAP interface: new ARM standard for embedded debug interface
- Data logging application
- Arduino R3 compatibility

Before we start on our project make sure the board is in Debug mode (refer to the blog how to load in Debug mode using OpenSDA)

Now that our board is loaded in Debug Let’s start on creating a CodeWarrior project to quickly demonstrate blinking LED on KL46 board.

A free version of Codewarrior can be downloaded following the link below in the Downloads section:

www.freescale.com/cwmcu10

Follow the below steps for creating the CW project:

Select File->New->Bareboard Project

Provide Project Name “Blink-it using CW” then click Next

Now select the MCU exist on our KL46 board it is “MKL46Z256”

Kinetis L Series-> KL4x Family->KL46Z(48 MHz) Family->MKL46Z256 then Click Next.

Select OpenSDA option to connect for this board for debugging and programming, then click Next

Then click Next to proceed further

proceed further by clicking Next

in Rapid application development do not select Processor Expert then click on finish.

I have created the project by name “Blink-it using CW” as shown below:

Now open “main.c” and add the below code to it.

#include"derivative.h"/* include peripheral declarations */

void delay(int itime);

int main(void)

{



SIM_SCGC5 |= SIM_SCGC5_PORTE_MASK;

PORTE_PCR29 = PORT_PCR_MUX(1);



           GPIOE_PDDR |= (1 << 29);



          for(;;) {

             GPIOE_PTOR |= (1 << 29);

             delay(1000);

        }



       return 0;

}

void delay(int itime){

   int icompTime = 0;

   for(icompTime=itime*1000;icompTime!=0;icompTime--){

   }

}

The line of code shown below is System Clock Gating Control Register 5 (SIM_SCGC5)and Enable clock for PORT E setting bit field PORTE

SIM_SCGC5 |= SIM_SCGC5_PORTE_MASK

Next below line is Pin Control Register n (PORTx_PCRn) setting for PORTE, and Select GPIO as pin functionality on multiplexer setting field MUX=001

PORTE_PCR29 = PORT_PCR_MUX(1);

The below line of code is Port Data Direction Register (GPIOx_PDDR) and Set GPIO direction set bit corresponding bit on the direction register for each port, set the bit means OUTPUT

GPIOE_PDDR |= (1 << 29);

In for() loop we are toggling the output LED connected to PortE29

This can be found from Schematic of KL46Z board (http://www.element14.com/community/docs/DOC-54780/l/element14-presents-the-frdm-kl46z--a-freescale-kinetis-l-based-freedom-development-platform)

LED	KL46
Green (LED1)	PTD5
Red (LED2)	PTE29

Now it’s time to clean and Build the project as shown:

You can then see project starts building as shown

Now Run the project as shown:

Now you can see the blinking of Red LED on KL46 board

Project created folder and Video output of this project execution is attached for reference.

Now we will modify our code to blink Green LED too (both Red and Green)

By referring to schematic we know Green LED is connected to port PTD5

#include"derivative.h"/* include peripheral declarations */

void delay(int itime);

int main(void)

{

           SIM_SCGC5 |= SIM_SCGC5_PORTE_MASK; // PORT E mask Red LED

    SIM_SCGC5 |= SIM_SCGC5_PORTD_MASK; // PORT D mask connected to Green LED

PORTE_PCR29 = PORT_PCR_MUX(1); // PORT E MUX

PORTD_PCR5 = PORT_PCR_MUX(1); // PORT D MUX

           GPIOE_PDDR |= (1 << 29); //      switching on RED LED

           GPIOD_PDDR |= (1 << 5); //      switching on Green LED



          for(;;) {

             GPIOE_PTOR |= (1 << 29); // Toggling RED LED after some delay

             GPIOD_PTOR |= (1 << 5);   // Toggling Green LED after some delay

             delay(1000);

        }



       return 0;

}

void delay(int itime){

   int icompTime = 0;

   for(icompTime=itime*1000;icompTime!=0;icompTime--){

   }

}

we can now see both LED's are blinking

Happy Blinking LED on KL46 board...

players.brightcove.net/.../index.html

Attachments:

community.element14.com/.../Blink-it-CW_2D00_KL46.rar

Tags: freescale, kl46, kinetis, freedom

New Kinetis Design Studio V3.0.0 available

bheemarao — Fri, 08 Oct 2021 08:27:17 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 8:27:17 AM

“This document has been extracted from Erich Styger blog https://community.freescale.com/docs/DOC-104880 with his agreement.”

Greetings,

The new Kinetis Design Studio V3.0.0 is available in the download section of the Freescale web:

http://www.freescale.com/kds

Kinetis Design Studio is free of charge and unlimited.

What's New

New Eclipse Luna 4.4 IDE
Added Mac OS X (10.10, "Yosemite") host operating system support with Segger J-Link.
Added CMSIS-SVD Peripheral Register viewer.
New 'Welcome' view
New GNU ARM Embedded (launchpad) toolchain, reducing memory footprint especially for small devices.
New upgrade/migration assistant to migrate projects to V3.0.0.
Updated and extended Segger and P&E debugging support: attach to running target, semihosting and advanced flash programming features.
New Processor Expert V3.0 with multiple repository support and simplified Kinetis SDK usage and ability to generate projects for IAR and Keil.
Updated New Project Wizard (NPW) for simpler project creation.
Updated GNU ARM Eclipse plugins, multiple tool chain configurations.
Aligned and optimized for Kinetis SDK v1.2
New Device Support: see attached release notes (Rev 1).

For full/additional device support:

Download the Kinetis SDK v1.2 from Software Development Kit for Kinetis MCUs|Freescale
Install the Kinetis SDK
Add Kinetis SDK v1.2 to KDS: Use the menu Help > Install New Software and use C:\Freescale\KSDK_1.2.0\tools\eclipse_update\KSDK_1.2.0_Eclipse_Update (KSDK path on windows)

See https://community.freescale.com/docs/DOC-103698 for additional details, especially about porting KDS v2.0.0 projects to the GNU ARM Embedded (launchpad) tools.

Screenshots of new features

Mac OS X support:

New Workspace Welcome view:

Kinetis SDK selection in New Project Wizard:

Ability to generate Processor Expert (Microcontroller Driver Suite) external projects for IAR and Keil:

Eclipse Luna 4.4, e.g. Split Editor Views:

Processor Expert V3.0 and multiple component repositories:

Upgrade assistant to migrate projects from KDS V1.x/V2.0.0 to V3.0.0:

Multiple tool chain configurations:

Peripheral Register Viewer:

JTAG Daisy Chaining:

Advanced Flash Programming Options:

Attach to running target:

And finally, for the 'lovers of the dark side' Eclipse Luna 'Dark' style:

Enjoy

Tags: kds_ide, kds-v3.0.0, kds

To Build MQX RTOS libraries required for MQX project execution using FRDM-K64F Board

bheemarao — Fri, 08 Oct 2021 08:27:11 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 8:27:11 AM

This section describes the steps required to configure KDS to build, run, and debug MQX™ RTOS demo applications and necessary driver libraries provided in the KSDK framework.

There are 3 libraries required to build for any new MQX project creation and execution:

Platform Library for MQX, MQX Library, MQX Standard Library.

Before building and debugging any demo applications, all libraries must be built.

To build the library for a device, follow these instructions:

1) Platform Library for MQX, ‘libksdk_platform_mqx.a’

We need to build a MQX platform library before we proceed.

Right click on project explorer and select import as shown below:

Select existing project into workspace as shown below

Next browse to the installed KSDK folder as shown below:

The folder path in my case is “C:\Freescale\KSDK_1.1.0\lib\ksdk_mqx_lib\kds\K64F12”

Proceed further by clicking finish

Now select the project from project explorer and build the library as shown below:

You can see the project build progress as shown below:

You can see the generated library file “libksdk_platform_mqx.a” under console window as shown below:

The path it is generated is “C:\Freescale\KSDK_1.1.0\lib\ksdk_mqx_lib\kds\K64F12\Debug”

Note: remember this path which has to be provided for any new MQX project creation.

2) MQX Library, ‘lib_mqx.a’

Follow the similar steps as above the path while importing for lib_mqx is

“C:\Freescale\KSDK_1.1.0\rtos\mqx\mqx\build\kds\mqx_frdmk64f”

Build the project “mqx_frdmk64f”

The library generated file is “lib_mqx.a” which is stored in path

“C:\Freescale\KSDK_1.1.0\rtos\mqx\lib\frdmk64f.kds\debug\mqx”

3) MQX Standard Library, ‘lib_mqx_stdlib.a’

Similarly import “mqx_stdlib_frdmk64f” project from the folder

“C:\Freescale\KSDK_1.1.0\rtos\mqx\mqx_stdlib\build\kds\mqx_stdlib_frdmk64f”

And build it as shown below:

you will find the generated library “lib_mqx_stdlib.a” stored at location

"C:\Freescale\KSDK_1.1.0\rtos\mqx\lib\frdmk64f.kds\debug\mqx_stdlib"

Note: remember these paths to be included at the time of any new MQX project building and execution.

NOTE: For information about building KSDK and MQX libraries in KDS please see chapter ‘3 Building the MQX RTOS libraries’ of ‘Getting Started with Freescale MQX™ RTOS for Kinetis SDK and Kinetis Design Studio IDE’ located in MQX for KSDK installation path C:\Freescale\KSDK_1.1.0\rtos\mqx\doc\tools

Tags: mqx, rtos, frdm-k64f, libraries

Eclipse Update for Freescale Kinetis SDK 1.0.0-GA

bheemarao — Fri, 08 Oct 2021 07:54:07 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:54:07 AM

This document will show how to install New Eclipse Update required to work on recent SDK 1.0.0-GA.

Without the update, KDS cannot generate KSDK-compatible projects.

To use the Kinetis SDK with Eclipse and Processor Expert, this updated needs to be installed into Eclipse (e.g. Kinetis Design Studio or Processor Expert Driver Suite). Otherwise both 'New Project Wizard' and Processor Expert will not know about the devices present and supported in the Kinetis SDK.

With the installation of this update, the 'New Project Wizard' will be enabled to use the Kinetis SDK for the devices supported, and Processor Expert components for the Kinetis SDK are added.

To install the update, follow these instructions:

In a KDS project window Select Help > Install New Software.

In the “Install New Software” dialog box, select the “Add…” button in the upper right corner.

Select “Archive…” In the “Add Repository” dialog as shown below.

Or optionally you can download the KSDK update from here Freescale Kinetis SDK_1.0.0 - Windows installer and provide the local path in “Add Repository” window.

In the dialog box that appears, browse the KSDK install directory. From the top-level, enter the tools/eclipse_update folder and select the SDK_1.0.0-GA_Update_for_Eclipse.zip file as shown below.

Click on “Open”, and then “OK” in the “Add Repository” dialog box. The KSDK update now shows up as “Processor Expert Software” >“Eclipse Update for KSDK 1.0.0-GA” as shown below.

Check the box to the left of the KSDK Eclipse update and click “Next” in the lower right corner. Follow the remaining instructions to finish the installation of the update.

Once the update is applied, restart KDS for the changes to take effect.

After installation you can see the contents as below

Click on Help> About Kinetis Design Studio

And click on installation details as shown below:

You can see all the updates installed check Eclipse Update for KSDK 1.0.0-GA is installed as shown

Tags: k64, freedom-board, kinetis, frdm-k64f, kds, led-toggling

[FRDM-K64F - PE - Eclipse] Project: Create a Data Logger

bheemarao — Fri, 08 Oct 2021 07:52:30 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:52:30 AM

“This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.”

The Freescale FRDM-K64F is a great board for data logger applications: it has a powerful ARM Cortex M4F with 120 MHz, 1 MB Flash and 256 KByte RAM. Best of all: it already has a micro SD card socket on the board

Data Logger with FRDM-K64F

Outline

In “Arduino Data-Logger Shield with the FRDM-KL25Z Board” I already used the FRDM-KL25Z with the Arduino Data-Logger shield with CodeWarrior. Basically the same can be applied to the FRDM-K64F. I moved to Eclipse Kepler (see “Constructing a Classroom IDE with Eclipse for ARM“), so here is an updated tutorial: how to create a data logger application with the FRDM-K64F and Eclipse Kepler.

You need:

Eclipse Kepler with Processor Expert as outlined in “Constructing a Classroom IDE with Eclipse for ARM“
Freescale FRDM-K64F board with USB cable
A micro SD card

: This tutorial can be used with CodeWarrior for MCU10.x, Processor Expert Driver Suite or Kinetis Design Studio too. The principle is the same, but the project creation steps will be somewhat different.

Make sure you have loaded the latest Processor Expert components from GitHub (see “Processor Expert Component *.PEupd Files on GitHub“).The project created in this tutorial is available on GitHub:https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/Eclipse/FRDM-K64F/FRDM-K64F120M/FRDM-K64F_DataLogger.In principle, this tutorial can be applied to any other board: Just make sure you select the microcontroller on your board, and adopt the pin settings for the devices you have.While it would make sense to use an RTOS like FreeRTOS for a data logger, I’m showing here a ‘bare metal’ data logger. An RTOS with tasks then can be easily added to the project.

Creating the Project

: The steps below are for standard DIY Eclipse Kepler IDE and GNU ARM Eclipse. If you are using Kinetis Design Studio (KDS), then use the File > New > Kinetis Design Studio menu. If using CodeWarrior for MCU10.6, then use the File > New > Bareboard project. Note that the wizard pages are different. Create a Processor Expert project for the MK64FN1M0xxx12.

Use the menu File > New > C Project to create a new

New Project

Provide a name for the Cross ARM GCC Freescale Processor Expert C/C++ Project:

DataLogger Cross ARM GCC Project for Processor Expert

Then select the M4 core with the PEx Driver Suite 10.4 Wizard invocation:

M4 core for PEx DriverSuite 10.4

In the next dialog I usually deselect the ‘Release’ configuration:

: In the Embedded World typically there is no such thing like ‘Release’ or ‘Debug’: it is always ‘Debug’, see “Debug vs. Release?“

Debug only

In the next dialog I have the opportunity to configure the tool chain.

: I’m using the ${gcc_path} Eclipse variable to point to my GNU ARM Embedded tool chain (see “Constructing a Classroom IDE with Eclipse for ARM“)

Cross GNU ARM Toolchain

Press ‘Finish’, and the project wizard calls the Processor Expert wizard to configure the microcontroller. Select the MK64FN1M0xxx12 which is present on the FRDM-K64F board:

MK64FN1M0xxx12

In the next dialog I use ‘Linked’: this means that the project uses links to the Processor Expert library files. Alternatively you can use ‘Standalone’, then the files get copied into the project.

Linked Mode

Then I select the GNU C Compiler:

GNU C Compiler

With ‘Finish’ the project gets created. Processor Expert opens a help window explaining how to convert a project for Processor Expert. We can ignore this as the wizard already has done everything for us

DataLogger Project

: I’m using Processor Expert views in the next step. If this is your first Processor Expert project, make sure select the menu Processor Expert > Show Views to open the needed views.

Project Cleanup and Adjustments

While the project created is fine, I usually do some cleanup. First I remove the ‘RAM’ configuration with the context menu, as I’m only going to use the FLASH target:

Deleting Configuration

Same for the obsolete CPU (orphaned now as it was tight to the RAM configuration

Removing RAM Configuration CPU

The MK64FN1M0VLQ12 derivative is a LQFP 144-pin package, but the FRDM-K64F board is using a LQFP 100-pin package. In the component inspector, I change it to the 100-pin package:

: Right click on CPU, select Inspector menu item to open the ‘Component Inspector’ view if not already open.

Changing CPU package

The PinSettings component can be removed, as we will care ourselves about the pin settings in the components:

PinSettings Component

Now the project is clean and using the 100-pin VLL12 package:

100-pin VLL12 package

Generating Code

The project is still ‘empty’, but at this stage I prefer to verify that I can generate code, build it and download it to the target. To generate the Processor Expert code I use the toolbar icon:

Generate Processor Expert Code

Building Project

To build the project I select the project and use the ‘Hammer’ drop down icon:

Building Project

It should build with no errors:

Console View with no Errors

Debugging

I’m using here the Segger OpenSDAv2 debug firmware on the FRDM-K64F board. I select the project and open the Debug Configurations:

Menu Debug Configurations

The double-click on the GDB Segger J-Link Debugging item to create a new configuration: The .elf and project name should be filled automatically:

New Segger Launch Configuration

In the Debugger tab I make sure the proper device name (MK64FN1M0xxx12) and interface (SWD) is selected:

Device name and interface for Segger

In the Startup tab I make sure semihosting and SWO are disabled:

Segger Semihosting and SWO disabled

Pressing Apply (if any changes), then press Debug to launch the debugger, and I should be debugging:

Initial Debug Session

So with this I know that everything works from building to debugging. Time to terminate the debugging session:

Terminating the debug session

And to return to the C/C++ perspective:

Return to C and C++ Perspective

FatFS File System

To use the SD card with the FAT file system, I add the FatFS component to the project:As to write files to the file system I need date/time information, it asks me to add a clock component. I select the GenericTimeDate component:

Adding GenericTimeDate Component

Next, FatFS needs a memory component, and here I select the SD_Card component:

Adding Memory Component for FatFS

To protect the critical sections, it asks me to select the component I want to use. It already should have added a Critical Section (CS1) component, so I go with the CS1 choice:

Linking to CS1 component

With this, I have new components added to my project. Some with a red X indicate that some settings are missing:

FatFS Components added

I need to configure the pins for the SPI which talks to the SD card. For this I open the Component inspector for the SPI component:

Need to configure the SPI

As the SD card on the board is connected to SPI1, I choose SPI1 as device with

MISO/Input pin: PTE1
MOSI/Output pin: PTE3
SCLK/Clock pin: PTE2
and no chip select list (use the ‘-’ button to remove it)

MISO, MOSI, Clock and chip select

The chip select list is not needed as the FatFs component will handle the chip select on its own. Scrolling down I need to configure the clock details. For this I clock on the ‘…’:

Configuring the clock

From the available timings, I double-click from the list on the right hand side to have a value assigned:

Selecting timing value

Then press OK, and do the same for the three delay timing needed:

Delay timing assigned

For the clock rate we not only need one timing, but three: initial/low and high-speed. Again clicking on the ‘…’ for the Clock rate to open the dialog.I want to assign values in kHz, so I select that from the Unit drop down list (click into the Value field to have it updated):

Clocks in kHz

As I need two values, I configure it as ‘List of values’:

List of Values

Then I assign for the low value a maximum value of 375 kHz, and for high I can go up to 12 MHz (my clock configuration only allows 10 MHz max

SPI Clock Values

Pressing OK to close the SPI clock configuration. To use the two configurations, I need to add a second attribute set. Because the ‘Tabs View’ uses a lot of screen real estate, it is easier if I switch to the ‘classic’ non-tabs view (small triangle in view toolbar to reach the menu

Disabling Tabs View

Next step is to enable the automatic initialization of the SPI component:

Automatic initialization of the SPI component

I click into the Attribute set list box (where the ’1′ is) and click on the ‘+’:

Adding New Attribute Set

Then specify that the SPI clock index 1 shall be used:

Clock Rate Index for Attribute Set 1

In the SD_Card Component, I need to specify that it can use the index 1 (10 MHz) for fast mode:

Fast Baud Rate Mode

I order to be able to switch different clock configurations, I need to enable the method SelectConfiguration():Next I need to assign the chip select pin. This is inside the SD_Card component:

Need to configure SPI Chip Select

The chip select is on PTE4. I can click into the field and type in the name (or to select from the list) to assign it:

Assigning PTE4 as Chip Select

Next we add the card detection (CD) pin: I select the SD_Card component and enable the pin:

Enable Card Detection Pin

On the FRDM-K64F, the card detection is HIGH active, so I need to deselect the ‘Card Detect is LOW active’:

Card Detect Low or High Active

Realtime Clock

For the SD card I need a realtime clock. Our board does not have this, but I have configured a software realtime clock: GenericTimeDate. As in this tutorial I’m not going to use an RTOS, I add a TimerInt component to the project and configure it for 10 ms:

TimerInt component

I need to call the AddTick() method of the realtime clock every 10 ms from above interrupt:

Realtime Clock AddTick() Method

So I generate code:

Generate Code

Then I double-click on the OnInterrupt() event to open the Events.c source file with that event created:

Timer OnInterrupt()

Then I can drag&drop the AddTick() method to the source:

Drag and Drop AddTick() Method

Then save the source changes:

Save Source Changes

The data to log: Accelerometer

With the FatFS I have everything to read and write the SD card. Only the data is missing. In this tutorial I’m using the accelerometer of the FRDM-K64F. So I’m adding the FXOS8700CQ component to the project.It will ask for the Wait component (which already is part of the project) and automatically adds the GenericI2C component to it. I enable the LDD I2C and add a new I2C_LDD component:

Adding I2C_LDD with FXOS8700CQ

The I2C_LDD component gets configured for I2C0, SDA (PTE25) and SCL (PTE24), with a clock configuration below 100 kHz:

Accelerometer I2C Configuration

Important and not to forget: according to the schematics, the SA1 is LOW and SA0 pin is HIGH, so the device has the address 0x1D:

Accelerometer Slave Address

With this, the hardware configuration is completed, and I can write the application code .

Application Code

I add a header file Application.h (context menu with File > New > Header File) and source file Application.c (context menu File > New Source File) to the Sources folder:

Application Files

The header file needs only one function:

/*

* Application.h

*/

#ifndef APPLICATION_H_

#define APPLICATION_H_

void APP_Run(void);

#endif /* APPLICATION_H_ */

In main.c, I include that header file and call APP_Run:

Main.c calling application

APP_Run() implements my logger loop: initialize the accelerometer and mount the file system. Then it gets the accelerometer data and logs it to a file every second.First, I need to make sure I have a pull-down enabled for the SD card detection pin (PTE6). Because the BitIO component has no methods to change the electrical characteristics, I’m using PDD macros (see “Low-Level Coding with PDD (Physical Device Driver)”)

/* SD card detection: PTE6 with pull-down! */

PORT_PDD_SetPinPullSelect(PORTE_BASE_PTR, 6, PORT_PDD_PULL_DOWN);

PORT_PDD_SetPinPullEnable(PORTE_BASE_PTR, 6, PORT_PDD_PULL_ENABLE);

For the file system I need to have a file system object and a file pointer. To keep things simple, I’m using global variables:

static FAT1_FATFS fileSystemObject;

static FIL fp;

The APP_Run() is implemented as below:

void APP_Run(void) {
  int16_t x,y,z;
  uint8_t res;

  /* SD card detection: PTE6 with pull-down! */
  PORT_PDD_SetPinPullSelect(PORTE_BASE_PTR, 6, PORT_PDD_PULL_DOWN);
  PORT_PDD_SetPinPullEnable(PORTE_BASE_PTR, 6, PORT_PDD_PULL_ENABLE);

  res = FX1_Enable(); /* enable accelerometer (just in case) */
  if (res!=ERR_OK) {
    Err();
  }
  if (FAT1_Init()!=ERR_OK) { /* initialize FAT driver */
    Err();
  }
  if (FAT1_mount(0, &fileSystemObject) != FR_OK) { /* mount file system */
    Err();
  }
  for(;;) {
    /* get accelerometer values */
    x = FX1_GetX();
    y = FX1_GetY();
    z = FX1_GetZ();
    /* log it to the file on the SD card */
    LogToFile(x, y, z);
    /* do this every second */
    WAIT1_Waitms(1000);
  }
}

The Err() function is used to indicate an error condition. I can show an error with LED’s or I simply stop application there:

static void Err(void) {
  for(;;){}
}

I want to append the accelerometer data to a file, with date/time information, separated with TABs so I can easily import it into Excel. To construct the strings, I’m going to use the Utility component, so I have added it to my project:

Utility Component

With this, I write my data to the SD card in LogToFile():

Open the log file (FAT1_open()) with FA_OPEN_ALWAYS (open the file if it already exists, otherwise create the file) and for writing (FA_WRITE).
Move the file pointer to the end of the file to append the data (FAT1_lseek()).
Get the current time information from the software realtime clock (TmDt1_GetTime()).
Construct in a buffer the string to write with time and accelerometer data.
Write it to the file with FAT1_write().
Close the file with FAT1_close().

static void LogToFile(int16_t x, int16_t y, int16_t z) {
  uint8_t write_buf[48];
  UINT bw;
  TIMEREC time;

  /* open file */
  if (FAT1_open(&fp, "./log.txt", FA_OPEN_ALWAYS|FA_WRITE)!=FR_OK) {
    Err();
  }
  /* move to the end of the file */
  if (FAT1_lseek(&fp, fp.fsize) != FR_OK || fp.fptr != fp.fsize) {
    Err();
  }
  /* get time */
  if (TmDt1_GetTime(&time)!=ERR_OK) {
    Err();
  }
  /* write data */
  write_buf[0] = '\0';
  UTIL1_strcatNum8u(write_buf, sizeof(write_buf), time.Hour);
  UTIL1_chcat(write_buf, sizeof(write_buf), ':');
  UTIL1_strcatNum8u(write_buf, sizeof(write_buf), time.Min);
  UTIL1_chcat(write_buf, sizeof(write_buf), ':');
  UTIL1_strcatNum8u(write_buf, sizeof(write_buf), time.Sec);
  UTIL1_chcat(write_buf, sizeof(write_buf), '\t');

  UTIL1_strcatNum16s(write_buf, sizeof(write_buf), x);
  UTIL1_chcat(write_buf, sizeof(write_buf), '\t');
  UTIL1_strcatNum16s(write_buf, sizeof(write_buf), y);
  UTIL1_chcat(write_buf, sizeof(write_buf), '\t');
  UTIL1_strcatNum16s(write_buf, sizeof(write_buf), z);
  UTIL1_strcat(write_buf, sizeof(write_buf), (unsigned char*)"\r\n");
  if (FAT1_write(&fp, write_buf, UTIL1_strlen((char*)write_buf), &bw)!=FR_OK) {
    (void)FAT1_close(&fp);
    Err();
  }
  /* closing file */
  (void)FAT1_close(&fp);
}

All what is missing now is the include of the needed header files at the beginning of Application.c:

#include "Application.h"
#include "WAIT1.h"
#include "FX1.h"
#include "FAT1.h"
#include "UTIL1.h"
#include "PORT_PDD.h"

Result

Time to generate code, build and then debug. And it writes file log.txt to the card I can import into Excel:

Data imported in Excel

And visualized in a chart:

Visualized Data

Summary

Writing a data logger is not that difficult with Processor Expert components. As there are many complex components (file system, SPI, I2C, accelerometer) and drivers involved, it takes some time to set everything up. But once understood, it is very easy to have such a data logger implemented easily for any other hardware.

The tutorial project (with minor extensions) is available on GitHub as reference implementation:https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/Eclipse/FRDM-K64F/FRDM-K64F_DataLogger

Happy Logging

Tags: freedom-board, freescale, kinetis, frdm-k64f

Basics of Bootloader

bheemarao — Fri, 08 Oct 2021 07:51:25 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:51:25 AM

What is a bootloader?

A bootloader is a program which is able to load another program (the application program). Typically, the bootloader program is not changed, and is kept in the microcontroller. That way the bootloader loads different program again and again.

The following figure-1 shows a typical diagram of a serial bootloader:

Figure 1: Serial Bootloader

Note: Depending on the architecture, there can be a mini or micro bootloader that can load the real bootloader. For example, the OpenSDA bootloader on the Freedom boards have this capability.

The Bootloader Code and the Bootloader Vectors are programmed into a new part (for example, with a debugger) or, a standalone flash programmer (for example, with USBDM). Then the bootloader can be used to load or change the Application Code and Application Vectors. With this, the bootloader remains the same, while the application can be updated.

What is Bootloader Sequence?

A typical bootloader has the following sequence:

At the startup the bootloader either enters in a bootloader mode or in the application running mode. Typically, this is decided with a button or jumper set (or removed). If the bootloader starts in application running mode, it calls the required application and the system starts automatically.
Otherwise, the bootloader reprograms the application with a new file. The S19 (S-Record) files are often used for this, as they are easy to parse and every tool chain can produce them.
The bootloader needs to use a communication channel to read that file. That can be RS-232, USB or an SD card file system (e.g. FatFS).
Using that file, the bootloader programs the flash memory. Special consideration has to be taken into account for the application vector table. When the bootloader runs out of reset, it uses its own (default) vector table, and needs to relocate the vector table if running the application.

Tip: It is possible to use the reset button on the FRDM-KL25Z board as a user. To keep things simple, you may use a dedicated bootloader push button on PTB8.

The following figure-2 shows the Bootloader System Block Diagram:

Figure-2: Bootloader System Block Diagram

The components of the Bootloader System Block Diagram are as follows:

Communication Channel
File Reader
Flash Programming
Vector Redirection
User Interface

Tags: freescale, kinetis, freedom

[FRDM-K64F - SDK] Introduction

bheemarao — Fri, 08 Oct 2021 07:50:45 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:50:45 AM

This Document was extracted from Anthony Huereca blog published at Freescale Community Forum https://community.freescale.com/docs/DOC-100718 with his agreement.

Kinetis SDK is a new complimentary software offering from Freescale for Kinetis microcontrollers. The Kinetis software development kit (SDK) provides an extensive suite of robust peripheral drivers, stacks, middleware and example applications designed to simplify and accelerate application development on any Kinetis MCU. The addition of Processor Expert technology for software and board support configuration provides unmatched ease of use and flexibility. The Kinetis SDK includes full source code under a permissive open-source license for all hardware abstraction and peripheral driver software.

Kinetis SDK is currently in beta, and can be used with FRDM-K64F or TWR-K64F120M. More boards will be supported in future releases. Note that because the SDK is in beta, certain features and API naming conventions may change before the General Availability (GA) release scheduled for summer 2014.

This document goes over the basics of starting with Kinetis SDK and common troubleshooting tips.

Getting Started with Kinetis SDK and FRDM-K64F

The FRDM-K64F is a new fully featured Freescale Freedom board with a 120MHz Cortex M4 based Kinetis K64 MCU. The board also features Arduino hardware compatibility, an accelerometer and magnetometer (Freescale’s FXOS8700CQ), and push buttons/LEDs, plus an Ethernet port, microSD port, and OpenSDAv2 for debugging.

Also note that only IAR and GCC are supported currently by the beta version of the SDK, though more IDEs will be supported in later releases. For now we’ll use the IAR compiler.

First download and unzip the beta release (FSLKSDK_1_0_0_BETA) of the Kinetis SDK software from http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_SDK

Take a look at the documentation in the /doc folder, in particular the Release Notes and the K64 User Guide. The Release Notes has an important note about a possible issue when debugging in IAR so be sure to read the last section.

Also note the basic Kinetis SDK directory structure. More details can be found in the Release Notes:

apps – SDK examples and demos
boards –board specific files
lib – where the compiled SDK libraries reside
platform – SDK driver and HAL source code, linker files, and startup code

Since all the examples are in the apps folder, check out the “hello_world” project at \KSDK_1.0.0-Beta\apps\hello_world\iar\frdmk64f120m\hello_world.eww of it for a simple hello world type app.Use Section 4.1.1 of the K64 User Guide for instructions on how to build the application. The platform_lib.a SDK library which provides the drivers and HAL layer is already pre-compiled.

Debugging Kinetis SDK on FRDM-K64F:

Typically, debugging is done via the OpenSDAv2 circuit built onto the FRDM-K64F board. Make sure to use the USB connector to the left of the Ethernet port, J26. By default the FRDM-K64F uses the CMSIS-DAP/mbed interface as the debug protocol. However it is also possible to use the P&E Micro debug interface on the board instead. As mentioned before, there is a potential issue with debugging with IAR if a project is allowed to exit out of main(). This may cause issues when connecting via the debugger again when using the CMSIS-DAP/mbed interface. Because of this, there is a P&E Micro app available for OpenSDAv2 that comes with the Kinetis SDK zip file that can be loaded onto the OpenSDAv2 circuit on the board. The CMSIS-DAP/mbed interface app is being updated to fix this issue. When debugging, you may get a warning about missing source files. You can ignore those as they are caused by using the pre-compiled SDK platform library. Look down below in the Troubleshooting section for how to get rid of these messages.

Debugging with CMSIS-DAP/mbed Interface:

The FRDM-K64F board uses the CMSIS-DAP/mbed interface by default as it is using OpenSDAv2. However the IAR projects in the beta version of Kinetis SDK use the P&E Micro debug interface. This will be changed for later version of the Kinetis SDK, but to use the default OpenSDAv2 debug interface, you’ll need to change the project’s debug interface to CMSIS-DAP. Instructions for this are in Appendix B of the K64 User Guide.

Debugging with P&E Micro Interface:

To debug using the P&E Micro interface, the P&E Micro OpenSDAv2 app needs to be loaded onto the OpenSDAv2 circuit. Instructions for loading and using this app are inSection 4.1.2 in the K64 User Guide. Use the DEBUG_K64F_MBED_PEMICRO_V108.BIN file that came inside the Kinetis SDK zip file.If you want to return to the original CMSIS-DAP/mbed interface, you can find a binary app to drag-and-drop onto the OpenSDAv2 bootloader on the FRDM-K64F mbed page.Firmware FRDM K64F - Handbook | mbed

Troubleshooting:

I’m using the CMSIS-DAP/mbed debug interface with IAR, and I can’t connect to my board anymore with an error: “Fatal error: Probe not found. Session aborted!”:There’s an issue as described in the Kinets SDK release notes where the debugger can become non-responsive if the code is allowed to exit the main() function when using the CMSIS-DAP interface with OpenSDAv2. To recover the board you have a few options:

Load the P&E Micro interface app onto OpenSDAv2, and then flash a known good program
The board should still enumerate as a mass storage device, and you can drag-and-drop a known good program onto the board. You may have to hit the reset button a few times to get it to properly enumerate though. A known good hello_world program has been attached to this post.

This will be fixed in future versions of the CMSIS-DAP/mbed interface app. In the meantime, make sure to put a while(1) loop in your code before exiting main(). Also check out the blog entry on this issue on MCU on Eclipse

When I start debugging, I get a warning message that it “Could not find the following source file: D:\mcu-sdk-re\rc3_2_release\Kinetis_SDK\platform\hal\pit\fsl_pit_hal.h”:

This is caused by using the pre-compiled SDK library, which was built on a different directory structure than what is on your particular computer.

To fix, recompile the Kinetis SDK platform library by following the directions in Appendix A of the Kinetis SDK K64 Users Guide.pdf

The serial port is not enumerating:

If using the default CMSIS-DAP/mbed interface, you must first install the mbed Windows serial port driver before it will enumerate on Windows properly. It should work in Mac OS and Linux without a driver.

When I start debugging, I get an error message that says “Undected. Disconnect/Connect USB cable. Click Refresh List”:

The likely problem is that the FRDM-K64F has the default CMSIS-DAP/mbed firmware, and the IAR project is trying to use the P&E Micro interface. Use the instructions inAppendix B of the K64 User Guide to change the debug interface in IAR to use CMSIS-DAP. Or else change the firmware in the OpenSDAv2 circuit to the P&E Micro firmware.

When compiling the Kinetis SDK platform library in IAR 7.10.x, I the following error messages: Error[Pm056]: all if, else if constructs should contain a final else clause (MISRA C 2004 rule 14.10):

This is caused by a MISRA C 2004 rule violation. The beta Kinetis SDK was built using IAR 6.70, but the MISRA C checks were changed when IAR moved to 7.10.x which is why this comes up in IAR 7.10.x.

This error can be fixed by disabling MISRA C checking in the project settings.

Right click on the platform_lib project, and under the General Options category, scroll over (using the arrow keys on the right) to the MISRA-C-2004 tab, and uncheck “Enable MISRA-C”.

When debugging with the P&E Micro OpenSDAv2 app, I get an error that says “Error reading data from OpenSDA hardware. E17925”

This is being investigated and seems to affect IAR 7.10.x and CW10, but not earlier versions of IAR. In the meantime, use the CMSIS-DAP/mbed interface app instead.

Attachments:

community.element14.com/.../hello_5F00_world.bin.zip

Tags: kinetis;

[OpenSDAv2] Tutorial: Set-up the right debug interface for your IDE toolchain

bheemarao — Fri, 08 Oct 2021 07:50:44 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:50:44 AM

This Document was extracted from Anthony Huereca blog published at Freescale Community Forum https://community.freescale.com/docs/DOC-100720 with his agreement.

OpenSDA/OpenSDAv2 is a serial and debug adapter that is built into several Freescale evaluation boards. It provides a bridge between your computer (or other USB host) and the embedded target processor, which can be used for debugging, flash programming, and serial communication, all over a simple USB cable.

The OpenSDA hardware consists of a circuit featuring a Freescale Kinetis K20 microcontroller (MCU) with an integrated USB controller. On the software side, it implements a mass storage device, bootloader which offers a quick and easy way to load OpenSDA applications such as flash programmers, run-control debug interfaces, serial to USB converters, and more. Details on OpenSDA can be found in the OpenSDA User Guide.

The bootloader and app firmware that lay on top of the original OpenSDA circuit was proprietary. But recently ARM decided to open source their CMSIS-DAP interface, and now a truly open debug platform could be created. This new open-sourced firmware solution is known as OpenSDAv2.

OpenSDAv2:

OpenSDAv2 uses the exact same hardware circuit as the original OpenSDA solution, and out of the box it still provides a debugger, drag-and-drop flash programmer, and virtual serial port over a single USB cable.

The difference is the firmware implementation:

OpenSDA: Programmed with the proprietary P&E Micro developed bootloader. P&E Micro is the default debug interface app.
OpenSDAv2: Programmed with the open-sourced CMSIS-DAP/mbed bootloader. CMSIS-DAP is the default debug interface app.

	Firmware Developer	Kinetis K20 Based Hardware Circuit	Default Debug Interface	Drag-and-drop Target MCUFlash Programming	Virtual Serial Port	Source Code Available
OpenSDA	P&E Micro	x	P&E Micro	.srec/.s19	x
OpenSDAv2	ARM/mbed.org	x	CMSIS-DAP	.bin	x	x

The bootloader and app firmware used by OpenSDAv2 is developed by the community at mbed.org, and is known as “CMSIS-DAP Interface Firmware”. If you explore that site, you will find that this firmware was also ported to run on other hardware, but the combination of this mbed.org firmware with the Kinetis K20 MCU is known as OpenSDAv2.

It is important to understand however that it is possible to run a P&E Micro debug app on the CMSIS-DAP/mbed bootloader found on OpenSDAv2. Likewise it is possible to run a CMSIS-DAP debug app on the P&E Micro bootloader found on OpenSDA. The debug application used needs to be targeted towards a specific bootloader though, as a single binary cannot be used on both the OpenSDA and OpenSDAv2 bootloaders.

OpenSDAv2 Apps:

mbed CMSIS-DAP (default app)
P&E Micro (found in Kinetis SDK beta release)
Segger JLink

OpenSDAv2 Bootloader:

The key difference between OpenSDA and OpenSDAv2 is the bootloader.

Boards with OpenSDA use a proprietary bootloader developed by P&E Micro, and it cannot be erased or reprogrammed by an external debugger due to the security restrictions in the firmware.
Boards with OpenSDAv2 use the open-source bootloader developed by mbed.org, and it can be erased and reprogrammed with an external debugger.

Apps need to be specifically tweaked to work with either the P&E bootloader (Original OpenSDA) or the CMSIS-DAP/mbed bootloader (OpenSDAv2) as the bootloader memory map is different. Thus it’s important to know which type of bootloader is on your board to determine which version of an app to load.

You can determine this by holding reset while plugging in the USB cable. A BOOTLOADER drive will appear for both OpenSDA and OpenSDAv2 as shown below.

The OpenSDAv2 bootloader (may also be called the CMSIS-DAP/mbed bootloader) developed by mbed.org will have the following files inside. Double clicking on bootload.htm will take you to the

mbed.org website.

The OpenSDA bootloader developed by P&E Micro will have the following inside. Clicking on SDA_INFO.HTM will take you to the P&E website.

Using CMSIS-DAP:

When you connect a Freedom board that has OpenSDAv2 (such as the FRDM-K64F) to your computer with a USB cable, it will begin running the default CMSIS_DAP/mbed application.

You will see a new disk drive appear labeled “MBED”.

You can then drag-and-drop binary (.bin) files onto the virtual hard disk to program the internal flash of the target MCU.

OpenSDAv2 will also enumerate as a virtual serial port, which you can use a terminal program. such as TeraTerm (shown below), to connect to. You may need to install the mbed Windows serial port driver first before the serial port will enumerate on Windows properly. It should work without a driver for MacOS and Linux.

The CMSIS-DAP app also allows you to debug the target MCU via the CMSIS-DAP interface. Select the CMSIS-DAP interface in your IDE of choice (IAR, Keil), and inside the CMSIS-DAP options select the Single Wire Debug (SWD) option as shown below :

IAR:

Keil:

Resources

CMSIS-DAP Interface Firmwarembed.org FRDM-K64 Page

FRDM-K64 User GuideOpenSDAv2 on MCU on Eclipse blog

OpenSDA User Guide

Appendix A: Building the CMSIS-DAP Debug Application

The open source CMSIS-DAP Interface Firmware app is the default app used on boards with OpenSDAv2. It provides:

Debugging via the CMSIS-DAP interface
Drag-and-drop flash programming
Virtual Serial Port providing USB-to-Serial convertor

While binaries of this app are provided for supported boards, some developers would like to build the CMSIS-DAP debug application themselves.

This debug application can be built for either the OpenSDAv2/mbed bootloader, or for the original OpenSDA bootloader developed by P&E Micro. If you are not sure which bootloader your board has, refer to the bootloader section in this document.

Building the CMSIS-DAP debug application requires Keil MDK. You will also need to have the “Legacy Support for Cortex-M Devices” software pack installed for Keil.

You will also need Python 2.x installed. Due to the python script used, Python 3.x will not work.

You can download and get the CMSIS-DAP source code from https://github.com/mbedmicro/CMSIS-DAP using the Download ZIP link.

The source can also be downloaded via git:

“git clone https://github.com/mbedmicro/CMSIS-DAP.git”

The source code can be seen as shown below:

This repository contains the files for both the bootloader and the CMSIS-DAP debug interface application. We will concentrate on the interface application at the moment.

Open up Keil MDK, and open up the project file located at \CMSIS-DAP\interface\mdk\k20dx128\k20dx128_interface.uvproj

In the project configuration drop-down box, you will notice there are a lot of options. Since different chips may have slightly different flash programming algorithms, there is a target for each specific evaluation board. In this case, we will be building for the FRDM-K64F board. Scroll down until you get to that selection:

Notice there are three options for the K64:

k20dx128_k64f_if: Used for debugging the CMSIS-DAP application with Keil. Code starts at address 0x0000_0000
k20dx128_k64_if_openSDA_bootloader: Creates a binary to drag-and-drop on the P&E developed bootloader (Original OpenSDA)
k20dx128_k64_if_mbed_bootloader: Creates a binary to drag-and-drop onto the CMSIS-DAP/mbed developed bootloader (OpenSDAv2)

Since the FRDM-K64F comes with the OpenSDAv2 bootloader, we will use the 3^rd option. If we were building the mbed app for another Freedom board which had the original OpenSDA bootloader,

we would choose the 2^nd option instead.

Now click on the compile icon. You may get some errors

If you get an error similar to the one shown below, make sure you have installed the Legacy pack for ARM as previously described earlier:

compiling RTX_Config.c... ..\..\Common\src\RTX_Config.c(184): error: #5: cannot open source input file "RTX_lib.c": No such file or directory

and

compiling usb_config.c...

..\..\..\shared\USBStack\INC\usb_lib.c(18): error: #5: cannot open source input file "..\..\RL\USB\INC\usb.h": No such file or directory

If you get an error regarding a missing version_git.h file, make sure that Python 2.x and git are in your path. A Python build script fetches that file.
If there is a warning about “invalid syntax” when running the Python script, make sure your using Python 2.x. Python 3.x will not work with the build script.

Now recompile again, and it should successfully compile. If you look now in \CMSIS-DAP\interface\mdk\k20dx128 you will see a new k20dx128_k64f_if_mbed.bin file

If you compiled the project for the OpenSDA bootloader, there would be a new k20dx128_k64f_if_openSDA.S19 file instead.

Loading the CMSIS-DAP Debug Application:

Now take the Freedom board, press and hold the reset button as you plug in the USB cable. Then, drag-and-drop the .bin file (for OpenSDAv2) or .S19 file (for OpenSDA) into the BOOTLOADER drive that enumerated.

Perform a power cycle, and you should see a drive called “MBED” come up and you can start using the CMSIS-DAP debug interface, as well as drag-and-drop programming and virtual serial port as described earlier in this document.

Appendix B: Building the CMSIS-DAP Bootloader

All Freedom boards already come with a bootloader pre-flashed onto the K20. But for those building their own boards that would like to use CMSIS-DAP, or those who would like to tinker with the bootloader, it possible to flash it to the Kinetis K20 device. Flashing the bootloader will require an external debugger, such as the Keil ULink programmer or Segger JLink.

Also note that the OpenSDA/PE Micro Bootloader cannot be erased! Due to the proprietary nature of the P&E firmware used by the original OpenSDA, it can only be programmed at the board manufacturer and JTAG is disabled. So these instructions are applicable for boards with OpenSDAv2 only.

First, open up the bootloader project which is located at \CMSIS-DAP\bootloader\mdk\k20dx128\k20dx128_bootloader.uvproj

There is only one target available because all OpenSDAv2 boards will use the same bootloader firmware as the hardware circuitry is the same.

Click on the compile icon and it should compile successfully. If you see errors about a missing version_git.h file, note that Python 2.x must be in the path to run a pre-build script which fetches that file.

Now connect a Keil ULink to J10 and then insert a USB cable to provide power to J26. Note that if you have the 20-pin connector, you’ll want to use the first 10 pins.

Then for Keil 5 you will need to change some debug options (CMSIS-DAP is built under Keil 4.x).

Right click on the bootloader project, and go to the Debug tab and next to ULINK Pro Cortex Debugger, click on Settings:

Then under “Cortex-M Target Driver Setup”, change the “Connect” drop down box to “under Reset” and “Reset” dropdown box to “HW RESET”. Hit OK to save the settings.

Then in Keil, click on Flash->Erase.

And then on Flash->Download.

If you get an “Invalid ROM Table” error when flashing the CMSIS-DAP bootloader, make sure you made the changes to the debugger settings listed above.

After some text scrolls by, you should see:

Now power cycle while holding down the reset button, and you should see the bootloader drive come up. You’ll then need to drag and drop the mbed application built earlier onto it. And that’s all there is to it!

The binaries for the bootloader and CMSIS-DAP debug app for the FRDM-K64F board created in writing this guide are attached.

Attachments:

community.element14.com/.../k20dx128_5F00_bootloader.axf.zip
community.element14.com/.../k20dx128_5F00_k64f_5F00_if_5F00_mbed.bin.zip

Interfacing Thermal Printer with Freedom board FRDM-KL25Z : Part 1

bheemarao — Fri, 08 Oct 2021 07:50:06 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:50:06 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

One of my embedded projects is to measure the running time in a sports event (see “Sports Timing System in a Lunch Box“). The recorded time is stored in an EEPROM plus sent over USB or wireless connection to the host. It would be great if I could print out the time and ranking directly, so if there is no PC, the system can be small and tiny. So here is my next project and tutorial: Printing with the Freedom board!

Hello World on the Printer with FRDM-KL25Z

The ability to print is a great addition to any other project: I can send messages to be printed out on a remote board, using it as a receipt printer, logging test results and many more things: having printing capabilities is such a great addition to any project, and it does not take much! I have spent this Sunday morning only 4 hours from unpacking, connecting the hardware, programming the first software with CodeWarrior+Processor Expert until I had a “Hello World from the FRDM-KL25Z!” showing up on the printer! And that 4 hours included writing this tutorial. So expect it would take you less than one hour with the help of this tutorial.

First Hello World Message on Printer

Adafruit Mini Thermal Receipt Printer

I ordered a small thermal printer from Adafruit (http://learn.adafruit.com/mini-thermal-receipt-printer) which costs $50. I added three thermal paper rolls (http://www.adafruit.com/products/599) to my order to have enough paper to start with :-):

Adafruit Mini Thermal Printer unpacked

The main features of the printer (from the data sheet):

Thermal paper printer, 2.25″/57mm wide (effective printing width 48 mm)
Built-in fonts: small, medium, large text
Bold, underline and inverted text with left/right/center positioning
Different bar codes
Printing monochrome bitmaps and images
Size: 111x65x57 mm
5-9V DC, 1.5 A
TTL Serial (RS-232, 5V) protocol

Useful links:

Printer data sheet:http://www.adafruit.com/datasheets/cashino%20thermal%20printer%20a2.pdf
Printer user manual: http://www.adafruit.com/datasheets/A2-user%20manual.pdf
Adafruit Thermal Printer Overview: http://learn.adafruit.com/mini-thermal-receipt-printer/overview

With the printer came a test print which has the baud listed. There are printers with 9600 baud and others with 19200, mine came with 19200. More about this later.

Printer Test Print with Baudrate

Mounting and Connectors

The two brackets are for mounting the printer behind a panel. In order not to lose the parts, I mounted them right away:

Adding Printer Mounting Brackets

The cables get connected to the backside of the printer:

Printer Backside Connectors

Power Supply

The printer requires a 5-9V power supply. Thermal printing needs a lot of power, so a 1.5 amps power supply is needed! There are many ways how you could give power to the printer. I usually have always a bunch of power supplies, but the challenges is that the plugs never match my needs. So usually I end up cutting the wires and making it fitting my needs. For this project I use a 5V 2A power supply I have left over from a damaged Cisco router:

5V 2A Power Supply

I cut the 5V wires:

Power Supply 5V Wires cut

Same for the printer supply wires:

:!: Cut the wires on the 2-pin connector (NOT on the 3-pin side)!

Cutting Printer Supply Wires

Then remove the isolation:

Removed Isolation

I’m using heat shrink tubes for isolation, but you can use electrical isolation tape too (not so nice as heat shrink tubes). I cut pieces of different diameter and size:

Shrink Tubes

Put them on the wire before soldering:

Shrink Tubes on Wires

Wrap the wires together:

:!: carefully check the wire polarity (what is plus, and what is ground)! In doubt, use a voltage meter to verify it!

Wires Wrapped together

Solder the wires:

Solder the Wires

Then use a hot air gun to shrink it:

Shrinking with Hot Air Gun

The result is a nice connection:

Shrinked Power Cable

Inserting Paper

When powered, the green LED flashes. There is a ‘Paper Feed’ button plus a lever to open the printer.

Printer button, LED and lever

A roll presses the paper on the printer head:

Paper Press Roll

The printer head is near the ‘cut off’ area:

Printer Head

The paper is placed inside the printer. Make sure the paper is clean and has no stickers/etc on it:

Paper inside the printer

Then close the cover:

Printer Cover Closed

Making a Test Print

Powering the printer with the ‘paper feed’ button pressed will print a test report:

Test Print with Baudrate

Now I’m sure my printer is working :-)

Printer Connection to the FRDM Board

There is problem: the printer uses 5V (TTL) logic levels, while my FRDM board has 3.3V levels. The printer accepts 3.3V input values (on the printer RX line), but it would be a bad idea to connect the printer output 5V TX signal to a microcontroller having 3.3V levels without a level shifter.

Printer Tx and Rx

As I’m only sending data to the printer, I’m *not* going to connect the printer 5V Tx line to my board. I’m only connecting the GND and the microcontroller Tx with the Printer Rx. For this I’m using connector cables:

Printer to Microcontroler Connection

Ground is connected to the board GND pin. I’m free to use any available UART Tx pin, and I have used UART0 Tx (Port A, pin 2) PTA2:

FRDM-KL25Z Connections

Summary

In few hours, I have now the ability to print at least some text, using the FRDM-KL25Z and the Adafruit thermal receipt printer. Much faster than I have expected, which is a great thing. Time for having lunch. A next post will be about how to use the software.

But if you cannot wait: the project is already on GitHub:https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/FRDM-KL25Z/FRDM-KL25Z_Printer

Happy Printing :-)

Low Power LLS Mode on Freescale's Kinetis FRDM-KL25Z board

bheemarao — Fri, 08 Oct 2021 07:50:05 GMT

Current Revision posted to Documents by bheemarao on 10/8/2021 7:50:05 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

In “IoT: FreeRTOS Down to the Micro Amps” I’m using an application with FreeRTOS to get down in micro amps low power mode. Well, nearly all or my applications are using FreeRTOS because it makes the application scalable and extensible. Still, for anyone not used to an RTOS, that might be a hard start. So here we go: how to get into the Kinetis Low Power LLS Mode *without* an RTOS.

Power Measurement

Outline

In this project I create a very simple bare-metal application for the Freescale FRDM-KL25Z board. All what it does is to blink an LED from the Low Power wake-up interrupt to show that the application is running. Right after the wake-up interrupt, it enters again the LLS low power mode. So I enter LLS low power mode, and the timer interrupt will wake me up every second. As in LLS mode only a few timer and wake-up sources are available, I’m going to use the 1 kHz Low Power clock source.

The project and all the settings is available on GitHub at the link provided at the end of this article.

Processor Expert Components

In this project, I’m using the following components:

3 LED components (RGB)
TimerInt with TimerUnit_LDD for the low power wake-up timer
WAIT component to flash different LED’s after power-up with a delay.

Processor Expert Components

Timer

As timer I use the LPTMR with a period of one second:

Low Power 1 Second Timer

Inside the period settings, I configure it to use the LPO 1 kHz timer as clock source, as this clock still will run in LLS mode:

LPO 1 kHz Source

CPU Component

First, we need to configure the CPU component to be ready for low power mode. I enable the methods SetOperationMode() and GetLLSWakupFlags() (so the black x is removed):

Enabled SetOperationMode and GetLLSWakeupFlags

In the CPU properties, I enable all low power modes, configure LPTMR0 as wake-up source, and enable the INT_LLW wake-up interrupt:

Enabled Low Power Modes

Then I configure the WAIT, SLEEP and STOP modes (these are the three different low power modes in Processor Expert):

WAIT, SLEEP and STOP modes

Source Files

Time to write the application code. I’m using Application.h and Application.c:

/** Application.h
*
*  Created on: Mar 16, 2014
*      Author: Erich Styger
*/
#ifndef APPLICATION_H_
#define APPLICATION_H_
/*! \brief callback called from the LLS wake-up interrupt */
voidAPP_OnLLSWakeUpInterrupt(void);
/*! \brief callback called from low power timer interrupt */
voidAPP_TimerInterrupt(void);
/*! \brief application main entry point */
voidAPP_Run(void);
#endif /* APPLICATION_H_ */

The the Application.c looks like this:

/* 
* Application.c
*
*  Created on: Mar 16, 2014
*      Author: Erich Styger
*/
 
#include "Application.h"
#include "LED1.h"
#include "LED2.h"
#include "LED3.h"
#include "WAIT1.h"
#include "LPTMR_PDD.h"
 
void APP_OnLLSWakeUpInterrupt(void) {
  uint32_t tmp;
 
  tmp = Cpu_GetLLSWakeUpFlags();
  if (tmp&LLWU_INT_MODULE0) { /* LPTMR */
    LPTMR_PDD_ClearInterruptFlag(LPTMR0_BASE_PTR); /* Clear interrupt flag */
  }
}
 
void APP_TimerInterrupt(void) {
  LED1_Neg(); /* red LED */
}
 
void APP_Run(void) {
  LED2_On();
  WAIT1_Waitms(1000);
  LED2_Off();
  for(;;) {
    //LED3_Neg(); /* blue LED */
    //Cpu_SetOperationMode(DOM_WAIT, NULL, NULL); /* next interrupt will wake us up */
    //Cpu_SetOperationMode(DOM_SLEEP, NULL, NULL); /* next interrupt will wake us up */
    Cpu_SetOperationMode(DOM_STOP, NULL, NULL); /* next interrupt will wake us up */
  }
}

From main() in ProcessorExpert.c I call APP_Run():

#include "PE_Types.h" 
#include "PE_Error.h"
#include "PE_Const.h"
#include "IO_Map.h"
 
/* User includes (#include below this line is not maintained by Processor Expert) */
#include "Application.h"
 
/*lint -save  -e970 Disable MISRA rule (6.3) checking. */
int main(void)
/*lint -restore Enable MISRA rule (6.3) checking. */
{
  /* Write your local variable definition here */
 
  /*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/
  PE_low_level_init();
  /*** End of Processor Expert internal initialization.                    ***/
 
  APP_Run();
 
  /*** Don't write any code pass this line, or it will be deleted during code generation. ***/
  /*** RTOS startup code. Macro PEX_RTOS_START is defined by the RTOS component. DON'T MODIFY THIS CODE!!! ***/
  #ifdef PEX_RTOS_START
    PEX_RTOS_START();                  /* Startup of the selected RTOS. Macro is defined by the RTOS component. */
  #endif
  /*** End of RTOS startup code.  ***/
  /*** Processor Expert end of main routine. DON'T MODIFY THIS CODE!!! ***/
  for(;;){}
  /*** Processor Expert end of main routine. DON'T WRITE CODE BELOW!!! ***/
} /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/

And from Events.c I call my hooks:

/* 
** ===================================================================
**     Event       :  TI1_OnInterrupt (module Events)
**
**     Component   :  TI1 [TimerInt]
**     Description :
**         When a timer interrupt occurs this event is called (only
**         when the component is enabled -  and the events are
**         enabled - ). This event is enabled only if a
**          is enabled.
**     Parameters  : None
**     Returns     : Nothing
** ===================================================================
*/
void TI1_OnInterrupt(void)
{
  APP_TimerInterrupt();
}
 
/*
** ===================================================================
**     Event       :  Cpu_OnLLSWakeUpINT (module Events)
**
**     Component   :  Cpu [MKL25Z128LK4]
*/
/*!
**     @brief
**         This event is called when Low Leakage WakeUp interrupt
**         occurs. LLWU flags indicating source of the wakeup can be
**         obtained by calling the [GetLLSWakeUpFlags] method. Flags
**         indicating the external pin wakeup source are automatically
**         cleared after this event is executed. It is responsibility
**         of user to clear flags corresponding to internal modules.
**         This event is automatically enabled when [LLWU interrupt
**         request] is enabled.
*/
/* ===================================================================*/
void Cpu_OnLLSWakeUpINT(void)
{
  APP_OnLLSWakeUpInterrupt();
}

Summary

This application shows how to set up an application for Low Power LLS mode, in a bare-metal mode. So it should be useful for you if you want to have a starting point for your own project without an RTOS.

The project and sources are available on GitHub.

OpenSDA Update Instructions for Freescale Freedom Development Boards for Windows 8.1 and Linux

Yiying — Fri, 08 Oct 2021 07:48:09 GMT

Current Revision posted to Documents by Yiying on 10/8/2021 7:48:09 AM

Here is how to update the OpenSDA bootloader firmware found on Freescale Freedom boards. Older bootloader firmware revisions did not load OpenSDA apps correctly under Linux or Windows 8.1, and thus a firmware upgrade is required for users working in those environments. If OpenSDA is not working, this is most likely the issue. This update is for the bootloader firmware that lets you drag-and-drop new apps onto OpenSDA.

For an overview of what OpenSDA is, see the OpenSDA overview. Also review the OpenSDA User’s Guide.

Determine the OpenSDA Firmware Revision:

Different Freedom boards will have different OpenSDA bootloader firmware revisions. Some boards will work out-of-the-box in Linux, while others will require an upgrade. At the time of this writing, bootloader version 1.11 is the latest firmware.

Hold down the reset button on your FRDM board
While holding the button down, plug the USB cable into OpenSDA USB socket, and then release the reset button
The board will enumerate as BOOTLOADER
Explore the new drive, and double click on SDA_INFO.HTM to see your current firmware revision.
You can see in this example, the bootloader firmware version is 1.10

Upgrade the OpenSDA Firmware:

If you are not running the latest firmware and need to use the board with Linux or Windows 8.1, you need to then update the firmware. You must do this on an OS supported by the current firmware version on your board (typically Windows XP/Vista/7). However after this one initial time, the board will be usable from then on in any OS environment.

Download the latest OpenSDA Firmware Apps zip
Read the BOOTUPDATEAPP_release_notes.txt file
Extract the OpenSDA_Bootloader_Update_App_v111_2013_12_11.zip inside the original zip file to get access to BOOTUPDATEAPP_Pemicro_v111.SDA
Hold down the reset button on your FRDM board
While holding the button down, plug the USB cable into OpenSDA USB socket, and then release the reset button
The board will enumerate as BOOTLOADER
Drag and drop the BOOTUPDATEAPP_Pemicro_V111.SDA file into the BOOTLOADER drive
After it finishes copying, unplug the FRDM board, and then replug it back in. This is the point where the bootloader firmware is updated.
Wait for it to enumerate as a drive labeled BOOTLOADER (this will happen automatically and reset should not be held down during this process)
Open up the drive and double click on SDA_INFO.HTM to ensure the bootloader is now updated to 1.11

Load an OpenSDA application:

The bootloader firmware update process will erase the previous OpenSDA application you had loaded, so you will need to load it again using the standard application loading process. Starting with v1.14, the Mass Storage Device (MSD) flash programmer application also includes P&E debug and serial capabilities. So there is no need to load separate OpenSDA applications for these features anymore.

Hold down the reset button on your FRDM board
While holding the button down, plug the USB cable into OpenSDA USB socket, and then release the reset button
The board will enumerate as BOOTLOADER
Drag and drop the appropriate OpenSDA application from the OpenSDA Firmware Apps zip downloaded earlier (such as MSD-DEBUG-FRDM-KL26Z_Pemicro_v114.SDA for a FRDM-KL26Z board) into the BOOTLOADER drive
Wait for it to copy
Unplug, then re-plug in the board
Now the OpenSDA MSD/Debug/CDC app will run (you will see a FRDM-KL26Z drive come up)

Tutorial for FRDM-KL25Z: Using the FRDM-KL25Z as Low Power Board

FreescaleTools_and_Software — Fri, 08 Oct 2021 07:32:32 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 7:32:32 AM

There will be a Freescale app note covering this topic, but in the meantime the tutorial below walks through the steps in lowering the power consumption of their Freedom board.

This tutorial was extracted from Erich Styger's blog http://mcuoneclipse.wordpress.com with his agreement.

The FRDM-KL25Z is a great board: inexpensive (around US$15), small form factor, has easily accessible pins, and has a low power (capable, at least) microcontroller, and comes with an embedded debugging interface. So why not using this board right away ‘as is’ for a low power battery operated device? Great idea, you think? Yes, I thought too. Only to find out that the board needs 20 mA out of the box.

The good news is: It is possible on a week-end to get this 150 times better down to 132 μA, with an RTOS running all the time . I invite you to join a journey with board modifications, jumpers, schematics and many multimeter pictures ….

132 micro amps!

Preface

Why do I want to use the FRDM-KL25Z as a battery operated device? I’m working on a data logger/weather station project: It features a barometric absolute pressure sensor, and I²C external EEPROM and the nRF24L01+ wireless transceiver. The Freescale FRDM-KL25Z board is great to start with: it is small and provides easy access to all signals, so I can build up my design with bread boards:

Data Logger Bread Boarding

Bread Boarding the Data Logger System

Yes, the wiring in the picture looks messy, but it allows quick prototyping and inspection of signals with a logic analyzer.

I get frequent questions and requests about “my SCI, SPI or I2C communication is not working!”: A logic analyzer or oscilloscope is something you should own. Without a logic analyzer, you likely will waste many, many hours. If you do not want to spend around $100 for professional tools, then I recommend you buy at least a $15 FRDM-KL25Z board and use it as a logic analyzer, see this post.

The system has following main parts:

Microchip 24AA external I²C EEPROM to store data values and configuration data. Data is stored in the EEPROM until it is transmitted over the wireless transceiver.
Nordic Semiconductor nRF24L01+ wireless transceiver for connectivity.
MEAS MS5607 I²C digital absolute pressure sensor.
ARM Cortex-M0+ processor on the FRDM-KL25Z.

I want to use a Cortex M0+ because of the low power characteristics of my application: The KL25Z is over-powered for my final design, but gives me a powerful development platform. And with using Processor Expert as hardware abstraction it allows me to change the processor later very easily: it will be just a different configuration made with a few mouse click .

The question is: how to use the FRDM-KL25Z to help with developing a battery operated low power embedded application?

My plan is the following:

Breadboard setup of the system with the FRDM-KL25Z: this allows me to develop the software with all the needed hardware.
Developing a simple ‘Arduino’ shield for the FRDM-KL25Z which has all the external parts (pressure sensor, EEPROM, transceiver) on it. This system will be battery operated and allows me to make long time measurement of the system.
And finally to develop my board with another microprocessor on it (most likely a KL02 or KL05). In this stage I do not need the FRDM-KL25Z any more.

Low Power (not ‘Ultra-Low-Power’)

The final system will be battery operated, so I need to make sure it uses as few energy as possible. Or better: that it uses as few energy as reasonable possible. And this means that the system shall consume less than 1 mA in average. Yes, this is not one of these ‘ultra-low-power’ applications. Silicon vendors advertise ‘nano-ampere’ solutions, but for many applications they are never achievable: to me these benchmarks are not realistic, as they assume that the processor is alive maybe one second every day? But my system needs to continuously measure and communicate several days a day. So a 99.9% inactivity is not achievable.

Silicon vendors build in multiple low power modes into their microcontroller: unfortunately many modes are easily usable waking up from the ultra-low-power modes is like a power-on-reset: all your SRAM is gone, and the peripherals and pin states are gone too. Such ultra-low-power modes are cool for a ‘dumb’ application, but were hard to deal with a more complex system where for example an operating system is running. Just to set the stage .

There is a lot which can be done to cut the power consumption, without impacting the application functionality or usability. The wireless transceiver, pressure sensor and EEPROM do not have critical power consumption in my design. What is critical is the processor: I need to get it down to below 0.5 mA. And do not want to switch the processor completely off: it shall run the operating (FreeRTOS) RTOS all the time .

FRDM-KL25Z RevE

For my experiments, I’m using the RevE version of the FRDM-KL25Z board. Compared to the earlier RevD it has a newer silicon plus jumpers to disconnect better parts on the board to reduce the power consumption. And I’m using CodeWarrior for MCU10.5 with Processor Expert:

Processor Expert makes it easier to deal with the low power modes: no need to spend many hours reading to silicon reference manual to understand all the different low power modes. And it makes it really easy to move to another processor later.
CodeWarrior debugger nicely is able to debug low power modes. Unlike other debuggers, it keeps the connection with the target under debug even if the microcontroller is in low power modes.

Test Setup

To keep things simple in a first phase, I measure only the power consumed by the FRDM-KL25Z (and ignore the external sensors/etc).

Test Setup

In my system I use a microcontroller voltage of 3.3V. Reducing the Vdd voltage usually has positive (square) impact. In my experiments I’m not going to reduce the Vdd. I instead focus on disabling unused board components, reducing clock speed and using low power modes.

The FRDM-KL25Z board runs a stripped down version of my application (just without the sensor and wireless application pats. I’m using a technique with ‘platform macros’ to enable/disable application functions:

#ifndef PLATFORM_H_ 
#define PLATFORM_H_
 
#define PL_BOARD_IS_FRDM 1
#define PL_HAS_LOW_POWER 1
#define PL_HAS_SHELL     0
#define PL_HAS_LED       1
#define PL_HAS_RTOS      0
 
#endif /* PLATFORM_H_ */

Board Power Measurement Jumpers

The FRDM-KL25Z RevE board has two jumpers (J3 and J4) to measure the power used by the KL25Z and/or the power used by the K20 for the OpenSDA debug interface:

J3 and J4 on FRDM-KL25Z (Source: Freescale)

Both headers are not populated by default. J3 has a 0 Ohm and 10 Ohm resistor populated.

I guess the idea is to remove the 0 Ohm (R73) so the voltage across R81 (10 Ohm) could be measured by the KL25Z itself?

On the RevD boards both headers hat a ‘cut trace’ between the jumper. I decided to remove all three resistors (R73, R81 and R74) so I can measure the current consumed.

R73 R81 and R74 removed

Removing SMD components without the proper equipment is challenging! It works best with SMD de-soldering iron tips. The RevD approach with cutting traces was more user-friendly.

Starting Point: 19.58 mA

I’m not so much interested here about the current consumed by the KL25Z and K20 (OpenSDA), as I need to focus on the overall board consumption. For my experiments I measured the board current coming through the P3V3 on pin 8 of J9:

Measured Board Current (Schematic Source: Freescale)

I started my experiments with following starting point:

KL25Z using 8 MHz external crystal (PEE mode, 48 CPU clock and 24 MHz bus clock)
FreeRTOS running SysTick for with 100 Hz RTOS tick counter
Shell command line interface through OpenSDA (38400 baud)
Blinking LED heartbeat so I can see that the application is running properly

With this, the board consumes 19.58 mA:

Base Board Current Consumption

Disabling Accelerometer: 19.55 mA

One rule of low power: disable what I do not use. The FRDM-KL25Z has the MM8451 accelerometer on the board, so I disabled it (disabled the accelerometer through the I²C interface/shell). But saving were minor. I guess only removing the accelerometer would bring some extra savings.

Accelerometer disabled

Reduced Clock Speed: 11.91 mA

Second rule of low power: slow down the clock speed. Current consumption usually is linear to the used clock speed. So reducing the clock speed should greatly reduce the current. I do not need that 48 MHz clock speed for my application. So I reduce the core clock to 2 MHz and the bus clock to 1 MHz:

External Crystal 8 MHz
MCG settings to BLPE (Bypass Low Power External reference clock)

BLPE with external Crystal

gives about 12 mA:

2 MHz with external clock

Disabled OpenSDA: 7.23 mA

I still have a lot of current consumed. And one part of this is the K20 microprocessor on the board used for OpenSDA. To get rid of that extra current:

Disconnect P3V3_SDA (remove R74 and remove jumper on J3)
Removed Power to K20
Disconnect OpenSDA reset line: for this cut the trace under J14 and install a jumper
Cut J14 Trace
Remove the J14 jumper to disconnect the reset line between the KL25Z and K20 OpenSDA, as otherwise current can flow between the K20 and KL25Z:
J14 disconnected by Jumper

With this, the current went down to 7.2 mA:

Disabled OpenSDA

Cut J20: 3.55 mA

Good progress so far: from 20 mA down to 7 mA. But what caused me a lot of head scratching: I would not have expected that 7 mA: it should be more in the 3-4 mA range. And indeed, measuring the current to the KL25Z microcontroller on J4 showed 3.4 mA:

KL25Z current at 2 MHz

So what is using all the excess current? My goal is to go below 1 mA, and somehow the board itself already uses 3.6 mA somewhere. It took me more head scratching (that’s why I’m getting bald ). And after a while I realized that current must be flowing back into U1:

Current flowing back through J20

With this, I decided to the trace under J20 and to install a jumper there to prevent that current:

Cut J20 Trace

Now my board shows a current I expect :

Current after cutting J20

Using Internal Clock: 2.69 mA

One general rule for low power is: using an external crystal uses less energy than using an internal (on chip) clock generator. However as the FRDM-KL25Z has a high frequency 8 MHz clock needed for its USB operation, it is probably better to use the internal (slower) clock generation module.

For this I disable the external crystal and change the mode from BLPE to BLPI (Bypass Low Power Internal):

Disabled Oscillator and BLPI mode

BLPI Settings

And the result is again a reduced current consumption:

Internal Clock

I did not expect that much reduction. Not sure why it has such a big impact. But it seems that this 8 MHz external crystal really is not good for low power applications?

Very Low Power Mode: 2.08 mA

To enter the ‘Very Low Power Modes’, I enable the setting in the CPU component. But as the bus clock cannot exceed 800 kHz in this mode, I set it to the next closest value:

Very Low Power Mode Settings

With this, I’m close to 2 mA . But still twice as high as where I want to be .

Very Low Power Enabled

Where is my current going?

To be clear: I’m down to 2.08 mA for the board, while the microprocessor is in RUN mode. So I not enter any of the special low power modes (yet). Still for 2 MHz CPU clock that 2.0 mA are too high to me?

So decided to do another measurement: measuring both the board current and the KL25Z current with the OpenSDA on the board enabled (J14 and P_SDA enabled).

KL25Z and Board Current

That 6.65 mA for the board is no surprise: the K20 of the OpenSDA is active. However what is interesting to see is that the K25Z current is down to 0.754 mA with the OpenSDA active, while it is very close to the 2.083 mA if the OpenSDA is *not* active. This means that about 1.3 mA is going ‘somewhere’ from the KL25Z if the OpenSDA is deactivated. The question is: where, and why?

OpenSDA Serial Interface

I already have cut the reset line between OpenSDA and the KL25Z. But there is the OpenSDA Serial-to-USB CDC connection:

OpenSDA UART Connection

And I’m using a UART0 in my application: I’m using it to communicate through OpenSDA to the host machine. But now I have OpenSDA disconnected, and there could be a current flowing from the KL25Z to the K20 (which is unpowered). So I turned of the shell and UART, and look at this :

UART0 and OpenSDA disabled

I’m getting definitely better

Processor Expert Low Power Modes

So far I’m not using any low power modes. The cool thing with Processor Expert is, that it makes usage of low power modes really easy. Calling SetOperationMode() changes between the different low power modes:

SetOperationMode

There are several settings inside the CPU component which deal with low power. First is the ‘Low power mode settings‘ group:

Low Power Mode Settings

In above dialog I specify which modes are allowed, and which interrupt/events bring me out of Low Leakage mode (LLWU = Low Leakage Wakeup Unit): Usually I use the Low Power Timer (LPTMR) to wake me up.

In the Operation mode settings I can specify

Which mode shall be entered with SetOperationMode()
What should happen after the wake-up interrupt

Operation Mode Settings

Entering Low Power Mode: WAIT down to 0.155 mA

With this, everything is ready to use low power modes from the application.

In my application I have a variable LP_mode:

typedef enum {

LP_RUN,

LP_WAIT,

LP_SLEEP,

LP_STOP

} LP_PowerMode;

static LP_PowerMode LP_mode;

which is defining the current active low power mode. To switch into a low power mode I use SetOperationMode():

if (LP_mode==LP_WAIT) {

Cpu_SetOperationMode(DOM_WAIT, NULL, NULL); /* next interrupt will wake us up */

} else if (LP_mode==LP_SLEEP) {

Cpu_SetOperationMode(DOM_SLEEP, NULL, NULL); /* next interrupt will wake us up */

} else if (LP_mode==LP_STOP) {

Cpu_SetOperationMode(DOM_STOP, NULL, NULL); /* next interrupt will wake us up */

}

/* interrupt will wake us up, and we are back in RUN mode */

WAIT is really easy to use: basically it stops the core clock, while interrupts are still active. And a perfect place to enter that low power mode is from the FreeRTOS Idle task hook:

void FRTOS1_vApplicationIdleHook(void)

{

/* Called when the RTOS is idle (from the IDLE task).

Here would be a good place to put the CPU into low power mode. */

LP_EnterLowPower();

}

Just doing the WAIT mode I get down to 0.155 mA :

WAIT mode enabled

With the above setup, I have only one task running and a blinking LED. The application with all the sensors will have two more tasks added, so the power consumption will go up again.

FreeRTOS Tickless Idle Mode: 0.132 mA

FreeRTOS comes with a cool low power feature: the Tickless Idle Mode. I have enabled it along with using the special Systick Prescaler:

FreeRTOS Tickless Idle Mode

With this, the RTOS will delay the SysTick interrupts as long as possible, extending the low power idle modes and reducing the interrupt load. And this is what I get as board current :

WAIT with FreeRTOS Tickless Idle Mode

Summary

The week-end is over, and I need to stop here at the WAIT mode. I have not explored the more advanced SLEEP and STOP modes, but on the other hand I’m now well below my target of 1 mA for the board anyway .

Modern microcontroller come with many advanced low power modes. Unfortunately for many applications most extreme low power modes are not usable as they completely shut down the processor, making it hard to use with an application e.g. using an operating system. The Freescale KL25Z processor is no exception to this. But even with ‘moderate’ power saving settings I’m able a reasonable power reduction. Still, there are a lot of settings, and I it is definitely not easy to find my way through the endless and complicated settings the silicon designers have invented. But at least with Processor Expert things are easier to find and configure.

Development boards are great for development or evaluation. They are usually not designed for low power usage, because they have too much components on it consuming energy. However, as shown with the FRDM-KL25Z it is possible to get into a working solution:

Disable by software any external devices not used (e.g. Accelerometer)
Disable any on-board debugging devices (e.g. OpenSDA). Do not only cut power, disable as well any other debugging signals (e.g. Reset).
Carefully check the changed current flow if not using the on board regulators (e.g. prevent current flowing back to the regulators).
Make sure that there is no current through connection lines to unused devices (e.g. UART0 to K20 OpenSDA).
Using an RTOS like FreeRTOS does not mean it cannot use low power modes. A mode like WAIT already greatly reduces the power consumption. The tickless idle mode of FreeRTOS is helping to reduce the power consumption too.
I would not have been able to reach this in such a short time without the help of Processor Expert

The project I have used for my testing is available on GitHub here. Hope this is useful, and helps your battery powering a FRDM-KL25Z. So far I have reached my goals with a board consumption less than 1 mA . But as soon as I find time, I’ll explore the more advanced low power modes. Until then, have a look at the Freescale web site for any documenation about how to use the low power modes for the KL25Z (or any other ARM Cortex-M0+).

Happy Low-Powering

Tags: freescale, frdm-kl25z, freedom

Codewarrior Tutorial for FRDM-KL25Z: Using the Freedom as an USB Keyboard

FreescaleTools_and_Software — Fri, 08 Oct 2021 05:34:59 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 5:34:59 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

I miss my old DELL laptop. Ok, the new one I received from IT services is not bad. It is faster and has a better screen. But I’m not really happy with the new keyboard. With the previous keyboard I was able to do a ‘PrtnScrn’ with a single key press. With the new one I need to press Fn + PrntScrn. And this is impossible to do with one hand:

Impossible to reach Fn+Prnt Scrn with one hand!

Yes, I have two hands . But many times I need to do ‘print screen’ while having my other hand on the mouse .What else can I do?

Exploring Options

Of course there are several options:

Call someone in my office and say “hey, can you give me a helping hand?”. Works, but my co-workers will hate me for this.
Reconfigure my laptop keyboard mapping. Doable, but then the writing on the keyboard does not match the reality any more which can be confusing.
Remapping the print screen functionality in SnagIt (the screen capture tool I’m using). That would be too easy
Using the FRDM-KL25Z board as USB keyboard

As you might have guessed from this post title: I’m going for option 4 .

This gives me the added value that I can do anything I want: having my own shortcuts, doing sequences of key press actions, and so on.

In the next steps I explain how to turn the FRDM-KL25Z into a USB HID Keyboard device with CodeWarrior for MCU10.4 and Processor Expert Components. A link to the project is posted at the end of this article.

Processor Expert Components

Make sure you have the latest Processor Expert components loaded (zip file attached to this post). Instructions how to load the components is explained in this post.

Creating CodeWarrior KL25Z Project

Create a new Processor Expert project in CodeWarrior using the menu File > New > BareBoard Project:

Provide a name for the project
Select the MKL25Z128 under Kinetis L Series > KL2x > KL25Z
Select OpenSDA as connection
In ‘Language and Build Tools Options’, the No I/O option can be selected for reduced footprint
Select Processor Expert under Rapid Application Development
Finished

USB HID Project Created

USB Clock Settings

The USB clock needs to be set at 48 MHz. For this, I open the Inspector on the Cpu:

Enable ‘System oscillator 0′. This enables it to use the 8 MHz external crystal:

System Oscillator Enabled
Set the MCG clock settings to PEE (PLL Engaged External) with 96 MHz:

PEE with 96 MHz
Set the core clock to 48 MHz and the bus clock to 24 MHz:
48 MHz Core Clock with 24 MHz Bus Clock

With this I have properly configured the microcontroller to work for USB.

Adding USB Stack

The next step is to add the USB stack. I have created the FSL_USB_Stack Processor Expert component which is a wrapper for the Freescale bare metal USB stack. This USB stack can be used as well with an RTOS like FreeRTOS too. The FSL_USB_Stack component now supports HID, CDC and MSD device classes.

From the Components Library view, I add the component to my project (double-click on the component):

FSL_USB_Stack Component

By default, it is added for CDC. So I need to configure it for USB HID Keyboard device class.

I select the FSL_USB_Stack and configure it:

USB is using Init_USB_OTG_VAR0: this one is used for Kinetis/ARM.
Device Class: HID Keyboard Device.
In the HID Keyboard field, I choose FSL_USB_HID_Keyboard_Device.

FSL_USB_Stack Configured for USB HID Keyboard

Next, I select the Init_USB_OTG component and configure it:

Enabled clock gate (otherwise the USB module is not clocked).
Set PLL/FLL as clock source (has to be 48 MHz, that’s why we configured the CPU clock in the previous step for 48 MHz).

Init Component Configured

Finally, configure the FSL_USB_HID_Keyboard_Device CPU:

FSL_USB_HID_Keyboard CPU Configured

Now all the error markers should disappear as I finished configuring the component.

FSL_USB_HID_Keyboard_Device Component

The component has two more settings which are used to report the device to the host:

HID Settings

The name is used in the Windows Device manager:

FSL HID Keyboard in the Windows Device Manager

The component features a ring buffer which is used to store keyboard events to be sent later:

USB HID Keyboard Buffer Settings

The buffer entries are 16bit each (2 bytes), because a keyboard event has one byte for the ‘modifier’ (e.g. SHIFT pressed) and the key itself (e.g. ‘a’). More about this later. By default the buffer is set up for 16 entries: so I can buffer up to 16 items (or key changes). If you always send just one key, then you can reduce this number to a lower number, say 4 (to be safe).

USB HID Keyboard Protocol

The HID Keyboard device has to send a report to the host. That report is an array of 8 bytes describing the current key status:

Byte 0: Modifier byte which encodes CTRL, SHIFT, ALT and GUI keys (8 bits are defined for this)
Byte 1: unused
Byte 2-7: 6 bytes with key codes. With this it is possible to report up 6 plus the modifier keys pressed at the same time.

Typically only Byte 0 and Byte 2 are used. So for example to send a USB HID report that ‘a’ is pressed, I send

Byte 0: 0x00 (no modifier) Byte 2: 0x04 (is the code for key 'a') all other bytes are 0x00

To send the a report that ‘A’ is pressed (which is SHIFT+a):

Byte 0: 0x02 (left SHIFT key pressed) Byte 2: 0x04 (is the code for key 'a') all other bytes are 0x00

It is important to note that these reports are ‘keys are down’ reports. And as long as I do not send a new report, the last sent report is still active (or key pressed). So I need to send a message for the ‘release’ event, which is a report with all bytes zero:

Byte 0: 0x00 (no modifier key pressed) Byte 2: 0x00 (no key pressed) all other bytes are 0x00

The Key Usage codes are documented in chapter 10 of the HID Usage Tables of the USB Standard Document.

The FSL_USB_HID_Keyboard_Device Processor Expert component I have implemented makes it really easy to use.

FSL_USB_HID_Keyboard_Device Interface

The component offers the following methods and events:

HID Keyboard Device Interface

App_Task() needs be called periodically. With this the elements from the ring buffer are sent to the USB bus. Call this method after you have used any of the Send methods. This routine returns ERR_OK if the device has been enumerated (is connected to the host).
SendStr() can be used to send an ASCII string. This method translates the string into USB HID messages and places them into the ring buffer to be processed by App_Task().
SendChar() is the same as SendStr(), but sends a single character only.
Send() is used to send native USB HID code. As for the other Send routines, it places the item into the buffer to be processed later by App_Task().

Examples how to use it:

for(;;) {

if (HIDK1_App_Task()==ERR_OK) { /* run the USB application task: this will send the buffer */

/* ok: we are connected! */

(void)HIDK1_SendStr((unsigned char*)"Hello!"); /* send a string */

}

I’m ignoring here the return code of SendStr(). It would return ERR_TXFULL in case the ring buffer is not able to store the string. In that case either increase the buffer size, or send smaller strings and call App_Task() in between.

Once the device is connected and has finished enumeration, App_Task() will return ERR_OK. Then the applications places the string “Hello!” in the ring buffer, which is sent to the host in the nextApp_Task() call, as if would have typed it on the keyboard.

It happened to me that such test code writes text to my host machine, potentially overwriting my stuff. I recommend to have a notepad window open (with active focus) so the board can write into that space instead overwriting your sources in the editor
you might get a ‘+’ character instead of the ‘!’. This is because my driver does not support different keyboard layouts and mappings. Contributions are more than welcome

To send a single ASCII character is simple:

(void)HIDK1_SendChar('A'); /* send the A character */

Knowing the USB CDC protocol, it cannot send just the ‘A’ character. USB CDC defines the ‘a’ (and ‘A’) keyboard character with the value 0×04:

#define KEY_A 0x04

The information if it is ‘a’ or ‘A’ is encoded as ‘modifier’: if the SHIFT key is pressed or not. And there are several modifier flags available in the header file of the component:

#define MODIFERKEYS_NONE 0x00

#define MODIFERKEYS_LEFT_CTRL 0x01

#define MODIFERKEYS_LEFT_SHIFT 0x02

#define MODIFERKEYS_LEFT_ALT 0x04

#define MODIFERKEYS_LEFT_GUI 0x08

#define MODIFERKEYS_RIGHT_CTRL 0x10

#define MODIFERKEYS_RIGHT_SHIFT 0x20

#define MODIFERKEYS_RIGHT_ALT 0x40

#define MODIFERKEYS_RIGHT_GUI 0x80

So to send ‘A’, I need to send MODIFERKEYS_LEFT_SHIFT and KEY_A.
This information is put together by SendChar() using the hidKeyCode table:

byte HIDK1_SendChar(byte ch)

{

if (ch&0x7F) { /* only handle 0x00..0x7F */

Tx2_Put(hidKeyCode[ch]); /* put 16bit value (modifier|code) into buffer */

}

Tx2_Put((MODIFERKEYS_NONE<<8)|KEY_NONE); /* send release message */

return ERR_OK;

}

Note that the above code uses a second Put() with MODIFIERKEYS_NONE and KEY_NONE which is a ‘keys release’ message (actually it says ‘no keys pressed’). The HID protocol sends the actual state of a key. So if I send the information ‘the A key is pressed’ the host assumes that I still have that key pressed until I send another message about the new key. If I would not send that release message, the host assumes that the key ‘A’ is still pressed, and repeats the character. That’s why I send a ‘release’ message right afterwards to tell the host that all keys have been released.

SendChar() and SendStr() perform automatic ASCII to HID code translation. If I want to send HID codes directly, I can use the method Send() of the component:

byte HIDK1_Send(byte modifier, byte key)

{

return Tx2_Put((modifier<<8)|key); /* put 16bit value (modifier|code) into buffer */

}

So for example if I want to send my ‘print screen’ action, I do it wit:

HIDK1_Send(MODIFERKEYS_NONE, KEY_PRINTSCREEN);

HIDK1_Send(MODIFERKEYS_NONE, KEY_NONE); /* release key */

And if I need CTRL+ALT+DELETE, then it is

HIDK1_Send(MODIFERKEYS_LEFT_CTRL|MODIFERKEYS_RIGHT_ALT, KEY_DELETE);

HIDK1_Send(MODIFERKEYS_NONE, KEY_NONE); /* release key */

Pretty easy

The Application

Now I have everything in place. What I want is an application which sends the ‘Print Screen’ key event to the host with a single button press. For this I re-use the reset button of my FRDM-KL25Z (see this post how to do this). Then to add LEDs to show the status of the USB enumeration (see this post how to add LED’s). Adding some mechanics for LED blinking and button debouncing, and voilà:

for(;;) {

WAIT1_Waitms(10);

cnt++;

if (SW1_GetVal()==0) { /* button pressed */

WAIT1_Waitms(100); /* wait for debouncing */

if (SW1_GetVal()==0) { /* still pressed */

/* send print screen */

HIDK1_Send(MODIFERKEYS_NONE, KEY_PRINTSCREEN);

HIDK1_Send(MODIFERKEYS_NONE, KEY_NONE); /* release key */

}

while(SW1_GetVal()==0) {} /* wait until button is released */

}

if (HIDK1_App_Task()==ERR_OK) { /* run the USB application task: this will send the buffer */

if ((cnt%100)==0) {

LEDR_Off();

LEDG_Neg(); /* blink green LED if connected */

}

} else {

if ((cnt%200)==0) {

LEDG_Off();

LEDR_Neg(); /* blink red LED if not connected */

}

The red RGB LED blinks if not connected to the host, and the green one if it is connected as USB HID Keyboard. And when I press the reset button, it sends the ‘Print Screen’ key to the host. Finally I can do ‘print screen’ with my left hand while having my right hand on the (FRDM-KL25Z) keyboard :mrgeen:

Summary

With the creation of the USB HID Keyboard Device Processor Expert component, I have turned my FRDM-KL25Z init a generic USB keyboard device. With a simple button press I can send any keyboard actions to my laptop, making such as ‘print screen’ a single button press again. So it makes it a great device even for users with disabilities. And my ‘disability’ is solved now too: I get a print screen with the press of single button :

Using FRDM-KL25Z as USB Keyboard Device

Other ideas I have in mind: I thinking of turning the FRDM board into a wireless presenter. All what I need on top of this is either Bluetooth (but this would need to be a Bluetooth HID Keyboard), or maybe just using two FRDM boards: one is the keyboard dongle, and the other is sending data over the wireless communication channels. Still thinking about the best solution, and ideas are welcome.

The project created above (along with the components) are available in attachement to this post. While it does not support international keyboard mappings, that project has been very useful for me. I hope it is useful for you too.

Happy Keyboarding

Attachments:

community.element14.com/.../Freedom_5F00_USB_5F00_HID_5F00_Kbd.zip
community.element14.com/.../0211.ProcessorExpertComponents070813.zip

Tags: keyboard, cortex-m0+, freescale, freedom_board, Cortex-M, kinetis, usb, cortex, frdm-kl25z, kinetis-l, cortex-m0, arm, freedom

Keil µVision (ARM-MDK) Tutorial for all FRDM with Processor Expert Driver Suite

FreescaleTools_and_Software — Fri, 08 Oct 2021 05:34:33 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 5:34:33 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

The good thing with using ARM microcontroller is: there are plenty of tool choices. Even myself, I’m using multiple different tool chains. And while I’m heavily using Eclipse, there are non-Eclipse tool chains which have their advantages too.

The cool thing with CodeWarrior is that beside of Eclipse based, it comes with Processor Expert integrated. And I’m using Processor Expert a lot in my projects. But using Processor Expert does not mean I’m limited to CodeWarrior or Eclipse. So I can use CodeRed or IAR as tool chain with it. And this post is about using Processor Expert with the µVision tool chain from Keil/ARM.

Keil uVision Splash Screen

Software Downloads

Keil is owned by ARM and of course supports ARM devices . Their IDE product is µVision (the current version is µVision4).

Processor Expert is available as ‘standalone’ version (called ‘Driver Suite’) from Freescale. Basically this is a stripped down Eclipse version with Processor Expert in it. It will be used to configure the drivers/components, and then things get imported and compiled by µVision (like IAR).

Software Installation

If not already installed, you need the following tools:

The µVision IDE, compiler and debugger, available from http://www.keil.com/download/product/ (MDK-ARM). Current version is V4.71a
Processor Expert Driver Suite, available from http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_DRIVER_SUITE ‘Download’ tab. Current version is Microcontrollers Driver Suite V10.2

Processor Expert Driver Suite

First, I’m going to create a new project with Processor Expert. For this I launch eclipse:

Launching PExDrv

If this is the first time, it asks me for a new Eclipse workspace:

Workspace Launcher

The it shows the ‘Welcome’ view, from where I go to the workbench:

Go To Workbench

External Tools Configuration

From the workbench, I need to configure µVision as an external tool:

External Tools Configurations

that menu is accessible as well under Run > External Tools.

Next step is to add a new external tool. For this I select the ‘Program’:

Program selected

and press the ‘New’ button:

New Program

This creates a new configuration:

New Configuration

Next I configure the settings:

Export2uVision Configuration

Name: just something useful and easy to remember.
Location: Browse where you have µVision installed and use the µVision executable.
Working directory: use ${workspace_loc:/${project_path}}
Arguments: use -i ProjectInfo.xml ${project_name}.uvproj

This configures to launch the µVision executable with the working directory of my (currently selected) project. It uses the -i argument to import a project. The project information are inside the ProjectInfo.xml which is generated by Processor Expert. The last argument is the project name µVision should use for when the .uvproj project does not exist yet.

Press ‘Close’ to return to the workbench.

Creating Processor Expert Project

In the next steps, I’m creating a Processor Expert project for the FRDM-KL25Z board.

To create the project, I use the menu File > New > Processor Expert Project:

New Processor Expert Project

I give it a name:

Project Name

Select the device:

Selected Device

Using the current perspective:

Using current perspective

The next step is important: I need to select the correct compiler to be used (Keil ARM C/C++ Compiler):

Selecting ARM Keil Compiler

Finish, and the project gets created.

Adding Components

Now I can configure my the Processor Expert components, or add my components from GitHub. For my example, I have added a LED and Wait component to have a blinking LED:

Generating Code

To generate the code, I use the ‘Generate Code’ Button:

Generate Code

Processor Expert has now generated the code and created the ProjectInfo.xml file which I can export to Keil to create an MDK project:

Generated Code and ProjectInfo.xml

Exporting to Keil µVision

To export it to Keil µVision, I launch the external tool I have configured before. As this is the first time, I do not have a launch history . So I first select the project (or the ProcessorExpert.pe file in the project), and then use ‘External Tools Configurations…’ again:

Running external tool the first time with no launch history

Next, I select the Program I want to run and press ‘Run’:

Run the External Program

Note: I need to have project (or ProcessorExpert.pe of that project) selected. Otherwise I get an error “Variable references empty selection: …” as my project variable is not defined:

Variable references empty selection

Now as I have it launched once, it is present in the recent launch list and I can execute it directly with a click:

Export2uVision with recent launch

It is important to have a current project selected. So make sure you select the project folder or the ProcessorExpert.pe file inside the project.

This has created a µVision project based on the ProjectInfo.xml:

uVision Project Created

Launching µVision from Processor Expert Project

Eclipse is able to launch an application based on the file extension. As the .uvproj file extension is associated with µVision, I can double-click on the .uvproj file inside the Eclipse project explorer view:

Launching uVision Project from Eclipse

In case the .uvproj file is not shown in the project view, use ‘Refresh’ context menu on it or hit the ‘F5′ key.
Note that if I double-click again, it will create another µVision IDE.

Open Project in µVision

And I can load that project from the Keil IDE too. In µVision I use Project > Open Project menu and browse to the .uvproj created in previous step:

Open Project in uVision

Now I have the project loaded:

Loaded Processor Expert Project

F7 performs the build of the project:

Building the Project

Changing Components

Whenever I change components (add, remove or change) in Processor Expert I need

Generate Code in Processor Expert Driver Suite
Run the external tool to import the changed files/settings into µVision (run my Export2uVision)
Switch to µVision to confirm to reload the changes:

Confirm to reload changed settings

Debugging the FRDM-KL25Z

Now that I have compiled my application, I want to debug it on the FRDM-KL25Z. µVision does not (seem) to support the P&E OpenSDA, but it has support for CMSIS-DAP (ARM is driving the CMSIS initiative). So I loaded my FRDM-KL25Z with the CMSIS-DAP firmware as described in this post. The debugger settings in µVision have one gotcha:

First I need to set it for CMSIS-DAP Debugger in the Project options:

Project Options for CMSIS-DAP Debugger

Next to verify that it is using SWD (and not JTAG) in the settings:

SWJ SWD Settings

First I thought: that’s it!

However, when I wanted to debug, I had “No ULINK Device found”:

No ULINK Device found

The gotcha is that I missed to set the CMSIS-DAP debugger in the Utilities tab too :

CMSIS-DAP Debugger in Utilities

After that, I was able to debug the application on the FRDM-KL25Z:

Debugging the Processor Expert Application

Summary

Processor Expert is not limited to CodeWarrior or Eclipse, it can be used as ‘Driver Suite’ with external tools like IAR or Keil. It is not as integrated with Eclipse based solutions, but still it allows to use the power of Processor Expert.

I wish µVision would implement something like in IAR to automatically reload the new files, so this is for sure something which would make µVision+Processor Expert an even better combination.

Happy Keiling

Tags: cortex-m0+, mdk-arm, freescale, freedom_board, Cortex-M, kinetis, cortex, frdm-kl25z, keil, kinetis-l, cortex-m0, arm, freedom

Review for CodeWarrior for MCU v10.4: Improved performance compared to the version 10.3 !!

FreescaleTools_and_Software — Fri, 08 Oct 2021 05:33:28 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 5:33:28 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

Freescale has released in May 2013 an updated version of CodeWarrior: version 10.4. I’m usually not switching a tools version in the middle of a university semester. Unless I see a real benefit, and the risk is low. Well, I have used it now for a few days, and I have decided to move my projects from 10.3 to 10.4. Why? Read on…

CW for MCU10.4

To switch or not, that’s the question…

As with any new software or new versions, it is always a judgement call between ‘never change a running system’ and ‘make a move to something new’. Or to answer the questions: is it worth the risk? Or is there anything new I despertaly need?

That new release comes with support for new microcontroller (new Kinetis and S12Z cores), 64bit floating point for S12Z, C++ support for DSC (Digital Signal Controllers), and many more. But in my context and with the projects I have at the university, the following things are by far more interesting:

New ARM gcc 4.7.3: new updated GNU tool chain from ARM Inc.
Component Development Environment (CDE) comes with free Community Edition license: Now everyone can create new Processor Expert components!
Ease-of-Use: many smaller things which makes it easier to use: exporting register values in CSV format, easier to read registers view, renaming Processor Expert folders and components, …
Improved performance: the release note lists IDE and debugger, both for startup and debugging.

Especially the last item is of big interest: I have tight schedules too (not only the students with their assignments ).

Installation

I admit: the installation is not new to 10.3, but I received several questions and requests for tips around CodeWarrior installation, so here we go….

MCU10.4 is not an update, it is a full installer. It does not need a license upgrade, as earlier 10.3 licenses work with the 10.4.

10.3 license files work, but as for 10.3: existing 10.x licenses prior 10.3 need an upgrade.

As the earlier V10.3 version, it can be downloaded from here in two versions:

Online Installer: here the download is half of the size (670 MB file size), and the needed other packages are downloaded during installation
Offline Installer: Here the download is twice as big (1.2 GB file size), and includes all architectures supported.

I prefer the ‘offline’ version. Yes, that’s a huge file. But too many times I have run into network connection problems, so at the end I saved time to just get the full stuff.

It comes either as ‘Evaluation’ or ‘Special Edition’:

Evaluation: it installs a 30 day professional license, time bombed.
Special Edition: same software, it just does not install that 30 day professional license. The free limits apply, e.g. 64 KByte code size for Kinetis ARM Cortex-M0+ or 128KB for Kinetis ARM Cortex-M4 derivatives.

So the ‘Evaluation’ is really the same as ‘Special Edition’. So no real sense to download the Special Edition at all. I can download the Evaluation, and then I get a 30 day full license (it does not work to re-install the product to get again a 30 day license ). If I’m annoyed by the ‘your license will expire in x days’ dialog, I simply can rename/remove the MCU\license.dat file, and I’m at special edition level

Launching the ‘offline’ version will extract the files into a sub-folder, because the .exe downloaded is a self-extracting executable:

Extracting Offline Version

After unpacking, all the files are that sub-folder, where the Setup.exe ist the installer:

Unpacked MCU10.4 Files

For my classroom installation, I only need to pass the Setup.exe plus the .zip files for the architectures I want to support/install. E.g. for Kinetis I only need the setup.exe plus the com.freescale.mcu10_4.kinetis.updatesite.zip: which then makes 850 MByte which is easier to distribute in the class. And if needed, the other .zip files can be installed with ‘Add new software’ inside Eclipse.

There is no need to uninstall an earlier CodeWarrior version. Actually I always recommend to keep the previous version. I install the new CodeWarrior into new directory, and then I can switch back and forward between the two versions.

As a negative point: the installation takes a very, very long time: not sure what it is, but it took about one hour to install it on my Windows7 64bit machine, compared to less than 10 minutes e.g. for Code Red. Not sure if this is just my machine? I love to hear your comments if you see the same.

I see about the same installation time with MCU10.3, so this is nothing new. I suspect is has something to do that the installer is using the Eclipse ‘Install New Software’ (Eclipse Updater) technology. It seems to me that the Eclipse Updater way slows down things.

GCC

MCU10.3 has gcc 4.6.2, while MCU10.4 has 4.7.3. I compared the code size for my application with -Os (optimize size) set.

gcc 4.6.2 in V10.3 gives this:

  text data bss dec hex filename 33076 88 12192 45356 b12c Freedom_Robo.elf

while gcc 4.7.3 in V10.4 gives this:

  text data bss dec hex filename 32924 88 12192 45204 b094 Freedom_Robo.elf

So this is not that big of a difference, just a few bytes less. More important: I have run several of my projects with the new compiler, and no issues found.

But the big plus with the MCU10.4 GNU integration is that it passes now the options to the linker by file: this means that the Windows command line length of 8191 characters is bypassed, and I’m able now to build a full CMSIS library with MCU10.4 .

The other good thing is: gcc 4.6.2 has issues with the generated debug information if optimizations were enabled. Basically often local variables were not displayed correctly. This is now fixed in the new gcc 4.7.3 which makes debugging optimized code a better experience.

The problem I have described here is solved now too: the ARM gcc integration has an extra option to disable the generation of the listing file:

Enable Assembler Listing Option

Debugger

In the debugger I noticed that the Registers view is now easier to read. In MCU10.3 I have this for hexadecimal and binary format:

MCU10.3 Registers in Hex

Now with V10.4, the values are padded with leading zeros:

MCU10.4 Registers View Hex

MCU10.4 Registers View Binary

The debugger features now an option to restore watchpoints:

Restoring Watchpoints

Processor Expert

With MCU10.3 or earlier, it was not possible to ‘freeze’ the code generation for the CPU component:

Don’t Write Generated Component Modules

Integration of Processor Expert with C++ is easier now, as extern "C" is added:

Added extern C

CDE

The Component Development Environment now works at the ‘community’ level free of charge: this means no license file is required any more, so the extra step to copy a license file as described here is not needed any more .

Performance: IDE, Build and Debug

Eclipse is probably not the fastest IDE in the world, for many reasons (maybe it is just too powerful ). What I noticed is that compared to V10.3, it is ‘snappier’. Startup time, build time and the time to launch the debugger were noticeable faster. So I decided to do a simple comparison (all numbers in seconds).

First, starting up a workbench with Eclipse:

IDE Startup Time

That’ already good news, but I do not need to start-up IDE as much as I do need to build my projects. So I compared to rebuild my Zumo projects which can be considered as a ‘medium’ size project (~200 source files):

Project Rebuild Time

Wow! Now this now much faster . Next, to start the debugger for that project:

Debugging Time

So an improvement here as well

Ease-of-Use: Highlighting of Active Project

CodeWarrior marks now the active project with a bold font. If I’m in a source file, then the project where this source file belongs to is marked with a bold font:

highlight of active project

That’s a very useful feature, as this tells me which project I will debug if I press the debug button:

Debugging Active Project

So no further guessing

Processor Expert

My Processor Expert components work without changes in V10.4, and the components are shared between 10.3 and 10.4, so both installation are using the same user components.

Summary

I decided to move on to MCU10.4, mainly for the performance reasons. The improvements in debugging and build time were obviouse when I switched back and forward between MCU10.3 and MCU10.4. I have used MCU10.4 for a few days, and tried many of my existing MCU10.3 projects, and no issues found. I would not switch versions if I’m in the middle of a critical project. This is not the case for me, so I can take the risk. As I still can keep my earlier 10.3 installed, I always can go back (just in case). The other features and ease-of-use things were not that important at the first look, but now as I have moved them more and more and explore new things, I definitely do not want to go back. Otherwise, you will hear from me, promised

Happy Codewarrioring

Tags: compiler, freescale, kinetis, codewarrior, ide_toolchain, 10.4

Tutorial for FRDM-KL25Z: Touch sensing demo featuring FreeMaster visualization tool

FreescaleTools_and_Software — Fri, 08 Oct 2021 05:33:19 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 5:33:19 AM

This tutorial was extracted from Pavel Sadek post on the Freescale Community https://community.freescale.com/docs/DOC-95001 with his agreement.

Hi everyone!

I have made a simple touch sensing demo for KL25z Freedom board for fast user friendly test using OpenSDA MSD bootloader (default combined application in Open SDA when you receive the Freedom - Mass Storage Device and serial port).

Demo changes the brightness of red led populated on the board and communicate with FreeMaster visualization tool over embedded virtual serial port of Open SDA connection.

Touch sensing application is controlled by TSS (touch sensing software). For more information about touch sensing and download of TSS go to www.freescale.com/tss

The visualization output has 2 separate scope windows:

one showing signals captured from electrodes of slider
another one showing position of finger on a slider

The operation is really simple:

just drag and drop the attached *.s19 file into your device using MSD bootloader (as other precompiled projects for Freedom board)
open the *.pmp file that is associated with FreeMASTER
choose the correct COM port at speed of 38400 kbps and
start communication

The demo was built with CodeWarrior 10.4 using TSS library 3.0.1 embedded as Processor Expert component. The source code can be provided if there will be an interest.

There is no need to configure MAP file for FreeMaster communication, application uses so called TSA table - it is position independent this way.

If you are not familiar with FreeMASTER or not have it installed in your PC - go to www.freescale.com/freemaster to read more and download the free installer, install it and you are good to run the demo.

There are two independent snapshots below, showing the response to my finger movement along the slider

Enjoy!

and keep in touch

Attachments:

community.element14.com/.../Freedom_5F00_KL25z-_2800_using-TSA-table_2900_.zip
community.element14.com/.../simple_5F00_FMSTR.pmp.zip
community.element14.com/.../Freedom_5F00_KL25z.s19.zip
community.element14.com/.../MSD_2D00_FRDM_2D00_KL25Z_5F00_Pemicro_5F00_v109.zip

Tags: 32bit, touch, cortex-m0+, freescale, freedom_board, Cortex-M, kinetis, cortex, freemaster, frdm-kl25z, kinetis-l, cortex-m0, arm, freedom

Processor Expert Trick & Tips: Switching Processor Package - Simplified in MCU10.4

FreescaleTools_and_Software — Fri, 08 Oct 2021 05:33:00 GMT

Current Revision posted to Documents by FreescaleTools_and_Software on 10/8/2021 5:33:00 AM

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

When I create a new project for the KL05Z with Processor Expert, then it shows up as 48 pin LQFP package in the project:

48pin LQFP Package in Components View

However, when I look at my board, it has a KL05Z32 in a LQFP package with 32 pins:

FRDM-KL05Z Board

Looking at the Processor View, it shows me the package as with 48 pins too:

48pin LQFP Package in Processor View

So how can I change things so Processor Expert is using a different package?

Note: I’m using here the CodeWarrior for MCU10.3 release from December 2013. See the note at the end if you are using a different version of CodeWarrior.

Why do I care about the package? In many cases, different packages contain the same silicon (die), but depending on the package some pins are not bonded to the outside. So it makes sense to select the proper package, so Processor Expert knows what pins and registers are available.

The first place to check if I can switch the package would be in the CPU component properties, but in MCU10.3 I only can check the FLASH size variant (16 KByte or 32 KByte), but not the package:

CPU Type in CPU Properties

The next place would be the list of supported CPUs in the Components Library view:

KL05Z32 in Components Library View

The trick here is: that tooltip actually does not tell everything: there *are* different packages supported beside of the one shown. And here is how to get it:

I double click on the CPU component to add it to my project. This will open a dialog where I can select the package supported, and here it lists all the packages:

Add Processor Component Wizard

Pressing next, and it offers me to select the compiler:

Selecting Compiler

Now here I need to be careful: for the Kinetis-L family, only GNU gcc is supported. So I better select GNU C Compiler here. But if I screwed up, I can change it in the CPU component properties under the ‘Build options’ tab:

Changing Compiler in CPU Properties

Now I have added a KL05Z in 32-pin LQFP package to my project:

KL05Z with 32pin LQFP Package

The other CPU package/variant is still in the project, but disabled. If I want, I can switch between the packaging variants. But usually I remove the ones I’m not using:

Removing Component from Project

I do the same for the orphaned configuration:

Delete Configuration

And if I rename the remaining configuration back to FLASH, I have it nice and clean:

Cleaned up Project

And a last look at the picture in the Processor View shows me that I have now the 32 pin package :

KL05Z with 32 pins in Processor View

Summary

Changing the processor package is important as not every package has all the registers/ports mapped to the outside world. Processor Expert creates you a project with maybe a widely used package, and it is easy to change the package type later in the project (if I know how to do it . Changing or switching packages is important as well if I develop a project which has to be used with different packaging variants.

Update

While writing this article, I had a sneak preview of the upcoming update of MCU10.3. In that update things are changed a lbit to make things easier. For example, the tooltip in the Components Library view shows now all supported packages:

Tooltip showing all packages

And I can switch the CPU package in the CPU properties directly:

Switching Packages in the CPU Type

Update Codewarrior for MCU v10.4

I continue to uncover new things in CodeWarrior in MCU10.4 .

Although that’s not something I need to do on a daily base, this process is simplified in the new version 10.4

Select Package

As a bonus, the Processor View has now a ‘Generate Code’ button too .

The ‘Processor’ view has now a button ‘Select Package’ where I can switch the package:

The Processor view is available from the menu Window > Show View > Other > Processor Expert > Processor.

Available Packages

This then changes me current package to the new one.

Another way is to use the Inspector view on the CPU: here I can change it too:

Selecting CPU Type in Inspector

Now things are easier and easier to find, and changing the microcontroller package is as easy as it should be .

Happy Selecting

Tags: compiler, Processor, expert, freescale, package, kinetis, codewarrior

Getting started with mbed.org and FRDM-KL25Z

bprewit — Fri, 08 Oct 2021 05:31:40 GMT

Current Revision posted to Documents by bprewit on 10/8/2021 5:31:40 AM

I recently came across mbed.org, an online toolchain for ARM parts. The first thing that I noticed was that they claimed to support the Freedom-KL25z, so I thought I would put that to the test.

The setup was not quite as effortless as I expected.

The first step was updating the bootloader by following this procedure:

Update the bootloader firmware from a Windows system. I attempted this from both Linux & Mac without success (this was the most frustrating part)
1. Dowload the firmware updates from PE Micro (here)
2. Unpack the file Pemicro_OpenSDA_Debug_MSD_Update_Apps_2013_01_07.zip to a convenient location.
3. Follow the instructions contained in the BOOTUPDATEAPP_release_notes.txt file.
Create an account on mbed.org
Install the mbed firmware by following this procedure

Once all of that has been completed, you should have a USB disk titled "MBED" available; mount this disk as required for your operating system.

The rest is just plain fun. Using the mbed compiler, The "HelloWorld" application that I created compiled and ran without any changes. Compliing a program from the online compiler results in a downloaded ".bin" file, which is then copied to the USB drive. Hit the reset button on the Freedom board and voila, your program is running!

I tested both the default (gpio) demo and a serial demo. Both compiled exactly as expected, downloaded without problems, and ran immediately.

If you want to do very much, you will probably want to replace the precompiled library with the source library. I had to do this to find out what mbed was calling the pins. The procedure is simple; delete the default "mded" lib and import the source libraries from the mbed SDK (here). You will need to import both the mbed-src lib and the mbed-Freescale lib. The pin names are (surprisingly) in the file "PinNames.h" under "mbed-Freescale/capi/KL25Z",

All in all, I was impressed with the mbed tools; other than the confusion regarding the requirement for the bootloader upgrade to be performed from Windows, getting started with mbed.org was faster than downloading and installing native tools. The library routines worked as expected and the documentation for both the library and compiler are both excellent. In addition, I do not believe that mbed has any code-size restrictions. There are provisions to export your project to several other formats:

I would say that this is a definite "win" ..