Hello Freedom community users Few weeks before, I produced for the Element14 community a full video review of the FRDM-KL46Z including all the steps to program and debug your first project example. Video has a length of less than 13 min so your evaluation of the Kinetis KL46 should be really quick and easy http://www.element14.com/community/community/designcenter/kinetis_kl2_freedom_board/blog/2014/06/17/frdm-kl46z-full-review-and-getting-started-in-video Enjoy Greg

Introduction What is a gated timer and why would I need one? A gated timer is a timer whose clock is enabled (or "gated") by some external signal.  This allows for a low code overhead method of synchronizing a timer with an event and/or measuring an event. This functionality is not commonly included on Freescale microcontroller devices (this functionality is only included on devices that are equipped with the upgraded TPM v2 peripheral; currently K66, K65, KL13, KL23, KL33, KL43, KL03) but can be useful in some situations.  Some applications which may find a gated timer useful include asynchronous digital sampling, pulse width duty cycle measurement, and battery charging. How do I implement a gated timer with my Kinetis FTM or TPM peripheral? To implement a true gated timer with a Kinetis device (that does not have the TPM v2 peripheral), additional hardware will be required to implement the enable/disable functionality of a gated timer.  This note will focus on two different ways (low-true and high-true) to implement a gated timer.  The method used will depend on the requirements of your application. Implementing a gated timer for Kinetis devices without the TPM v2 peripheral requires the use of a comparator and a resistive network to implement a gated functionality (NOTE:  Level shifters could be used to replace the resistive network described; however, a resistive network is likely more cost effective, and thus, is presented in this discussion).  Figure 1 below is the block diagram of how to implement a gated timer functionality.  The theory behind this configuration will be explained in later sections. Theory of Operation Comparator and resistive network implementation The comparator is the key piece to implementing this functionality. For those with little experience with comparators (or need a refresher), a comparator is represented by the following figure.  Notice that there are three terminals that will be of relevance in this application: a non-inverting input (labeled with a '+' sign), an inverting input (labeled with a '-' sign), and an output. A comparator does just what the name suggests: it compares two signals and adjusts the output based on the result of the comparison.  This is represented mathematically in the figure below. Considering the above figure, output of the comparator will be a  logic high when the non-inverting input is at a higher electric potential than the inverting input.  The output will be a logic low if the non-inverting input is at a lower electric potential than the inverting input.  The output will be unpredictable if the inputs are exactly the same (oscillations may even occur since comparators are designed to drive the output to a solid high or solid low).  This mechanism allows the clock enable functionality that is required to implement a gated timer function provided that either the non-inverting or inverting input is a clock waveform and the opposite input is a stable logic high or low (depending on the desired configuration) and neither input is ever exactly equal.  Comparator Configurations There are two basic signal configurations that an application can use to enable the clock output out of the comparator: low-true signals and high-true signals.  These two signals and some details on their implementation are explained in the following two sections.  Low-true enable A low-true enable is an enable signal that will have zero electric potential (relative to the microcontroller) or a "grounded" signal in the "active" state.  This configuration is a common implementation when using a push button or momentary switch to provide the enable signal.  When using this type of signal, you will want to connect the enable signal to the non-inverting input of the comparator, and connect the clock signal to the inverting input. The high level of the enable signal should be guaranteed to always be the highest voltage of the input clock plus the maximum input offset of the comparator. To find the maximum input offset of the comparator, consult the device specific datasheet.  See the figure below to see a graphical representation of areas where the signal will be on and off. The external hardware used should ensure that the low level of the enable signal never dips below the lowest voltage of the input clock plus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. High-true enable A high-true enable is an enable signal that will have an electric potential equal to VDD of the microcontroller in the "active" state.  This configuration is commonly implemented when the enable signal is provided by an active source or another microcontroller.  When interfacing with this type of signal, you will want to connect the enable signal to the inverting input of the comparator, and connect the clock signal to the non-inverting input.  When the comparator is in the inactive state, it should be at or below the lowest voltage of the clock signal minus the maximum input offset of the comparator.  Refer to the following figure for a diagram of the "on" and "off" regions of the high true configurations. The external hardware will need to guarantee that the when the enable signal is in the active state, it does not rise above the highest voltage of the clock signal minus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. Clocking Options Clocking waveform requirements will vary from application to application.  Specifying all of the possibilities is nearly impossible.  The point of this section is to inform what options are available from the Kinetis family and provide some insight as to when it might be relevant to investigate each option. The Kinetis family provides a clock output pin for most devices to allow an internal clock to be routed to a pin.  The uses for this option can vary.  In this particular scenario, it will be used to provide the source clock for the comparator clock input. Here are the most common clock output pin options across the Kinetis K series devices.  (NOTE:  If the application requires a clock frequency that the CLKOUT signal cannot provide, a separate FTM or TPM instance or another timer module can be used to generate the required clock.) In the Kinetis L series devices, the following options will be available. The clock option selected should be the slowest allowable clock for the application being designed.  This will minimize the power consumption of the application.  For applications that require high resolution, the Bus, Flash, or Flexbus clock should be selected (note that the Flexbus clock can provide an independently adjustable clock, if it is not being used in the application, as it is always running).  However, if the target application needs to be more power efficient, the LPO or MCGIRCLK should be used.  The LPO for the Kinetis devices is a fixed 1 kHz frequency and will, therefore, only be useful in applications that require millisecond resolutions.

