Hello Kinetis fans, This time I bring to you a document which explains what is and how to configure channel linking feature which is present in the Enhanced Direct Memory Access (eDMA). If you are interested in the scatter/gather feature, please take a look into the document What is and how to configure the eDMA scatter/gather feature. I hope you find this document useful. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

Hello Kinetis fans, This time I bring to you a document which explains what is and how to configure scatter/gather feature which is present in the Enhanced Direct Memory Access (eDMA). This document includes an example project for the Kinetis Design Studio (KDS) which works in the FRDM-K64F board but the configuration is the same for any MCU which includes the eDMA peripheral. If you are interested in the channel linking feature, please take a look into the document What is and how to configure the eDMA channel linking feature​. I hope you find this document useful. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

When you go with your laptop to a public place and you don't have a wi-fi connection available you can connect your cellphone in the USB port of your computer, turn on the USB tethering feature of your smartphone and you get full acess to the internet using your carrier data plan. The USB tethering uses the the RNDIS protocol and is easy to implement on a laptop.   But how to connect a Kinetis to the internet using a cellphone?   I'm sharing the the first version of the implementation I made of the RNDIS protocol.It's based in the KSDK 1.3 + MQX + LwIP and it can be used for reference in other projects. It's only a first release and I plan some additional implementation, bugfixes and support for other Kinetis boards in the near future but it already can be useful in some projects. Initially it only supports FRDM-K22F and FRDM-K64F but it can be implemented in any MCU with USB controller and enough FLASH. It's a low-cost and simple way to connect your MCU to the internet when you don't have a Ethernet cable available or an Wi-fi connection or a 4G module available in your board.   Introduction   This project implements the RNDIS protocol on the top of the USB Host Stack and in the bottom of the LwIP (TCP/IP stack). When a cellphone is connected to a freedom board, it acts as a USB device and the Freedom board acts as a host.   * Software implementation * Cellphone connected to a FRDM-K64F providing internet connection to the board   The user can design his own software in the top of the TCP/IP stack (LwIP) like if it's connected through an ethernet cable.   Demonstration   To run the demo you will need the KDS 1.3 (www.nxp.com/kds).   To load all the projects needed to your project you have to extract the .zip file and in KDS go to File -> Import, Project of Projects -> Existing Project Sets, and browse to the *.wsd file present in the folder:   USB_RNDIS\KSDK_1.3.0\examples\[your board]\demo_apps\lwip\usb_tethering_demo\usb_tethering_demo_mqx\kds   It will import all the needed project in to your workspaces so you will be able to build all the projects and flash it into your board.   With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:     Connect your cellphone in to the USB of the MCU. After connect the phone turn on the USB tethering feature and wait some seconds:   The Freedom Board will be connected to the internet. As an example, this demo connects to an HTTP server in the internet, download to MCU some data (Lastest news from an newspaper website) and displays it through the Serial connection.   You can modify this demo for your own application, using the TCP/IP and UDP/IP provided by the LwIP.   Typical Aplications   - Low-cost temporary internet connectivity to the MCU. - Remote updat (i.e.: bootloader through USB downloading the new firmware direct from the web) - Remote control - Remote diagnostics   Known Issues and Limitations: - This first version was only full implemented for FRDM-K22F and FRDM-K64F. I can implement for other boards through requests. - It was tested on Android Phones (Samsung Galaxy, Motorola G, Motorola X). I don't have a iPhone to test yet. - Some cellphones need additional current to detect that is attached to a host.A external power is needed in this situation.For FRDM-K64F I suggest to use the J27 footprint to provide 5V and short the diode D13. - Not all the RNDIS messages was implemented yet, only the most fundamental ones. - There's a flash size limitation due the size of the TCP/IP stacks ( that requires a considerably space of flash). It can adapted in the future for stacks with smaller footprint. - Only support KDS 3.0 at this time. And it only supports MQX at this time.   Let me  know if you have any question. Hope it can be useful!   1-      With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:

