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

     我想“超频”这个词估计大家都不会陌生，很多玩计算机的都会尝试去把自己电脑的CPU超频玩一些高端大型游戏（咳咳，当然玩的high的时候别忘了小心你的主板别烧了），而对我们这些搞嵌入式的人们来说，估计就只能用这样的情怀去折磨MCU了（当然前提得是有PLL或者FLL的MCU）。      在超频之前首先需要澄清几个概念，我们通常所说的主频一般是指内核时钟或者系统时钟（即core_clk或system_clk）。而对K60来说，其内部还有总线时钟（Bus_clk）、外部总线时钟（FlexBus_clk）、flash时钟（Flash_clk），而这几个时钟互相关联且每个都是有其频率限制的（如下图1所示），所以当我们要超频内核时钟的时候还不得不考虑其他时钟承受极限（姑且用这个词吧）。在我们用MCG模块内部的PLL将输入时钟超频到200MHz作为MCGOUTCLK输出的时候还需要一道关卡（如下图2），也就是说虽然这几个时钟属于同宗（都来自MCGOUTCLK），但是也可以通过不同的分频器（OUTDIV[1:4]）约束不同的时钟范围，这里想起一个形象的例子。MCGOUTCLK就类似以前的官家大老爷，娶了四房姨太太（OUTDIV[1:4]）,分别生了四个少爷（即core_clk、Bus_clk、FlexBus_clk和Flash_clk），每个少爷都是老爷的儿子，不过在家中地位却是由姨太太的排序决定的，其中大房的大少爷（core_clk）地位最高（频率范围最大），四房的小少爷（flash_clk）地位最低（频率范围最小），不过他们的地位最高也不会超过老爷（其他clk<=MCGOUTCLK），呵呵，有点意思~ 图1 图2      经过上面的分析之后，就可以开始着手超频了。经过验证，其实系统频率超不上去就是“小少爷”（flash_clk）拖了后腿，当我们将MCGOUTCLK超到200MHz的时候，OUTDIV1的分频可以设置为1分频，保证内核频率为200MHz，但却要同时保证其他几个时钟不要超过太多，尤其是Flash_clk的限制要严格（建议不要超过30MHz，小少爷有些“娇气”），因为flash_clk过高就代表取指令的频率过高，指令出错就会造成系统程序跑飞。     说到这里，可能有些人会质疑，把主频超的那么高，但取指令的速度上不去有个啥用，岂不是颇有些大马拉小车的感觉吗，其实不然，这里我说两点。一个是通过RAM调试或者将函数声明成RAM执行函数的时候是可以加快执行速度的，另一个就是当做一些数学运算的时候作用就很明显了，因为一般可能会单纯用到CPU内部的ALU和寄存器组，后者数据访问多一些（注意Cortex-M4是哈佛结构，数据与指令总线独立的），自然其运算速度就上去了，所以还是好处多多的。      当然飞思卡尔本身是不建议超频的，数据手册上给出的极限值都是在保证系统可靠性和稳定性的前提下测试出来的，再往上就不敢保证了（跟你的硬件电路设计能力有一定关系），正所谓“超频有风险，用时需谨慎啊”，呵呵，所以我们大多数的应用还是老老实实的按照“规矩”来吧。不过这里需要提的一点是，每家厂商一般会为超频留有余地（为了满足一些客户的超频需要，哎，不容易啊），至于这个余地是多少，不同的半导体厂商也会有不同的标准。对我来说，记得那是2008年的第一场雪，比往年来的稍晚了些…（没收住，开始整词儿了，呵呵），那一年我第一次接触飞思卡尔的9S12 16位的单片机（MC9S12DG128，哎，搞过智能车的都懂的），额定主频是25MHz，我把它超到40MHz，后来又换成了MC9S12XS128，额定主频是40MHz，我又把它超到80MHz（有点超频强迫症了，呵呵），一直到如今的ARM K60，额定主频为100MHz（VLQ100），所以。。。咳咳。。。很自然的我就把它超到200MHz，再往上我就没有测试了，因为基本也用不到那么高的频率，还是要掌握好这个“度”的，想过把超频的瘾的可以试试看，呵呵~