In this document we are going to see how to use the attached code which implements the configuration of the FRDM-KL25 board as a USB HOST interfacing with a Numeric Keyboard and a 16x2 LCD. The project is compiled in the CodeWarrior IDE using Processor Expert and the Components to support the USB module of the USB Stack 4.1.1. How to add the Processor Expert USB components. The instructions to install the USB components to use them with Processor Expert are in the documentation of the USB Stack 4.1.1; here you can see the steps as well: Download the USB Stack 4.1.1 from the Freescale’s Website (USB Stack 4.1.1) Run the .exe file and install it in the default location. Open CodeWarrior and select Import Components in the Processor Expert button in menu bar. An Open windows will pop up, there you need to go to the path: <install folder>\Freescale USB Stack v4.1.1\ProcessorExpert\Components. To have the complete components and support for the USB module add each PEupd file repeating this step. Close CodeWarrior and open it again to ensure correct installation of the components. Check that the new components are available in the Components Library. About this Project. This project is based in the example code for Processor Expert in the USB Stack 4.1.1 USB_HID_MOUSE_HOST_MKL25Z128_PEx which implements the use of the FRDM-BOARD KL25 and a HID Mouse Device to interface with. In this project the HID Device is a Numeric Keyboard and the HOST Device (FRDM-KL25) is handling the data and printing them in a 16x2 LCD used in 8 bits mode (The LCDHTA component used here was created by Erich Styger; find the component an all the information about it here: http://mcuoneclipse.com/2012/12/22/hd44780-2x16-character-display-for-kinetis-and-freedom-board/ and say Thank you Erich: “Thank you Erich”). Here you can find a video of the implementation of this application: HID HOST WITH FRDM-KL25 The hardware components are: FRMD-KL25 Rev.E Adafruit Prototype Shield v.5 LCD JHD-162A Numeric USB Keyboard (Product Name: Numpad i110, Model No. GK-100010) USB _host Inside the project you can see there is a folder called USB_Host an it contains two important folders with source files: App_keyboard: Contains the specific function for the Keyboard configuration: in use, attached detached, callbacks and more; contain how to handle the data coming from the device. The function process_kdb_buffer is where the data is transmitted to the LCD and use it for the application. Classes: contain the necessary function to handle a hid as the device. Handle all the functions necessary for the USB protocol. Note: The usb_classes.c and usb_classes.h files are generated by processor expert. I attach these two files as well to have a reference how these files must look like. This is because sometimes during the code generation process Processor Expert erases part of the code. I hope this project is useful for you. Best Regards, Adrian.

This is a Processor Expert project created by CodeWarrior for MCUs v10.6 which implements the charge-discharge time of a RC circuit for measuring capacitance. The charge-discharge sequence is performed by TPM0 operating in PWM mode, while the time is measured by TPM1 operating in Input Capture mode. A 100K ohm series resistor is being used, and the result is expressed on nF. It is also using the LCDHTA component from Erich Styger for showing the measurements on a 16x2 LCD, connected to the FRDM-KL05Z through a proto shield. The project is attached, and the pictures shows the measurements of three different capacitors: 10nF, 47nF and 1uF.

The KL TSI Library provides the following benefits: • Reduces time to market and development costs. Already available turn-key TSI Library for IH cooker, remote controller applications, etc. • KL TSI is a hardware touch sensing solution, without any additional peripherals, e.g. Timers, GPIO, CPU execution, as a result reduces overall system cost and size. • Enhances reliability by enabling environment adaptive algorithm, eliminating water droplet and stream influence, and filtering electromagnetic interference. • Easy to use, simplifies user interface design. Flexible TSI software library enabling customers to develop an application • FreeMaster1.4 visualizes TSI signal on screen, thus customer can debug and tune touch software simply.

我们知道Kinetis L系列的中断向量表中只支持两个外部中断向量（vector_46 and vector_47），而FSL早期推出的的KL系列（包括KL25\KL24、KL15\KL14）只有PORTA和PORTD两个IO口支持中断，不过最新推出的KLx6系列（KL26、KL16和KL46）可以支持PORTA、PORTC和PORTD三个IO口的外部中断，其中PORTC和PORTD这两个IO端口共享同一个中断向量，另外，KL0x系列（包括KL02、KL04和L05）由于外部引脚只有PORTA和PORTB两个IO端口，所以它所支持的外部中断只有PORTA和PORTB。 下图分别为KLx5\KLx4系列（不包括KL05\KL04）、KLx6系列和KL05\KL04\KL02的外部中断向量分配表： KLx5\KLx4: KLx6: KL0x: KLx6的头文件注释： 最后需要注意的是，目前所有官方的demo例程（KLxx_SC）的中断向量表vector.h和MKLxxxx.h文件中关于中断向量的注释仍然是PORTA和PORTD，甚至有一部分例程中中断向量表的注释仍然是M4的注释直接移过来的，容易误导客户编程，这点需要在设计PCB板的时候有所考虑。

        在我们嵌入式工程应用中，中断作为最常用的异步手段是必不可少的，而且在一个应用程序中，一个中断往往是不够用的，多个中断混合使用甚至多级中断嵌套也经常会使用到，而这样就涉及到一个中断优先级的问题。         以我们最熟悉的Cortex-M系列为例，我们知道ARM从Cortex-M系列开始引入了NVIC的概念（Nested Vectors Interrupts Controller），即嵌套向量中断控制器，以它为核心通过一张中断向量表来控制系统中断功能，NVIC可以提供以下几个功能： 1）可嵌套中断支持； 2）向量中断支持； 3）动态优先级调整支持； 4）中断可屏蔽。         抛开其他不谈，这里我们只说说中断优先级的问题。我们知道NVIC的核心工作原理即是对一张中断向量表的维护上，其中M4最多支持240+16个中断向量，M0+则最多支持32+16个中断向量，而这些中断向量默认的优先级则是向量号越小的优先级越高，即从小到大，优先级是递减的。但是我们肯定不会满足于默认的状态（人往往不满足于约束，换句俗话说就是不喜欢按套路出牌，呵呵），而NVIC则恰恰提供了这种灵活性，即支持动态优先级调整，无论是M0+还是M4除了3个中断向量之外（复位、NMI和HardFault，他们的中断优先级为负数，它们3个的优先级是最高的且不可更改），其他中断向量都是可以动态调整的。         不过需要注意的是，中断向量表的前16个为内核级中断，之后的为外部中断，而内核级中断和外部中断的优先级则是由两套不同的寄存器组来控制的，其中内核级中断由SCB_SHPRx寄存器来控制（M0+为SCB_SHPR[2:3]，M4为SCB_SHPR[1:3]），外部中断则由NVIC_IPRx来控制（M0+为NVIC_IPR[0:7]，M4为NVIC_IPR[0:59]），如下图所示： M0+中断优先级寄存器： M4中断优先级寄存器：         其中M4所支持的动态优先级范围为0~15（8位中只有高四位[7:4]才有效），而M0+所支持的动态优先级范围则为0~3（8位中只有高两位[7:6]才有效），而且秉承着号越小优先级越高的原则（0最高，15或3为最小），同时也间接解释了为什么复位（-3）、NMI（-2）和HardFault（-1）优先级最高的原因，很简单，人家都是负的了，谁还能比他们高，呵呵，而且这三位中复位优先级最高，NMI其次，HardFault最低（这个最低仅限于这三者）。 下面给出个ARM CMSIS库中关于M0+和M4中断优先级设置的API函数NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)实现供大家来参考： M0+: NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority) {   if(IRQn < 0) {     SCB->SHP[_SHP_IDX(IRQn)] = (SCB->SHP[_SHP_IDX(IRQn)] & ~(0xFF << _BIT_SHIFT(IRQn))) |         (((priority << (8 - __NVIC_PRIO_BITS)) & 0xFF) << _BIT_SHIFT(IRQn)); }  /* set Priority for Cortex-M  System Interrupts */   else {     NVIC->IP[_IP_IDX(IRQn)] = (NVIC->IP[_IP_IDX(IRQn)] & ~(0xFF << _BIT_SHIFT(IRQn))) |         (((priority << (8 - __NVIC_PRIO_BITS)) & 0xFF) << _BIT_SHIFT(IRQn)); }   /* set Priority for device specific Interrupts  */ } M4: void NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority) {   if(IRQn < 0) {     SCB->SHP[((uint32_t)(IRQn) & 0xF)-4] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff); } /* set Priority for Cortex-M  System Interrupts */   else {     NVIC->IP[(uint32_t)(IRQn)] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff);    }        /* set Priority for device specific Interrupts  */ }

