CodeWarrior v10.6 and KDS are integrated development tools which are based on Eclipse, these two IDEs provide easy way to build project when using the GUI, but some engineers still want to build their projects from command line to do automated builds. This document provides examples on how to do it! Build project in CodeWarrior from command line: For a CW v10.6 created project, CW provides the “Make” tool and can also generate the needed “MakeFile” to build this project out of eclipse GUI. The below are the steps: Create and new project “k22_makefile” in CW v10.6, you will see there are two build configurations: RAM & FLASH Launch “cmd prompt” in Windows and go to “eclipse” folder of CW installation Now, you can generate the makefile for configuration FLASH by executing the below command ecd.exe –generateMakefiles –project “C:\workspace_cmd\k22_makefile” –config FLASH Now, checking the “FLASH” subfolder in project location, you will see “makefile” is generated. 4.To use “make” tool convenient, we can define an environment variable pointing to {CW}\gnu\bin where “make” is located. See command as below: 5. Go to the configuration folder “FLASH” where the project’s makefiles are located and run the follow commands to build the project. %MCU_BIN%\make.exe PS: to get more information of make and ecd, please just run the below command: Ecd.exe –help Make.exe –help Build project in KDS from command line: Compare with CodeWarrior, it is much easier to build an application in command mode. KDS provides a command “eclipse.exe” with which you can build a project with only two steps. In this example, I have created an application with name “cmd_ke02”, and the workspace path is “C:\wks_kdscmd”. To build the application in cmd, please first launch command mode in Windows system and then go to {KDS}\eclipse. Then, you need import the application into current workspace in the below command: eclipsec.exe -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data "C:\wks_kdscmd" -import "C:\wks_kdscmd\cmd_ke02" then, build the project with the below command: eclipsec.exe -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data "C:\wks_kdscmd" -build "cmd_ke02" For more details of building project from command line in KDS, please refer: http://mcuoneclipse.com/2014/09/12/building-projects-with-eclipse-from-the-command-line/

by: Carlos Musich, Luis Garabito Microcontrollers Application Engineers with Freescale. This application note is intended to demonstrate http client implementation using Freescale MQX RTOS capabilities. The hardware used to illustrate this is the TWR-K60N512-KIT. The remote controlling and monitoring have become a need rather than an option in the embedded world. This application note takes advantage of two social media interfaces for these purposes. One is used to enter commands to the MCU; http://twitter.com/. The other one is used to pull out data from the MCU; https://www.supertweet.net/. It is important to focus in the fact that with these methods the MCU is reachable through Internet without the need of a public IP address or without mounting a HTTP server in the MCU. The application source code described in this document can be found in the AN4417SW.zip file. For a full description of Freescale MQX RTOS, please visit https://www.freescale.com. This application defines two tasks in MQX. The first task is main. It is meant to configure GPIO, the RTCS and create the second task. The name of this second task is httpclient. The purpose of this task is to carry out the communication with the Twitter server and read the commands to be executed. To retrieve the input commands, the httpclient task reads them from the last tweet published by a specific Twitter account. The command then is parsed and executed according to the implementation. The main task enters into an infinite loop where the httpclient is restarted in each loop to allow a cycle behavior for reading commands. The time for each loop is controlled by a sample rate value that can be configured by the user via a command. Get the full application note...

The following file contains codewarrior code that was migrated from the IAR example code in the sample code package at the freescale webpage. It contains the following examples: adc_demo freedom_greem_led freedom_red_led lcd_rtc_lowpower PIT_basic sLCD_freedom uart_low_power_wu_dut Regards

