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!

MCUXpresso Pins Tool allows you to configure pin routing and generates ‘pin_mux.c & h’ source files. This article describes how to configure Pins in a FreeRTOS project with MCUXpresso pins tool.  In this example, pin PTC9 on Freedom-k66 board is configured.   Software and Tools In this article, I’m using the following: MCUXpresso IDE 10.2.1   www.nxp.com/mcuxpresso ,  MCUXpresso SDK 2.4.1 for  Frdm-k66f  board.  With Amazon FreeRTOS v10 .You can get it from https://mcuxpresso.nxp.com FRDM-K66 board www.nxp.com/frdm-k66f First, we need to have a working FreeRTOS project. Here we import the freertos_hello example into MCUXpresso IDE workspace. To open the tool, simply right click on the project in Project Explorer and select the appropriate open command. Then we can see the pin table, peripheral signals, package/pinout view, Routed pins view, generated code view. Basic configuration can be done in either of these views Pins, Peripheral Signals or package. More advanced settings can be adjusted in Routed Pins view. Beginning with Peripheral selection In the Pins view on the left find a pin and peripheral signal in the table and configure the routing by clicking on the signal cell.   In this example, select PTC9.  Click into the cells to make them ‘green’ Select PTC9 on the Peripherals signals view, Routed Pins configure Route the selected signal to the desired pin,and configure it in the Routed Pins view. It is possible to easily identify routed pins/peripherals in the package using highlighting. By default, the current selection (pin/peripheral) is highlighted in the package view. State Indicator of Pin Tool Green indicates pin/peripheral is routed Yellow indicates pin/peripheral is currently selected Red indicates an error Light grey indicates pin/peripheral is available but is not currently routed. It is also possible to configure the pin electrical features. Use the table drop down menu to configure the pin. To configure pins, start from left to right—select the peripheral first, then select required signal, and finally select the routed pin. Code generation  The Pins Tool automatically generates the source code for pin_mux.c and pin_mux.h on the right panel of the Code Preview view. The configuration will be saved into .mex file, see picture below Export the code.   You can now copy-paste the content of the sources to the application and IDE. Alternatively, you can export the generated files. To export the files, select the menu  Export Click Next and specify the directory, Click Finish to export the files. Integrate code the FreeRTOS task In the source code, Board_InitBootPins() calls initial code in pin_mux.c/h In hello world task, we toggle the configured pin /*!  * @brief Task responsible for printing of "Hello world." message.  */ static void hello_task(void *pvParameters) {     for (;;)     {         PRINTF("Hello world.\r\n");         /* Toggle LED. */         GPIO_PortToggle(BOARD_LED_GPIO, 1U << BOARD_LED_GPIO_PIN);         vTaskDelay(200);     } }   Then run the example, we can see LED is toggled every 200ms.   For information about how to create an FreeRTOS project with MCUXpresso IDE, please see the following document https://community.nxp.com/docs/DOC-341972  For information about configuring with MCUXpresso peripheral tool in an FreeRTOS project, please see the following document. https://community.nxp.com/docs/DOC-341986

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

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

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

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

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

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

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

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

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

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