This document covers some of the more common questions about the new Kinetis K8x family. Any new specific issues or questions should be posted into it's own thread, and will be added to this document as appropriate. Kinetis K80 Basics What is the K8x family? It is a new Kinetis family of Cortex-M4F devices, running up to 150MHz, that include 256K of Flash and 256K of SRAM. It features FS USB, SDRAM, QuadSPI, SPI, I2C, LPUART, and much much more. How does the Kinetis K8x family differ from other Kinetis K families? The K8x family offers the same advantages and compatibility as other Kinetis K families, but also offers several new features not found on other Kinetis K families: QuadSPI Support Dual Voltage Domains (independent VDDIO domain down to 1.8V for QuadSPI or other interfaces) EMVSIM (Euro, MasterCard, Visa Serial Interface Module) FlexIO Additionally the K81 and K82 families offer the following new security modules: LTC (Low Power Trusted Cryptography) Encryption / Decryption algorithms in hardware (as opposed to using mmCAU s/w libs) OTFAD (On The Fly AES Decryption) Zero latency decryption when executing encrypted code from QuadSPI Secure RAM 2KB of Secure Session RAM Because of the addition of a second voltage domain and QuadSPI, there is no hardware pin compatibility with previous Kinetis derivatives. However there is significant module and enablement re-use, so if you’re familiar with other Kinetis devices, it will be easy to get started with the K80. Where can I find reference manuals, datasheets, and errata? These can be found on the K8x documentation pages. Detailed information on the K81 is under NDA, so please contact your NXP sales representative for those documents. What’s the difference between the different K8x devices? K80 is the base version, which includes QuadSPI controller, SDRAM controller, FS USB, and much more. K81 adds DryIce Tamper Detect and the LTC/OTFAD modules K82 adds just the LTC/OTFAD modules K80 and K82 families have the same pin out for their respective packages. The pinout for K81 is slightly different but can still be compatible. What boards are available to evaluate the K80 family? FRDM-K82F: A Freedom board with a 100LQFP K82 device. Also includes dual QuadSPI, touch pad, Arduino compatible footprint, and FlexIO header compatible with OV7670 camera. TWR-K80F150M: A Tower board with 121XFBGA K80 device. Includes dual QuadSPI, SDRAM, EVMSIM, SDCard holder, touch pads, and more. TWR-POS-K81: A Point of Sale reference design board in tower form factor. This board is only available via your NXP sales representative. The K8x MCU Family Hardware Tools selection guide has more details on board differences. What packages are available? The 100 LQFP and 121 XFBGA packages are lead packages available today. The 144 LQFP package and the WLCSP are part of the Package Your Way (PYW) program, and you should contact your NXP sales representative if interested in those packages. What is the difference between K8x and KL8x families? The KL8x family shares many of the same features as the K8x family. The biggest differences are that the KL8x family uses the Cortex-M0+ core (instead of Cortex-M4F), has a lower max clock speed, and has less internal Flash and RAM. It also reduces the instances of peripherals available, but still includes QuadSPI, FlexIO, LTC, and BootROM peripherals like on the K80. See the KL8x Fact Sheet for more details. KL8x devices will be available in the first quarter of 2016. Software/Tools Where can I find instructions and details on the hardware used to evaluate the K8x family? FRDM-K82F: http://nxp.com/frdm-k82f/startnow​ TWR-K80F150M: http://nxp.com/twr-k80f150m/startnow ​ Which version of Kinetis SDK supports the K8x family? Kinetis Software Development Kit (KSDK) support is split depending on the evaluation platform. For TWR-K80F150M, support can be found in the Kinetis SDK 1.3 Mainline Release. For FRDM-K82F, support can be found in the Kinetis SDK FRDM-K82F Stand-alone release. Note that the FRDM-K82 standalone release is truly standalone, and does not require the mainline release to be installed. How do I run the FRDM-K82F OV7670 camera demo? See this Community post: https://community.freescale.com/docs/DOC-329438 How can I use the micro SD card reader on the TWR-K80F150M? Because the SD card signals are shared with the QuadSPI signals, the SD card slot is not connected by default. See section 3.14 of the TWR-K80F150M User Guide for details on how to connect it, with the understanding that QuadSPI will not be available on the board while using SDHC. How do I use the SDRAM on the TWR-K80F150M? See section 3.9 of the TWR-K80F150M User Guide. Due to the layout of the board, the OpenSDA UART feature cannot be used while running the SDRAM as jumpers J6 and J8 need to be removed. QuadSPI What is QuadSPI Flash? Why should I use it? QuadSPI is a name for a popular type of serial NOR flash memory that is SPI compatible, but also allows for multiple data lines (up to 4 per device, or 8 if done in parallel) with bi-directional data for increased memory bandwidth. The QuadSPI controller on the K8x also allows for Execute-In-Place (XIP) mode so that code can be executed out of this external memory. QuadSPI memory can be used for either extra memory storage or for extra code space, or a combination of both. After initialization, it appears as a readable area of memory starting at 0x6800_0000 (as well as at the alias regions). How can I program the QuadSPI? There is an example application in Kinetis SDK that shows how to program the QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\driver_examples\qspi For programming an entire application, the ROM bootloader can be used. Details are in the K80 Bootloader Tools Package. The Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. There is also an example Kinetis SDK application that runs out of QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi_alias What performance tips are there if doing QuadSPI XIP? A few key performance factors: Ensure both the data and instruction cache is enabled Use as many data lines as possible (4, or 8 if available in dual/octal modes) Use DDR mode Any critical code should be placed in Flash/RAM for fastest performance If using XIP, code should be executed out of the QuadSPI aliased address space which starts at 0x0400_0000. A more detailed app note is under development. How do I debug code located in QuadSPI? You must make use of the aliased QuadSPI address space at 0x0400_0000. There is an example of this in the hello_world_qspi_alias example in Kinetis SDK. Due to the architecture of the M4 core on Kinetis, breakpoints cannot be set in the 6800_0000 address space, which is why the alias address space is provided. What app notes are available for the QuadSPI? Because the QuadSPI module found on the K8x family has also been used on other NXP devices, there are some app notes available that can be useful for QuadSPI development. Note that some of the implementation details and features as described in the app notes will be different for K8x, so please use the K8x reference manual for full details. AN4186​ AN4512​ AN4777​ ROM Bootloader Where can I find more information on the bootloader that comes built into the silicon of the K8x family? Download the K80 Bootloader Tools package. If interested in QuadSPI, the Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. The other information found on the Kinetis Bootloader website is also useful as this is what the ROM Bootloader is based off of. What interfaces does the ROM Bootloader support? The ROM Bootloader on the K8x family can interface via LPUART, I2C, SPI, or USB HID (via BLHost) to erase and program both the internal flash and/or QuadSPI flash. This is the same bootloader found on other Kinetis devices, but also includes some more advanced features to support QuadSPI. How can I enter bootloader mode? By default, when using a Kinetis SDK project, the bootloader is disabled and the code immediately jumps to the address in Flash pointed at location 0x4. By asserting the NMI pin at reset though, the part can be forced to enter bootloader mode. This is useful for programming the QuadSPI or interfacing with the bootloader in other ways. This feature is controlled via the FOPT[BOOTPIN_OPT] bit, which the Kinetis SDK code sets to '0' to enable the NMI pin to enter bootloader mode. The NMI button on each board is: FRDM-K82F: SW2 TWR-K80F150M: SW2 The FOPT register (at 0x40C) can be modified to always go into Bootloader mode if desired. Details are in boot chapter of the K80 reference manual. Where is the bootloader configuration data found in Kinetis SDK? The Bootloader Configuration Area (BCA), which begins at address 0x3C0, is defined in C:\Freescale\KSDK_1.3.0\platform\devices\MK80F25615\startup\system_MK80F25615.c starting on line 133. You must also add the define BOOTLOADER_CONFIG in the project settings to let the linker files know to program this BCA area. The FOPT configuration register (at 0x40D) is defined in C:\Freescale\KSDK_1.3.0_K82\platform\devices\MK82F25615\startup\<compiler>\startup_MK80F25615.s and by default is set to 0x3D which disables the bootloader, but does enable the option to enter bootloader via the NMI pin at reset (see previous question) How can I use the UART port on the FRDM-K82F with the BootROM? The OpenSDA/UART lines on the FRDM-K82F use LPUART4, which is not used by the BootROM. If you would like to use the serial UART lines to interact with the BootROM, you can blue wire a connection from either J24 or J1, and connect to R32 (RX) and R36 (TX). This was due to muxing trade-offs. The OpenSDA/UART lines on the TWR-K80F150M are connected to UART1 and thus no modification is necessary for that board. Also keep in mind that you can use the USB interface with the BLHost tool on both boards with no modification. The examples in Kinetis SDK setup the QuadSPI Configuration Block (QCB) data using a qspi_config.bin file. How can I generate my own custom QCB file? There is a C file that come as part of Kinetis SDK (C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi\qspi_config_block_generator.c) or in the KBoot zip file, that can be compiled with various toolchains on a host computer, that will then produce a .bin file. You could import this file, and then after compilation, run it, and it will write out the new .bin to your hard drive. There is a tool under development that simplifies this process by reading in that example .bin file and then you can modify the fields in the app, and then it will write out the modified .bin file. Can I jump directly to QuadSPI for Execute in Place (XiP) after booting? Yes. However note that you must still put the Bootloader Configuration Area (BCA) into internal flash. And you also may want to put the QuadSPI Configuration Block (QCB) in flash as well since it needs to be read before the QuadSPI is setup. Thus even if all your code is in QuadSPI address space, the internal flash must also be written at least once to put in the configuration data. Once you have that set though, then you can develop code by only programming the QuadSPI address space. Troubleshooting I’m having debugger connection issues when using an external debugger, like a Segger JLink. Why? It’s likely that the OpenSDA circuit is interfering, and thus needs to be isolated via jumpers on the board. For TWR-K80F150M: Pull J16 and J17 For FRDM-K82F: Pull J6 and J7 Also make sure you are using the correct debug header for the K8x device on the board: For TWR-K80F150M: J11 For FRDM-K82F: J19 Where is the CMSIS-DAP/OpenOCD debug configuration for the K8x family in Kinetis Design Studio? KDS 3.0 does not support programming the K8x family via the CMSIS-DAP interface. You will need to change the OpenSDA app on the board to either J-Link or P&E as described in the K8x Getting Started guides (Part 3). I can't get OpenSDA on the FRDM-K82F into bootloader mode. Make sure jumper J23 is on pins 1-2 to connect the reset signal to the OpenSDA circuit. On some early versions of the board this was incorrectly installed on pins 2-3 instead. When using IAR with the default CMSIS-DAP debug interface, I sometimes get the error: “Fatal error: CPU did not power up” This is an issue in some older versions of IAR. Upgrade to at least version 7.40.5 which fixes this. When using KDS with the JLink interface with the FRDM-K82F board, I get an error. If you see the error "The selected device 'MK82FN256XXX15' is unknown to this version of the J-Link software." it's because the J-Link driver that comes with KDS 3.0.0 does not know about the K82 family. You can either select a MK80FN256XXX15 device (which is compatible with the K82 on the board) or update the JLink software by downloading and installing the latest JLink Software and documentation pack. At the end of the installation process it will ask to update the DLLs used by the IDEs installed on your computer, so make sure to check the KDS checkbox on that screen. I’m using the P&E OpenSDA App and debugging is not working. I get either "Error reading data from OpenSDA hardware. E17925" or “The system tried to join a drive to a directory on a joined drive” in KDS If using IAR, make sure you have the latest version (7.40.7 or later) If using KDS, you need to update the P&E plugin in KDS. Go to Help->Check for Updates, and select the P&E debug update. Make sure not to select the other debugger updates as it will break it in KDS 3.0.0 (see this thread)