作者 Sam Wang & River Liang 在RISC架构的MCU中，通常是加载-存储（Load and Store）的操作机制，而这种方式不能提供传统8bit架构MCU的直接位操作内存和地址空间。为此飞思卡尔在M0+系列MCU上集成了BME（Bit Manipulation Engine）位操作引擎功能，例如KE和KL系列里都带有BME，它从硬件上提供了对外设地址空间用读-修改-写的操作方式来实现位操作。         使用BME能够降低总线的占用率和CPU执行时间，这些效果都能够降低系统的功耗。另外使用相比于用C语言实现相同功能的代码，使用BME能够更节省代码空间。这些可以参照         BME功能支持访问从0x4000_0000开始的，大小为512K的地址空间，并把它映射成从0x4400_0000到0x5fff_ffff的内存空间。         好了，长话短说。下面转入正题，我们应该如何使用BME来进行位操作，并达到节省代码空间、提高效率的效果。 一、写操作方式，对定义内容用写的方式来实现与、或、异或、位域插入功能 1：BME的&操作可以一次对IO的几个bit清0     //     0x21<<26 | addr (A0~A19) //GPIOA_PDOR   地址为   400F_F000 #define GPIOA_AND *((volatile unsigned char *) (0x44000000+0xFF000)) 例: GPIOA_AND=0xaa; #define GPIOA_AND_I *((volatile unsigned int *) (0x44000000+0xFF000)) 例: GPIOA_AND_I=0x55aa; 实际上命令是将400f_f000的内容与目标数进行&运算。修改volatile unsigned char, volatile unsigned int, volatile unsigned long来实现BME的所谓8,16,32位操作.下面命令相同。 2：BME的|操作可以一次对IO的几个bit置1     //       0x22<<26 | addr (A0~A19) #define GPIOA_OR *((volatile unsigned char *) (0x48000000+0xFF000)) 例: GPIOA_OR=0xaa; #define GPIOA_OR_I *((volatile unsigned int *) (0x48000000+0xFF000)) 例: GPIOA_OR_I=0x55aa; 实际上命令是将400f_f000的内容与目标数进行|运算。 3： BME的^操作          //     0x23<<26 | addr (A0~A19) #define GPIOA_XOR *((volatile unsigned char *) (0x4C000000+0xFF000)) 例：GPIOA_XOR=0xaa; #define GPIOA_XOR_I *((volatile unsigned int *) (0x4C000000+0xFF000)) 例: GPIOA_XOR_=0x55aa; 上面3个例子讲解了一般的与、或、异或等常用操作，下面来点复杂一点的。                                                                                           4： BME的位域插入操作BFI（Bit Field Insert）//   (5<<28) | (bit<<23) | (width<<19) | addr (A0~A18) #define BME_BFI_ADDR (ADDR, BIT, WIDTH)   (*(volatile uint32_t *) (((uint32_t) ADDR) | (1<<28) | (BIT<<23) | (WIDTH<<19))) 在这里bit是插入的位置，表示被操作目标的最低位开始被操作，Width这里是插入的数据长度 例：BME_BFI_ADDR(&ADC0_CFG1, 0x05, 0x01) = 0x40; 结果是将寄存器ADC0_CFG1从bit5开始，用0x40的bit5来替换ADC0_CFG1的bit5，0x40的bit6来替换ADC0_CFG1的bit6，调用该命令后，寄存器ADC0_CFG1_ADIV = 2 相当于执行了mask = ((1 << (w+1)) - 1) << b;                          //等一系列位操作。                             (ADC0_CFG1 & ~mask) | (0x40 & mask); 使用BFI功能需要注意的是，操作地址是A0到A18，而GPIO寄存器的A0到A19是从FF000开始，因此会有1bit 的地址冲突。为此，在使用BFI操作GPIO的寄存器时，使用的是内存映射出来的地址空间，此时GPIO的起始地址将为F000，如果还使用原来的地址，命令将会无效。之前提到的AND、OR、XOR操作，对于GPIO地址空间在FF000还是F000都适用 #define BME_BFI_GPIOA (BIT, WIDTH)        (*(volatile uint32_t *) ((uint32_t) (5<<28) | (BIT<<23) | (WIDTH<<19) | 0xF000)) 例：BME_BFI_GPIOA(0,3) = 0x0a; 结果是GPIO_PDOR从bit0开始，一共4位被1010替换了。 二、读操作方式 5, BME的读操作使某位置1, Load-and-Set 1 Bit// #define PTA1_SET   (void) (*((volatile unsigned char *) (0x4C000000+ (1<<21) + 0xF000))) #define PTA1_SET_I   (void) (*((volatile unsigned int *) (0x4C000000+ (1<<21) + 0xF000))) 例: PTA1_SET;   //效果是GPIOA1高电平         LAS1      第1位    GPIOA_PDOR地址的A0-A15 6, BME的读操作使某位清0, Load-and-Clear 1 Bit #define PTA2_CLR   (void) (*((volatile unsigned char *) (0x48000000 + (2<<21) + 0xF000))) #define PTA2_CLR_I   (void) (*((volatile unsigned int *) (0x48000000 + (2<<21) + 0xF000))) 例: PTA2_CLR;     //效果是GPIOA2低电平        LAC1      第2位     GPIOA_PDOR地址的A0-A15 7, BME同时提取多个bit，Unsigned Bit Field Extract 前8位内                     //UBFX      第1位开始       取1+1位   GPIOA_PDOR地址的A0-A18 #define PTA_OUT    *((volatile unsigned char *) (0x50000000+ (1<<23) + (1<<19) + 0xF000)) 前16位内                   //UBFX      第1位开始       取1+1位   GPIOA_PDOR地址的A0-A18 #define PTA_OUT_I    *((volatile unsigned int *) (0x50000000+ (1<<23) + (1<<19) + 0xF000)) 例: 初始值GPIO_PDOR = 0x3a;   //            11_1010   temp = PTA_OUT; //                    此时temp = 0x01 例: 初始值GPIO_PDOR = 0x35;   //            11_0101   temp = PTA_OUT; //                    此时temp = 0x02 该宏定义UBFX功能是将GPIO_PDOR从bit1开始提取1+1位，并以bit1为最低位赋值到目标变量。          需要注意的是UBFX与BFI一样操作的都是映射内存空间，用来操作GPIO时要以F000为起始地址。         BME执行的是读-修改-写操作，而我们很多寄存器有些位是w1c，也就是所谓的write-1-clear，写1清0的工作方式。使用BME时就需要特别注意和小心了，否则会出现很多不可预料的后果。               如果一个寄存器中有多个连续的W1C位，我们就不要使用LAS1来对寄存器写1清0了，因为在LAS1这个操作中，其中有一步操作是将数据读回（在reference manual中有read data return to core一说）。这一步会将原本不需要清0的位给清了。         下面介绍这个情况的实验。 在我们M0+的PWM模块中，寄存器TPM0_STATUS所有有效位都为w1c，我们模拟一个情景： 系统48MHz，TPM时钟128分频，TPM0定时中断计数器最大值为37499，并使能溢出中断。 通道0设置为output compare模式的match output low，比较值为10000，不触发中断。 通道1设置为output compare模式的match output high，比较值为20000，不触发中断。 上面的设置可以使我们每50ms进入一次中断，需要我们在中断服务程序中清中断标志。 TPM0_STATUS 地址为 0x4003_8050 中断函数中设置断点观察TPM0_STATUS的值，为1_0000_0011 B #define TPM0_STATUS_LAS1   (void) (*((volatile unsigned int *) (0x4C000000| (1<<21) | 0x38050))) 中断程序中用TPM0_STSTUS_LAS1将bit1置1清0，得到的结果是TPM0_STATUS = 0，使用LAS1作用在该寄存器的其他位结果都一样。将其他不需要改动的位都清0了。     我们换种方式。 #define TPM0_ STSTUS_BFI *((volatile unsigned int *) (0x50000000 | (0<<23) | (8<<19) | 0x38050)) =0x001 中断里用BFI去修改该连续的w1c位，从bit0开始，长度为8+1位，执行TPM0_STSTUS_BFI后bit8和bit2仍为1， bit0已经被清0了。这确实是我们想要的效果。         此后我们遇上一个寄存器有多个连续w1c时，可以使用BFI的方式来改写寄存器w1c位的值，而位判断则采用UBFX的方式来提取该位域。 下面是针对比较器的CMP0_SCR寄存器操作的例程. CMP0_SCR是8bit的寄存器bit1和bit2是w1c #define CMP_SCR_CFR_CLR *((volatile unsigned char *) (0x50000000+ (1<<23) + (1<<19) + 0x73003)) =4 #define CMP_SCR_CFF_CLR *((volatile unsigned char *) (0x50000000 + (1<<23) + (1<<19) +0x73003)) =2              //           BFI                    第一位开始   1+1位          2对应bit2bit1为01          4对应bit2bit1为10 #define CMP_SCR_CFR    *((volatile unsigned char *) (0x50000000 + (2<<23) + (0<<19) + 0x73003)) #define CMP_SCR_CFF    *((volatile unsigned char *) (0x50000000 + (1<<23) + (0<<19) + 0x73003))             //            UBFX                分别是提取bit2和bit1的值 void CMP_Change(void) { If (CMP_SCR_CFR) { CMP_SCR_CFR_CLR; }                   If (CMP_SCR_CFF) { CMP_SCR_CFF_CLR; } }         总结，BME功能可以有效提高M0+的位操作性能并减少代码占用空间，但用于处理w1c位时要特别小心，总的来说BME是个好东西，在内核资源紧张的时候可以给用户提供一个精简代码的手段。