Reference Solution being developed with Kinetis V (also can be done with a Kinetis K device) of a Class-D audio amplifier. 16-bit ADC sampling the audio input FlexTimer doing the PWM's for the Class-D amplifier DC/DC switched power supply with input of 12V and output of 130V to 180V (generates the power you need for making some good noise - 1kW) being controlled by the Kinetis MCU also. Capabiltiy of Audio processing/filtering using the Cortex-M4 DSP capabilities. Solution originally designed for cost-effective Automotive aftermarket sound systems. But can be adapted for implementing other audio amplifier applications also in the consumer space! Can you thing of cool applications/markets that this solution can be also quickly adapted? Soon, plan to make the reference solution design files available in the community. Stay tunned. Cheers! PK

1. Freedom开发板： 飞思卡尔Freedom开发平台是一套低成本的用于性能评估和软件开发的工具，自带板载调试器，用户可以直接通过自己的PC机快速搭建开发环境并进行测试和评估芯片简单的外设资源。一般来说，同一个系列功能互相兼容的芯片会推出一款Freedom开发板来评估，具体分类如下： Freedom开发板 可以覆盖的芯片型号 开发板代码包 FRDM-KL02Z Kinetis KL02 MCUs KL02_SC FRDM-KL03Z Kinetis KL03 MCUs Kinetis SDK for KL03 FRDM-KL05Z Kinetis KL04 and Kinetis KL05 MCUs KL05_SC FRDM-KL25Z Kinetis KL14, Kinetis KL15, Kinetis KL24 and Kinetis KL25 MCUs KL25_SC FRDM-KL26Z Kinetis KL16 and Kinetis KL26 MCUs KL26_SC FRDM-KL43Z Kinetis KL17, Kinetis KL27, Kinetis KL33 and Kinetis KL43 MCUs FRDM-KL43_SC FRDM-KL46Z Kinetis KL36 and Kinetis KL46 MCUs KL46_SC FRDM-KE02Z Kinetis KE02_20M MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE02Z40M Kinetis KE02_40M MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE04Z Kinetis KE04 MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE06Z Kinetis KE06 MCUs KEXX_DRIVERS_V1.2.1_DEVD 2. TWR开发板： 飞思卡尔塔式系统开发板为可扩展性比较强的评估板，板载资源比较丰富且通过构建塔式系统可以灵活的添加和裁剪外设资源，用户可以通过与相应外设塔式板结合使用进行更高级和复杂的功能测试或验证。 Tower开发板 可以覆盖的芯片型号 Header 3 TWR-KL25Z48M Kinetis KL14, Kinetis KL15, Kinetis KL24 and Kinetis KL25 MCUs KL25_SC TWR-KL43Z48M Kinetis KL17, Kinetis KL27, Kinetis KL33 and Kinetis KL43 MCUs TWR-KL43Z48_SC TWR-KL46Z48M Kinetis KL16, Kinetis KL26, Kinetis KL36 and Kinetis KL46 MCUs KL46_SC TWR-KM34Z50M Kinetis KM3x MCUs KMSWDRV TWR-KV10Z32 Kinetis KV1x TWR-KV10Z32_SC 3. 第三方开发板 (1) MAPS四色板套件 (2) YL-KL26Z 开发板

KL17 reference manual V4.1 and V5.1 with updated Figure 13-2. Kinetis Bootloader Start-up Flowchart at page 179 There with modification to add "is direct boot valid" check. Please check below picture for the detailed info: The "is direct boot valid" check function is not supported for KL17 product, the correct flow chart should be below: The "is direct boot valid" check function is reserved for further parts(such as KL82), which has one bit in BCA filed to control running code in QSPI Flash or internal Flash: Thank you for the attention.