One of the new features that can be found on the FRDM-K82F is the FlexIO header. It’s be specifically designed to interface with the very cost-efficient OV7670 camera, and uses 8 FlexIO lines to read data from the camera. By using the FlexIO feature, it makes it easy to connect a camera to a Kinetis MCU. A demo is included with Kinetis SDK 1.3 which streams the video data from the camera to a host computer over USB. FlexIO: The FlexIO is a highly configurable module found on select Kinetis devices which provides a wide range of functionality including: • Emulation of a variety of serial/parallel communication protocols • Flexible 16-bit timers with support for a variety of trigger, reset, enable and disable conditions • Programmable logic blocks allowing the implementation of digital logic functions on-chip and configurable interaction of internal and external modules • Programmable state machine for offloading basic system control functions from CPU All with less overhead than software bit-banging, while allowing for more flexibility than dedicated IP. Running the Demo: First you’ll need to setup the hardware. An 18 pin header needs to be installed on the *back* of the board. The camera is oriented this way to allow for use of shields on the top, even if the camera is being used. This way the functionality could be extended with WiFi or LCD shields. After the header is soldered on, plug in the camera. It will look like the following when complete: Next we need to program the K82 device with the example firmware. The software can be found in the Kinetis SDK FRDM-K82F stand-alone release, in the C:\Freescale\KSDK_1.3.0_K82\examples\frdmk82f\demo_apps\usb\device\video\flexio_ov7670 folder. Open the project, compile, and program the example specific for your compiler like done for other examples. Make sure you also compile the USB Device library as well. After programming the K82, unplug the USB cable from J5 (OpenSDA) and plug it into J11 (K82 USB). The board will enumerate as a generic USB video device called “USB VIDEO DEMO”. You can then use this device with any video capture software, like Skype or Lync.  Here's a shot of the clock in my cube: The resolution is 160*120, the video image format is RGB565. You may need to manually adjust the focus by rotating the lens on the camera. The frame rate can also be sped up by modifying line 342 in usb_descriptor.c: 5fps: 0x80,0x84,0x1E,0x00, /* Default frame interval is 5fps */ 10fps:  0x40,0x42,0x0F,0x00, 15fps:  0x2A,0x2C,0x0A,0x00, 20fps:  0x20,0xA1,0x07,0x00, The 160*120 max resolution was determined by the amount internal SRAM of the device, as there is not external RAM on the FRDM-K82F board. More Information: One of many places to buy the OV7670 camera module​ OV7670 Reference Manual​ FlexIO Overview ​ FlexIO Training presented at FTF