You probably have heard of what's new on Kinetis side of the house. YES, talking about KL02, measuring only 1.9mm x 2.0mm. Take a look at the picture in which this powerful ARM based chip gets compared real scale, and being this tiny yet delivers 60 percent more GPIO than the nearest competing MCU. :smileygrin:!!!

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. 

Recently, some customers have provided us with feedback stating they have been experiencing difficulties when connecting  Kinetis L series  microcontrollers using Multilink Universal probes, after checking the connection and software settings no obvious errors could be found. This recurrent problem has been confirmed by several customers, the  problem is caused by a long connection line. My suggestion is to keep connection line length to 10cm or less; otherwise, the IDE may not be able to establish the connection through the Multilink Universal.

Hi everyone! I have made a simple touch sensing demo for KL25z Freedom board for fast user friendly test using MSD bootloader (default combined application in Open SDA when you receive the Freedom - Mass Storage Device and serial port). Demo changes the brightness of red led populated on the board and communicate with FreeMaster visualization tool over embedded virtual serial port of Open SDA connection. Touch sensing application is controlled by TSS (touch sensing softwere). For more information about touch sensing and download of TSS go to www.freescale.com/tss The visualization output has 2 separate scope windows: one showing signals captured from electrodes of slider another one showing position of finger on a slider The operation is really simple, just drag and drop the attached *.s19 file into your device using MSD bootloader (as other precompiled projects for Freedom board) open the *.pmp file that is associated with FreeMASTER, choose the correct COM port at speed of 38400 kbps and start communication The demo was made in CodeWarrior 10.4 using TSS library 3.0.1 in Processor Expert tool, source code can be provided if there will be an interest. There is no need to configure MAP file for FreeMaster communication, application uses so called TSA table - it is position independent this way. If you are not familiar with FreeMASTER or not have it installed in your PC - go to www.freescale.com/freemaster to read more and download the free installer, install it and you are good to run the demo. There are two independent snapshots below, showing the response to my finger movement along the slider Enjoy! and keep in touch