KBOOT learning diary Overview      FSL’s already released the KBOOT v1.1.0 in Dec, 2014 and the v1.2.0 will be released in Jun, 2015. KBOOT is an innovation bootloader solution instead of former and it just seems like a platform for quick and easy programming the Kinetis MCUs. KBOOT will make the developers to save the effort for design the bootloader, even it support the developers to customize the bootloader.        KBOOT provides two ways for implementing, ROM bootloader and Flash bootloader, ROM bootloader is only applicable to the Kinetis MCUs which already integrate the ROM and the KBOOT application reside in it. So the ROM bootloader is available during the entire product life cycle.  The opposite side, the Kinetis MCUs without ROM can be programmed through the Flash bootloader. For the Flash bootloader, it runs into RAM and receive the application image, after it program the image into the Flash completely, then it Flash bootloader will go to die, in another word, it will no longer be available again. Table 1 shows supported Kinetis MCUs. Table 1 Support Kinetis Devices        KBOOT’s supported to program the target through the UART, SPI, I2C, USB HID communication and it will also support the MSD Device and MSD HOST mode, Ethernet, etc in future. And developers can use blhost application or GUI tool as the host tool to communicate with the bootloader, then program the application code in flash via the bootloader. Implementing        In these user guides as follow: Getting Started with the Kinetis ROM Bootloader, Getting Started with the Kinetis Flashloader, Kinetis blhost User's Guide, Kinetis Updater User's Guide, you can find a completely procedure to program the application code via bootloader. Exception However I’ve encountered an issue when I tried to use the blhost application to communicate the FRDM-KL03Z (Fig1), it still couldn’t establish a connection, as Fig 2 shows. Fig 1 Fig 2 Workaround       The issue will disappear after choose a lower baud rate when blhost application communicate with the FRDM-KL03Z board after I validated. And the whole procedure to program application code as follow.       1. Establishes the connection        2. Erases the entire flash array       3. Programs the application code       4. Application code runs

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-335320

Description Thing.... Internet Enabled..... with command line and GUI over a TCP connection Parts Fantasma Toys Hand Runner: http://www.newegg.com/Product/Product.aspx?Item=9SIA0190BB9057 FRDM-K64 : http://mbed.org/platforms/FRDM-K64F/ RN-XV: https://www.sparkfun.com/products/10822 FRDM-AUTO: https://community.freescale.com/docs/DOC-99621 GUI Code:  https://github.com/ehughes/InternetofThing MBED Code: http://mbed.org/users/emh203/code/InternetOfThing/wiki/internet_of_thing Action Shots

Hello. I am trying to use a PIT interrupt. I had never used Kinetis so there are certain things which with I am not familiarized yet. once i have created de PE code, cleaned and then I build the proyect, the following error pops up 'undefined reference to int_disp'. What it is about? Where should I write my ISR fuction? Does the ISR pit function has to have an specific name so as to be recognised by PIT.c?

1. AN5218-使用LPUART实现ISO7816接口功能​ 2. AN4373-Cookbook for SAR ADC Measuresments 3. AN5160-低功耗模式下使用UART唤醒Kinetis L系列MCU的方法​ 4. AN4905-Kinetis MCU 上支持无晶振 USB​ 5. AN3298-Kinetis芯片焊接温度曲线控制​ 6. AN5034-FleIO模拟UART​ 7. AN4752-FreeMaster的使用方法​ 8. AN4282-使用Kinetis的FlexMemory作为EEPROM的方法​ 9. AN4655-使用I2C接口引导更新Kinetis L系列MCU​ 10. AN4368-使用U盘方式更新带USB Host功能的Kinetis固件程序​