This is an update to the KE0x Driver Library package with the example projects ported to Kinetis Design Studio (KDS).  These examples support the following boards: FRDM-KE02 FRDM-KE04 FRDM-KE06 The examples were tested with KDS v3.0.0

Hi All, I designed one multi-uarts bootloader project for customers, with which the customers can improve their production efficency in factory. The attached files is the host machine and slave machine bootloader programs and a document for reference. Now the programs can work smoothly on K64 freedom board with three uarts broadcust function. Anybody who has such request can refer to my new program. Best regards David

  对于 Kinetis 芯片来说，发生在工程师调试，小批及量产阶段都经常发生的一个问题就是Kinetis Lock(锁住)，尤其是在刚用这个芯片设计及小批的客户身上，这个错误几乎都会遇 到。附件中的文档将对这个问题作出详细的讨论。

Hi team ,      I would like to share an experiment that about the Fast IO - zero wait state access of KL series . Detail please refer to attached file . Best regards, David

Kinetis芯片在量产时有以下事项需要注意： 1. 保证正确的上电时序，VDD应该先于所有其他引脚上电，VDD上电之前RESET引脚不应该出现高电平。 2. 推荐在RESET引脚加10k上拉电阻，并且和编程器的Reset引脚断开。 3. 编程器至MCU的引线越短越好，最好控制在15厘米之内。 4. 所有引脚不能有超过芯片手册规定之最高电平。 5. 保证焊接温度不超过芯片手册规定之最高温度。

Hello Kinetis World, I just wanted to take this opportunity to share the press release for our newly announced WLCSP device.         http://finance.yahoo.com/news/thin-blade-grass-freescale-newest-120000684.html The Ultra Thin CSP, MK22FN512CBP12R, is equivalent to the standard height CSP, MK22FN512CBP12R.  Therefore, from Therefore, from a software enablement perspective, the MK22FN512CAP12 device can be selected as shown in the attached Processor Expert screenshot.  We're looking forward to seeing what amazing things you can accomplish using Kinetis technology!      

