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

Overview The Sub-GHz Remote Control Dimmer is a reference design which demonstrates the functionality of the MKW01Z128 MCU working in a custom IEEE 802.15.4 star network.   This reference design is focused on a home automation application where the user is able to control various RGB bulbs connected into a network using the KW01-RCD-RD board as a remote control. Controlled devices are USB-KW019032 boards, and each board simulates an RGB bulb in a GUI.   Sub-GHz technology has some advantages over other wireless technologies such less data traffic in its respective ISM band.   Features: Documentation: Quick start guide Application users guide Board users guide Software user guide Schematics, Software, GUI and BSP: Link Best regards, Luis Burgos.

Hi All, all presentations were included in this archive file.

1. Kinetis L系列外部IO中断分配问题（Tips about extern IO interrupt distribution of Kinetis L serious） 2. KL26通过UART的DMA方式发送数据包（Send data package through UART with DMA mode on KL26） 3. Freescale ARM Cortex-M系列软复位的使用方法 4.分享飞思卡尔KL25使用UART通信唤醒低功耗模式代码 5. 飞思卡尔KL系列低功耗特性和唤醒时间测试 6. BME学习心得(BME Study Notes) 7. 分享一个基于Kinetis KL25/KL26 USB读写U盘的例程 8. 如何实现Kinetis ADC自校准 9. Kinetis系列Flash烧写数据时写命令需要放到RAM中运行 10. Kinetis内部ADC转换速率探讨 11. KE02底层驱动库内部时钟Trim造成的UART通信不准的问题 12. Kinetis之教你将K60主频超到200MHz以上 13. 在Kinetis参考手册中快速找到芯片的Flash和SRAM地址空间分配 14. KL26 SD卡读写程序 15. KL03不能正常进入低功耗模式的原因及解决办法 16. 对Flash擦写数据时使用ESFC位以避免写冲突造成擦写失败（Using ESFC bit - Flash programming routines in Cotex M0+ kinetis MCU） 17. M0+单周期快速GPIO的使用方法 18. Kinetis 16-bit ADC+DMA+定时器实现AutoScan自动通道扫描采样 19. Kinetis将Flash保护打开造成程序下载失败的解决办法 20. 移植ARM CMSIS USB Stack的CDC类到飞思卡尔Kinetis KL25 21. I2C总线被挂起的原因和解决办法 22. 使用Kinetis系列中UART的IDLE Line功能识别帧结束 23. Kinetis K系列SPI接口设计注意事项 24. I2C从机地址左移一位的原因 25. Kinetis 使用eDMA完成串口接收功能 26. 移植ARM CMSIS USB Stack 的CDC类到飞思卡尔Kinetis KL26[Keil]​ 27. KE 驱动库中UART中断问题​ 28. KE驱动库中KE06 CAN Demo的遇到几个问题和说明​ 29. 深入剖析Kinetis系列内部IO结构​ 30. ARM Cortex-M4和Cortex-M0+中断优先级及嵌套抢占问题​

Freescale's Jeff Bock highlights the awesome features of the Kinetis 32-bit microcontrollers based on the ARM Cortex-M4 core

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

      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 is a copy of the currently posted KL26 reference manual to be used to enter community comments.  Please feel free to add inline comments in this reference manual. You can point out where more information is needed or where existing information is incorrect.  You can also enter information in your comment that expands on existing information in the document, based on your experience with the device.  If you are pointing out that more information is needed in a paragraph or a section, please be very specific, not “needs more information”.  Your comments in this manual may help other members and will drive improvements in this and future documentation. Note: The doc viewer does not support going directly to a specified page.  Instead of manually paging through one page at a time, you can do a search on a string on a page such as "types of resets", or you can go to chapter links listed in the inline comments.  To do this, page down to the comments below the doc view, select "Inline Comments", sort the comments by "page", and then select the chapter you want to view.

The DOC focuses on how to access SDRAM based on K65 SDRAM controller, it describes the hardware connection especially the address connection, the SDRAM controller initialization,the code to access SDRAM.

My customer wanted to use K60 in his design but he only has the Keil IDE, so I helped to port some examples in KINETIS_SC for him as a starting point. The attachment is my porting work, which also includes a exe file to create new keil project. You may refer to "keil\build\uv4\make_new_project_keil.exe" for details. Hope that helps, B.R Kan