1. Introduction MCUboot is a common used bootloader for most of Kinetis and i.mx RT devices. It can support download application via UART/USB/CAN/I2C/SPI. It enables quick and easy programming of Kinetis MCUs and i.mx RT MPU through the entire product life cycle, including application development, final product manufacturing, and beyond. K64 is a very popular device in Kinetis family. It has a M4 core, 512k and above flash, 120M main frequency and plenty of interface, such as I2C/SPI/UART/CAN/USB/ENET. But it is a bit awkward that the MCUboot demo of K64 is not include CAN. Does K64’s CAN can’t support bootloader application? No, of course not. Here we are going to port CAN function to K64 bootloader. There are two kind of CAN peripheral in Kinetis family, FlexCAN and MSCAN. FlexCAN is more complex than MSCAN. K64 has a FlexCAN. To speed up our work, we can port FlexCAN driver and related code from TWR-KV46 bootloader. Hardware: two TWR-SER board two sets of TWR-ELEV TWR-K65F150M TWR-K64F120M   Software: MCUXpresso 11.0 MCUBoot 2.0.0 package SDK_2.6.0_TWR-K64F120M 2. Software porting Step 1, copy below files to twrk64f120m_tower_bootloader project. \drivers\fsl_flexcan.c \drivers\fsl_flexcan.h        \source\bootloader\src\flexcan_peripheral_interface.c   Step 2, modify the project to enable the FlexCAN.       In bootloader_config.h, change BL_CONFIG_CAN definition to 1.        In peripherals_MK64F12.c, add #if BL_CONFIG_CAN     // CAN0     {.typeMask = kPeripheralType_CAN,      .instance = 0,      .pinmuxConfig = can_pinmux_config,      .controlInterface = &g_flexcanControlInterface,      .byteInterface = &g_flexcanByteInterface,      .packetInterface = &g_framingPacketInterface }, #endif    // BL_CONFIG_CAN       Pin mux setting. In peripherals_pinmux.h, add #define BL_ENABLE_PINMUX_CAN0 (BL_CONFIG_CAN) //! CAN pinmux configurations #define CAN0_RX_PORT_BASE PORTB #define CAN0_RX_GPIO_PIN_NUM 18             // PIN 13 in the PTA group #define CAN0_RX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 RX functionality for pin 13 #define CAN0_TX_PORT_BASE PORTB #define CAN0_TX_GPIO_PIN_NUM 19             // PIN 12 in the PTA group #define CAN0_TX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 TX functionality for pin 12       Set clock. FlexCAN clock source can be OSCERCLK or bus clock. Here we use bus clock run at 48Mhz. In flexcan_peripheral.c, add these code. const flexcan_timing_config_t bit_rate_table48m[] = {     { 23, 3, 4, 4, 4 }, /* 125 kHz */     { 11, 3, 4, 4, 4 }, /* 250 kHz */     { 5, 3, 4, 4, 4 },  /* 500 kHz */     { 3, 3, 4, 4, 4 },  /* 750 kHz */     { 2, 3, 4, 4, 4 }   /* 1   MHz */ }; change line 621 FLEXCAN_SetTimingConfig((CAN_Type *)baseAddr, &bit_rate_table48m[s_flexcanInfo.baudrate]); Step 3, compile the project.   3. Function test Software preparation To connect bootloader via CAN bus, NXP has TWR-K65 as bridge. But its source code is not in K64 SDK. It is in MCUBoot2.0.0 package. User can download the package from https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuboot-mcu-bootloader-for-nxp-microcontrollers:MCUBOOT The bridge project is called buspal which can be found in NXP_Kinetis_Bootloader_2_0_0\apps\bus_pal\MK65F18. BusPal is an embedded software tool that is available as a companion to blhost. The tool acts as a bus translator with an established connection with blhost over UART and with the target device over I2C, SPI, or CAN, and assists blhost in carrying out commands and responses from the USB target device. The BusPal is available for selected platforms. The source code for BusPal is provided with the Kinetis bootloader release, it support FRDM-KL25, TWR-KV46F150M and TWR-K65F180M and can be customized to run on other platforms. More detail of buspal is in Kinetis blhost User's Guide appendix C.   Hardware connection TWR-SER has TJA1050 as transceiver. We can connect J7 on both boards. When construct the Tower system, user should take care the power. The power tree is very flexible. Improper setting may cause TJA1050 can’t work.   The Buspal project on TWR-K65F180M use UART1 to connect with computer. The port is on TWR-SER. To make the connection simple, we can share the openSDA UART port. The openSDA UART use UART2, we can jump UART1 signal to J33 and J34 on K65 tower board.     Testing: Open a command window, type >blhost -p com4,57600 –buspal can,0,321,123 – get-property 10 This command can check if the whole system work properly. Then, you can download the code to K64 now. Please type >blhost -p com4,57600 –buspal can,0,321,123 – flash-image xxxxxx.s19 erase