Kinetis M0+ FAQ文档的版本更新历史： Version 1: Basic structure; Version 2: Add 2 items Top highlights, 7 items Common and 7 items Tools; Version 3: add "Cyclone Max 使用步骤及注意事项"; Version 4,5,6: Adjust the FAQ structure; Version 7: Add "Kinetis L 、E、V、M系列选型指南"; Version 8: Add "开源工具"; Version 9: Add "Kinetis SDK"; Version 10,11,12: Add "智能插座"; Version 13: Add “FAQ使用规范” and "Kinetis Bootloader", and Readjust the "参考设计与方案"; Version 14, 15: Add the new motor control solution link into the "参考设计与方案"; Version 16: Add Blogs to "常用网站资料"; Version 17: Push the Kinetis M0+ FAQ Version log histors' information into subpage of "Kinetis M0+ FAQ 版本更新历史"; Version 18: Add "飞思卡尔MAPS开发板资料" into "常用网站资料"; Version 19: Replace "iBeacon" with "BLE"; Version 20, 21: Remove "WIFI" solution, Add "SPI接口读写SD卡"; Version 22: Rename "软件和例程" with "软件和文档", Add "常用的应用笔记" into "软件和文档" list; Click here to return to Kinetis M0+ FAQ main page...​

1.jicheng0622-AET-电子技术应用 2.wuyage-AET-电子技术应用 3.fanxi123-AET-电子技术应用

[EEPROM emulation driver for KEA128 and KEA8] software used for Kinetis EA family product (without integrated EEPROM memory), which using the sector-erasable Flash memory be used to emulate the EEPROM through EEPROM emulation software.  The software could downloaded from here: This document will interpret EEPROM emulation driver demo for KEA128 product and shows how the EEPROM emulation driver works and related API function introduction. 1> EEPROM emulation driver feature The EEPROM emulation driver for SGF/FTM flash family implements the fix-length data record scheme. Several sectors shall be involved in emulation with a round robin scheduling scheme. The EEPROM functionalities to be emulated include initializing, de-initializing, reading, writing records. The EEPROM emulation driver is more complicated than general Flash program data application with following features: User configurable emulated EEPROM size. Larger life for the flash memory used for EEPROM emulation. Unique feature of Cache Table which makes data retrieval fast. Support fix length record scheme only. Support synchronous model which can be run from both RAM and FLASH. When running from FLASH, user needs to relocate flash launch command routine to RAM to avoid Read While Write error. If any operation fails during EEPROM emulation, the driver will try to repeat that operation until successfully for several times (which is defined by user). If that operation still fails, the driver will make the related sector to DEAD to eliminate it from round robin sequence and continue other tasks without stopping driver. Concurrency support via callback. Release in C source code format. Ready-to-use demos illustrating the usage of the driver with different compilers. 2> Demo interpretation The demo routine located at default installation path: ..\\KEA EEPROM Emulation Driver\KEA_SGF180\Demos\build\TRK_KEAZ128\iar\Normal_demo folder. For the demo runs in Flash memory, avoiding Read While Write error happened, Eed_FlashLauchnCommand and g_EECallBack must be relocated to or placed in RAM when the main routine start. Then it will disable the cache and initialize Flash clock(KEA128 ICS module default clock mode is FEI, the default system/core clock is 21MHz, the Flash clock divider value set to 20 to make Flash clock to be 1MHz).   After flash clock initialized, it will initialize EEPROM configuration start address. The status of each sector with five value, which means Blanked, Alternative, Active, Dead and Invalid. The EE_ALLOTED_SECTORS macro will calculate the total number of sectors, which includes Active sectors and Alternative sectors. #define EE_ALLOTED_SECTORS              (EE_ACTIVE_SECTORS + EE_READY_SECTORS) The EE_ACTIVE_SECTORS value is 1 and EE_READY_SECTORS value is 2, so the EE_ALLOTED_SECTORS value is 3. Then there with three allotted sector, and allocated at below address:      eepromConfig.startSecAddr[0] = 0x1A00;      eepromConfig.startSecAddr[1] = 0x1C00;      eepromConfig.startSecAddr[2] = 0x1E00; After initialize start address for EEPROM configuration, following to call Eed_DeinitEeprom() function to erase all sectors used for emulation. Then it will initialize EEPROM emulation, includes to remove dead sector from EEPROM system and determine maximum valid index in array of start sector address after that; also includes initialize all sectors by erasing the “possible-error-sector”; and initialize and update cache table if enabled. It call Eed_InitAllSectors() function to initialize all sectors and allocate the current active sector to base sector. The Eed_ShiftIdxToBase() function will be called to shift the current index to base index of 0. After that, the EEPROM configuration startSecAddr array will change to :      eepromConfig.startSecAddr[0] = 0x1E00;      eepromConfig.startSecAddr[1] = 0x1A00;      eepromConfig.startSecAddr[2] = 0x1C00; The active sector start address at 0x1E00. Then it will program erase cycle value to each sector start address, the erase cycle value will occupy 4 bytes with sector start address offset 0: Then make the base sector to be active and program the active indicator at sector start address offset 8. Here the base sector start address is 0x1E00, the active indicator will be programmed at 0x1E08 with active indicator value 0x55555555: Then it will call Eed_SearchBlankSpace () function to find blank space of EEPROM system, in this demo, the blank space start address at 0x1e0c. If enable the Flash cache, the cache will be cleared and updated during EEPROM emulation initialize phase. The demo will write eight group data to EEPROM system, each group with 16 bytes data, total data number is 128 bytes. The data located at Flash start address is 0x1e0c. After each group data programming, it will following with the data ID info and program the status. With all data was written, the all 128 bytes data was programed at 0x1e00 start EEPROM sector. When the write data exceed the active EEPROM sector, the swapping will occur. The swapped EEPROM sector will record previous data and current write data. If there exist sector erase action, it will also update the erase cycle value. The data is full and the new data written will make swap happens: After swap happens: At the end of demo, it will read EEPROM data back and make sure all valid record ID are written to EEPROM emulation.