Hi: Kinetis's ADC have no multi channels sequence sampling function, compared with LPC's ADC. But we could use DMA for such case, attached are two demos: 1.multi_channels_edma_ADC_DMA_SW_TRIG Description: use SW trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; 2.multi_channels_edma_ADC_DMA_LPIT_HW_TRIG Description: use LPIT timely trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; but LPIT could trigger continuously without SW engage.

I2C (Inter-Integrated Circuit) Module by Alejandro Lozano, Freescale TIC. i2C Protocol Explanation. Connection Diagram. How to configure the registers. Hands-On. Presentación del módulo de I2C (Inter-Integrated Circuit) por Alejandro Lozano, Freescale TIC. Explicación del Protocolo I2C. Diagrama de conexión. Explicación de cómo configurar los registros. Hands-On

DFU_PC_demo_source_code.zip

I’m using the NXP FRDM-K64F board in several projects.One issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues. The EzPort is a special serial interface present on some Kinetis, ColdFire+ and ColdFire V2 devices. The issue is that if the EzPort chip select (EZP_CS) is LOW during reset of the microcontroller, it enters the special EzPort mode. The problem is that a pull-up on the EZP_CS line might not pulled up fast enough due capacitance on the line. The commance is if something is not used, disable it! So the solution is to disable the EzPort functionality. That setting is part of the FOPT (flash option register).