主板原理图。

I have included the files needed to mass erase the flash of the MCU and re-program another binary.   The procedure is shown in the folder " FRDM-KW31_FAT_added_2019" Summarizing you... 1) update the debugger with bootloader mode (press reset and plug in usb cable) drag and drop .sda file on MSD bootloader. 2) unplug and re-plug USB. program the flashloader_loader_mkv31f512.bin by dragging and dropping the binary on to the virtual mass storage device FRDM-KV31 which appear when you plug the USB cable from the FRDM-KV31 to the PC.  3) Open a CMD prompt window and navigate to the folder the files were unzipped to. 4) Determine the COM port by using the device manager 5) from the CMD prompt run the batch file      Erase_KMS_program_bubble.bat COMX

Test Environment: FRDM-KL43Z Rev. A MCUXpresso IDE v10.2.0 MCUXpresso SDK for FRDM-KL43Z V2.4.1(2018-06-18) Create new project in MCUXpresso IDE select [New project...], there will pop the SDK Wizard panel, then select [frdmkl43z]: Then, click [Next] will enter into [Configure the project] panel, we can set the [Project name] and select [flexio_i2s] in [driver]: Click [Finish], the new project was created. In general, the project is based on [hello_world] project with board default console available. In [Project Explorer], we could find the <fsl_flexio_i2s.c> & <fsl_flexio_i2s.h> & <fsl_flexio.c> & <fsl_flexio.h> files in drivers folder: Edit the code The application note AN5397 detailed introduce how FlexIO emulate I2S bus communication. The MCUXpresso SDK <flexio_i2s> driver using the AN5397 showed second solution to use two timers and two shifters. Please check here to get more detailed info. The I2S signal was below, we need to use four FlexIO pins to provide: BCLK, Fss, TxData & RxData. In <pin_mux.c> file, it need to config pin function, we use PTD7 pin provide I2S BCLK clock; PTD6 pin as I2S Frame_sync pin; PTD5 pin as Tx data pin; PTD6 pin as Rx data pin; In <frdmkl43z_flexio_i2s_interrupt_tx.c>,  config flexio_i2s and config the audio frame format: Please check attached source code for the detailed project info. Test result From the actual measured I2S signal, it shows the 8 bytes was sent out:

在工业热电偶数据采集与处理方面，ADI，MAXIM的模拟芯片几乎占据了90%以上的市场，尽管他们的单片售价高的吓人。1片16位的AD芯片没有个2个美金是买不到的，24位的更不用多说。现在他们的竞争对手来了，飞思卡尔针对表计市场推出的基于M0+内核的KM1x，KM3x，片上集成24位的Σ-Δ模拟前端, 其中2路带有独立的可编程最高32倍PGA，无论是市场上应用最多的K型热电偶、还是专注于低温测量的T型热电偶，通过合理的配置都可以满足他们极宽范围的量程。确切的讲，KMxx和这两种产品根本不能算是一个数量级的PK对手，无论从资源上还是从价格上。但是尽管这样，就一定能打败竞争对手吗？首先得有的说服力的参考设计吧，不着急，已经开始设计了。 处理器：MKM33Z128CLH5 暂定功能： 1. K型热电偶+T型热电偶兼容采集处理，板上预留2种热电偶接口，带冷端温度补偿功能 2. 按键切换热电偶类型 3. 段码式LCD显示采集的实时温度，状态显示 4. 低功耗演示，面向手持式设备市场 5. 音乐变调蜂鸣器 主要针对竞争目标：Maxin的 MAX31855KASA （T型热电偶） 关于精度嘛，等参考设计完成了测试一下就知道了。 以上参考设计敬请等待，也欢迎多提宝贵建议。

           This is a demo of NFC device to read and write the contactless card. Kinets K60 tower board and NXP PN512 board are used for this test enviroment. These connected pins from K60 tower board to PN512 RF board are listed as below:   SPI1:     SPI1_SIN : PTE1/SDHC0_D0     SPI1_SCK : PTE2/SDHC0_DCLK     SPI1_SOUT : PTE3/SDHC0_CMD     SPI1_PCS0 : PTE4/SDHC0_D3     Reset:     PTB9   External interrupt:     PTA26         Because the SPI1 port is used as the host interface of pn512, it is necessary to enable the SPI1 driver in the user configuration file of MQX.           To open the project file in the /build folder with CW10.5.    And the PSP and BSP libraries had to be built before test image is built, as they are needed in this test project.   The following diagram shows the serial numbers and block data of reading from the test card of Mifare one.

