What is needed: SW: KDS 3.2 KSDK 2.0 Hercules (Visual Studio 2015)   HW: FRDM-K64F Ethernet Cable   Install KSDK 2.0 Be sure, that you have downloaded correct package KSDK 2.0 for FRDM-K64F, for all procedure please follow instructions mentioned at How to: install KSDK 2.0   Install KDS 3.2 Be sure, that you will work with the newest Kinetis Design Studio v.3.2, please see New Kinetis Design Studio v3.2.0 available for more details.   Import demo example For start with this example we will build on existing demo project, located under C:\Freescale\<ksdk2.0_package>\boards\frdmk64f\demo_apps\lwip\lwip_tcpecho\freertos\kds Please, import this example according to the procedure described at How to: import example in KSDK   Start with programming Let´s start with programming example for LED RGB controlling via ethernet   Checking and parsing incoming packets This packet is divided into header and data. The header represents first two bytes and the remaining three bytes are occupied by data. The zero byte is 0xFF and the first byte must be 0x00. The second byte represents red color, the third byte green color and the last fourth byte presents blue color. lwip_tcpecho_freertos.c Server is listening on port 7 and waiting for a connection from the client. If the client sends 5B, it find out according to header whether it is correct 5B. If so, each RGB parts will be parsed individually and set the LED accordingly.       while (1)     {         /* Grab new connection. */         err = netconn_accept(conn, &newconn);         /* Process the new connection. */         if (err == ERR_OK)         {             struct netbuf *buf;             u8_t *data;             u16_t len;               while ((err = netconn_recv(newconn, &buf)) == ERR_OK)             {                 do                 {                     netbuf_data(buf, &data, &len);                     if(len==5){                         if(data[0]==0xFF && data[1]==0x00){                             if(data[2]>0){                                 LED_RED_ON();                             }else {                                 LED_RED_OFF();                             }                             if(data[3]>0){                                 LED_GREEN_ON();                             }else {                                 LED_GREEN_OFF();                             }                             if(data[4]>0){                                 LED_BLUE_ON();                             }else {                                 LED_BLUE_OFF();                             }                             //err = netconn_write(newconn, "ok", 2, NETCONN_COPY);                         }                     }                 } while (netbuf_next(buf) >= 0);                 netbuf_delete(buf);             }             /* Close connection and discard connection identifier. */             netconn_close(newconn);             netconn_delete(newconn);         }     }   Initializing LEDs   It is needed to set all LEDs in pin_mux.c in BOARD_InitPins() function and initialize in lwip_tcpecho_freertos.c in main() function.   pin_mux.c Go to BOARD_InitPins() and at the end of the function add these lines: Copy and paste to your project     CLOCK_EnableClock(kCLOCK_PortB);     CLOCK_EnableClock(kCLOCK_PortE);     PORT_SetPinMux(PORTB, 21U, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTB, 22U, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTE, 26U, kPORT_MuxAsGpio);   lwip_tcpecho_freertos.c Go to main() and initialize LEDs Copy and paste to your project LED_RED_INIT(LOGIC_LED_OFF); LED_GREEN_INIT(LOGIC_LED_OFF); LED_BLUE_INIT(LOGIC_LED_OFF); Set up connection on PC site Set PC on 192.168.1.100   Controlling the application Hercules For test connection you can use Hercules. After testing don´t forget disconnect Hercules, server can handle only one TCP connection. IP Address of the board is set on 192.168.1.102 It works - the board is green lighting:   Visualization in Visual Studio 2015 For better controlling we will create application in Visual Studio 2015. Start with new project and create new form according this:   And set functionality for all items. Client connects to the IP Address on port 7 and sends our packet according selected colour. For red color are data set on { 0xFF, 0x00, 1, 0, 0 };, for yellow { 0xFF, 0x00, 1, 1, 0 }; etc.   Form1.cs public partial class Form1 : Form     {         Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);          public Form1()         {             InitializeComponent();                      }          private void button1_Click(object sender, EventArgs e)         {             try              {                 s.Connect(IPAddress.Parse(textBox1.Text), 7);                 byte[] data = { 0xFF, 0x00, 0, 0, 0 };                 groupBox1.Enabled = true;                 button1.Enabled = false;                 s.Send(data);                  textBox1.Enabled = false;             }             catch              {                 MessageBox.Show("Connection failed");             }         }          private void button_red_Click(object sender, EventArgs e)         {             if (s.Connected) {                 byte[] data = { 0xFF, 0x00, 1, 0, 0 };                 s.Send(data);             }         }          private void button_green_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 1, 0 };                 s.Send(data);             }         }          private void button_blue_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 0, 1 };                 s.Send(data);             }         }          private void button_black_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 0, 0 };                 s.Send(data);             }         }          private void button_white_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 1, 1 };                 s.Send(data);             }         }          private void button_cyan_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 1, 1 };                 s.Send(data);             }         }          private void button_magenta_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 0, 1 };                 s.Send(data);             }         }          private void button_yellow_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 1, 0 };                 s.Send(data);             }         }     }     Enjoy! 🙂   Iva

The one way how to set TAD shell is to use current example shell for e.g. FRDM-K64F, modified it and use it.   1. Open demo Shell (located at C:\Freescale\KSDK_1.2.0\middleware\tcpip\rtcs\examples\shell\build\kds\shell_frdmk64f) in KDS, as .wsd file 2. Open demo_cmd.c (located at /shell_frdmk64f/Source/demo_cmd.c) and add the line for shell tad, { "echosrv",   Shell_echosrv},     { "echo",      Shell_echo},     { "email",     Shell_smtp },     { "gate",      Shell_gate },     { "gethbn",    Shell_get_host_by_name },     { "getname",   Shell_getname },     { "getrt",     Shell_getroute },     { "ipconfig",  Shell_ipconfig },     { "llmnr",  Shell_llmnrsrv }, { "tad",  Shell_tad },   3. Open tad.c (located at /mqx_frdmk64f/MQX_Generic/tad/tad.c) and remove at the first line:         #if MQX_USE_IO_OLD and last line        #endif // MQX_USE_IO_OLD and included fio library       #include <fio.h>    4. Build libraries first, then build demo shell_frdmk64 5. Set the Tera Term and after typing tad in Tera Term, you will see the output:   Enjoy!   Iva

For this demo, Kinetis SDK was configured to implement a distance meter using a FRDM-K64F and the GP2D12 IR Sensor. The operating principle of this sensor consists in sending IR pulses and according to the existing distance between it and the reflective object, it generates different output voltages. Its analog output varies from 0.4 to 2.6 V approximately; the higher output voltage values are reached when the reflective object is closer to the sensor and the lower ones when it’s farther. The range of distance measured goes from 15 to 100 cm, if the distance from the sensor to the reflective object isn’t between this range, the demo’s results will not be reliable. The following figure depicts the application’s block diagram Figure 1. Block Diagram The signal received from the sensor goes through the Channel_1 at the instance 0 of the ADC module (ADC0_CH1), which is periodically triggered by the low power timer (every 125 µs). After getting every ADC’s sample an average is calculated from a total of 32 samples in order to make the ADC’s value reliable before using it to calculate the current distance. The application’s schematic diagram is shown in the following figure Figure 2. Schematic Diagram The required electrical connections to implement the application are explained below Table 1. Electrical connections   The following figure shows the application’s flow diagram    Figure 3. Flow Diagram   The required configuration for the ADC initialization in the application is shown on the following code snippet static int32_t init_adc(uint32_t uiInstance) {     /*      * Initialization ADC for      * 10bit resolution, interrrupt mode, hw trigger enabled.      * normal convert speed, VREFH/L as reference,      * disable continuous convert mode.      */     ADC16_DRV_StructInitUserConfigDefault(&adcUserConfig);     adcUserConfig.intEnable = true;     adcUserConfig.resolutionMode = kAdcResolutionBitOf10or11;     adcUserConfig.hwTriggerEnable = true;     adcUserConfig.continuousConvEnable = false;     adcUserConfig.clkSrcMode = kAdcClkSrcOfAsynClk;     ADC16_DRV_Init(uiInstance, &adcUserConfig);      /* Install Callback function into ISR. */     ADC_TEST_InstallCallback(uiInstance, CHANNEL_0, MyADCIRQHandler);      adcChnConfig.chnNum = IR_SENSOR_ADC_CHANNEL;     adcChnConfig.diffEnable = false;     adcChnConfig.intEnable = true;     adcChnConfig.chnMux = kAdcChnMuxOfA;     /* Configure channel0. */     ADC16_DRV_ConfigConvChn(uiInstance, CHANNEL_0, &adcChnConfig);      return 0; }             Here is the initialization of the ADC, the interrupt mode is enabled assigning the ‘true’ value to the variable adcUserConfig.intEnable, 10bit resolution is selected by kAdcResolutionBitOf10or11, the hardware trigger is enabled and the continuous conversion disabled with adcUserConfig.hwTriggerEnable and adcUserConfig.continuousConvEnable, respectively. Moreover, the selected clock source is asynchronous, kAdcClkSrcOfAsynClk. After these comes the call to the function ADC16_DRV_Init that receives as parameters the ADC uiInstance being used and a pointer to the structure adcUserConfig that contains the configuration selected by the user. The function ADC_TEST_InstallCallback installs the callback for the interrupt, its parameters are the uiInstance, the CHANNEL_0 from which will be received the interruption trigger and the name of the interruption handler function, MyADC1IRQHandler. The configurations for the ADC reading channel are the selection of the channel number adcChnConfig.chnNum (in this case it is being used the CHANNEL_1), the differential mode is disabled with the variable adcChnConfig.diffEnable, the trigger interrupt is enable at adcChnConfig.intEnable and with adcChnConfig.chnMux the channel multiplexer for a/b channel is selected by kAdcChnMuxOfA. Finally, the call to the function ADC16_DRV_ConfigConvChn receives the uiInstance number, the CHANNEL_0 for receiving the interrupt trigger and a pointer to the structure adcChnConfig that configures the ADC channel. The ADC trigger source initialization is presented below void init_trigger_source(uint32_t uiAdcInstance) {     lptmr_user_config_t lptmrUserConfig =     {         .timerMode = kLptmrTimerModeTimeCounter,         .freeRunningEnable = false,         .prescalerEnable = false, /* bypass prescaler */         .prescalerClockSource = kClockLptmrSrcMcgIrClk, /* use MCGIRCCLK */         .isInterruptEnabled = false     };      /* Init LPTimer driver */     LPTMR_DRV_Init(0, &lptmrUserConfig, &gLPTMRState);      /* Set the LPTimer period */     LPTMR_DRV_SetTimerPeriodUs(0, LPTMR_COMPARE_VALUE);      /* Start the LPTimer */     LPTMR_DRV_Start(0);      /* Configure SIM for ADC hw trigger source selection */     SIM_HAL_SetAdcAlternativeTriggerCmd(gSimBaseAddr[0], uiAdcInstance, true);     SIM_HAL_SetAdcPreTriggerMode(gSimBaseAddr[0], uiAdcInstance, kSimAdcPretrgselA);     SIM_HAL_SetAdcTriggerMode(gSimBaseAddr[0], uiAdcInstance, kSimAdcTrgSelLptimer); }            The user configuration for the LPTMR is located at the structure lptmrUserConfig, here the LPTMR Time Count mode is selected by kLptmrTimerModeTimeCounter, the free running mode, the prescaler and the timer interrupt are disabled with freeRunningEnable, prescalerEnable and isInterruptEnbled, respectively. Furthermore, the LPTMR clock source is selected as the Internal Reference Clock with kClockLptmrSrcMcgIrClk. The function LPTMR_DRV_Init receives as parameter the instance number, a pointer to the structure lptmrUserConfig that contains the user configurations and a pointer to the structure gLPTMRState with internal information of the LPTMR driver. The function LPTMR_DRV_SetTimerPeriodUs set the corresponding timer period for the LPTMR, its parameters are the ADC instance and LPTMR_COMPARE_VALUE that saves the period value in us. The LPTMR_COMPARE_VALUE macro is located and can be set at the lptmr_trigger.c file. Moreover, the user will be able to change this period during the execution time at the Variable Watch section in the FreeMASTER project, modifying the value of LPTMR Interrupt Time (us) and setting the LPTMR Time Flag on 1. LPTMR_DRV_Start starts the LPTMR and its only parameter is the ADC instance.                                           Finally, there are three functions that configure the SIM for the ADC hardware trigger source selection; they receive as parameters the array initializer of SIM peripheral base addresses, gSimBaseAddr[0], and uiAdcInstance. The function SIM_HAL_SetAdcAlternativeTriggerCmd enables/disables the alternative conversion triggers; in this case it receives a true value, so it is enabled. Moreover, SIM_HAL_SetAdcPreTriggerMode selects the pre-trigger source; its third parameter is kSimAdcPretrgselA that corresponds to Pre-trigger A. The last one, SIM_HAL_SetAdcTriggerMode, selects the trigger source, so it’s receiving kSimAdcTrgSelLptimer. The following code snippet shows the implemented algorithm to calculate the distance void GetCurrentDistanceValue(uint32_t uiAvgAdc) {     static uint32_t sdwCurrentDistance = 0;      uint32_t dwm = 0;     uint32_t dwb = 0;      if((520 <= uiAvgAdc) && (uiAvgAdc < 840))     {       dwm = 641;       dwb = 683970;     }     else if((260 <= uiAvgAdc) && (uiAvgAdc < 519))     {       dwm = 1337;       dwb = 1011000;     }     else if((130 <= uiAvgAdc) && (uiAvgAdc < 259))     {       dwm = 2941;       dwb = 1423500;     }     sdwCurrentDistance = (dwb-(dwm*uiAvgAdc));     g_dwDistanceIntegers = (sdwCurrentDistance/10000);     g_dwDistanceTenths = ((sdwCurrentDistance - (g_dwDistanceIntegers*10000))/1000); }            The implemented algorithm to calculate the distance is based on the division of the characteristic curve of the IR Sensor’s behavior in three different sections in order to approximate it to a linear behavior. Each line was generated from two different points. The first line is used when the uiAvgAdc value is between 520 and 840 (15 - 35 cm). The second one, for an uiAvgAdc value higher than 260 and lower than 519 (40 - 65 cm). And the last one, for uiAvgAdc values between 130 and 259 (70 - 100 cm). Depending on the calculated uiAvgAdc value, the slope (dwm) and the intersection with the y axis (dwb) change for each line.   In order to make the demo compatible with different microcontrollers and IDEs, it was necessary to avoid the use of float variables to calculate the distance, so that the result could be printed on a console without problems. The real values of the slopes and intersections with the y-axis for each line were multiplied by 10000. After getting sdwCurrentDistance value it is divided into integers and tenths; to get the integers at g_dwDistanceIntegers, the current distance is divided by 10000 and the corresponding fraction for tenths is stored in g_dwDistanceTenths. As a result, the current distance value is printed combining the integers and tenths variables, avoiding the use of a float variable.        The following graphic shows the characteristic curve and the three lines in which it was divided Figure 4. Characteristic curve’s graphic The application test’s results are shown in the following table 1 The error for the Distance Measured values is approximately ± 0.5 cm 2 The ADC Average values have an error of approximately ± 5 units Table 2. Test’s Results Steps to include IR sensor software to KSDK In order to include this demo in the KSDK structure, the files need to be copied into the correct place. The distance_measure_IRsensor folder should be copied into the <KSDK_install_dir>/demos folder. If the folder is copied to a wrong location, paths in the project and makefiles will be broken. When the copy is complete you should have the following locations as paths in your system: <KSDK_install_dir>/demos/distance_measure_IRsensor/iar <KSDK_install_dir>/demos/distance_measure_IRsensor/kds <KSDK_install_dir>/demos/distance_measure_IRsensor/src In addition, to build and run the demo, it is necessary to download one of the supported Integrated Development Enviroment (IDE) by the demo: Freescale Kinetis Design Studio (KDS) IAR Embedded Workbench      Once the project is opened in one of the supported IDEs, remember to build the KSDK library before building the project, if it was located at the right place no errors should appear, start a debug session and run the demo. The results of the distance measurement will be shown by UART on a console (use 115 200 as Baud rate) and at FreeMASTER, just as in the following example where the reflective object was located at 35 cm from the IR sensor: Figure 5. Example of the distance measured being shown in a console Figure 6. Example of the ADC Values obtained from the IR sensor monitored with FreeMASTER Figure 7. Example of the distance measured results at FreeMASTER FreeMASTER configuration For visualizing the application’s result on FreeMASTER it is necessary to configure the corresponding type of connection for the FRDM-K64F: 1. Open FreeMaster. 2. Go to File/Open Project. 3. Open the Distance Measurement IR Sensor project from <KSDK_install_dir>/demos/distance_measure_IRsensor/ FreeMaster. 4. Go to Project/Options. 5. On the Comm tab, make sure the option ‘Plug-in Module’ is marked and select the corresponding type of connection.    Figure 8. Corresponding configurations FRDM-K64F’s connection at FreeMASTER It is also necessary to select the corresponding MAP file for the IDE in which will be tested the demo, so: 6.  Go to the MAP Files tab. 7.  Select the MAP File for the IAR or the KDS project. *Make sure that the default path matches with the one where is located the MAP file of the demo at your PC. If not, you can modify the path by clicking on the ‘…’ button (see Figure 9) and selecting the correct path to the MAP file: <KSDK_install_dir>/demos/distance_measure_IRsensor/iar/frdmk64f/debug/distance_measure_IRsensor_frdmk64f.out <KSDK_install_dir>/demos/distance_measure_IRsensor/kds/frdmk64f/Debug/distance_measure_IRsensor_frdmk64f.elf 8.  Click on ‘OK’ to save the changes. Figure 9. Selection of the MAP File for each IDE supported by the demo I hope this demo to be useful for your applications, enjoy!

Hi all,   Please find attached document describing how to get started with FreeRTOS and KSDK1.2 using KDS3.0.   For information about creating a new KSDK project with MQX please see the following document. How To: Create a New MQX RTOS for KSDK Project in KDS   Regards, Carlos

Sharing a porting guide for the USB CCID demo from using EMVSIM module on K8x/KL8x to more general UART-ISO7816 module on Kinetis K devices. The demo has been tested with K64 tower board and one internal tower card named as TWR-ISO7816, MK64 is connected directly with smart card connector without using external PHY.   Attached the porting guide and associated demo code based on KSDK2.0.   When running the demo code, you will see console log similar as in attached log file. After installing driver according to the readme file with the USB CCID demo, you will see something as follows in device manager for smart card. Then you can use the PC test tool "Snooper" to talk to smart card.     Hao Original Attachment has been moved to: USB_CCID_MK64.zip Original Attachment has been moved to: USB-CCID-log.txt.zip

Recently one of our customers reported an issue when he tried to run "dspi_edma_demo" with KSDK 1.0 on K22F freedom board. He connected SPI signals between master and slave according to the demo user guide on freedom board, but the demo was not working.   I reproduced the issue on freedom and found this is due to incorrect documentation in demo user guide.   The connection table shown in demo user guide for K22F freedom board is as follows. This is not correct.   It should be the following table instead.  Master Connects to Slave Signal Pin Name Board Location Pin Name Board Location SS PTD0 J6 Pin 8 -> PTD4 J2 Pin 6 SCK PTD1 J6 Pin 5 -> PTD5 J2 Pin 12 Data Out PTD2 J6 Pin 6 -> PTD7 J2 Pin 10 Data In PTD3 J6 Pin7 -> PTD6 J2 Pin 8   Also, the associated pin mux configuration in pin_mux.c file should be changed from the original workaround one in red to the original commented one.   void pin_mux_SPI(uint32_t instance)   {     switch(instance) {       case 0:                             /* SPI0 */         /* PORTD_PCR0 */         PORT_HAL_SetMuxMode(g_portBaseAddr[3],0u,kPortMuxAlt2);         //PORT_HAL_SetMuxMode(g_portBaseAddr[2],4u,kPortMuxAlt2);   /*** Temporary work around until next board spin. ***/         /* PORTD_PCR3 */         PORT_HAL_SetMuxMode(g_portBaseAddr[3],3u,kPortMuxAlt2);         //PORT_HAL_SetMuxMode(g_portBaseAddr[2],5u,kPortMuxAlt2);   /*** Temporary work around until next board spin. ***/         /* PORTD_PCR1 */         PORT_HAL_SetMuxMode(g_portBaseAddr[3],1u,kPortMuxAlt2);         //PORT_HAL_SetMuxMode(g_portBaseAddr[2],6u,kPortMuxAlt2);   /*** Temporary work around until next board spin. ***/         /* PORTD_PCR2 */         PORT_HAL_SetMuxMode(g_portBaseAddr[3],2u,kPortMuxAlt2);         //PORT_HAL_SetMuxMode(g_portBaseAddr[2],7u,kPortMuxAlt2);   /*** Temporary work around until next board spin. ***/         break;   }   }  

The SAR-ADC of KM family supports using 4 triggering signals to trigger SAR-ADC, for the KM sub-family with PDB, it is okay to use PDB. But for the KM family without PDB module, it is difficult to generate  4 triggering signals to trigger SAR-ADC. The DOC introduce how to use quadTimer to generate 4 sequential triggering signals to trigger SAR-ADC so taht the SAR-ADC can get 4 samples in one conversion.

Kinetis SDK v2 is here! Introducing Kinetis SDK v2 The first steps with KSDK How to start with KSDK* List of published examples: KSDK list of examples* List of published documents: KSDK list of documents* * All of the source code placed in spaces above is for example use only. NXP does not accept liability for use of this code in the user’s application.

This example project shows how to use CMSIS DSP functions to implement a digital filter. The project is based on Kinetis KV31F512.   It first generates a mixed signal which is composed by two sine waves.  Then it uses PDB to trigger DAC every 200 microsecond and output the signal through DAC, so that the mixed signal can be displaying on oscilloscope.   With QEDesign tool, a lowpass filter is designed, the filter coefficients are used directly to initialize the FIR function supplied by CMSIS DSP library. This example calls the FIR functions in CMSIS DSP lib, and the filtered signal is output though DAC module.

Documentation for current KSDK 1.3 is located under C:\Freescale\KSDK_1.3.0\doc Application Notes and another documents are located under Software Development Kit for Kinetis MCUs|NXP   There are more documents, which were created:   KSDK 2.0 How to: install KSDK 2.0 Introducing Kinetis SDK v2 Using Kinetis Design Studio v3.x with Kinetis SDK v2.0   KSDK 1.3 How to add SD card support in the composite msd_cdc demo[KSDK 1.3] KSDK Clock configurations and Low Power modes with Processor Expert New Kinetis SDK Project Generator v2 is available! KSDK Project Generator - BUG workaround KSDK 1.3 Documents Plugin in KDS - is available now! KSDK 1.3.0 Documents Plugin for KDS 3.0.0   KSDK 1.2 Interrupt handling with KSDK and Kinetis Design Studio Creating a New USB project with KSDK and Processor Expert support in KDS IAR MQX TAD solution for "Unknown error" in Task error code (with KSDK) How to Add lwIP to KDS3.0 Project How to: Create a New FreeRTOS for KSDK1.2 Project in KDS3.0 How to Create a C++ Project Using MQX RTOS for KSDK1.2 How to implement a USB Device MSD demo based on KSDK PEx components and KDS 3.0 How to: execute the demo HVAC on lwIP TCP/IP Stack in KSDK Kinetis SDK FAQ Adding TAD shell in KSDK shell demo FRDM-KL43Z and KL33Z - standalone package New KSDK 1.2. is available! Getting started with KSDK: Building the demo applications   KSDK 1.1 KSDK 1.1 Release How to create copy of KSDK example in KDS UART Example with KSDK   KSDK 1.0 Create new KSDK Projects Kinetis SDK and FRDM-K64F Sharing one documentation issue in KSDK 1.0 demo user guide

Download from Software Development Kit for Kinetis MCUs|NXP   How to: install KSDK 2.0 Using Kinetis Design Studio v3.x with Kinetis SDK v2.0   Kinetis SDK 2.0 API Reference Manual: Introduction   For older versions KSDK, KDS: Kinetis Design Studio Videos, Part 1: Installation of KDS and Kinetis SDK Kinetis Design Studio Videos, Part 2: Installation of OpenSDA Firmware on Freedom Board Kinetis Design Studio Videos, Part 3: Debugging with Kinetis Design Studio Kinetis Design Studio Videos, Part 4: Using Processor Expert in KDS   Installing Kinetis SDK into KDS Kinetis Design Studio V3.0.0- User´s Guide   other documentations you can download from Software Development Kit for Kinetis MCUs|NXP

This document includes two chapters , chapter 1 is about how to use printf() to print string in KSDK1.3 project , the usage in project without MQX has been introduced on another document, you can find it here : https://community.freescale.com/docs/DOC-104349 , so in this DOC I only introduce how to use the printf() in KSDK MQX- Lite and KSDK MQX-Standard project .   Chapter 2 introduces how to check which UART port is used when use printf() to print string on the FRDM board and TOWER board .   In sum, only the project of “MQX standard” use it own driver for printf(), so we need delete the driver “fsl_debug_console”. In other SDK+PE projects , they all use the driver of “fsl_debug_console” for printf().

Problem: Unknown error in Task error code column (in Task List view from MQX TAD) is displayed when debugging MQX project in IAR with KSDK.   Cause: This error means that TAD cannot find mqx.tad file with messages for error codes. In this case code 0x0 means MQX_OK, so it might lead user to believe there is some error with task but it is not. IAR TAD was made before first KSDK release, so there is no way for IAR TAD to find mqx.tad file because it isn’t part of KSDK. It works only when classic MQX is also installed on computer.   IAR TAD finds mqx.tad file this way (written as example for MQX 4.2): It takes _mqx_version_number defined as hex number 0x04020000 in “mqx\source\kernel\mqx.c” Looks into windows registry key of specified MQX version “HKEY_LOCAL_MACHINE\SOFTWARE\Freescale\FreeScale MQX\4.2” Takes its path variable "PATH"="C:\\Freescale\\Freescale_MQX_4_2" Tries to find mqx.tad file in directory specified in PATH or in its child folder "\tools\tad\" (e.g. C:\Freescale\Freescale_MQX_4_2\tools\tad\mqx.tad)   Solution: Use of fake registry key, which will point to classic MQX installation or some blank directory with only mqx.tad file (e.g. C:\fake_mqx\mqx.tad or better C:\Freescale\KSDK_1.2.0\tools\tad\mqx.tad). This registry key must use MQX version specified in used KSDK (for KSDK 1.2 and 1.3 it is 0x05000200, for 1.1 0x05000001 and for 1.0 0x04010000). Registry key might look like this: Then TAD translates error codes to messages successfully and path to mqx.tad file can be checked in Check for errors view under Show MQX TAD Diagnostics. Attached is example registry key with \tad\mqx.tad structure for placing into KSDK\tools directory.

Hello community,   This document is the continuation of the document Line scan camera with KSDK [ADC + PIT + GPIO] which shows the ease of use of the peripheral drivers from Kinetis SDK applied to the Freescale Cup smart car. This time I bring to you a document which explains how to control the speed in DC motors and the position in servomotors with KSDK step-by-step. This document is intended to be an example for the TPM and the GPIO peripheral drivers usage.   The required material to run this project is: A Servomotor (the project supports up to two servomotors, one servomotor is included in the smart car kit). Two DC motors (included in the smart car kit). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable.   This material can be bought in The Freescale Cup Intelligent Car Development.         The document Create a new KSDK 1.2.0 project in KDS 3.0.0 explains how to create a new KSDK project for the KL25Z MCU. The result of this document is the project BM-KSDK-FRDM_KL25Z. The document Controlling speed in DC motors and position in servomotors with the FRDM-KL25Z and the Kinetis SDK [FTM + GPIO] explains how to implement an application to control the motors. The result of this document is the project BM-KSDK-FRDM_KL25Z_LINE_SCAN_CAMERA-SERVO-DC_MOTORS.   If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The Freescale Cup Technical Reports TFC - Mexico, TFC - Brazil, TFC - China, TFC - Malaysia, TFC - Japan, TFC - North America, TFC - India, TFC - Taiwan, The Freescale Cup EMEA.   Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor

There was a macro definition issue in the flexcan driver of ksdk 2.0, the macros of RX_FIFO_STD_MASK_TYPE_B/C were defined based on maco FLEXCAN_ID_STD(id), for example: #define FLEXCAN_RX_FIFO_STD_MASK_TYPE_B_HIGH(id, rtr, ide) \ (((uint32_t)((uint32_t)(rtr) << 31) | (uint32_t)((uint32_t)(ide) << 30)) | \ (FLEXCAN_ID_STD(id) << 16)) /**< Standard Rx FIFO Mask helper macro Type B upper part helper macro. */ but FLEXCAN_ID_STD(id) is defined for flexCAN Message Buffer structure, so FLEXCAN_ID_STD(id)  is a value of "id" left-shifted by 18,  according to the spec. while for RX FIFO ID table structure, the spec of Type B/C is different. so we should use the value of id directly to define the type B and type C Rx Frame Identifier. For example, #define FLEXCAN_RX_FIFO_STD_MASK_TYPE_B_HIGH(id, rtr, ide) \ (((uint32_t)((uint32_t)(rtr) << 31) | (uint32_t)((uint32_t)(ide) << 30)) | \ ((id & 0x7FF) << 19)) /**< Standard Rx FIFO Mask helper macro Type B upper part helper macro. */   This patch doesn't affect FlexCAN operation related with message buffers , neither with RX FIFO A type ID table.   Please kindly refer to the attachment for details.   Sorry for the inconvenience that has caused.   -Kan

Hello community,   This document is the continuation of the documents Line scan camera with KSDK [ADC + PIT + GPIO] and Controlling speed in DC motors and position in servomotors with KSDK [FTM + GPIO] which show the ease of use of the peripheral drivers from Kinetis SDK applied to the Freescale Cup smart car. This time I bring to you a document which explains an easy way to detect the track's line from the data acquired with the linear camera.   The required material to run this project is: A Servomotor (the project supports up to two servomotors, one servomotor is included in the smart car kit). Two DC motors (included in the smart car kit). Line scan camera (the project supports up to two cameras). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable.   This material can be bought in The Freescale Cup Intelligent Car Development.         If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The Freescale Cup Technical Reports TFC - Mexico, TFC - Brazil, TFC - China, TFC - Malaysia, TFC - Japan, TFC - North America, TFC - India, TFC - Taiwan, The Freescale Cup EMEA.   Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor

Hi all,   there is a simple modification of ftm driver example based on KSDK 1.3, KDS 3.0 on FRDM-K22F.   enabling clocks for PORTs in hardware_init.c   void hardware_init(void) {    /* enable clock for PORTs */   CLOCK_SYS_EnablePortClock(PORTA_IDX);   CLOCK_SYS_EnablePortClock(PORTD_IDX);   CLOCK_SYS_EnablePortClock(PORTE_IDX);    PORT_HAL_SetMuxMode(PORTA,1u,kPortMuxAlt3);//red   PORT_HAL_SetMuxMode(PORTA,2u,kPortMuxAlt3);//green   PORT_HAL_SetMuxMode(PORTD,5u,kPortMuxAlt4);//blue    /* Init board clock */   BOARD_ClockInit();   dbg_uart_init(); } function for converting HSV to RGB color palette downloaded from hsv2rgb.cpp - shiftpwm - Arduino library to PWM many outputs with chained shift registers. - Google Project Hosting   setting ftm parameters for red, green and blue color, for red color: ftm_pwm_param_t ftmParamR = {         .mode                   = kFtmEdgeAlignedPWM,         .edgeMode               = kFtmLowTrue,         .uFrequencyHZ           = 24000u,         .uDutyCyclePercent      = 0,         .uFirstEdgeDelayPercent = 0,     };   setting PWM output for each color in infinite loop         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamR, 6);         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamG, 7);         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamB, 5);   forwarding parameters to hsv2rgb() hsv2rgb(hue,255,255,&red,&green,&blue,255);   changing hue and checking overflow of hue         hue++;         if(hue>=360)hue=0;   normalizing from 0-255 to 0-100 percent of PWM pulse width for each color         ftmParamR.uDutyCyclePercent = (uint8_t)(((float)red/255.0)*100.0);         ftmParamG.uDutyCyclePercent = (uint8_t)(((float)green/255.0)*100.0);         ftmParamB.uDutyCyclePercent = (uint8_t)(((float)blue/255.0)*100.0);   That´s all!   Importing example extract ftm_rainbow.zip to C:\Freescale\KSDK_1.3.0\examples\frdmk22f\driver_examples Go to KDS, import file and choose .wsd file After then don´t forget compile library first and then project.     I hope you will enjoy the demo 🙂   Iva

Kinetis SDK 1.1.0 is now officially released! You can download it via the big "Download" button on the KSDK website at http://freescale.com/ksdk   There are Windows and Linux 32-bit and 64-bit installers available. KSDK 1.1 will install in a new directory, which by default is C:\Freescale\KSDK_1.1.0, and will not interfere with previous installations of KSDK except to (optionally) update the Windows KSDK_PATH variable used by Kinetis Design Studio.   A high-level overview of what's new in KSDK 1.1 can be found in the Kinetis SDK 1.1 Release Notes but the most significant changes are: Additional devices supported Atollic TRUEStudio 5.2 is now supported Driver, HAL, and Platform Updates   There were also some other notable changes: GCC Make System Directory layout CMSIS-DAP/OpenOCD debug configurations now provided by default for KDS MQX for KSDK now included as option in the KSDK installer MQX Kernel 5.0.1 now supports lightweight configuration option   Details: 1)      Additional Devices The following devices are supported by Kinetis SDK 1.1 FRDM-K22F FRDM-K22F-K02* FRDM-K22F-K02 64* FRDM-K64F FRDM-KL03Z FRDM-KL46Z TWR-K22F120M TWR-K22F120M-K02* TWR-K24F120M TWR-K60D100M TWR-K64F120M TWR-KV10Z75M TWR-KV31F120M TWR-KV31F120M-KV30*   *These boards do not physically exist, but you can use the associated board to develop code for the subset devices listed. So for instance, if you're interested in the K02 device, use the FRDM-K22F for evaluation but use the K02 libraries provided to write code which will run on the K22F since it is a superset device.   2)      Atollic TRUEStudio 5.2 support   3)      Driver, HAL, and Platform Updates The HAL, Driver, and Platform code was updated with additional features, bug fixes, and enhancements. Several new peripherals are also supported which are listed in the Kinetis SDK 1.1 Release Notes. The Kinetis SDK v.1.1 API Reference Manual.pdf contains the latest KSDK API, and look at the updated demo projects for how to use the updated features like the power manager. There is now also the option to copy or not copy the vector table from ROM to RAM based on the linker file configuration using the ‘__ram_vector_table__’  argument in your IDE linker settings.   4)      GCC Make Changes Compiling with GCC now uses CMAKE.  Details on how to setup your system for compiling with GCC can be found in the GCC section of the <KSDK_path>/doc/Getting Started with Kinetis SDK (KSDK).pdf document. If you have "C:\MinGW\msys\x.x\bin" in your PATH variable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly.   5)      Directory Layout The HAL, Driver, and platform directory layout was slightly changed so that all the include files are now in a single directory instead of separate directories. This makes it simpler to add the include path into projects, and can also improve library compile times (by up to 50%). The KSDK platform library has also been slightly renamed to libksdk_platform.a   6)      CMSIS-DAP Debug Configuration OpenOCD debug configurations in Kinetis Design Studio are now provided by default for boards that use OpenSDAv2. OpenOCD makes use of the CMSIS-DAP debug protocol.   7)      MQX for KSDK Installer The Kinetis SDK 1.1 installer now includes options to install full MQX for KSDK support. The installation screen has also made it clearer during installation on how to select this option. There will no longer be a separate MQX for KSDK installer like there was for KSDK 1.0.   😎      MQX 5.0.1 Kernel Support of MQX Lite configuration and new example application rtos/mqx/examples/. There are provided options for creating tasks from statically allocated memory and application can define these tasks before MQX RTOS starts (using create_task() API). More changes are detailed in the MQX Release Notes in <KSDK_Path>/rtos/mqx/doc/Freescale MQX RTOS for Kinetis SDK Release Notes.pdf   This is just a high level overview of the changes, and should make developing applications using Kinetis SDK easier than ever.

The USB stack in ksdk 1.3 has provided a macro of “USBCFG_DEV_ADVANCED_SUSPEND_RESUME” , while the RM says “suspend/resume is not implemented yet.”, but if you looks into the source code, you may find APIs like USB_Suspend_Service() which is reserved for further implementation, so users may use these APIs as a starting point to add suspend and resume feature in ksdk 1.3. The test is based on FRDM-KL27Z, dev_hid_mouse_bm demo. And before we modify the device stack, we have to clone a copy of this demo. Set USBCFG_DEV_ADVANCED_SUSPEND_RESUME to 1 to releases APIs related with suspend and resume features. But we will have the following errors after compile, that is because remote resume function is not supported by KL27. so we should disable it for this device, with the help of #if USBCFG_DEV_ADVANCED_SUSPEND_RESUME == 1 && FSL_FEATURE_USB_KHCI_HOST_ENABLED == 1. For example, like below: 2.Further implement USB_Suspend_Service() and USB_Resume_Service() to let them notify the upper layer application on the event of suspend/resume. With reference of USB_Error_Service() and Don’t forget to add two more events for suspend and resume. 3.USB module has two types of resume interrupt , one is sync resume , issued by the bit of ISTAT[RESUME] bit, the other is async resume, issued by the bit of TRC0[USB_RESUME_INT], so we have to monitor these two interrupt status flag in the ISR, as below: And so we have modify the resume and sleep interrupt services for supporting the async resume interrupt as below: 4.Modify application and add code to handle suspend and resume event, in this case, such kind of events are handled in USB_App_Device_Callback() 5.Verify the hid_mouse demo with USB 2 CV tool from usb.org Select the FS device with VID 15a2 from the list. Test passed! if you print some messages on the event of suspend and resume, you will see something like below from the Terminal channel. 6. Now we can add low power mode switch function in the main application code to meet the suspend current limitation specified by USB spec, with reference of power_manager_hal_demo for frdmkl27z, and for this case, add code in USB_App_Device_Callback() of mouse.c to tell the main application when to enter low power mode. Please also note Don’t enter low power mode in this callback function, as it is called by the interrupt service, so if the device enter low power mode during interrupt, that would prevent the following resume interrupt happen, so the device never wake up! For more details on the implementation, please refer to the attached mouse.c 7.Test low power mode current:   Before test, please do the following modification to the FRDM-KL27Z board: Please note, if your board has the following jumpers, no need to remove R7,R21 and R83, just keep J19 and J22 open during the test. Select the low power mode you are going to test from the Ternimal: Leave KL27 USB port (J10) open and power the board with USB SDA port, that would make the device enter suspend interrupt out of reset. And you may also see the current vary with power mode switch with the help of USB 2 CV tool. I have tested wait, stop and vlps modes, the current measured under these modes are shown as below: Wait: Stop: VLPS: So it is recommend using VLPS mode during USB suspend mode as it far below the suspend current specified in USB spec (500uA). 8. Patch and demo code Please replace the following files with the attached one, as well as the mouse.c in dev_hid_mouse_bm demo. Recompile the stack and application code. C:\Freescale\KSDK_1.3.0\usb\usb_core\device\include\MKL27Z644 usb_device_config.h C:\Freescale\KSDK_1.3.0\usb\usb_core\device\sources\controller usb_dev.h usb_dev.c usb_framework.c C:\Freescale\KSDK_1.3.0\usb\usb_core\device\sources\controller\khci device_khci_interface.c khci_dev.c khci_dev.h C:\Freescale\KSDK_1.3.0\usb\usb_core\device\include usb_device_stack_interface.h C:\Freescale\KSDK_1.3.0\examples\frdmkl27z\demo_apps\usb\device\hid\hid_mouse mouse.c