最近搞了一个基于TWR-K20D50M的的USB MSD device bootloader, 可以打开文件夹CW中的K20D5下的.project来查看。 在原始的MSD的基础上移植了FAT过来。 其他IAR和Kinetis的其他chip没有测试，如果需要使用，一个是新增相关头文件，二是在bootloader.h中修改相应的MCU_K20D50M定义下的flash及ram配置

Introduction This document is being written to communicate the need for serialization of memory operations and events in an end application.  In addition, directions will be provided to properly serialize memory operations in the end application.  Memory operations and event serialization applies to all Kinetis devices but is only necessary in specific scenarios. These scenarios include memory writes and reads, clearing status flags, and changing mode control operations. Serialization of memory operations Serialization of memory operations or events is the action of guaranteeing that said memory operations or events are executed in a specific order.  This action is required when making a change to a peripheral module when that change must complete before continuing with program execution.  Users often make the mistake of assuming that since a peripheral register has been written to, the change is in effect immediately.  However, this is not always the case.  The Kinetis series devices implement a crossbar and peripheral bridge interface system that allows masters (the CPU, DMA, etc.) to interface with the peripherals.  The crossbar allows multiple masters to access the individual peripherals on the bus, and the peripheral bridge functions as a bus protocol translator between the crossbar switch and the slave peripheral bus.  Wait states can be inserted at either stage of the communication channel (crossbar or peripheral bridge).  When a master attempts to access a slave and another master is already accessing this slave or the slave is busy, wait states will be inserted.  If the access is a write, then the master's write is simply pushed to the peripheral bus and the master continues.  However, if the access is a read, the master must wait for a response from the slave.  The slave may insert wait states in this communication as it must finish any commands (or writes) it was previously given before responding.    Peripheral module changes that require serialization actions include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  If the events or memory operations are not serialized in these situations, the CPU could go on to execute code with undesired effects. When do I need to serialize my memory operations and events? Memory operations and events require serialization anytime the program needs to guarantee that a peripheral access happens before code execution continues.  Examples of these situations includes: Exiting an interrupt service routine (ISR) Changing a clock mode or power mode Configuring a function Configuring a hardware change Software triggering a hardware event How do I serialize my memory operations and events? Memory operations are serialized by performing the following operations: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations By simply reading the register that was just written, the core is forced to wait for a response from the peripheral module that was written before code execution can continue.   In this manner, it is guaranteed that the peripheral module will have completed the desired operations. Example event serialization The following is an example of a function that services the LPTMR ISR flag and implements the event serialization discussed in this document.  void lptmr_isr(void) {   // Declare dummy variable to store the read of the LPTMR0_CSR register volatile int dummy_var; /****   STEP #1  ****/   // Clear the flag; enable interrupts; enable the timer   LPTMR0_CSR = ( LPTMR_CSR_TEN_MASK | LPTMR_CSR_TIE_MASK | LPTMR_CSR_TCF_MASK  );   /****  STEP #2  ****/    // Store CSR register in dummy_var to serialize the clearing of the TCF flag   dummy_var = LPTMR0_CSR; } Conclusion In conclusion, there are situations where code execution can continue before a peripheral change has taken effect. These situations include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  Sometimes these events can cause unexpected results or even cause your application to crash.  These situations call for the serialization of memory operations and events, which is simply the act of guaranteeing that events and code are executed in a specific order.  To serialize memory operations, simply follow these directions: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations Following these steps, you will be guaranteed that peripheral configurations have taken effect before continuing with the application. 

Hi, I have a project created by Processor Expert and CodeWarrior 10.2 for TWR-K20 demo kit. Becasue I have some problem to use the Processor Expert USB HID Keyboard Host of the USB stack 4.1.1, I need to change to add the non-PE USB HID Keyboard Host into the project. Can anyone tell me how to do it? It will be very appreciated to give me a simple 'PE' example project, and add the non-PE USB HID keyboard host stack. Thank you! Stanley

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

What's eCos eCos is a free open source real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint. With provided configuration tools (configtool and ecosconfig) it is possible to build configurations that scale from minimal that require less than 32KiB memory to reach full featured operating system with networking, file system, serial communication, etc. eCos for Kinetis Currently the Kinetis eCos support includes: UART; Ethernet - with TCP/IP through either lwIP or BSD stack; Flash - program and erase; eDMA library; DSPI - including MMC/SD card support; Real Time Clock. Cache; DDRAM; FlexBus; Following features are available for testing: I2C; CAN; Watchdog. Configuring eCos for Kinetis Start the graphical configuration tool configtool, then from menu select Build->Templates. In Hardware selection box select your board: In our case we select TWR-K70F120M. Save the configuration and select Build->Library. configtool will build a customised eCos library and extract headers for you. Now you are ready for your "Hello world". Further reading You shall find complete eCos documentation at eCos Documentation

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. Full application note and  software attached.