The Real Time Clock (RTC) module is the right tool when we want to keep tracking the current time for our applications. For the Freedom Platform (KL25Z) the RTC module features include: 32-bit seconds counter with roll-over protection and 32-bit alarm 16-bit prescaler with compensation that can correct errors between 0.12 ppm and 3906 ppm. Register write protection. Lock register requires POR or software reset to enable write access. 1 Hz square wave output. This document describes how to implement the module configuration. Also, how to modify the hardware in order feed a 32 KHz frequency to RTC module (it is just a simple wire link).     Hardware. The RTC module needs a source clock of 32 KHz. This source is not wired on the board; hence we need to wire it. Do not be afraid of this, it is just a simple wire between PTC3 and PTC1 and the good news are that these pins are external.   PTC1 is configured as the RTC_CLKIN it means that this is the input of source clock.     PTC3 is configured as CLKOUT (several options of clock frequency can be selected in SIM_SOPT2[CLKOUTSEL] register). For this application we need to select the 32 Khz clock frequency.                         RTC configuration using Processor Expert. First of all we need to set the configurations above-mentioned in Component Inspector of CPU component. Enable RTC clock input and select PTC1 in Pin Name field. This selects PTC1 as RTC clock input. MCGIRCLK source as slow in Clock Source Settings > Clock Source Setting 0 > Internal reference clock > MCGIRCLK source. This selects the 32 KHz clock frequency. Set ERCLK32K Clock Source to RTC Clock Input in Clock Source Settings > Clock Source Setting 0 > External reference clock > ERCLK32K Clock Source. This sets the RTC_CLKIN as the 32 KHz input for RTC module. Select PTC3 as the CLKOUT pin and the CLKOUT pin output as MCGIRCLK in Internal peripherals > System Integration Module > CLKOUT pin control. With this procedure we have a frequency of 32 KHz on PTC3 and PTC1 configured as RTC clock-in source. The MCG mode configurations in this case is PEE mode: 96 MHz PLL clock, 48 MHz Core Clock and 24 MHz Bus clock.   For the RTC_LDD component the only important thing is to select the ERCKL32K as the Clock Source. The image below shows the RTC_LDD component configuration for this application.   After this you only need to Generate Processor Expert Code and write your application.  The code of this example application can be found in the attachments of the post. The application prints every second the current time.     RTC bare-metal configuration. For a non-PEx application we need to do the same configurations above. Enable the internal reference clock. MCGIRCLK is active.          MCG_C1 |= MCG_C1_IRCLKEN_MASK; Select the slow internal reference clock source.          MCG_C2 &= ~(MCG_C2_IRCS_MASK); Set PTC1 as RTC_CLKIN and select 32 KHz clock source for the RTC module.          PORTC_PCR1 |= (PORT_PCR_MUX(0x1));              SIM_SOPT1 |= SIM_SOPT1_OSC32KSEL(0b10); Set PTC3 as CLKOUT pin and selects the MCGIRCLK clock to output on the CLKOUT pin.     SIM_SOPT2 |= SIM_SOPT2_CLKOUTSEL(0b100);     PORTC_PCR3 |= (PORT_PCR_MUX(0x5));   And the RTC module configuration could be as follows (this is the basic configuration just with seconds interrupt): Enable software access and interrupts to the RTC module.     SIM_SCGC6 |= SIM_SCGC6_RTC_MASK; Clear all RTC registers.   RTC_CR = RTC_CR_SWR_MASK; RTC_CR &= ~RTC_CR_SWR_MASK;   if (RTC_SR & RTC_SR_TIF_MASK){      RTC_TSR = 0x00000000; } Set time compensation parameters. (These parameters can be different for each application) RTC_TCR = RTC_TCR_CIR(1) | RTC_TCR_TCR(0xFF); Enable time seconds interrupt for the module and enable its irq. enable_irq(INT_RTC_Seconds - 16); RTC_IER |= RTC_IER_TSIE_MASK; Enable time counter. RTC_SR |= RTC_SR_TCE_MASK; Write to Time Seconds Register. RTC_TSR = 0xFF;   After this configurations you can write your application, do not forget to add you Interrupt Service Routine to the vector table and implement an ISR code.   In the attachments you can find two zip files: PEx application and non-PEx application.   I hope this could be useful for you,   Adrián Sánchez Cano. Original Attachment has been moved to: FRDM-KL25Z-RTC-TEST.zip Original Attachment has been moved to: FRDM-KL25Z-PEx-RTC.zip