Hello Freedom community users Bheema has posted on the Element14 community a very clear tutorial (accessible following the link below) to create from scratch a basic project example featuring the SLCD of the FRDM-KL46Z with Processor Expert. Freescale Freedom development platform: [FRDM-K... | element14 Those steps should be very useful to create your own project featuring SLCD display and better understand the constraints of this peripheral. Happy SLCD Displaying Greg

Hello all,      So, this time there is a query on implementing IRDA communication by bit banging the GPIOs. So, I come up with an experiment to do so. Before that, why bit banging when KE02 supports IR communication right away by using FTM at TX and ACMP at RX? something similar to this Implementing infrared functions on UART0 with FRDM-KE02Z platform.        The answer lies in the waveform attached. In the code from the above discussion, the PWM modulation is performed on FTM channel for transmission, while the communication that customer required was different and the waveform required is the one attached.                                                                                           Note that the IRDA transmitter on FRDM-KE02Z is connected to UART0. But, in the attached code, UART0 is not configured for IRDA_TX. while ACMP is used for RX.      This post is intended to be a reference to those who want to implement IRDA with 3/16th bit width by bit banging.      Here is the schematic snapshot of the FRDM-KE02.   There are 2 sets of codes attached. 1. FRDM_KE02_singleboard_IRDA_BITBANGING_TX_RX - IRDA on a single board. 2. FRDM_KE02_interboard_IRDA_BITBANGING_TX_RX - IRDA between 2 boards.   To run a single board demo, the orientation of IRDA Transmitter and IRDA receiver is already taken care as both are on the same board. But, to run the second demo, the orientation is supposed to be something like this.   Both the demos are configured for 9600baud to communicate with PC. And the IRDA communication is at 2400baud.      The figure in page 13 of this document is referred while development. http://www.vishay.com/docs/82513/physical.pdf                                                                            Transmission - 1. The bit width is calculated depending on the required IRDA baud and PIT1 modulo is adjusted accordingly. There are 3 MOD values initialized one after the other to generate required IR frame. 2. The data to be transmitted is sent over the HyperTerminal @ 9600baud. This data is accordingly transmitted on PTB1.      The green waveform in the below oscilloscope snap is the IR frame from the above picture. The data being sent is 'e', the hex value of which is 0x65 which can be made out from the waveform. 0x65 is 0xa6 in reverse since LSB is sent out first in the IRDA protocol[The first logic high is the start bit. In IRDA transmission, logic low is data '1' and logic high is data '0'].                                                                                      Reception - 1. ACMP0 is configured to generate interrupts on either the rising edge or the falling edge. 2. The falling edge of the start bit triggers ACMP. 3. The logic received on PTA1 is decoded to arrive at the received data. 4. The falling edge on ACMP channel decides logic 0 and the PIT0 interrupt decides the logic 1.      The below waveform is the one probed at PTA1.                                                                     Thanks, Pramod TM