@@This article describes how to do in-system reprogramming of Kinetis for Cortex-M4 core devices using standard communication media such as SCI. Most of the codes are written in C so that make it easy to migrate to other MCUs. The solution has been adopted by customers. This bootloader is based on FRDM-K22 demo board and KDS3.0. The bootloader and user application source codes are provided. GUI is also provided. Customer can make their own bootloader applications based on them. The application can be used to upgrade single target board and multi boards connected through networks such as RS485. The bootloader application checks the availability of the nodes between the input address range, and upgrades firmware nodes one by one automatically. Key features of the bootloader: Able to update (or just verify) multiple devices in a network. Application code and bootloader code are in separated projects, convenient for mass production and firmware upgrading. Bootloader code size is small, only around 3k, which reduces on chip memory resources. Source code available, easy for reading and migrating. For Cortex-M0+ products, please refer to here :Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+ , it based on FRDM-KL26. The main difference between Cortex-M4 and Cortex-M0+ is the FLASH program routine. - In Cotex-M4 core kinetis, we need copy the Flash operating routines to RAM. In the bootloader code, the copy to ram code is realized in the function of “FLASH_Initialization()”: Byte buffer[200]={0}; - In Cotex M0+ core kinetis, we do not need to copy the Flash operating routines to RAM. Platform Control Register (MCM_PLACR) is added. The MCM_PLACR register selects the arbitration policy for the crossbar masters and configures the flash memory controller. Enabling ESFC bit can stall flash controller when flash is busy.  Setting ESFC bit can well-balance time sequence of Flash reading and writing – when writing Flash, reading Flash instruction can wait, and vice versa. Using ESFC bit can make our flash programming easier. Thus one Flash can write itself, which is not possible for other one Flash MCU without ESFC bit control. ESFC bit is easy to be set in C code: For more information, please see attached document and code. User can also download the document and source code from Github: https://github.com/jenniezhjun/Kinetis-Bootloader.git

      In the practical KE KEA usage, a lot of customers meet the watchdog can’t reset problems. Some customers find when they want to enable the watchdog, but can’t really enable the watchdog by set the EN bit in register WDOG_CS1; Some customers find when in debug mode, the EN bit WDOG_S1 register always be clear, but from the reference manual, this bit should be set after reset, even they check their code, and make sure they didn’t disable the watchdog;  There also have some customers find when they use the KEXX_DRIVERS_V1.2.1_DEVD code, and set the timeout value register by themselves, but the watchdog can’t reset in the timeout value. Now according to these problems, this document will analyze it and give the recommendation to avoid these problems.      From the above problem description, we can get that there actually mainly 2 reasons caused these problems: 1, software configuration; 2, debugger usage 1.  Software configuration   1) Start code disable the watchdog In the KE KEA sample code, after reset, the chip will enter in the start code at first, the start code always disable the watchdog at first, if the watchdog is disabled, the watchdog can’t be enable just by set the EN bit in register WDOG_CS1, because bit EN in register WDOG_CS1 is the write-once bit after reset. It only can be modified when the UPDATE bit is set and with 128 bus clocks after performing the unlock write sequence. Now how to find the disable code in the start code? Take KEXX_DRIVERS_V1.2.1_DEVD sample code as an example IAR: from crt0.s, will find the watchdog disable code WDOG_DisableWDOGEnableUpdate();  in the start function. The above IAR start picture is for KE, but in the KEA start file, you can’t see the start function in the KEA sample code which download from the freescale web, just find the __iar_program_start in cstartup_M_KEA128.s after the reset happens, but where is the __iar_program_start function, it can’t be searched in the whole project. Actually __iar_program_start is the default program entry function, it include the following function: You can find it will enter __low_level_init function, the watchdog disable code is just in  __low_level_init function. MDK:  From startup_MK0XZ4.s will find the watchdog disable code in the SystemInit function. Codewarrior: From __arm_start.c file, will find the watchdog disable code in __init_hardware function. 2) Codewarrior script init_kinetis.tcl disable the watchdog      To the Codewarrior, just comment the disable watchdog code in the __arm_start.c file is not enough to check the watchdog enable after reset, because in the codewarrior connect script init_kinetis.tcl, there also have the watchdog disable code.      If you want to find the state of EN bit in register WDOG_S1 after reset, you must disable all these watchdog disable code.   3) Timeout register configuration incorrect From the header file MKE02Z2.h, we can find the time out register define like this:   union {                                          /* offset: 0x4 */     __IO uint16_t TOVAL;                             /**< WDOG_TOVAL register., offset: 0x4 */     struct {                                         /* offset: 0x4 */       __IO uint8_t TOVALH;                             /**< Watchdog Timeout Value Register: High, offset: 0x4 */       __IO uint8_t TOVALL;                             /**< Watchdog Timeout Value Register: Low, offset: 0x5 */     } TOVAL8B; This structure means that customer can define the watchdog timeout value by separated unit8 TOVALH, TOVALL or just defined it with unint16 TOVAL. But actually in the IAR project usage, take an example, use 1khz as the clock source for watchdog, then want to set the timeout value as 1s, it means the timeout value should be 1000=0x03e8, so one of the customers configure it like this:    You can find, we need the TOVALL= 0XE8, TOVALH=0X03, but from the test result, the register is TOVALL= 0X03, TOVALH=0Xe8, this will cause the timeout value is much larger than 1000, that is why customer can’t reset the mcu after 1s, because the register configuration is not correct. It is caused by the IAR int16 store endian mode, the default IAR endian mode is little endian mode. So in the practical usage, it is recommended to use the separated time out value definition. 2. debugger usage When in debug mode with IDE, some customers find even they comment all the watchdog disable code, they still can’t reset the MCU by the watchdog. After check the register WDOG_S1, bit EN is 0, it means the watchdog is disabled. But from the reference manual, we get that after reset, the EN bit should be 1. What caused this? After test, we find this actually caused by the debugger, the debugger hardware which you are using. Eg, in the same project which already comment all the watchdog disable code, SEGGER JLINK will still disable the watchdog, but the PE opensda or PE multilink won’t do this, the EN bit is enabled by default, the following is the test picture, take codewarrior as an example: 1) JLINK 2) PE Opensda or PE multilink    So, if you want to test the watchdog in debug mode, and want the EN is set after reset, you can choose PE debugger tool instead of JLINK, but this JLINK feature is just influence the debug mode, after you download the code to the chip flash, and after reset, the EN bit in WDOG_S1 will still be set. Wish this document will help you get out the problem of watchdog can’t be reset.