Hello all.   I would like to share an example project for FRDM-KL25Z board on which C90TFS Flash Driver was included to implement emulated EEPROM (Kinetis KL25 doesn’t have Flex Memory). It is based on the “NormalDemo” example project. A string of bytes is stored on the last page of the flash memory (address 0x1FC00-0x1FFFF), and then, it is overwritten with a different string.   The ZIP file also includes the “Standard Software Driver for C90TFS/FTFx Flash User’s Manual” document. For more information, please refer to Freescale website and search for “C90TFS” flash driver. Hope this will be useful for you. Best regards! /Carlos

Microgenios viabilizou a realização de videos de treinamentos de curta duração para ensinar os primeiros passos com o microcontrolador Kinetis L como parte do Road Show de Microcontroladores ARM cortex-M0+ (Kinetis L Freescale), projeto realizado em parceria pela a Freescale em 10 cidades espalhadas pelo Brasil. Veja os videos para iniciar seu projeto com Kinetis L: Neste vídeo aprenderemos o processo de download e instalação do CodeWarrior V10.3 e outros pacotes de softwares Freescale: http://www.youtube.com/watch?v=bjtsLHMImDY Neste vídeo aprenderemos o processo de atualização do CodeWarrior V10 (baseado no Eclipse) e conheceremos as pastas criadas na instalação: http://www.youtube.com/watch?v=Sslf0nF0Td8 Neste vídeo conheceremos a ferramenta de hardware Freedom Board da Freescale com microcontrolador ARM cortex-M0+; e entenderemos a utilização da interface de gravação e depuração OpenSDA: http://www.youtube.com/watch?v=jeuq7ErvTGQ Neste vídeo aprenderemos a criar nosso primeiro projeto com a Freedom Board (FRDM-KL25Z), que possui microcontrolador da família Kinetis L (núcleo ARM cortex-M0+) da Freescal; utilizaremos como ferramenta de software o CodeWarrior V10.3 e o Processor Expert: http://www.youtube.com/watch?v=sx2tpDBWDt8 Neste vídeo conheceremos a IDE cloud mbed, que possibilita desenvolvimento e aplicações diretamente no navegador: http://www.youtube.com/watch?v=N7qMvO_R6Sc Mais informações visite: http://www.microgenios.com.br/website/index.php/hands-on-freescale