LwIP is a small independent implementations of the TCP/IP protocol suite that has been initially developed by Adam Dunkels . The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This makes lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM.  Currently LwIP 2.1.2 is ported to Kinetis and I.MX RT families in MCUXpresso SDK 2.6 . Features: LwIP comes with the following protocols: IPv4 and IPv6, including packet forwarding over multiple network interfaces. ICMP for network maintenance and debugging IGMP for multicast traffic management MLD (Multicast listener discovery for IPv6).  ND (Neighbor discovery and stateless address autoconfiguration for IPv6) DHCP and DHCPv6. UDP (User Datagram Protocol) TCP (Transmission Control Protocol) Raw/native API for enhanced performance Optional Berkeley -  like socket API. TLS: optional layered TCP for nearly transparent TLS for any TCP-based protocol PPPoS and PPPoE DNS (Domain name resolver incl. mDNS) 6LoWPAN Organization of the LwIP stack Let’s take SDK_2.6.1_EVKB-IMXRT1050 for example, LwIP code in under SDK_2.6.1_EVKB-IMXRT1050\middleware\lwip Port: This folder includes the adapter code which can make the LwIP stack run on the bare metal and FreeRTOS. Enet_ethernetif.c/h: Adapt the LwIP stack to the underlying MCUXpresso SDK ethernet driver, provides ethernet interfaces , like  phy init and  ethernetif_input. cc.c/h: provide typedefs, compiler hints for packing and platform specific diagnostic output. Perf.h: architecture specific performance measurement, current the definitions is NULL, reserve for future use. Src: This folder includes the latest stable LwIP 2.1.2 source code which can be downloaded from below link download.savannah.gnu.org/releases/lwip/ --api: netconn and socket API files --core: LwIP core files --include: LwIP include files --netif:  network interface files LwIP APIs overview LwIP provides three application programming interfaces (API) for programmers to use for communication with the TCP/IP code: Raw APIs:   Non thread-safe APIs, callback style for maximum performance and minimum memory footprint. Program execution is driven by callbacks functions, which are then invoked by the lwIP core when activity related to that application occurs. A particular application may register to be notified via a callback function for events such as incoming data available, outgoing data sent, error notifications, poll timer expiration, connection closed, etc. An application can provide a callback function to perform processing for any or all of these events. Sequential-style APIs:    blocking functions. More overhead, but can be called from any thread except TCPIP thread. The sequential API provides a way for ordinary, sequential, programs to use the lwIP stack. It is quite similar to the BSD socket API. The model of execution is based on the blocking open-read-write-close paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP code and the application program must reside in different execution contexts (threads). Socket API: BSD-style socket API.  The socket API is a compatibility API for existing applications, currently it is built on top of the sequential API. It is meant to provide all functions needed to run socket API applications running on other platforms. TCP Raw API   API function Description TCP connection setup   tcp_new() Creates a new TCP PCB tcp_bind() Binds a TCP PCB to a local IP address and port tcp_listen() Starts the listening process on the TCP PCB. tcp_accept() Assigns a callback function that will be called when a new TCP connection arrives. tcp_connect() Used to connect to a remote TCP host. Sending TCP data tcp_write() Queues up data to be sent. tcp_output() Forces queued data to be sent tcp_sent() Assigns a callback function that will be called when sent data is acknowledged by the remote host. Receiving TCP data tcp_recv() Sets the callback function that will be called when new data arrives. tcp_recved() Must be called when the application has processed the incoming data packet (for TCP window management). Application polling tcp_poll() Assigns a callback functions that will be called periodically. It can be used by the application to check if there is remaining application data that needs to be sent or if there are connections that need to be closed. Closing and aborting connections tcp_close() Closes a TCP connection with a remote host. tcp_abort() Aborts a TCP connection. tcp_err() Assigns a callback function for handling connections aborted by the lwIP due to errors (such as memory shortage errors). UDP Raw API API Description udp_bind Binds a UDP PCB with a local IP address and port. udp_new Creates a new UDP PCB. udp_send Sends UDP data. udp_recv Specifies a callback function which is called when a datagram is received udp_remove Removes and de-allocates a UDP PCB. udp_connect Sets up a UDP PCB remote IP address and port udp_disconnect Removes a UDP PCB remote IP and port. Netconn API netconn_new Creates a new connection netconn_listen Sets a TCP connection into a listening mode netconn_write Sends data on a connected TCP netconn netconn_accept Accepts an incoming connection on a listening TCP connection netconn_close Closes a TCP connection without deleting it. netconn_send Sends data to the currently connected remote IP/port (not applicable for TCP connections). netconn_bind Binds a connection to a local IP address and port. netconn_recv Receives data from a netconn. netconn_connect Connects to a remote IP address and port. …   Socket API Macro API description accept lwip_accept Accepts a new connection on a socket bind  lwip_bind Binds a socket to an IP address and port shutdown  lwip_shutdown   getpeername  lwip_getpeername   getsockname lwip_getsockname   setsockopt lwip_setsockopt   closesocket  lwip_close   connect lwip_connect Connects a socket to a remote host IP address and port. listen  lwip_listen Listens for socket connections recv  lwip_recv   recvmsg lwip_recvmsg   recvfrom  lwip_recvfrom   send  lwip_send   sendmsg  lwip_sendmsg   sendto lwip_sendto   socket  lwip_socket Creates an new socket. poll lwip_poll   ioctlsocket lwip_ioctl   inet_ntop  lwip_inet_ntop   inet_pton  lwip_inet_pton   read  lwip_read Reads data from a socket readv lwip_readv   write lwip_write Writes data on a socket writev lwip_writev   close  lwip_close Closes a socket (socket is deleted). fcntl  lwip_fcntl   ioctl lwip_ioctl         LwIP Configure Configuration file is placed in application source folder: Lwipopts.h: Lwipopts.h is a user file that you can use to fully configure LwIP and all of it’s modules. You do not need to define every option that LwIP provides; if you do not define an option, a default value will be used. Therefore, your lwipopts.h provides a way to override much of the behavior of LwIP. LwIP Demos in MCUXpresso SDK MCUXpresso SDK comes with lots of demos that use different API sets. Name Description Lwip_tcpecho a TCP echo demo on the lwIP TCP/IP stack with bare metal KSDK or FreeRTOS. The demo uses the TCP protocol and acts as an echo server Lwip_udpecho a UDP echo demo on the lwIP TCP/IP stack with bare metal KSDK or FreeRTOS, which uses the UDP protocol and acts as an echo server. Lwip_ping a Ping Demo on the lwIP TCP/IP stack which using the ICMP protocol lwip_nghttp2cli_mbedTLS an NGHTTP2 client set up on lwIP TCP/IP and the MbedTLS stack with FreeRTOS lwip_mqtt MQTT client connecting to MQTT broker via unsecured socket lwip_iperf check your bandwidth using the network performance measurement IPerf application on a PC as a client or a server lwip_httpsrv an HTTPServer on the lwIP TCP/IP stack with bare metal SDK or FreeRTOS lwip_httpscli_mbedTLS an HTTPS client set up on lwIP TCP/IP and the MbedTLS stack with FreeRTOS lwip_dhcp_usb a DHCP and ping demo on the lwIP TCP/IP and USB stack lwip_dhcp a DHCP client and prints the status as it is progressing

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

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

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

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

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

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