This sample is to use two FRDM-KL02Z to testing the I2C.  By working at 400KHz baud rate, some customer may found the I2C_SDA will generating a dig when failing edge of the I2C_CLK.  Actually it should related with I2C port layout and the question is why this happen and how to get rid of the dig? The truth is I2C pins are open drain, so no one actually drives a high value. The high value is only there because of a pullup resistor on the lines. For the case to connect two of FRDM-KL02Z using the I2C0_SCL and I2C0_SDA lines that are available on J7, these lines are also used for connecting to the inertial sensor that is on the board, and there are 4.7K pullups on both lines. Problem is that there are 4.7K pullups on the lines on both boards, so the pullups are weaker than intended. So customer should remove the pullup resistors from one of the two boards that should help. We even recommend customer might need to replace the 4.7K pullups with an even stronger pullup though when they have more devices on the I2C bus that are all adding loading.

As general introduction on thread https://community.freescale.com/docs/DOC-328302 , I did a smart LED application with GoKit and FRDM-KL02. In this design, FRDM-KL02 will communicate with GoKit by WIFI, and control LED flash. Code Structure Code Basic Introduction In this project structure, you need to do following items on code. ü Add your functions, such as UART, LED, motor driver code. ü Add function running functions in protocol.c ü Add functions order in main loop. You can find my main.c and protocol.c as attachment. In this document, I would like to detail introduce function MessageHandle()， void MessageHandle(void) {                 pro_headPart    tmp_headPart; //Common command package                 memset(&tmp_headPart, 0, sizeof(pro_headPart));                 if(get_one_package)                 {                                                                              get_one_package = 0;                                 memcpy(&tmp_headPart, uart_buf, sizeof(pro_headPart));                                                                 //CRC error, send back error command                                 if(CheckSum(uart_buf, uart_Count) != uart_buf[uart_Count-1])                                 {                                                 SendErrorCmd(ERROR_CHECKSUM, tmp_headPart.sn);                                                 return ;                                 }                                 So, you can see that only get_one_package=1, we can receive frame completely.                                 switch(tmp_headPart.cmd)                                 {                                                              case       CMD_GET_MCU_INFO:                                                                 CmdGetMcuInfo(tmp_headPart.sn);                                                                                                                                     break;                                                                   case CMD_SEND_HEARTBEAT:                                                                 SendCommonCmd(CMD_SEND_HEARTBEAT_ACK, tmp_headPart.sn);                                                                                 break;                                                 case CMD_REBOOT_MCU:                                                                 SendCommonCmd(CMD_REBOOT_MCU_ACK, tmp_headPart.sn);                                                 case       CMD_SEND_MCU_P0:                                                                 CmdSendMcuP0(uart_buf);                                                                 break;                                                 case       CMD_REPORT_MODULE_STATUS:                                                                 CmdReportModuleStatus(uart_buf);                                                                 break;                                                 default:                                                                 SendErrorCmd(ERROR_CMD, tmp_headPart.sn);                                                                 break;                                 }                              } } After that, you can do operations mentioned in thread https://community.freescale.com/docs/DOC-328302. You can see smart LED device and been found.