La serie Kinetis L es una combinación de eficiencia energética, escalabilidad, valor y facilidad de uso que revolucionará el mercado de microcontroladores de nivel básico. Ofrece a los usuarios de arquitecturas heredadas de 8 y 16 bits una ruta de migración hacia la gama de microcontroladores Kinetis de 32 bits y les permite aumentar el rendimiento y ampliar la funcionalidad de sus productos finales sin incrementar el consumo de energía ni los costes del sistema. La serie Kinetis L se compone de cinco familias de microcontroladores: KL0, KL1, KL2, KL3 y KL4. Cada familia combina excelentes corrientes dinámicas y de parada con una capacidad extraordinaria de procesamiento, una amplia selección de memorias flash y una gran variedad de opciones analógicas, de conectividad y de periféricos HMI. La familia KL0 es compatible en pines con la familia S08Px de 8 bits (lo que tiende un puente entre el desarrollo de 8 bits y la cartera Kinetis) y compatible en software con otras familias de la serie Kinetis L. Las familias KL1, KL2, KL3 y KL4 presentan una compatibilidad mutua en hardware y software, además de ser compatibles con sus equivalentes de la serie Kinetis K basada en el Cortex-M4 (KL1 -> K10, KL2 -> K20…). De este modo, los desarrolladores disponen de una ruta de migración ascendente/descendente hacia mayor/menor rendimiento, memoria y funcionalidad integrada, lo que les permite reutilizar el hardware y el software en todas las plataformas de productos finales y reducir el tiempo necesario para la comercialización. Las primeras familias disponibles en el mercado serán KL0, KL1 y KL2 a finales de septiembre de 2012. La disponibilidad de las familias KL3 y KL4 está prevista para el primer trimestre de 2013. Procesador ARM Cortex-M0+ El procesador ARM Cortex-M0+ ofrece niveles más altos de eficiencia energética y de rendimiento y es más fácil de usar que su antecesor, el Cortex-M0. En cuanto a las instrucciones, mantiene plena compatibilidad con todos los demás procesadores de la clase Cortex-M (Cortex-M0/3/4), por lo que los desarrolladores pueden reutilizar sus compiladores y herramientas de depuración existentes. Principales características: 1,77 coremarks/MHz: entre 2 y 40 veces más que los microcontroladores de 8/16 bits, un 9 % más que el Cortex-M0. Coremarks/mA: entre 2 y 50 veces más que los microcontroladores de 8/16 bits, un 25 % más que el Cortex M0. Pipeline de 2 etapas: reducidos ciclos por instrucción (CPI), lo que permite instrucciones de bifurcación y entradas ISR más rápidas. MTB (Micro Trace Buffer): solución ligera y no intrusiva; la información del rastreo se guarda en una pequeña área de la SRAM del microcontrolador (tamaño definido por el programador), lectura a través de SWD/JTAG. Amplio soporte para el entorno ARM. Acceso E/S monociclo: frecuencia de conmutación de la interfaz GPIO un 50 % más alta que la de la E/S estándar, lo que mejora el tiempo de respuesta a eventos externos y permite manipular bits (bit-banding) y emular protocolos de software. Espacio de direcciones lineal de 4 GB: elimina esquemas de paginación complejos y simplifica la arquitectura de software. Solamente 56 instrucciones: mayoritariamente codificadas en 16 bits; opción para MUL rápida de 32 x 32 bits en un ciclo. Conjunto de instrucciones: totalmente compatible con el procesador Cortex-M0, subconjunto de instrucciones del procesador Cortex-M3/4. La mejor densidad de códigos de su categoría en comparación con arquitecturas de 8/16 bits; menor tamaño de memoria flash y reducción del consumo de energía; mayor rendimiento que sus equivalentes de 8 y 16 bits. Acceso a la memoria del programa; reducción del consumo de energía. Familias de microcontroladores de la serie Kinetis L Los microcontroladores de la serie Kinetis L se basan en la funcionalidad del procesador ARM Cortex-M0+, que presenta un diseño de plataforma de bajo consumo energético así como modos operativos y dispositivos periféricos que ahorran energía. El resultado es un microcontrolador que ofrece la mejor eficiencia energética de la industria, consume menos de 50 μA/MHz en el modo VLPR (Very Low Power Run) y puede despertarse rápidamente desde el estado de reposo, procesar datos y restablecer el modo de reposo, lo cual alarga la vida útil de la batería en las aplicaciones. Para ver una demostración de la eficiencia energética de la serie Kinetis L, visite www.freescale.com/ftf. Familias de microcontroladores: Familia KL0: la puerta de entrada a la serie Kinetis L; microcontroladores de 8-32 kB y de 24-48 pines, compatibles en pines con la familia S08P de 8 bits y en software con todas las demás familias de la serie Kinetis L. Familia KL1: microcontroladores de 32-256 kB y de 32-80 pines con comunicaciones adicionales y periféricos analógicos, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K10 (CM4) de la serie K. Familia KL2: microcontroladores de 32-256 kB y de 32-121 pines con USB 2.0 de máxima velocidad tipo host/device/OTG, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K20 (CM4) de la serie K. Características comunes a todas las familias de microcontroladores de la serie Kinetis L: Procesamiento extremadamente eficiente Procesador ARM Cortex-M0+ de 48 MHz Tecnología flash de bajo consumo de energía: 90 nm Funciones de manipulación de bits < 50 μA/MHz; 35,4 coremarks/mA Barra cruzada de puente periférico Controlador de memoria flash con estado de espera cero Modos de consumo de energía ultrabajo Tecnología flash con baja fuga: 90 nm Múltiples modos RUN, WAIT y STOP Activación en 4,6 μs desde el modo de reposo profundo Bloqueo de reloj y de potencia (clock & power gating), opciones de arranque con bajo consumo de energía Reloj VLPR: precisión con un 3 % máximo de margen de error, que normalmente es del 0,3-0,7 % Consumo de corriente en modo de reposo profundo: 1,4 μA con retención de registros; LVD activo y activación en 4,3μs Periféricos que ahorran energía Los periféricos funcionan en modos de reposo profundo y son capaces de tomar decisiones inteligentes y de procesar datos sin despertar al núcleo: ADMA, UART, temporizadores, convertidor analógico-digital (ADC), pantalla LCD con segmentos, sensores táctiles... ADC de 12/16 bits Convertidor digital-analógico (DAC) de 12 bits Comparadores analógicos de alta velocidad Temporizadores de alta capacidad para una gran variedad de aplicaciones, incluyendo el control de motor Para tener más información del fabricante y de los servicios, por favor visiten nuestra microsite. Via Arrow Europe

