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

1.基于CMSIS-DAP的脱机编程工具         飞思卡尔的FRDM开发板都板载OpenSDA仿真器，该仿真器基于MK20DX128VFM5芯片，内部由Bootloader和app所组成，当用户按下Reset按钮后再插上USB接口，此时会进入Bootloader模式，此时PC端会出现一个名为Bootloader的可移动存储器，用户可以通过拖入预编译好的*.SDA升级app，更新v114版本的app后，重新插拔USB即可生效，此时会枚举出虚拟串口，仿真器以及MSD的可移动存储器。Bootloader占用了MK20DX128VFM5内部从0开始到0x5000的地址，App从0x5000地址开始。        CMSIS-DAP(mbedmicro/CMSIS-DAP · GitHub)是ARM公司的一个开源项目，它提供了一个基于Web的开发环境(mbed | welcome), 开发环境提供了基于C++的开发库，用户可以通过Web编程，然后下载编译好的bin文件，通过CMSIS-DAP烧写到FRDM开发板中。CMSIS-DAP与OpenSDA类似，也是由Bootloader和app所组成，最大的区别是CMSIS-DAP的Bootloader占用的地址为0x0~0x8000。        由于CMSIS-DAP是Apache License开源的，通过修改其Bootloader代码可以比较容易的做出一个脱机烧写器参考。        1. 添加SWD的访问接口。        2. 修改链接文件，默认Bootloader是运行在0地址上的，而实际编程工具最好运行在0x5000或者0x8000这两个地址上，这样不需要通过仿真器对于MK20DX128进行编程即可更新其内容，同时也可以轻松在仿真器及烧写器间进行切换。        3. 修改MSD烧写文件的地址，默认Bootloader是烧写从0x5000或者0x8000开始的地址，而这个地址现在放的是脱机烧写器代码，所以需要向后移动到0x10000，并将目标文件大小存放在0x1F800地址上。脱机烧写器由于将目标文件存放在K20芯片内部，所以受到K20内部flash大小的限制，只能烧写目标文件小于60K。        4. 添加编程算法工程，由于目标芯片内部的flash需要不同的驱动，所以可以将他们生产的算法代码先放到K20内部0x1FC00的地址上，烧写器开始工作时，先将编程算法通过SWD下载到目标文件的RAM中，并修改目标芯片的SP PC指针，让其运行。编程算法与烧写器的运行程序通过RAM进行交互。 参考代码下载地址： hudieka/OpenSourceOfflineProgrammerTools · GitHub 具体使用方法可以参考附件：

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固件程序​

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

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 开发板

主板原理图。

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

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

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...

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.

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

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

for M68HC08, HCS08, ColdFire and Kinetis MCUs by: Pavel Lajsner, Pavel Krenek, Petr Gargulak Freescale Czech System Center Roznov p.R., Czech Republic The developer's serial bootloader offers to user easiest possible way how to update existing firmware on most of Freescale microcontrollers in-circuit. In-circuit programming is not intended to replace any of debuging and developing tool but it serves only as simple option of embedded system reprograming via serial asynchronous port or USB. The developer’s serial bootloader supported microcotrollers includes 8-bit families HC08, HCS08 and 32-bit families ColdFire, Kinetis. New Kinetis families include support for K series and L series. This application note is for embedded-software developers interested in alternative reprogramming tools. Because of its ability to modify MCU memory in-circuit, the serial bootloader is a utility that may be useful in developing applications. The developer’s serial bootloader is a complementary utility for either demo purposes or applications originally developed using MMDS and requiring minor modifications to be done in-circuit. The serial bootloader offers a zero-cost solution to applications already equipped with a serial interface and SCI pins available on a connector. This document also describes other programming techniques: FLASH reprogramming using ROM routines Simple software SCI Software for USB (HC08JW, HCS08JM and MCF51JM MCUs) Use of the internal clock generator PLL clock programming EEPROM programming (AS/AZ HC08 families) CRC protection of serial protocol option NOTE: QUICK LINKS The Master applications user guides: Section 10, Master applications user guides. The description of Kinetis version of protocol including the changes in user application: Section 7, FC Protocol, Version 5, Kinetis. The quick start guide how to modify the user Kinetis application to be ready for AN2295 bootloader: Section 7.8, Quick guide: How to prepare the user Kinetis application for AN2295 bootloader.

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

Kinetis E series MCUs target to applications where require high performance on EMC/ESD. With 5V power supply and robust IO design, Kinetis E series MCUs can help customer for a robust design. Here take a Microwave Oven demo as example, shares how to make a robust design with Kinetis E Series MCU, from hardware, software perspective.

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:

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

           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.