This video shows how to use Processor Expert to configure the KSDK GPIO Peripheral Driver with the component fsl_gpio in Kinetis Design Studio. The steps show how to blink the red and blue LEDs while reading the SW2 button input of a FRDM-K64F. The procedure can be replicated for any KSDK supported board and also with PE Driver Suite. Enjoy!

This solution is just for you, who does not enjoy finding documentation for KSDK does not enjoy many opened windows (all in one) often ask where is the documentation for KSDK like an overview will appreciate embedded help   For detailed information please see KSDK 1.3.0 Documents Plugin for KDS 3.0.0   I hope you will really invite this tool. Iva

This video shall guide you on how to build and run the demo applications provided by Kinetis SDK.   Overview: Classes of software examples Importing and building library file project Importing, building and running a demo application   Software/Tools used: Kinetis Design Studio V3.0.0 Kinetis SDK V1.2.0 FRDM-K64F Board   Related Documents: Getting Started with Kinetis SDK v.1.2 - http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12GSUG.pdf Kinetis SDK v.1.2 Demo Applications User’s Guide - http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12DEMOUG.pdf Kinetis SDK FAQ - https://community.freescale.com/docs/DOC-102926   Related videos: Installation of KDS and Kinetis SDK - https://community.freescale.com/videos/3281 Installation of OpenSDA Firmware on Freedom Board - https://community.freescale.com/videos/3282 Debugging with Kinetis Design Studio - https://community.freescale.com/videos/3283 Using Processor Expert in KDS - https://community.freescale.com/videos/3297 KSDK GPIO driver with Processor Expert - https://community.freescale.com/videos/3195