Recently I was told that there really lack of enough document && demo regarding the lwIP stack with SDK. So I would like to share more detail regarding this topic, and hope it will been helpful and useful. Introduction Small independent implementations of the TCP/IP protocol suite One of the most widely used TCP/IP stack Under a BSD-style license Support run in both bare metal and RTOS environment Suitable for use in embedded system with tens of free RAM and room for around 40 kilobytes of code ROM lwIP stack on KSDK     - <ksdk_install_dir>/middleware/tcpip/lwip lwIP stack on KSDK - Code Structure lwIP code structure is shown as below: src     This subfolder includes the latest stable lwIP 1.4.1 source code which can be downloaded from this link: download.savannah.gnu.org/releases/lwip/ port     This subfolder includes the adapter code which adapts lwIP stack to SDK. lwIP stack on KSDK - Source Code Structure of source code under is shown below: lwIP stack on KSDK – Adapter code <ksdk_install_dir>/middleware/tcpip/lwip/port <ksdk_install_dir>/middleware/tcpip/lwip/port/arch These Adapter code could be divided into four types:         Ethernet driver adapter code         OSA adapter code         Additional code         lwIP stack configuration code Ethernet Driver Adapter Code Provide Ethernet relevant interface including    − Ethernet hardware initialization    − Network interface initialization    − Send packet to Ethernet hardware    − Receive packet from Ethernet hardware    − Pass packet to lwIP stack Both polling and interrupt mode are provided for packet receiving     - In <ksdk_install_dir>/platform/drivers/inc/fsl_enet_driver.h,          #define ENET_RECEIVE_ALL_INTERRUPT 0 to enable polling mode.          Or set          #define ENET_RECEIVE_ALL_INTERRUPT 1 to enable interrupt mode. Ethernet driver adapter code provides ENET_receive API for polling mode Under RTOS environment, a separate task executing ENET_receive for packet receiving is created in Ethernet hardware initialization code for polling mode Under Bare Metal environment the ENET_receive API need to be called endlessly to do packet receiving OSA Adapter Code Provide OS dependent types and interface for RTOS environment (configured NO_SYS = 0)    −Semaphore    −Mutex    −Mailbox    −Thread Provide time tick for bare metal environment(NO_SYS = 1) sys_now to get the current time sys_assert to print an assertion messages and abort execution. Additional Code Provide definition and interface for:    −Typedefs    −Compiler hints for packing and platform specific    −Diagnostic output lwIP Stack Configuration Code Provides a way to override much of the behavior of lwIP based on opt.h.     − Module support (Code size)           Default inclusions:     ARP (LWIP_ARP)     UDP (LWIP_UDP) and UDP-Lite (LWIP_UDPLITE)     TCP (LWIP_TCP) -- this is a big one!     Statistics (LWIP_STATS)          ……          Default exclusions:    DHCP (LWIP_DHCP)    AUTOIP (LWIP_AUTOIP)    SNMP (LWIP_SNMP)    IGMP (LWIP_IGMP)    PPP (PPP_SUPPORT)    − Memory management (RAM usage)              lwIP’s custom heap-based mem_malloc              C standard library malloc and free              Memory pools lwIP Stack Porting Guide    Possible Situation for Porting New Soc with Limited RAM In current KSDK, the main RAM consumption for lwIP is show below: If resource on the new platform is not enough, could reduce ram consumption for ram_heap and pbuf_pool.         In lwip/port/lwipopts.h: #define MEM_SIZE                (12*1024)    /**the size of ram_heap/ #define PBUF_POOL_SIZE          10      /*the number of buffers in the pbuf pool. */ #define PBUF_POOL_BUFSIZE       1518 /* the size of each pbuf in the pbuf pool. */ pbuf_pool also support dynamically allocate from ram_heap.        In lwip/include/opt.h:          #define MEMP_MEM_MALLOC     1 /*Use mem_malloc/mem_free to do allocate*/ Use libc malloc/free to manage the memory allocation instead of mem_malloc/mem_free, memory definition for ram_heap is not needed.         #define MEM_LIBC_MALLOC       1 /*Use malloc/free/realloc provided by C-library*/   New Soc NOT Support PIT timer OSA adapter code should provide Bare metal lwIP stack with a 1ms period timer. Current the code use pit timer to do this and the definition in sys_arch.c is as below: #define HWTIMER_LL_DEVIF    kPitDevif      // Use hardware timer PIT #define HWTIMER_LL_SRCCLK   kBusClock     // Source Clock for PIT #define HWTIMER_LL_ID       3 #define HWTIMER_PERIOD          1000      // 1 ms interval If the new platform does not provide PIT, we could use other hardware timers to implement the 1ms period timer. Lightweight TCP/IP (lwIP) Stack Porting v Lightweight TCP/IP (lwIP) Stack Porting Guide Lightweight TCP/IP (lwIP) Stack Porting Guide

There is a popular WIFI platform called “GoKit” in China. This testing kit can be use to do some customized application. Not only WIFI communication, kit also support other functions. You can find interfaces listed as below. GoKit Interfaces: I try to use FRDM-KL02 to communicate with this kit to do a WIFI communication application. Board connection as below. This platform has two running mode. One is AirLink mode, and another is normal running mode. AirLink mode is used to WIFI communication or pair. Go to AirLink mode steps: Power on FRDM-KL02 Long press key1 to reset WIFI module. Wait until RED led on. Short press Key2 to go into configuration mode, wait until RED led flash on WIFI module. Open demo APP, select “adding device”, input SSID password. Waiting for configuration finish. Command Format HOF: 2bytes, value 0xFFFF Length: 2bytes Cmd:1byte SN:1byte Flags:2bytes DATA: Xbytes Checksum:1byte WIFI acquire device information MCU inform WIFI into configure mode MCU reset WIFI WIFI inform MCU status WIFI ask for reset Illegal command For detail code, I will post another thread for your reference.