Kinetis Software Development Kit Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis Software Development Kit Knowledge Base

Labels
  • General 62

Discussions

Sort by:
Hello community,   This document 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 make the line scan camera with KSDK works step-by-step. This document is intended to be an example for the ADC, the PIT and the GPIO peripheral drivers usage.   The required material to run this project is: Line scan camera (the project supports up to two cameras). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable. TFC camera wire.   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 Line scan camera with KSDK [ADC + PIT + GPIO] explains how to implement an application to acquire the data provided by the line scan camera. The result of this document is the project BM-KSDK-FRDM_KL25Z-LINE_SCAN_CAMERA.   The video below shows the line scan camera working.     If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The NXP Cup Technical Reports The NXP Cup - Mexico, The NXP Cup - Brazil, The NXP Cup - China, The NXP Cup - Malaysia, The specified item was not found., The NXP Cup - North America, The specified item was not found., The NXP Cup - Taiwan, The NXP Cup EMEA.       Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor
View full article
Just today release new KSDK version 1.2. and KDS 3.0! Download here   For more details please visit our websites Software Development Kit for Kinetis MCUs|Freescale and Kinetis Design Studio Integrated Development |Freescale   What´s new   Added device family support:   MK10D10 MK66F18 MKL34Z4 MK11DA5 MKL02Z4 MKL36Z4 MK20D10 MKL14Z4 MKL43Z4 MK21DA5 MKL15Z4 MKV40F15 MK21FA12 MKL16Z4 MKV43F15 MK26F18 MKL17Z4 MKV44F15 MK30D10 MKL17Z644 MKV45F15 MK40D10 MKL24Z4 MKV46F15 MK50D10 MKL25Z4 MKW01Z4 MK51D10 MKL26Z4 MKW21D5 MK52D10 MKL27Z4 MKW22D5 MK53D10 MKL27Z644 MKW24D5 MK65F18 MKL33Z4 MK24F12 MK63F12   Added Peripheral support: AOI ENC FLEXBUS FLEXIO LMEM VREF XBAR PWM   Documentation   Kinetis SDK v.1.2.0 Release Notes http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK120RN.pdf?fsrch=1 Kinetis SDK v.1.2 API Reference Manual http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12APIRM.pdf?fsrch=1 Kinetis SDK v.1.2 Demo Applications User's Guide http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12DEMOUG.pdf?fsrch=1 Getting Started with Kinetis SDK (KSDK) v.1.2 http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12GSUG.pdf?fsrch=1 MQX™ RTOS for Kinetis SDK 1.2.0 Release Notes http://cache.freescale.com/files/soft_dev_tools/doc/support_info/MQXKSDK120RN.pdf?fsrch=1   Porting an MQX RTOS Application to MQX RTOS for Kinetis SDK http://www.freescale.com/files/soft_dev_tools/doc/support_info/MQXKSDKPUG.pdf   for KDS 3.0. please don´t forget visit New Kinetis Design Studio V3.0.0 available   Enjoy! Iva
View full article
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
View full article
Hello Kinetis world! Kinetis SDK is here to stay and with it there are good opportunities ahead, such as coding flexibility, portability, RTOS enablement, projects scalability and more. Right now this is a brand new solution introduced by Freescale, so a lot of tutorials, How-To's and demo codes are coming, in addition to those already in the KSDK installation. I wanted to share an example project developed with KSDK v1.0.0 and KDS v1.1.1, which uses a simple driver to communicate to an I2C EEPROM memory using a FRDM-K64F board. The driver is focused and was tested with a 256 Kbit memory (24xx256), but it should be compatible with the 64Kbit, 128 Kbit, 256 Kbit and 512 Kbit versions. This demo project demonstrates how to use the APIs of the KSDK I2C Master Driver. The connections are as next: Please notice this is not intended to be a robust driver for I2C EEPROMs. Instead consider it a basic demo code, but with time we could improve it. The attached pdf is an overview/explanation of the example, while the zip folder contains the project for Kinetis Design Studio v1.1.1. :smileyalert: Before the project can be successfully compiled, you need to have installed KSDK v1.0.0 (www.freescale.com/ksdk) and have the FRDM-K64F platform library already built. For instructions on how to build the platform library you can refer to Appendix A of the next document in KSDK installation folder: C:\Freescale\KSDK_1.0.0\doc\Kinetis SDK K64 User's Guide.pdf :smileyinfo: NOTE: Disregard IAR and Keil instructions and refer to KDS part. Importing and compiling the example project with KDS      1) Unzip the package. It is recommended to place it into your KDS workspace, but it can be located at any place.      2) From KDS go to File -> Import -> General -> Existing Projects into Workspace.      3) Check "Select root directory" and click on "Browse" to search for the location of the unzipped folder. Then click OK.      4) Mark the check box for "I2C_EEPROM_K64" and click on "Finish".      5) Go to Project -> Build Project or simply click on the hammer icon. Build process should finish with no errors. The project provides a default Debug Configuration to use with the Segger J-Link emulator firmware v2.0 installed in the FRDM-K64F. If you wish to use a different connection please refer to the next link: https://community.freescale.com/docs/DOC-101845 I hope you like this demo. Many thanks and credits to abigailinzunza, for her valuable help developing this project. Regards! Jorge Gonzalez
View full article
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!
View full article
So far the composite msd_cdc demo from ksdk 1.3 just supports ram disk application, to have the SD card support just as the dev_msd demo, you have to go through the following steps: Add platform/composite/src/sdcard/fsl_sdhc_card.c and platform\drivers\src\sdhc\fsl_sdhc_irq.c to the project. Add project including path: platform\composite\inc and platform\drivers\inc. Change usb\example\device\composite\msd_cdc\disk.c as attached file      Change usb\example\device\composite\msd_cdc\disk.h as attached file      Change usb\example\device\composite\msd_cdc\hardware_init.c as attached file. Compile the demo and let it go, the PC would recognize the MSD and CDC device,  but might need you install the CDC driver, use the one from the folder of "C:\Freescale\KSDK_1.3.0\examples\twrk60d100m\demo_apps\usb\device\cdc\virtual_com\inf". With SD card inserted , you may see the removable disk, and format the disk just like below: Copy a ~50M file to this disk eject the disk after done, and then pull and plug the device again, you may verify the copied file with fc.exe command This solution has been tested on TWR-K60D100M with TWR-SER, both bm and mqx examples are verified ok, please kindly refer to the attached files for more details.
View full article
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.
View full article
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.
View full article
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
View full article
Hello KSDK fans:   As you may know, KSDK provides comprehensive software support for Kinetis MCUs to accelerate application development. Besides providing Hardware abstraccion layer and peripherals drivers it can be Processor Expert capable.   Here is an example on how to create a new project with KSDK and Processor Expert support.   It shows a simple USB HID example that is ready to add your application code by using either KSDK drivers or Processor Expert support.   I hope this can help you.   Regards,   Isaac Avila
View full article
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.
View full article
The latest Kinetis SDK 1.1.0 supported HID bi-directional communication, the new API USB_Class_HID_Recv_Data() can be used to receive data from USB HOST. But without demo and test tool, customer still has no idea about how to enstablish such kind of communication in their application. I create a simple demo derived from existed hid_keyboard project, together with basic endpoint read/write test by Bus Hound. The demo is built and tested on my FRDM-K64F and can be port to other USB Kinetis device as well. Working steps: 1) Unzip attached code and project to C:\Freescale\KSDK_1.1.0\usb\example\device\hid folder. 2) Compile project (IAR) and download to FRDM-K64F via CMSIS-DAP debugger. 3) Open Bus hound, enter "Devices" table and uncheck all box and check "auto select hot plugged devices". 4) Plug USB cable and connects to PC, will found the device is checked in bus hound device tree. 5) Double click device, and select OUT endpoint to send 16 bytes to device. 6) Observe the g_OUT_ep_buf[]'s change in firmware (Demostrate receive function only)
View full article
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;   }   }  
View full article
Hello dear community:   The attached document is an introductory guide to the Clock configuration system and Power manager system in KSDK v1.3 and its configuration using Processor Expert.   Some topics covered:   - KSDK Clock Manager system- Clock manager notification framework - Clock switch callbacks - KSDK Power Manager system - Power manager notification framework - Power mode switch callbacks - Creating and managing clock/power configurations with Processor Expert. - Managing custom clock/power callbacks with Processor Expert.   There is also an example project attached created for the FRDM-KL27Z board, but it can be taken as reference to use a different evaluation board or custom board. This project was developed by colleague Adrian Sanchez Cano.   I hope you find it useful. In case of any doubts please do not hesitate to ask.   Regards! Jorge Gonzalez
View full article
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.
View full article
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.
View full article
Very simple, but very often asked question - how can I import example in KSDK general? The easiest way is import .wsd file, it is a set of all needed files for your project.   1. Open KDS, go to Project Explorer Window and by right click select Import option 2. Choose Existing Projects Sets option 3. Click on Browse and select the project, which you would like to work. In case of KSDK 2.0 go to C:\Freescale\<ksdk2.0_package>\boards\frdmk64f\demo_apps\lwip\lwip_tcpecho\freertos\kds   4. You will see the demo project successfully imported in your Project Explorer window and now you can compile and execute demo project.   Enjoy! Iva
View full article
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().
View full article
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.
View full article