Heart rate monitors measure the heart rate during exercise or vigorous activity and gauge how hard the patient is working. Newer heart rate monitors consist of two main components: a signal acquisition sensor/transmitter and a receiver (wrist watch or smart phone). In some cases, the signal acquisition is integrated into fabric worn by the user or patient. MCUs analyze the ECG signal and determine the heat rate, while an 8-bit MCU can suffice for a simple heart rate monitor. For more complex analysis, such as heart rate variability, activity level and breathing rate, a high-end 32-bit MCU may be used. Furthermore, low power wireless technologies are used to allow the sensor to communicate to the receiver. Freescale offers 8-bit and 32-bit MCUs that are applicable across the entire spectrum of heart rate monitors. In addition, the Freescale portfolio includes inertial sensors or accelerometers for activity monitoring and ZigBee® and proprietary wireless solutions to enable communication between the sensors and the receiver. For more information go to freescale.com/APLHRM

The Kinetis K70 MCU family includes 512KB-1MB of flash memory, a single precision floating point unit, Graphic LCD Controller, IEEE 1588 Ethernet, full- and high-speed USB 2.0 On-The-Go with device charge detect, hardware encryption, tamper detection capabilities and a NAND flash controller. 256-pin devices include a DRAM controller for system expansion. The Kinetis K70 family is available in 196 and 256 pin MAPBGA packages. For more information visit www.freescale.com/kinetis

The ARM Cortex-M4 Kinetis K50 MCU integrates an analog measurement engine consisting of integrated operational and transimpedance amplifiers and high-resolution ADC and DAC modules that make it ideal for portable healthcare and medical applications. For more information visit www.freescale.com/kinetis

Freescale Semiconductor is to demonstrate its Kinetis L series microcontrollers (MCUs) built on the ARM Cortex-M0+ processor at DESIGN West in San Jose, California, with alpha sampling due to start in the second quarter of 2012. Freescale  says the ability to demonstrate these devices is possible due to its  close partnership between ARM during the Cortex-M0+ core development  process and as a lead partner provided  input that helped ARM define and  develop the processor. The devices are slated for applications  such as domestic appliances, portable medical systems, smart meters,  lighting, power and motor control systems. "Our close partnership  with ARM throughout the design and development of their new core has  positioned us as the first MCU supplier to produce and demonstrate an MCU based on the Cortex-M0+ and continues our strategy of driving to  market new products based on the ARM architecture," said Reza  Kazerounian, senior vice president and general manager of Freescale’s  Automotive, Industrial and Multi-Market Solutions Group. Mike  Inglis, executive vice president and general manager of ARM’s Processor  Division, added "With the addition of the L series to their Kinetis  line, Freescale is creating one of the industry’s broadest, most  scalable ARM Cortex-M MCU portfolios, ranging from very low-cost,  entry-level products based on the ARM Cortex-M0+ processor, up to 4 MB,  200 MHz devices based on the Cortex-M4 processor." Manufactured  using Freescale’s low-leakage, 90 nm thin film storage (TFS) process  technology, the Kinetis L series will have a selection of on-chip flash  memory densities and analog, connectivity and HMI peripheral options. Upward  migration through the Kinetis portfolio is available via compatible Kinetis K series devices (built on the ARM Cortex-M4 processor) that  provide access to DSP performance and advanced feature integration. The  ARM Cortex-M0+ processor includes a reduced two-stage pipeline,  allowing faster branch instruction execution, single-cycle access to I/O  and critical peripherals, optimized access to program memory, linear 4  GB address space that removes the need for paging, reducing software  complexity and ensuring a more 8-bit-like user experience and a micro  trace buffer, providing a low-cost trace solution that allows faster bug  identification and correction without the need for additional I/O  resources. Freescale will demonstrate the ARM Cortex-M0+ core at its exhibition booth #1604 at DESIGN West , March 26-29 at the San Jose McEnery Convention Center.