For this demo, KSDK was configured to measure distance with a FRDM-K64F and the 255-400Sx16-ROX ultrasonic transducers. The transmitter transducer sends an ultrasound’s signal that travels through the air, after clashing with any object, the signal bounces and starts its way back until it gets to the receiver transducer. The time it takes for the ultrasound to arrive to the receiver can be use to measure the distance from the transducers to the object, because for a larger distance, the ultrasound’s travel time will be longer. When the receiver gets the ultrasound it generates an output signal, whose intensity is related to the distance to the reflective object, the signal is more intense for closer distances. The demo works for a range from 15 to 100 cm, if the distance to reflective object isn’t between this range, the results shown wouldn’t be reliable. The following figure shows the application’s block diagram Figure 1. Block Diagram        The schematic diagram for the application is shown in the following figure Figure 2. Schematic Diagram        The electrical connections needed to implement the demo are presented by this table Table 1. Electrical connections        The application’s flow diagram is displayed by the following figure Figure 3. Flow Diagram for Distance’s Calculation        The initial configuration for the FTM0 is presented in the following code snippet   void vfnFTM0_Config(void) {     ftm_user_config_t ftm0Info;          configure_ftm_pins(FTM_INSTANCE_0);          FTM_DRV_Init(FTM_INSTANCE_0, &ftm0Info);     FTM_DRV_SetTimeOverflowIntCmd(FTM_INSTANCE_0, true);     FTM_HAL_SetTofFreq(g_ftmBaseAddr[FTM_INSTANCE_0], TOF_FREQ_VALUE);          FTM_DRV_PwmStart(FTM_INSTANCE_0, &highTrueParam, HIGH_TRUE_PWM_CH);     FTM_DRV_PwmStart(FTM_INSTANCE_0, &lowTrueParam, LOW_TRUE_PWM_CH);     bPwmOnFlag = 1; }   The FTM0 was configured to generate two different signals of PWM that complement each other in order to duplicate their voltage’s range. First of all, it was necessary to configure the FTM0’s pins of the board, so that the PWM signals could be used externally to feed the ultrasonic Tx transducer. Then the FTM driver was initialized, the timer overflow interrupt was enabled and the NUMTOF was set to 14 so that just 15 PWM pulses were generated each time. Finally, the PWM was started at FTM0, generating a high true signal for channel 0 and low true for channel 1, these configurations were set from the structures highTrueParam and lowTrueParam of type ftm_pwm_param_t, in which the signals are configured as edge aligned, frequency of 40 kHz and the duty cycle is set to 50%.        The FTM0 IRQ Handler function was modified to match with the demo requirements   void FTM0_DRV_MyIRQHandler(void) {     FTM_DRV_IRQHandler(0U);     bDeadTimeCount++;     if(bPwmOnFlag)     {         FTM0_OUTMASK ^= PWM_CHANNELS_OUTMASK;         swPWMDeparture_CountVal = FTM2_CNT;         FTM_HAL_SetSoftwareTriggerCmd(g_ftmBaseAddr[0], true);         bPwmOnFlag = 0;     }     else if((!bPwmOnFlag) && (bDeadTimeCount == 50))     {         vfnStartPwm();         bDeadTimeCount = 0;     } }   After every 15 FTM0’s overflows this function was accessed and every 50 access to it determined the PWM dead time, which refers to the time between the sending of a PWM signal and the next one. The PWM dead time is necessary to avoid the clash of a signal being transmitted by the Tx transducer and the one that is returning to enter to the Rx, this clash could affect the genuine signal that bounced against the reflective object and also affect the distance measure’s results. If the PWM signals were active when entering to this function, then they should be disabled with the FTM0 outmask, this would assure that the sending pulses are just 15 and it would be harder that the returning bounced signal clashes with a prolonged sending signal. After disabling the PWM bPWMOnFlag is set to 0. On the other hand, if the bPWMOnFlag is disabled and the bDeadTimeCount has achieved the corresponding counts, the PWM is restarted and the bDeadTimeCount is set to 0.   The FTM2’s initial configurations are stated on the following code snippet void vfnFTM2_Config(void) {     ftm_user_config_t ftm2Info;          configure_ftm_pins(FTM_INSTANCE_2);     FTM_DRV_Init(FTM_INSTANCE_2, &ftm2Info);     FTM_HAL_SetClockPs(g_ftmBaseAddr[FTM_INSTANCE_2], kFtmDividedBy16);     FTM_DRV_SetTimeOverflowIntCmd(FTM_INSTANCE_2, true);          vfnInputCaptureStart(); }   For the FTM2, which was used for input capture mode, in this function were configured their pins, the driver was initialized, the clock prescaler was set to 16 and the timer overflow interrupt was enabled before calling to the function vfnInputCaptureStart(), in which are established more specific configurations for the input capture.   The FTM2 IRQHandler was also modified to trigger the required actions for the demo’s functionality void FTM2_DRV_MyIRQHandler(void) {     if ((FTM2_SC & 0x80))     {         bFtm2OverflowCount++;         FTM_HAL_ClearTimerOverflow(g_ftmBaseAddr[2]);     }     else     {         FTM_HAL_DisableTimerOverflowInt (g_ftmBaseAddr[2]);         CMP_DRV_Stop(1);         vfnGetPwmArriveTime();         vfnGetPwmTravelTime();         FTM_HAL_ClearChnEventStatus(g_ftmBaseAddr[2], 0);         bFtm2OverflowCount = 0;     } }   This function is accessed whether a timer overflow occurs or if a rising edge is detected by the input capture. If an overflow occurred then the overflow bit is clear and bFtm2OverflowCount’s value is increased by 1, this count is important for the signal’s travel time calculation. On the contrary, if the IRQ handler function is accessed because of the detection of a rising edge by the input capture, the timer overflow interrupt is disabled to avoid the count of time after the edge detection and to assure the correct travel time calculation. After storing the FTM2 count value as the arrive time of the signal, the function vfnGetPwmTravelTime() is called to calculate the total period of time that the signal spent on its travel through the air. Additionally the bFtm2OverflowCount is set to 0.        The comparator’s configurations are displayed on this function   void vfnCMP1_Config(void) {     cmp_user_config_t cmpParam =      {           .hystersisMode = kCmpHystersisOfLevel0, /*!< Set the hysteresis level. */           .pinoutEnable = true, /*!< Enable outputting the CMP1 to pin. */           .pinoutUnfilteredEnable = false, /*!< Disable outputting unfiltered result to CMP1. */           .invertEnable = false, /*!< Disable inverting the comparator's result. */           .highSpeedEnable = false, /*!< Disable working in speed mode. */       #if FSL_FEATURE_CMP_HAS_DMA           .dmaEnable = true, /*!< Enable using DMA. */       #endif /* FSL_FEATURE_CMP_HAS_DMA */           .risingIntEnable = true, /*!< Enable using CMP1 rising interrupt. */           .fallingIntEnable = false, /*!< Disable using CMP1 falling interrupt. */           .plusChnMux = kCmpInputChn1, /*!< Set the Plus side input to comparator. */           .minusChnMux = kCmpInputChn3, /*!< Set the Minus side input to comparator. */       #if FSL_FEATURE_CMP_HAS_TRIGGER_MODE           .triggerEnable = true, /*!< Enable triggering mode.  */       #endif /* FSL_FEATURE_CMP_HAS_TRIGGER_MODE */       #if FSL_FEATURE_CMP_HAS_PASS_THROUGH_MODE           .passThroughEnable = true  /*!< Enable using pass through mode. */       #endif /* FSL_FEATURE_CMP_HAS_PASS_THROUGH_MODE */     };          cmp_sample_filter_config_t cmpFilterParam =     {         .workMode = kCmpSampleWithFilteredMode, /*!< Sample/Filter's work mode. */         .useExtSampleOrWindow = false, /*!< Switcher to use external WINDOW/SAMPLE signal. */         .filterClkDiv = 32, /*!< Filter's prescaler which divides from the bus clock.  */         .filterCount =  kCmpFilterCountSampleOf7 /*!< Sample count for filter. See "cmp_filter_counter_mode_t". */     };       cmp_state_t cmpState;     configure_cmp_pins(CMP_INSTANCE_1);     CMP_DRV_Init(CMP_INSTANCE_1, &cmpParam, &cmpState);     CMP_DRV_ConfigSampleFilter(CMP_INSTANCE_1, &cmpFilterParam);     CMP_DRV_Start(CMP_INSTANCE_1); }   The initial configuration’s parameters for the comparator are stated on the structure cmpParam. First of all, the CMP1 input and output was enabled, the rising interrupt was enabled too. In addition, channel 1 was set as the plus side input of the comparator; this channel is the one that receives the output of the ultrasonic Rx transducer. On the other hand, channel 3 was configured as the minus side input of the comparator, this channel corresponds to the 12-bit DAC module that sets the comparison value. Finally, the trigger and the pass through mode were enabled. It was necessary to stabilize the comparators results, so a sample filter was configured in sample with filter mode, the filter’s prescaler for clock was set to 32 and the filter count sample was set to 7 samples.   After establishing all these parameters, the comparator’s pins were configured, the driver was initialized, the filter was configured to the CMP1 and the driver was started.        The 12-bit DAC was configured to generate the comparison value, as shown in this code snippet   void vfnDAC12_Config(void) {     dac_user_config_t dacParam;          // Set configuration for basic operation     DAC_DRV_StructInitUserConfigNormal(&dacParam);     // Initialize DAC with basic configuration     DAC_DRV_Init(DAC_INSTANCE_0, &dacParam);     // Set DAC's Comparison Value     DAC_DRV_Output(DAC_INSTANCE_0, CMP_DAC_VALUE); }        The DAC’s configuration was simple, the default configurations were used for this one, the driver was initialized and the comparison value was set to 4020. This value was selected according to the Rx transducer’s output signal, the comparison value was determined by the levels achieved, so that the demo could be able to detect a reflective object in all the distance’s range (15 to 100 cm).        The initialization for input capture mode are shown in this function   void vfnInputCaptureStart(void) {     FTM_HAL_SetChnEdgeLevel(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH, INPUT_CAPTURE_RISING_EDGE);     FTM_HAL_SetMod(g_ftmBaseAddr[FTM_INSTANCE_2], FTM2_MOD_VALUE);     FTM_HAL_EnableChnInt(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH);     FTM_HAL_SetChnInputCaptureFilter(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH, INPUT_CAPTURE_FILTER_VAL);     FTM_HAL_SetCountReinitSyncCmd(g_ftmBaseAddr[FTM_INSTANCE_2], true);     FTM_HAL_SetCounterInitVal(g_ftmBaseAddr[FTM_INSTANCE_2], FTM2_COUNTER_INIT_VALUE);     FTM_HAL_SetClockSource(g_ftmBaseAddr[FTM_INSTANCE_2], kClock_source_FTM_SystemClk); }        The input capture’s configurations for the demo were: rising edge mode, the MOD value was set to its maximum (0xFFFF), the FMT2_CH0’s interrupt was enabled, the filter on the input was enabled to help in the stabilization of the signal being analyzed, the counter’s init value is set to 0 and finally, the system clock is selected as the clock source.        The function vfnStartPwm is the one that enables the PWM sending   void vfnStartPwm(void) {     FTM2_CNT = FTM2_COUNTER_INIT_VALUE;     FTM0_OUTMASK ^= PWM_CHANNELS_OUTMASK;     bPwmOnFlag = 1;     FTM_HAL_SetSoftwareTriggerCmd(g_ftmBaseAddr[FTM_INSTANCE_0], true);     FTM_HAL_EnableTimerOverflowInt (g_ftmBaseAddr[FTM_INSTANCE_2]);     CMP_DRV_Start(CMP_INSTANCE_1); }        Before enabling the PWM signals, the FTM2 count value is stored as the sending time of the signal, then the FTM0 outmask de PWM channels, the bPWMOnFlag is set to 1 and the comparator driver is start in order to wait the Rx transducer’s response.        The signal’s travel time calculation algorithm is presented in the following code snippet   void vfnGetPwmTravelTime(void) {     uint32_t wTimeDifference = 0;     static uint8_t bAux_OFCount = 0;     static uint32_t waTimeBuffer[TIME_SAMPLES];     static uint8_t bTimeSamples = 0;          bAux_OFCount = (bFtm2OverflowCount-1);          if(bFtm2OverflowCount != 0)     {         if(bAux_OFCount != 0)         {             wTimeDifference = (FTM2_MOD_VALUE * bAux_OFCount);         }         else         {             wTimeDifference = 0;         }         wTimeDifference = (wTimeDifference + (FTM2_MOD_VALUE - swPWMDeparture_CountVal));         wTimeDifference = (wTimeDifference + swPWMArrive_CountVal);     }     else     {         wTimeDifference = (swPWMArrive_CountVal - swPWMDeparture_CountVal);     }          waTimeBuffer[bTimeSamples] = wTimeDifference;     if(bTimeSamples != TIME_SAMPLES)     {         bTimeSamples++;     }     else     {         wAverageTravelTime = dwGetTravelTimeAverage(TIME_SAMPLES, waTimeBuffer);         vfnGetCurrentDistance();         bTimeSamples = 0;     } }   The travel time’s calculation algorithm is simple. If just one overflow occurred during the signal’s traveling period, the time difference is calculated as the difference of the FTM2_MOD_VALUE and the FTM2 counter value at the departure time, plus the counter value at the arriving time. Otherwise, if more than one overflow occurred then the time difference is the same as the last case, but adding the product of the FTM2_MOD_VALUE and the overflow’s counts minus 1. The simplest case is the one there haven’t been overflows, the time difference is calculated subtracting the departure counter value from the arriving counter value. After obtaining 20 samples of travel time an average of all these values is calculated so that the time data is the most reliable possible.   The distance calculation algorithm was implemented on the following function   void vfnGetCurrentDistance(void) {     static uint64_t dwDistance = 0;     uint8_t b_m = 3;     uint32_t w_b = 27130000;     uint32_t w_FixedPointAux = 100000;     uint16_t swTimeBase = 265;          // 265ns per FTM2 Count          wAverageTravelTime >>= 1;        wAverageTravelTime = (wAverageTravelTime*swTimeBase);          dwDistance = (wAverageTravelTime * w_FixedPointAux);     dwDistance = (dwDistance * b_m);     dwDistance = (dwDistance / w_FixedPointAux);     dwDistance = (dwDistance - w_b);          bDistanceIntegers = (dwDistance / w_FixedPointAux);       bDistanceUnits = (dwDistance % w_FixedPointAux);     bDistanceUnits = (bDistanceUnits / 10);          bDistanceReadyFlag = 1; }   The distance calculation is based on the linear behavior of the transducers’ response. Some samples of the signal’s travel time were taken for distances from 15 to 80 cm and according to that data, it was calculated a linear equation that describes the calculated travel time in function of the distance to the reflective object (See Figure 4 below). After getting the time difference, in FTM2 counts, between the departure and the arriving time of the signal, it was necessary to divide that number of counts, because that time difference corresponds to the travel of the signal to the reflective object and back to the transducers. Furthermore, it was required to convert those counts to real time, and according to the configurations of the FTM2, each of its counts was equal to 265 ns. The rest of the algorithm consists just on the use of the linear equation the travel time as variable, multiplying by the corresponding slope (b_m) and adding the intersection with the y-axis (w_b). The real values of the slope and the intersection with the y-axis were fixed in order to avoid the use of float variables.   The following graphic shows the characteristic linear behavior of the relation between the signal’s travel time and the distance from the transducers to the reflective object Figure 4. Characteristic curve’s graphic   The application test’s results are shown in the following table 1 The error for the Distance Measured is approximately ± 2 cm for short distances and ± 5 cm for the longer ones Table 2. Test’s Results        Steps to include the ultrasonic distance measurer demo in KSDK   In order to include this demo in the KSDK structure, the files need to be copied into the correct place. The ultrasonic_distance_measurer 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/ultrasonic_distance_measurer/iar <KSDK_install_dir>/demos/ultrasonic_distance_measurer/kds <KSDK_install_dir>/demos/ultrasonic_distance_measurer/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 ultrasonic transducers: Figure 5. Example of the distance measured being shown in a console Figure 6. Example of the distance measure 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 Ultrasonic Distance Measurer project from <KSDK_install_dir>/demos/ultrasonic_distance_measurer/ FreeMaster.           4. Go to Project/Options.          On the Comm tab, make sure the option ‘Plug-in Module’ is marked and select the corresponding type of connection. Figure 7. 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:           1. Go to the MAP Files tab.           2. 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 😎 and selecting the correct path to the MAP file: <KSDK_install_dir>/demos/ultrasonic_distance_measurer/iar/frdmk64f/debug/ultrasonic_distance_measurer_frdmk64f.out <KSDK_install_dir>/demos/ultrasonic_distance_measurer/kds/frdmk64f/Debug/ultrasonic_distance_measurer_frdmk64f.elf   Click on ‘OK’ to save the changes.   Figure 8. Selection of the MAP File for each IDE supported by the demo   Enjoy the demo!

The tutorial shows how to toggle LED with KSDK 1.1.0 in KDS 2.0 and Processor Expert using a Timer Output for FRDM-KL03Z. Guide is prepared for red LED which is connected to Timer/PWM Module 0 (TPM0), channel 1. Create new project Create new project in KDS 2.0 with KSDK 1.1.0 Type the project name, choose board. e.g. FRDM-KL03Z, mark off options Kinetis SDK and Processor Expert Now, the structure looks like this: Set Processor Expert Settings Now, go to Components Library, find fsl_tpm component and by double click add the component to Component View. Rename the component tpmTmr:fsl_tpm to e.g. RedLed. Double click on RedLed:fsl_tpm in Components View and see Component Inspector Follow these steps: Set frequency and duty cycle. Debug configuration DONE!

Hi all Kinetis lovers,   Freescale has launched the Kinetis SDK and I believe this is a great opportunity for us to start our new applications using these drivers. The information contained on this post will show you how to use the SPI drivers based on simple master and slave examples.   The examples attached here were developed for KDS IDE using KSDK. To build and run the example you may need to consider the following: Install KSDK: You need to have  KSDK v1.1.0 installed on your machine. You can find it HERE. Build the KSDK library and import the examples: In the KSDK install folder go to the doc folder and look for the Getting Started with Kinetis SDK (KSDK) document. Follow the instructions of the section 5 Run a demo using Kinetis Design Studio IDE. To know how to build and import projects. If you have further question you may find useful information in this posts: OpenSDAv2 Complete information for the OpenSDA v2. Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt excellent post from colleague Carlos_Musich   I hope you can benefit from this post.   If you have questions please let me know   If this post was useful for you do not hesitate to click the Like button.   Best Regards, Adrian Sanchez Cano Technical Support Engineer  

For installation standalone KSDK packages please follow these instructions:   Go to www.freescale.com/ksdk and click to download Is needed to be signed in After that is seen standalone package for FRDM-KL43Z and KL33Z Agree with Software Terms and Conditions Choose installation package according to platform Save file and install it After installation, final folder appears at C:\Freescale\KSDK1.2.0_KL33Z_1.0.0 and Eclipse update - import package to KDS from C:\Freescale\KSDK1.2.0_KL33Z_1.0.0\tools\eclipse_update   Eclipse Update In KDS choose Install New Software Click Add Choose Archive Choose the Eclipse Update zip file located at C:\Freescale\KSDK1.2.0_KL33Z_1.0.0\tools\eclipse_update Select update for KL33Z and KL43Z Accept terms of the license agreement   🙂 Enjoy!

Hi folks,   I would like to share my experience using lwIP with KSDK1.2, I hope this will be useful for people who is getting started with this TCP/IP stack.   I must admit that I really dislike working over an example application (please do not misunderstand my message, these examples are really nice but just as examples, not to develop new applications over them), the problem is that these project are not stand alone and if they are moved from their original locations it becomes a mess. This is why I always create a standalone projects. For instance I will describe how to run ‘lwip_tcpecho_demo’ and after this, how to reproduce this example as a standalone project.   Running ‘lwip_tcpecho_demo’ Creating a new project with lwIP support using FreeRTOS       I hope you find it useful.   Regards, Carlos

Hi all,   Please find attached the new version of this document using KDS3.0 and KSDK1.2.0.   For more information about using Interrupts please see the following document from Jorge_Gonzalez Interrupt handling with KSDK and Kinetis Design Studio   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   For information about creating a new C++ project in MQX for KSDK1.2 please see the following document. How to Create a C++ Project Using MQX RTOS for KSDK1.2   For information about getting started with FreeRTOS and KSDK1.2 see the following document. How to: Create a New FreeRTOS for KSDS1.2 Project in KDS3.0     I hope it is useful.   Regards, Carlos Technical Support Engineer

This document will cover some of the most commonly asked questions about Kinetis Software Development Kit (Kinetis SDK). Anything requiring more in-depth discussion/explanation will be put in a separate thread. All new questions should go into their own thread as well. The variable KSDK_PATH is mentioned in several answers. This is the path into which Kinetis SDK was installed. With the current 1.2 release of Kinetis SDK, this would be equivalent to C:\Freescale\KSDK_1.2.0     What is the Kinetis Software Development Kit? Kinetis SDK is a free software framework that was created to make it easier for developers to create applications for Freescale’s line of Kinetis microcontrollers. It ensures there’s a common and thoroughly tested software framework for Kinetis devices that you can then use to build your application on top of. Let Kinetis SDK provide the basic startup code and drivers, so that you can spend more time creating your specific application code.   The two most significant features of Kinetis SDK are: Hardware Abstraction Layer (HAL) – A common API used to abstract hardware accesses into functional accesses Peripheral Drivers – High-level drivers that make use of the HAL API to implement higher level functionality for common peripheral use cases.   Additionally there are several other features: System Services – Code for utilizing specific Kinetis features which includes a clock manager, low-power manager, hardware timer, and interrupt manager ARM CMSIS Core and DSP standard libraries CMSIS compliant register header files Sample code for accessing accelerometers and audio codecs on Freescale evaluation boards Stacks and middleware for USB, Ethernet, and filesystems. Many examples and demo code to showcase how to use Kinetis SDK   This sounds great! Where can I download it and find more documentation and information? http://freescale.com/ksdk   How do I get started using Kinetis SDK? First read the Kinetis SDK 1.2 release notes to learn about the software. You will also want to check to make sure your Kinetis device is supported by Kinetis SDK. If you don't see your device in the KSDK 1.2 release notes, check to see if one of the stand-alone releases available includes it.   Once you’ve selected the appropriate installer for your device, either the mainline or one of the stand-alone releases, install it on your computer. The default path for the mainline Kinetis SDK 1.2 is C:\Freescale\KSDK_1.2.0 You will also need to install one of the compilers that Kinetis SDK supports. Kinetis Design Studio 3.0 IAR Embedded Workbench for ARM 7.40.2 MDK-ARM Microcontroller Development Kit (Keil) 5.14 ARM GCC 4.8.3 Atollic TrueSTUDIO for ARM 5.3 If you are not sure, we recommend starting with Kinetis Design Studio since it is free and also runs on Linux.   Then read the Getting Started with Kinetis SDK (KSDK) v1.2.pdf document. It can also be found in <KSDK_PATH>/doc. It will have details about Kinetis SDK and there will be a section for getting up and going with your particular IDE to run the hello_world demo application. Note that you will need to compile the Kinetis SDK platform library first before you can compile the demos.   You can then run one of the other demo applications included with Kinetis SDK to see examples of how to use the HAL and Driver APIs.   If you are using Kinetis Design Studio, also make sure to follow the directions in Appendix A of this document to update Kinetis Design Studio to work with Kinetis SDK: https://community.freescale.com/docs/DOC-102612   How do I run the demo projects that are included with Kinetis SDK? First read the Getting Started with Kinetis SDK (KSDK) v1.2.pdf document. You will need to import and compile the KSDK platform library, and then import and compile the particular demo project.   Where can I find specific instructions on a particular demo? For details on a specific demo, including any board jumper settings and to check if the demo will run on your particular board, refer to the Kinetis SDK v1.2 Demo Applications User's Guide.pdf found in the <KSDK_PATH>/doc folder.   How does Kinetis SDK fit in with other Freescale enablement? Kinetis SDK is a key component going forward in all Freescale Kinetis enablement. It replaces the bare-metal sample code examples. Freescale’s MQX RTOS will now use KSDK drivers for supported devices, instead of the classic MQX-specific drivers. And it will use the KSDK startup and board support code.   Processor Expert, a GUI tool for software configuration and code generation, now uses the KSDK HAL and Drivers to implement its code for KSDK supported devices. And the mbed platform also uses Kinetis SDK underneath for devices supported by Kinetis SDK.   Kinetis SDK Details:   What exactly am I getting when I download and install Kinetis SDK? The default installation path for KSDK 1.2 is at C:\Freescale\KSDK_1.2.0   Inside that directory, you’ll find the full source code for the various KSDK components (HAL, drivers, system services, header files, etc) as well as demos, documentation, and higher level stacks like our USB stack, lwIP, FatFS, and various RTOS kernels.   Some of the key directories are: examples – SDK examples and demos doc - Documentation lib – SDK libraries projects, and where the compiled library .a files are generated platform – SDK driver and HAL source code, linker files, and startup code   Section 5 of the Kinetis SDK v1.2 release notes lists the different components and where they are located in the Kinetis SDK directory structure.   What Kinetis devices/boards are supported by Kinetis SDK? In KSDK 1.2, the following boards are supported: FRDM-K22F FRDM-K64F FRDM-KL02Z FRDM-KL03Z FRDM-KL27Z FRDM-KL43Z FRDM-KL25Z FRDM-KL26Z FRDM-KL46Z FRDM-KW24 MRB-KW019032xx TWR-K21D50M TWR-K21F120M TWR-K22F120M TWR-K24F120M TWR-K60D100M TWR-K64F120M TWR-K65F180M TWR-KL43Z48M TWR-KV10Z75M TWR-KV31F120M TWR-KV46F150M TWR-KW24D512 USB-KW24D512   Kinetis SDK also supports many of the subfamiles that these boards support. 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. The subset devices supported are all listed in the Release Notes.   The KSDK 1.2 release can be found at http://freescale.com/ksdk   Which version of Kinetis SDK do I install? I see that there are Mainline and Standalone Releases. What's the difference? If the device you are interested in is listed in the previous question, download the Mainline release appropriate for your computer (Windows/Linux/Mac).   If your device is listed as a Standalone install, you just need to use that Standalone installer. These are releases for new devices that did not make into KSDK 1.2 but will be rolled into later releases. Note that installing "Kinetis SDK Mainline 1.2" is not a pre-requisite as these truly are 'standalone' releases and include all the standard KSDK features and code: KL33Z for the FRDM-KL43Z   These standalone releases can be found under the Downloads tab on the KSDK website. You may need to select "All Downloads" to see them.   How do I determine if my particular Kinetis device is supported by Kinetis SDK and which board it is associated with? Section 4, “Supported Development Systems”, of the Kinetis SDK release notes lists the specific Kinetis devices that are supported by that release of Kinetis SDK. The table can also be used to determine which evaluation board is associated with your particular Kinetis device. Each of the stand-alone releases will also have their own table like this in their release notes.   When will device XYZ be supported by KSDK? Most new Kinetis devices will launch with Kinetis SDK support. Support for some older Kinetis devices will be added over time in new releases. Those older devices selected for porting will be announced on the Community once a release date is confirmed. In the meantime, use the bare-metal sample code and MQX support already available for those legacy devices.   I don’t see my device in either the Kinetis SDK 1.2 release or the stand-alone releases. Can I just port Kinetis SDK to my device? There are several key components that would be missing to do a port to a different family, like header files and start up files, and thus it is discouraged and is not supported by Freescale. Support for some older Kinetis devices is being added in future releases, and most Kinetis devices released in the future will have Kinetis SDK support at launch.   What compilers are supported by Kinetis SDK? In Kinetis SDK 1.2 the following compilers are supported: Kinetis Design Studio 3.0 IAR Embedded Workbench for ARM 7.40.2 MDK-ARM Microcontroller Development Kit (Keil) 5.14 ARM GCC 4.8.3 Atollic TrueSTUDIO for ARM 5.3   Kinetis Design Studio and ARM GCC are code sized unlimited and will also run on Linux. If you do not already have a preferred compiler, we recommend starting with Kinetis Design Studio.   What exactly is the HAL? The Hardware Abstraction Layer (HAL) creates an abstraction layer for hardware accesses.  For example, instead of digging into a reference manual to figure out which bit in which register bit is used to enable the UART transmit feature, you can just call UART_HAL_EnableTransmitter(…). The HAL is stateless and is intended to cover the entire hardware functionality.   Where is the source code for the HAL? You can find the source for the HAL at <KSDK_PATH>\platform\hal.   For a good example of how the HAL is implemented, look at the <KSDK_PATH>\platform\hal\src\dspi\fsl_dspi_hal.c and <KSDK_PATH>\platform\hal\inc\fsl_dspi_hal.h files. Notice how most of the HAL API is just macros for accessing the SPI registers, or else simple functions for calculating the baud rate and other simple features like that.   Is there a library for the HAL that I can pull into my project? There is a device and compiler specific library available that you can pull into your own custom project at <KSDK_PATH>\lib\ksdk_hal_lib.   You will need to compile the library first as KSDK does not come with pre-compiled libraries.   What are the peripheral drivers? The peripheral drivers are built on top of the HAL to provide a set of easy-to-use interfaces to handle high-level data and stateful transactions. They cover the most common use-cases, but may need to be optimized for your particular application.   Where is the source code for the drivers? You can find the source for the KSDK drivers at <KSDK_PATH>\platform\drivers.   For a good example, take a look at <KSDK_PATH>\platform\drivers\src\dspi\fsl_dspi_master_driver.c. You can see how the driver API is implemented by making calls to the HAL API and using structures defined by the SPI driver.   Is there a library I can pull into my project to use the drivers? The KSDK Platform library contains both the drivers and the HAL. This is the library most of the KSDK demo projects pull in. Device and compiler specific project files for this library can be found at <KSDK_PATH>\lib\ksdk_platform_lib   You will need to compile the library first as KSDK does not come with pre-compiled libraries.   Where are the HAL and Driver APIs documented? The Kinetis SDK API Reference Manual describes all the HAL and Driver APIs, and it can be found in the <KSDK_PATH>/doc folder.   How do I create my own Kinetis SDK application? The easiest way is to copy an already existing project. However if you are using Kinetis Design Studio, you can also create one from scratch using the New Project Wizard.   To copy an already existing demo project, see this thread: Create new KSDK Projects   To create a totally new project with Kinetis Design Studio, see this thread: Writing my first KSDK Application in KDS - Hello World and GPIO Interrupt   To create a MQX project that works with Kinetis SDK, see this thread: How To: Create a New MQX RTOS for KSDK Project in KDS   A full featured KSDK project creation tool is under development and should be released in Q2 2015.   Where can I find information on the Kinetis SDK low power manager? See this thread: Low Power Application Using the SDK (Note: The demo was created for KSDK 1.0)   What changed between KSDK 1.0 and KSDK 1.1? See this thread: KSDK 1.1 Release   What changed between KSDK 1.1 and KSDK 1.2? See this thread: New KSDK 1.2. is available!   Can I install a new version, or standalone version, of KSDK without it affecting my already existing version? Yes. Each new release of KSDK, including standalone releases, will be installed into a unique directory. The only thing to be aware of is the (optional) update the global Windows KSDK_PATH variable used by Kinetis Design Studio. See Appendix B of this document: Writing my first KSDK Application in KDS - Hello World and GPIO Interrupt   Do I need to recompile the platform library every time I change my demo application? After the initial compilation, you will only need to recompile the platform library for your device if you change something in the HAL, Drivers, or other source code that makes up the platform library. The platform project is included as part of the workspace when opening up a demo as a convenience for that initial compile. If you only change the code for the demo application, you do not have to recompile the platform library every time.   Is there training available for Kinetis SDK? There are some presentations at the Designing with Freescale event webpage: http://www.freescale.com/webapp/Download?colCode=DWF14_AMF_SDS_T0127 http://www.freescale.com/webapp/Download?colCode=DWF14_AMF_SDS_T0805   Also make sure to read through the Kinetis SDK 1.2 Release Notes as there is a lot of very useful information in there as you get started using Kinetis SDK.   Many more app notes and community posts are being created to further showcase how to use Kinetis SDK.   RTOS:   Does Kinetis SDK supports RTOSs? Yes. Several different RTOS kernels can be ran on top of Kinetis SDK. This was done to solve the biggest trouble of porting a particular RTOS to a new device, in that new drivers and startup code needs to be developed. Kinetis SDK provides that solution, so that the RTOS kernel features can sit on top of Kinetis SDK.   What RTOS kernels are supported with Kinetis SDK? Freescale MQX FreeRTOS Micrium uCOSII Micrium uCOSIII   How do I get these RTOSs with Kinetis SDK? Starting with Kinetis SDK 1.2, all the RTOSs are included by default with the installation.   If using Kinetis SDK 1.1, during installation process, there will be a screen asking if you would like to install 'Kinetis SDK Basic', 'KSDK+MQX', or 'KSDK+RTOS Kernels'. If you are only interested in MQX, use the middle option. If you are interested in other RTOS kernels (including MQX) select the last option which will take you to a new screen to select which RTOSes you are interested in.   If using Kinetis SDK 1.0, you must select the "Custom" option during installation to select a RTOS kernel.   Why don’t I have an <KSDK_PATH>/rtos folder? Where are the RTOS kernels at? See the above answer. You will need to run the KSDK installer again, select to modify the installation, and this time select an RTOS install option.   What else do I get when selecting the MQX RTOS option? When selecting the MQX RTOS option, the MQX RTCS Ethernet stack and MQX MFS Filesystem stack will be installed as well. These are more fully featured stacks than the 'lwIP' and 'FatFS' stacks provided by default with Kinetis SDK. These RTCS and MFS stacks require MQX to run, and full source code is provided.   What is the difference between MQX for KSDK and 'classic' MQX 4.2? MQX for KSDK is the future of MQX, and it was developed to leverage Kinetis SDK features like startup code and drivers. The biggest difference is the drivers, as MQX for KSDK uses the KSDK drivers which are significantly different than the classic MQX drivers. The startup code is also different as MQX for KSDK relies on the KSDK startup files. However the kernel API and how to you start and manipulate tasks, semaphores, events, etc, are the same between the two versions.   A full porting guide between classic MQX and MQX for KSDK is now available.   How can I learn how to create a new MQX for KSDK project for Kinetis Design Studio? A tutorial can be found here   Where can I find more information on MQX for KSDK? http://freescale.com/mqx/ksdk Beta version of MQX RTOS for Kinetis SDK - Now Available MQX with KSDK and Processor Expert   What is the OSA? The Operating System Abstraction (OSA) layer is an optional feature that allows a user application to use the same API regardless of which RTOS is being used. This can be used to make code more portable. An example of this can be found in the <KSDK_PATH>/demos/i2c_rtos demo, which uses almost the exact same source code to do a demo using I2C communication when using baremetal, MQX, FreeRTOS,  uCOSII, or uCOSIII.   Do I have to use the OSA? No, it is optional. You can always call the particular RTOS API directly. For example, if you were using the MQX kernel, you have the option to call either the OSA API call for a time delay (OSA_TimeDelay) or the MQX API call (_time_delay).   You can see how the OSA layer implements the OSA_TimeDelay() function for MQX by opening the file <KSDK_PATH>\platform\osa\src\fsl_os_abstraction_mqx.c, and on line 662 you’ll see that all the OSA is doing is calling MQX’s own _time_delay() API.   Note that some drivers make use of the bare-metal OSA implementation for certain functionality (like delays or semaphores).   USB:   What USB stack is included with Kinetis SDK? The USB stack is developed by Freescale and is a continuation of the 5.0 Beta bare-metal stack. The stack in Kinetis SDK has more features, and Kinetis SDK is where USB development work will be focused in the future.   You may also see it referenced as the “Unified USB stack” since this same USB stack is used by both bare-metal KSDK and by MQX for KSDK. This makes it simpler to add RTOS support to an already existing USB application.   What classes does the Kinetis SDK USB stack support? It supports Audio, CDC, HID, MSD, and PHDC classes in both Host and Device modes. Some composite class support is also provided.   How do I compile a USB demo? There are two libraries that need to be compiled before a USB demo will compile properly. Host or Device USB Library at <KSDK_PATH>\usb\usb_core\<host or device>\build\<compiler>\<board>\ KSDK Platform library at <KSDK_PATH>\lib\ksdk_platform_lib\   Then one of the USB demos can be compiled at <KSDK_PATH>\usb\example\<host or device>\<class>\<example project>   Troubleshooting:   I’m seeing an error about missing a missing ksdk_platform_lib.a or libksdk_platform.a file when I try to compile a demo There are two common cases where this happens:   1) You must first compile the KSDK platform library for your device. The project files for the library are found in <KSDK_PATH>/lib/ksdk_platform_lib/<compiler>/<device>/   2) Make sure the KSDK platform library you compiled is for the same target (Debug or Release) as the demo you are trying to compile. The Debug target has no optimization. The Release target uses full optimization.   Why is the “Kinetis SDK” checkbox unavailable when creating a new project in Kinetis Design Studio using the ‘Kinetis Design Studio Project’ Wizard? This checkbox is only selectable if the device you selected on the previous screen is supported by Kinetis SDK.   Also make sure to follow the directions in Appendix A of this document to update Kinetis Design Studio to work with Kinetis SDK. You will need to update KDS with the KSDK 1.2 file to get the boards supported by KSDK 1.2 in the project wizard: Writing my first KSDK Application in KDS - Hello World and GPIO Interrupt   I’m trying to use a driver and keep falling into the default ISR in startup_<mcu>.s Make sure to include an interrupt handler for the peripheral you’re using inside your project. By default, all the peripheral IRQ handlers go into a default handler that does an infinite branch. The easiest way to fix this issue is to add the C:\Freescale\KSDK_1.2.0\platform\drivers\src\<drivername>\fsl_<drivername>_irq.c file inside your project.   How do I change the default interrupt priority for a driver? Use the CMSIS NVIC_SetPriority function.  As an example from the i2c_rtos demo: NVIC_SetPriority(I2C0_IRQn, 6U);   I’m using a FRDM-KL03 and none of the KDS projects work Due to the small RAM size of the KL03, the default toolchain in Kinetis Design Studio needs to be swapped out for the ARM GCC toolchain. Instructions are in the appendix of the “Kinetis SDK Freescale Freedom FRDM-KL03Z Platform User’s Guide.pdf” found in the KSDK KL03 installation inside the /doc folder.   I'm using IAR and I get the following error when I try to compile: Fatal Error[LMS001]: License Check failed. Use the IAR License Manager to resolve the problem. Found no license for ARM EW.MISRAC[LicenceCheck:2.13.4.627,RMS 8.5.0.0021, Feature ARM.EW.MISRAC, Version 1.05]. The specified license feature is needed to enable MISRA-C support. This error occurs because the IAR projects are setup by default to enable MISRA-C checking, as KSDK is MISRA compliant. However the evaluation version of IAR doesn't support MISRA checking. To work-around this issue, right click on the project name that is giving the error, and select "Options...". Then under the "General Options" category, scroll over to the the tab on the far right that says "MISRA-C 2004". Then uncheck the box that says "Enable MISRA_C"   I'm seeing errors when using the SPI driver. What is the difference between the DSPI and SPI drivers? See this thread   The I2C_RTOS demo isn't compiling properly. It says it is missing libksdk_platform_mqx.a (or some other library). What libraries do I need to compile for the I2C RTOS demo? See this thread   I don't see any terminal output when using the power_manager_demo demo. You need to adjust the baud rate of the terminal to 9600 due to some clock speed limitations necessary for this demo. See the \doc\Kinetis SDK v.1.2 Demo Applications User's Guide.pdf for more details.   I don't see any terminal output when using some of the FRDM-KL03 demos. The following KL03 demos use a baud rate of 9600 due to some clock speed limitations necessary for those particular demos: flash_demo lptmr_demo power_manager_demo rtc_func See the \doc\Kinetis SDK v.1.2 Demo Applications User's Guide.pdf for more details.   I’m seeing odd compile errors in Kinetis SDK, what could be going on? If using KSDK 1.0 or KSDK 1.1, double check that the KSDK_PATH environment variable in Windows is pointing to the current installation of Kinetis SDK you’re trying to use. KSDK 1.2 does not make use of this environmental variable anymore. For details see Appendix B of this document Writing my first KSDK Application in KDS - Hello World and GPIO Interrupt   Where can I find a document of known issues? Known issues can be found in the Kinetis SDK 1.2 Release Notes.   Additional issues found after the Kinetis SDK release can be found in the Kinetis SDK Software Errata document, if one is needed, on the “Documents” tab of the KSDK webpage.   Updated Jun-2015 for KSDK 1.2 Release.

This patch adds Segment LCD (SLCD) examples for the Kinetis Tower boards with the TWRPI-SLCD module.  It reuses the SLCD driver included in the "Kinetis SDK 1.2.0 Standalone for KL33Z for the FRDM-KL43Z", and ports the example to boards using the TWRPI-SLCD module.    The patch was written for KSDK v1.2.0, found at www.freescale.com/KSDK.  To install the patch, unzip to the KSDK installation directory, by default it is C:\Freescale\KSDK_1.2.0.  Only the Debug Build Configurations in the libraries and example applications were updated for these examples.  The Release Build Configurations will need to be updated before using.  The boards supported with these examples are:   TWR-KL46Z48M   TWR-KL43Z48M   TWR-KL46Z48M board example is provided with a project for Kinetis Development Studio (KDS) toolchain, and tested with KDS v3.0.0.  The path for this example is at  \KSDK_1.2.0\examples\twrkl46z48m\demo_apps\slcd_low_power_demo\kds.  The example also includes the KDS .WSD working set file.  When this is imported to KDS, it imports both the platform library and example application.  The example is written to display time on the TWRPI-SLCD, and will display mm:ss.   TWR-KL43Z48M board example is provided with a project for Kinetis Development Studio (KDS) toolchain, and tested with KDS v3.0.0.  The path for this example is at \KSDK_1.2.0\examples\twrkl43z48m\demo_apps\slcd_low_power_demo\kds.  The example also includes the KDS .WSD working set file.  When this is imported to KDS, it imports both the platform library and example application.  The example is written to display time on the TWRPI-SLCD, and will display mm:ss.

What is it FreeMASTER?   FreeMASTER is a tool with variety GUIs in one offered free. FreeMASTER is a user-friendly real-time debug monitor and data visualization tool −GUI can be easily extend by multimedia content (charts) and user-modified content (possible mix user´s data with default values) − offers access to target variables, symbols and data types − access over UART, CAN or USB with target-side driver and over BDM − possibility to direct control via variable modifications − addresses parsed from ELF file or provided by target (TSA) − scope graphs with real-time data in [ms] resolution − recorder visualization transitions close to 10[us] resolution     FreeMASTER features Real Time Monitor -Displaying variable values in various formats (Text, Real-Time waveforms, High-speed recorded data) Control Panel - Direct variable value settings and variable stimulation, scribtable in JScript or VBScript Demonstration Platform - Demostration embedded app by HTML pages, display simultaneous real-time data monitoring Easy Project Deployment - Entire project saved to a single file   FreeMASTER communication There are two types of communication. It is possible to communicate via Direct RS232 or selected Plug-in Module. In short: SCI, UART USB – CDC – Kinetis, ColdFire V2 CAN JTAG (56F8xxx only) BDM – Kinetis, PowerPC, ColdFire, HCS with Segger, P&E Micro, CMSIS-DAP…     FreeMASTER usage Real-time debugging - FreeMASTER allows users to debug applications in true real-time through its ability to watch variables. Moreover, it allows debugging at the algorithm level, which helps to shorten the development phase Diagnostic tool - FreeMASTER remote control capability allows it to be used as a diagnostic tool for debugging customer applications remotely across a network Demonstrations - FreeMASTER is an outstanding tool for demonstrating algorithm or application execution and variable outputs. Education - FreeMASTER may be used for educational purposes. Its application control features allow students to play with the application in demonstration mode, learning how to control program execution.   FreeMASTER description of the environment   The FreeMASTER window is divided into 4 parts - Project Tree, Detail View Pane, Commands and Variable Watch Grid. Project Tree is the project, New Block is a root of the project, New Scope is similar to classical Oscilloscope. Scope periodically reads variable values and plots them in real-time. It is limited by the serial communication speed. The recorder is also monitoring and visualising variable values, but the change is much faster. The recorder is running on target board and variable values are sampled into memory buffer on the board and then these sampled data are downloaded from the board to FreeMASTER.   Detail View Area is dynamically changes depending on content which is selected in Project Tree. Detail View Tab can be control page, algorithm block description, scope, recorder or another HTML document whose URL is defined in the Scope or Recorder properties. Commands window is list of commands to send, Variable Stimulus - is the list of defined variables for the defined time. In Variable Watch Grid contains the list of watched variables.   Supported devices FreeMASTER download and support   The installation package you can download from the Official website:   FreeMASTER Official website www.nxp.com/freemaster   You can ask us on Community or you can create new SR according to https://community.freescale.com/docs/DOC-329745   More about FreeMASTER   FreeMASTER Official Website https://www.nxp.com/freemaster   Using FreeMASTER https://cache.freescale.com/files/microcontrollers/doc/reports_presentations/FREEMASTERPRESENT.pdf   FREEMASTER:  Remote Server Tutorial https://community.freescale.com/docs/DOC-103293   Tutorial: FreeMASTER Visualization and Run-Time Debugging https://mcuoneclipse.com/2013/08/24/tutorial-freemaster-visualization-and-run-time-debugging   Let´s continue with reading! Let´s start with KSDK!

Hi everybody,   You can find the new version of this document using KDS2.0 and KSDK1.1.0 is in the following link: Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt   Best regards, Carlos Technical Support Engineer

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!

Hardware and software configuration: FRDM-K22F, SCH-28164 REV D OpenSDA: J-Link firmware KDS 3.0 with SDK 1.2.0 Eclipse update installed KSDK 1.2 provides an Eclipse update for those who want to use the Kinetis SDK with Eclipse and Processor Expert. and with this update , users may find MSD Class component has been supported, and there is a simple USB mass storage demo available directly in this PEx USB component, so that customers may easily build this demo and develop their own application based on that. Here I will start to illustrate how to implement this demo step by step. As FRDM-K22F is used in this test, so I directly choose this board and make the following configuration: After above steps, we have a PEx project with some pre-installed components as shown below: clockMan1 components has 6 configurations , and one of it is for USB application, you may set it as the init configuration right now, or it would be set automatically when you add the USB MSD components. Now I find the MSD component from KSDK 1.2 and add it to my project: This component will add 4 more reference components into this project, and we only have to configure the component "fsl_debug_console" to get rid of the error mark. For FRDM-K22 board, UART1 is used as the debug console, and PTE0 and PTE1 are used as the TXD and RXD, so I set up this components as below: The simple MSD demo is a RAM disk demo, and it is disabled by default, so we have to enable it in the fsl_usb_device_msd_class component, and the demo code will be automatically added into the project afterwards: and then set the correct PID and VID information in the component of fsl_usb_descriptors. so far looks like all components are configured correctly , but if we directly download this application, we will have an enumeration issue like below: This is due to USB descriptors are placed to Flash memory area by default . You know , USB descriptors contain constant values so storing them in flash would leave more RAM for user application. The highlighted option in the following figure determines this . but USB module in Kinetis doesn't have the permission for flash out of reset, so we still have something to do before going ahead. There are several solutions for it, the most easiest way is setting the above option to "no", but we may do it in a PEx-like way by using the "Init_FMC" component. Please note USB is the M4 of K22's crossbar-lite. so we give it the "read only" permission. Init_FMC() is placed in Peripherals_Init() which is called right before  Components_Init() where USB_Class_MSC_Init () is in, so it guarantees USB have the flash access permission before it starts up. Now the demo can work well with the PC host, just as shown below: So far only HID and MSD Class components are supported, and if you go through a similar process as above, you may easily implement a HID demo by yourself. Here I attach both the MSD and HID mouse demo for your reference. Hope that helps,

Hello All,   Here is a document for creating an USB Host Project (MSC + fatfs) with KSDK 1.3 and Processor Expert support in KDS. It uses FRDM-K64F board as example and lists some specific considerations that needs to be accomplished when creating an USB Host project by using fsl_usb_framework component (Processor Expert) in Kinetis Software Development Kit (KSDK) version 1.3.   I hope you can find it useful!   Regards, Isaac Avila

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 Kinetis MCUs. 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 can be downloaded from the following location: http://freescale.com/ksdk   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 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.   First download and install the latest release of Kinetis SDK from http://freescale.com/ksdk   Then select one of the five IDEs that Kinetis SDK supports: Kinetis Design Studio 2.0 IAR Embedded Workbench for ARM 7.20.2 MDK-ARM Microcontroller Development Kit (Keil) 5.11 ARM GCC 4.8.3 Atollic TrueSTUDIO for ARM 5.2 Note that Kinetis Design Studio and ARM GCC are code sized unlimited and will also run on Linux.   Then take a look at the documentation in the /doc folder, in particular the Release Notes and the Getting Started with Kinetis SDK (KSDK) documents. The Release Notes contain an overview of Kinetis SDK, supported devices, details on the directory structure, and known issues.   Also note the basic Kinetis SDK directory structure. More details can be found in the Release Notes: demos – 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 demos folder, check out the “hello_world” project at \demos\hello_world\<ide>\frdmk64f\hello_world.eww of it for a simple hello world type app. Use the Getting Started with KSDK Guide for details on how to compile and run the demo for your particular IDE.   Also check out the Kinetis SDK FAQ for information on other boards supported by Kinetis SDK, MQX RTOS and other RTOS support, USB support with KSDK, and much much more.   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 or Segger JLink debug interfaces with the board instead.   Debugging with CMSIS-DAP/mbed Interface: The FRDM-K64F board uses the CMSIS-DAP/mbed interface by default as it is using OpenSDAv2. The KSDK 1.1 demo projects should be setup to use the CMSIS-DAP debug interface by default for the FRDM-K64F projects.   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 in Appendix C of the Getting Started with KSDK 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   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 your project is trying to use the P&E Micro or JLink interface. Change the debug interface in your IDE to use CMSIS-DAP. Or else change the firmware in the OpenSDAv2 circuit to the proper firmware as described in Appendix C of the Getting Started with KSDK document.   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.