The FRDM-KL25Z is an ultra-low-cost development platform enabled by Kinetis L Series KL1 and KL2 MCUs families built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL25Z is supported by a range of Freescale and third-party development software. Features MKL25Z128VLK4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP Capacitive touch “slider,” MMA8451Q accelerometer, tri-color LED Easy access to MCU I/O Sophisticated OpenSDA debug interface Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps P&E Multilink interface provides run-control debugging and compatibility with IDE tools Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit Take a look at these application notes: USB DFU boot loader for MCUs Developer’s Serial Bootloader. Low Cost Universal Motor Drive Using Kinetis L family . Writing your First MQXLite Application Learn more...

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.

The Freescale Freedom development platform is a low-cost evaluation and development platform featuring Freescale's newest ARM® Cortex™-M0+ based Kinetis KL25Z MCUs NEW! Quick Start Guide Features: KL25Z128VLK4--Cortex-M0+ MCU with:   - 128KB flash, 16KB SRAM - Up to 48MHz operation  - USB full-speed controller OpenSDA--sophisticated USB debug interface Tri-color LED Capacitive touch "slider" Freescale MMA8451Q accelerometer Flexible power supply options   - Power from either on-board USB connector - Coin cell battery holder (optional population option)  - 5V-9V Vin from optional IO header - 5V provided to optional IO header - 3.3V to or from optional IO header Reset button Expansion IO form factor accepts peripherals designed for Arduino™-compatible hardware

Kinetis L series MCUs combine the exceptional energy-efficiency and ease-of-use of the new ARM® Cortex™-M0+ processor with the performance, peripheral sets, enablement and scalability of the Kinetis 32-bit MCU portfolio. The Kinetis L series frees power-critical designs from 8- and 16-bit MCU limitations by combining excellent dynamic and stop currents with superior processing performance, a broad selection of on-chip flash memory densities and extensive analog, connectivity and HMI peripheral options. Kinetis L series MCUs are also hardware and software compatible with the ARM Cortex-M4-based Kinetis K series, providing a scalable migration path to more performance, memory and feature integration. The Kinetis L Series MCUs are Energy-Efficient Product Solutions by Freescale. For more information visit Freescale.com\Lseries