Introduction This document provides guidance to program or store code in FlexNVM memory available in KW36 MCU to use it as P-Flash memory. This article uses as the starting point, an example imported from the connectivity software stack. Software Requirements 1. FRDM-KW36 SDK 2.2.0.   2. MCUXpresso IDE. Hardware Requirements 1. FRDM-KW36 board. Programming KW36 FlexNVM Example The objective is to explain how to place a linker input section, variable or function into the FlexNVM memory. Before starting, the developer must know that the GNU linker cannot automatically place code or data across two separate memory regions, so the developer must analyze and manually choose what sections will be placed at which memory (P-Flash or FlexNVM) to get the most efficient way to use the total memory size. This example will use the "bare-metal" version of the heart rate sensor project (included in the SDK), however, the same steps apply for the "freertos" version. 1. Select "Import SDK example(s)..." option in the "Quickstart Panel" window. Next, choose the FRDM-KW36 board. Click the "Next" button. 2. Expand "wireless_examples/bluetooth/hrs" folders and select bm project with the checkbox beside. Click the "Finish" button. 3. Replace the "MKW36Z512xxx4_connectivity.ld" file by "MKW36_connectivity_dflash_use.ld" (attached to this document) into the source folder in the workspace. 4. Open the "Project/Properties" window and select "C/C++Build/Settings". Next, go to the "MCU Linker/Managed Linker Script" perspective and edit the linker script name to "MKW36_connectivity_dflash_use.ld". Click "Apply and Close" button.   Placing input sections in FlexNVM memory It is possible to program specific input sections in the FlexNVM memory following the next steps: 1. Open the "MKW36_connectivity_dflash_use.ld" linker file. 2. Search for output sections. In this example, we will edit the "text" section to save it in the FlexNVM array. Replace the "m_text" memory by "FLEX_NVM" memory as in the following picture.  3. Debug the project using the CMSIS-DAP debugger. 4. Open the memory perspective. Add a new memory monitor with the "green plus icon" in the 0x1000_0000 address. Verify the expected results.      Placing variables and functions in FlexNVM memory Also, it is possible to place a specific function or variable in the Flex NVM using attributes as follows: 1. Open the "MKW36_connectivity_dflash_use.ld" linker file. 2. Search for output sections. In this example, we will create a new section placed at Flex NVM address range. The name of this output section is "text_Flash2". Edit the linker file as shown below.   3. Create your functions and variables using the following section attribute (in this example we will open and place the text below in the "fsl_os_abstraction_bm.c" file under framework/OSAbstraction/Source folder in the workspace): __attribute__ ((section(".d_flash_array"))) const uint32_t const_data_table[10] = {0,1,2,3,4,5,6,7,8,9}; __attribute__ ((section(".text.$FLEX_NVM"))) void delay (void) {        volatile uint32_t i = 0;        for (i = 0; i < 800000; i++)        {               __asm("NOP");        }        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Use your own variables and functions in the code (this step is only for testing purpose, this is important to prevent any optimizations performed by the compiler). In this example, we will use the delay function and the const array in the main function located at "fsl_os_abstraction_bm.c" file. uint32_t Use_Array; uint32_t index;     for (index = 0; index < 10; index++) {        delay();        Use_Array = const_data_table[10]; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 5. Debug the project using the CMSIS-DAP debugger. 6. Open the memory perspective. Add a new memory monitor with the "green plus icon" in the 0x1000_0000 address. Verify the expected results.

En México, el 5.1% de la población vive con algún tipo de discapacidad, de los cuales 23% poseen discapacidades del tipo motriz en extremidades inferiores y superiores (INEGI, 2011). Los métodos que actualmente se utilizan en el proceso de rehabilitación no poseen características integrales en las que el usuario pueda aprovechar la terapia para ejecutar diferentes acciones. El objetivo de este proyecto es el de diseñar y construir una herramienta que permita al usuario no solo hacer ejercicios de rehabilitación, sino que también le ayude a realizar tareas cognitivas o a interactuar con algún medio electrónico (i. e. navegar por internet, realizar trabajos a través de una computadora con Rehab Glove como mouse y/o teclado). Rehab Glove es una herramienta en forma de guante que posee sensores de flexión en las articulaciones de los dedos y de fuerza en las yemas, ubicados estratégicamente con el fin de obtener diferentes valores arrojados mientras el usuario realiza ejercicios de rehabilitación como cerrar el puño o tocar las yemas de los dedos con el pulgar. Estos valores serán convertidos en instrucciones diversas que van desde mover un  carro a control remoto, pasando por el control de videojuegos educativos, hasta llegar a tareas más complejas como escribir o controlar el cursor de una computadora sin la necesidad de un mouse o un teclado. La terapia comenzará con el usuario portando RehabGlove frente al elemento que desea controlar, pidiéndole que realice movimientos específicos con la mano para que pueda lograr el objetivo final. Se espera que el nivel de complejidad vaya aumentando en cuanto al tipo de movimientos, rapidez, precisión y fuerza aplicada en cada acción. Con el uso de RehabGlove se espera que las terapias de rehabilitación posean niveles de cognición mayores y que tengan un avance progresivo aumentando el nivel de complejidad en cada ejercicio.   Video de prototipo<<<<< Rehab Glove Kinetis - YouTube Original Attachment has been moved to: Codigo-Fuente-Rehab-Glove.txt.zip

There is new amazing feature in FreeMaster ver 1.4 ( www.freescale.com/freemaster ) - you can do the debugging and visualization of your application in FreeMASTER without adding any code in there (you do not need a serial driver of any kind to achieve the connection), just using the communication plug-in to OSDA embedded in new version of Freemaster connected instead of the debugger from IDE. The driverless use of Freemaster use is easy to use, just open the FreeMaster, assuming you have your own application, without any Freemaster driver in it. Load the application into flash memory of the KL device and close debugging session from IDE. Open FreeMaster and  go to Project/Options/Comm, use setup from picture below Choose Plug-in - use the FreeMASTER BDM Communication Plug-in, hit configure and take P&E Kinetis. you can test the connection there too. The next step is to go to Options/MAP files, navigate to *.ELF file of your project and set file format to ELF/DWARF (I have chosen .elf from some usb demo project just to show the way how to do so) well, the connection is established, now there is need to choose variables for display and visualization. Go to project/Variables and choose variables you want to follow (hit Generate.. to do so, list of variables available in your project will appear and you can choose the desired one and hit generate - it will check and generate the variable connection, you can do it for single variable, array or more variables - it is intuitive ) When desired variables are generated, close the dialog. You can make a scope or add variables to watch. To add variable to variable watch window click by right mouse button in watch area go to watch properties, Watch tab and hit Add---->> to add it between watched wariables and hit OK and value appears in the Variable Watch window. To create scope, go to project tree window and use right mouse button on NewProject, choose Create Scope... In scope properties chose the name for this scope and go to  Setup tab. You can add your variable to the scope here by choosing in drop down menu Hit OK and start the session (Ctrl+K) or hitting Stop icon in the menu, the variable is displayed in the window. The value in my case stays 0 however displays correctly... Pavel

Agenda Mastering Kinetis-M Microcontrollers Schedule Module Description Duration Presenter 8:00 Registration 0:30 8:30 Introduction & Welcome 0:15 MM 8:45 MKM34Z256 core and peripherals architecture 1:00 Cano 9:45 DSP fractional, Filter, and FFT-based libraries for general signal processing and metering applications 1:00 LV 10:45 Break 0:15 11:00 Power meter & PLC reference design overview (1ph, 2ph (MKM34Z128), 3ph, 3ph shunt based + sensor node) 1:00 RK 12:00 Introduction to TWR-MKM34Z75, bare-metal drivers, SDK 2.0, FreeRTOS and FreeMaster 1:00 Cano+ID 13:00 Launch in the office 1:00 14:00 Workshop - TWR LCD example (preprogrammed, debugging, SW re-flashing) 0:45 Cano 14:45 Workshop - Using serial bootloader example (learn the way of bootloder integration into application) 0:45 PK 15:30 Workshop - LPTMR and GPIO example (LPTIM & GPIO API, programming interrupt, debugging) 0:45 MM 16:15 Break 0:15 16:30 Workshop - FreeRTOS preemptive multitasking example (basics of FreeRTOS programming) 0:30 MM 17:00 Workshop - High-precision waveform measurement example (SD ADC & FreeMaster programming) 0:45 MM 17:45 Workshop - 64-bit math coprocessor example (mastering DSP instruction set the MMAU) 0:45 MM 18:30 Q&A 0:30 19:00 Dinner @ Brasserie restaurant 2:00 21:00

Problem Analysis and solutions for booting from ROM BOOTLOADER in KL series 1 Abstract      When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, they have found a problem that if the code boot from the ROM instead of the flash, the application code about the LPUART and I2C will run in abnormal state, especially when use PTA1 as the  LPUART receive pin, UART transmit function has no problem, but when the PTA1 receive the UART data, the code will run to the abnormal area and can’t return back, the code will be crash. This problem only happens on booting from the ROM and the uart and i2c peripheral are enabled in BCA 0x3d0 address, uart peripheral enablement in BCA area will influence the application PTA1 uart receive, i2c peripheral enablement in BCA area will influence the i2c0 module in the application code. If booting from the flash or booting from ROM but the uart and I2C peripheral are disabled in the BCA 0x3d0 address, everything is working ok in the application code.      This document will take the UART problem as an example, give details of the problem reproduction, testing, analysis and the solutions. The I2C problem is the same when booting from the ROM bootloader. 2 Problem reproduction and analysis  Testing preparation: IDE: KDS 和IAR Hardware: FRDM-KL43 Software: 3.0 and KSDK2.0_FRDM-KL43      We mainly reproduce the uart receive problem in two ways: new KDS PE project based on KSDK1.3.0 and official newest sample code package KSDK2.0_FRDM-KL43. 2.1 Problem reproduction in new creating kds project Because the KSDK2.0 still doesn’t support the PE function in the KDS IDE, so we use the KSDK1.3.0 as the PE KSDK to create the new KDS project. 2.1.1 Create KDS KL43 project The new KDS PE project creating is very simple, here just describe the important points which is relate to the UART problem after booting from the ROM. At first create a new KDS PE project which is based on KSDK1.3.0, and choose the chip as MKL43Z256VLH4, select the MCG mode as HIRC, and configure core clock to 48Mhz, bus clock to 24Mhz. Then add the uart module fls_debug_console for testing, because the FRDM_KL43 is using PTA1 and PTA2, the console module can be configured like the following picture, after the module is configured, press the code generation button to generate the project code. Then add the simple code in file main.c main function for testing: char a; for(;;) {                 PRINTF(" test!\n");                 a= GETCHAR();                 PUTCHAR(a);               } The code function is: printf the “test!” to the COM port in the PC, then wait the uart data, if receive the data, then printf the received data back and run this loop function again.   2.1.2 Add the BCA area    From the KL43 reference manual, we can get that, BCA start address is 0X3C0:     The KDS newly created project didn’t contain the BCA area in the link file, so we need to add this area in the link file and add the BCA data in the start file by ourselves. 2.1.2.1 Divide the BCA flash are in .ld file Add the following code to define the BCA start flash address and the flash size in the ProcessorExpert.ld memory area: m_bca                 (RX)  : ORIGIN = 0x000003C0, LENGTH = 0x00000040 Then add this code in the SECTIONS area:   .bca :            {              . = ALIGN(4);              KEEP(*(.bca)) /* Bootloader Configuration Area (BCA) */              . = ALIGN(4);            } > m_bca At last, the ld file is like this: For the ld file protection, we can change the ld file properties to read-only, then this file won’t be changed to the initial one after building. 2.1.2.2 Add the BCA data in the start file      After add the BCA flash area divide code, we still need to define the BCA data in the start file:    /* BCA Area */     .section .bca, "a"                 .ascii "kcfg"                            // [00:03] tag                 .long 0xFFFFFFFF // [07:04] crcStartAddress                 .long 0xFFFFFFFF // [0B:08] crcByteCount                 .long 0xFFFFFFFF // [0F:0C] crcExpectedValue                 .byte 0x03                                             // [10] enabledPeripherals  I2C and UART                 .byte 0xFF                                              // [11] i2cSlaveAddress                 .short 3000                           // [13:12] peripheralDetectionTimeout (milliseconds)                 .short 0xFFFF                        // [15:14] usbVid                 .short 0xFFFF                        // [17:16] usbPid                 .long 0xFFFFFFFF  // [1B:18] usbStringsPointer                 .byte 0xFF                                              // [1C] clockFlags                 .byte 0xFF                                              // [1D] clockDivider                 .byte 0xFF                                              // [1E] bootFlags                 .byte 0xFF                                              // [1F] reserved*/    More details, please refer to this picture:       So far, we have create the FRDM-KL43 test project which contains the BCA area, and boot from the ROM that can be modified in the flash address 0X40D, bit 6-7 in 0X40D is the BOOTSRC_SEL bits, 00 boot from flash, 10 and 11 boot from ROM, more details about the FOPT, please refer to Table 6-2. Flash Option Register (FTFA_FOPT) definition in reference manual.     2.1.3 Test result and analysis       Now, list the test result after booting from ROM or flash, and boot from ROM but enable the peripherals. Boot from: ROM peripheral Test Result Flash XX OK ROM 0XFF, enable all NO, UART can’t receive 0X08, enable USB Yes, UART can receive 0X04, enable SPI Yes, UART can receive 0X02, enable I2C Yes, UART can receive 0X01, enable LPUART NO, UART can’t receive      From the test result, we can reproduce the problem. The UART receive problem just happens on booting from ROM and the LPUART is enabled, when we run it with debugger, and test it step by step, we can find after the PTA1 have received the data, the code will run to the abnormal area. Note: when debug this code, please choose the JLINK as the debugger, because the P&E tool will protect the FOPT area automatically in the KDS IDE when do debugging, the code will still run from flash, so if customer use the P&E tool, they will found the PTA1 still can receive the data, this is not the real result, but the JLINK won’t protect FOPT area in the KDS IDE, it can reflect the real result.      After using the JLINK as the debugger, and we have found after PTA1 getting data or pulling low, the code will enter to the abnormal area like this:      We can get that the code run to the defaultISR, and display with USB_IRQHander, but this is not really the USB_IRQHander, just caused by the PC abnormal. Normally, it is caused by the missing of interrupt service function.       Now, we test the NVIC data to check which module interrupt caused this, the following picture is the result by enabling the LPUART and I2C peripheral in the ROM BCA area. We can find, even we didn’t do the cpu and peripheral initialization after booting from ROM, there still have peripheral be enabled, what the interrupt is enabled? From the definitive guide to the ARM Cortex-M0.pdf: NVIC_ISER = 0x40000100, Vector46=IRQ30 and vector24=IRQ8 is enabled, it should be not disabled after booting from the ROM. Now check the KL43 reference manual, Table 3-2. Interrupt vector assignments, we can get that the I2C0 and PORTA interrupt is enabled. Checking the PORTA register before do the cpu and peripheral initialization, PTA1 is enabled the port interrupt, and choose Flag and Interrupt on falling-edge.     This can tell us why the PTA1 pin have the problem of uart receive data or give a falling edge in PTA1 will run abnormal, because in default, even we configure the PTA1 as the uart receive function, but the code didn’t clear IRQ and NVIC register, when the signal happens on PTA1 pin, it will caused the PORTA interrupt, but we didn’t add the PORTA interrupt ISR function, it is also not useful to us, then PC don’t know where to go, so it will run abnormal, enter the defaultISR, and can’t recover. If you have interest, you can add the PORTA_IRQHandler function, you will find the code will run to this function. 2.2 Problem reproduction in KSDK2.0 IAR project  Test project: SDK_2.0_FRDM-KL43Z\boards\frdmkl43z\demo_apps\hello_world  Test the official project just to make sure, it is really the chip hardware function, not only the problem from new generated code in KDS.   Because the IAR IDE will protect the 0X400 area, then if we want to modify the FOPT, we need to modify the .board, add –enable_config_write at first.    Then modify the FOPT in startup_MKL43Z.s: __FlashConfig         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFE   ; 0xFFFF3FFE   __FlashConfig_End   Because the BCA peripheral area is in default as 0XFF, it enables all the peripheral, we don’t need to define the BCA area independently.  For getting the real test result, we add the NVIC and PORTA_PCR1 register printf code in the main function,    PRINTF("PORTA_PCR1=%X \n", PORTA->PCR[1]);    PRINTF("NVIC=%X \n", NVIC->ICER[0U]); And download the modified KSDK sample code to the chip, after testing, we get this result: hello world. PORTA_PCR1=A0205 NVIC=40000100 It is the same result as the new created project after booting from the ROM, PORTA interrupt and I2C interrupt is enabled, and it caused the PTA1 receive data problem.  3 Solutions and test result 3.1 Solutions      From the Chapter 2 testing and analysis, we can get that UART receive problem is caused by the PORT interrupt and NVIC is enabled after booting from the ROM, this should be caused by exiting the ROM, the ROM forget to disable it. We also can find some descriptions from the KL43 reference manual page 211: So, if customer want to solve this problem, to avoid the application enter to the abnormal area, we can disable the NVIC in the application code like this, the I2C NVIC is the same:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt 3.2 Test result   From the test result after adding the NVIC I2C and PORTA disable code, we can get the uart can works ok, if you have interest to test, the I2C will also work ok. 4 Conclusion When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, and want to boot from the ROM and enable the LPUART and I2C in BCA area, please add the NVIC I2C(IRQ8) and PORTA(IRQ30) disable code in the application code:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt So far, I just find KL43, KL27 and KL17 which flash size is above 128K have this problem, other kinetis chip which have ROM bootloader don’t have this problem.

Recently I did a porting based on AN4370SW for a customer to support TWR-K20D72M, and with some modification in source code, header file and link file as well, it works well as expected. The following simple describes what I have done: 1.Copy the project file folder for K20D50M "AN4370SW\Source\Device\app\dfu_bootloader\iar_ew\kinetis_k20" and rename is as "kinetis_k20d70m" 2.Change the target settings as well as the flash loader. 3. Replace the header file for K20D50M and include it in derivative.h. The header file for K20D72M can be found from KINETIS_72MHz_SRC(http://cache.freescale.com/files/32bit/software/KINETIS_72MHz_SRC.zip?fpsp=1&WT_TYPE=Lab%20and%20Test%20Software&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&sr=9) 4.Modify the interrupt table in cstartup_M.s, which is more likely a K60's vertor table. 5.Search the code related with the macro "MCU_MK20D5", and add similar code snippet for K20D72M , You may easily find them by search the keyword "MCU_MK20D7". That code parts include initialization for MCG, and PIT0 and USB interrupt enablements, some definition in bootloader.h . 6. Copy the link file from K20D50M, and modify the PFLASH size,SRAM size and DFLASH size as shown below: Perform MassErase before programming . and then you may press the SW1 on TWR-K20D72M to select which mode to enter after download the application firmware: pressing SW1 to enter bootloader mode and releasing it to enter application mode. 7. Build image for this DFU bootloader. Actually the bareboard projects in KINETIS_72MHz_SRC can be used for that purpose, and only link file needs some modification to put the image starting from 0xA000, since exception table redirection has already been done in these projects. after that, user needs change some settings in the CW projects to use the new link file: and generate S19 file as the output as well as the map file: after compiling , you will have a xxx.afx.s19 file, but that is not the final format, we still need to transform it to bin format, and it can be done by a small tool in "C:\Program Files\Freescale\CW MCU v10.3\MCU\prog" There are some settings for this tool to transform the S19 file, by clicking Burner->Burner Dialog, you will see some option views, please set them as below: Referring to the above figure, maybe you would wonder how to set up the Origin and Length field, actually Origin is the value where the image starts from just as the link file specified , and Length is calculated by the results from the map file. Please refer to the following figure for details. 0x3550 = 0x1c90 + 0x18c0. I also attached the burner's configuration file and image link file as well as the image for reference. Please copy the link file in "KINETIS_72MHz_SRC\build\cw\linker_files". Please kindly refer to the attachment for more details. Hope that helps, B.R Kan