Hi community!! The following example uses a PIT to start an adc conversion, once the conversion has finished it issues a DMA request and the DMA controller stores the converted value in a buffer. The examples were implemented in both CodeWarrior 10.6 and KDS 1.1 for every board. The recommended test circuit is the following: Please feel free to modify the files, I hope this examples will be useful for you and will help you by decreasing your development time. Best Regards Manuel Rodríguez Technical Information Center Intern

Hi All Kinetis Lovers, Microcontroller programming is a passion for all we are following this Community, but sometimes, trying to understand the peripherals of a Microcontroller is not an easy task, especially if we are in our first approach to a new module or device. In this post you will find a document that explains in detail the DMA module for Kinetis devices and also some examples for CodeWarrior and Kinetis Design Studio using DMA and other peripherals. The Documentation found here is: Using DMA module in Kinetis devices (complete): Document that includes DMA module explanation: everything you need to know when using DMA and the necessary information to understand the code included (K20_DMA for CW or K20D72_DMA for KDS). Using DMA module in Kinetis devices (example): Document that includes the necessary information to understand the code included (K20_DMA for CW or K20D72_DMA for KDS). Attached are two folders named: DMA examples for CW: include the DMA example projects for CW DMA examples for KDS: include the DMA example projects for KDS. Each folder includes 5 examples that are: Please feel free to modify the examples; I hope this will be useful for you. Many thanks and credits to manuelrodriguez for his valuable help developing and editing this project. :smileyinfo:For the SPI examples it is necessary to make a bridge between MOSI and MISO pins (master loop mode is used for the example). For this the TWR Elevators were used.     In the attachments you can find some extra information when using SPI and DMA. Best Regards, Adrian Sanchez Cano Technical Support Engineer

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.

Hello All, Power consumption of devices and implications around designing on embedded systems is a common topic nowadays. Kinetis MCUs offer different power modes to fit user's needs. Among these low power modes, we can find the lowest consumption modes: Low-Leakage Stop (LLS) and Very Low-Leakage Stop modes (VLLS). Attached document provides a brief introduction/explanation on these modes and lists the steps needed to configure MCU to operate in any of these modes. It is a bare-board project for FRDM-KL26Z but same principle applies to other Kinetis families. Also, two projects for KDS v3.2 are attached for reference. I hope you can find them useful! Regards, Isaac

作者 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:!!!

ROM Bootloader KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports. When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash. The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader. For example:       When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;       When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application). There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT]  = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0. blhost utility application The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder. About how to use blhost application, please check KBLHOSTUG document for more detailed info. Call Rom Bootloader from customer application In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example. Set a signal for application code to call the ROM bootloader, such as press a button. In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader. //Initalize PTEC3 as GPIO button PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL); GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3); The bootloader entry point for customer application to call the ROM bootloader.  //prototype of the entry point definition void run_bootloader(void * arg); //Variables uint32_t runBootloaderAddress; void (*runBootloader)(void * arg);   // Read the function address from the ROM API tree. runBootloaderAddress = **(uint32_t **)(0x1c00001c); runBootloader = (void (*)(void * arg))runBootloaderAddress; in <main.c> routine to call the ROM bootloader:   while (1)   {     if ((GPIOC_PDIR & (1 << 3)) == 0)     {       // Start the bootloader. runBootloader(NULL);     }   } Press SW3 button of FRDM-KL43Z board will call ROM bootloader.  Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0. In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43. When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product. More detailed info, please check attached demo code. BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.

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.

Introduction Even with the prevalence of universal asynchronous receiver/transmitter (UART) peripherals on microcontrollers (MCUs), bit banged UART algorithms are still used.  The reasons for this vary from application to application.  Sometimes it is simply because more UARTs are needed than the selected device provides.  Maybe application or layout restrictions require certain pins to be used for the UART functions but the device does not route UART pins to the required package pins.  Maybe the application requires a non-standard or proprietary UART scheme. Whatever the reason, there are applications where a bit banged UART is used and is typically a pure software implementation (a timer is used and the MCU core controls a GPIO pin directly).  A better alternative may be to use Flextimer (FTM) or Timer/PWM Module (TPM) to take advantage of the features of these peripherals and possibly offload the CPU.  This document will explain and provide a sample application of how to emulate a UART using the FTM or TPM peripheral.  A Kinetis SDK example (for the TWR-K22F120M and FRDM-K22F platforms) and a baremetal legacy code example (for the FRDM-KL26Z) are provided here. UART protocol Before creating an application to emulate a UART, the UART protocol and encoding must be understood. The UART protocol is an asynchronous protocol that typically includes a start bit, payload (of 7-10 data bits), and a stop bit but does allow for many variations on the number of stop bits and what/how to transfer the data.  For this document and application example, the focus will be UART transmission that follows 1 start bit, 8 data bits, 1 stop bit, no parity, and no flow control.  The data will be transmitted least significant bit (LSB) first.  The following image is a block diagram of this transmission. However, this doesn't specify what the transmission looks like electrically. The figure below shows a screenshot of an oscilloscope capture of a UART transmission.  The data transmitted is 0x55 or a "U" in the ASCII representation. Notice that the transmission line is initially a logic high, and then transitions low to signal the start of the transmission.  The transmission line must stay low for one bit width for the receiver to detect it.  Then there are 8 data bits, followed by 1 stop bit.  In the case shown above, the data bits are 0x55 or 0b0101_0101.  Remember that the transmissions are sent LSB first, so the screenshot shows 1-0-1-0-1-0-1-0.  The last transition high marks the beginning of the stop bit and the line remains in that state until the start of the next transmission.  The receiver, being asynchronous, does not require any type of identifying transition to mark the end of the stop bit. FTM/TPM configuration The first question many may ask when beginning a project like this is "How do I configure the FTM/TPM when emulating a UART".  The answer to this depends on the aspect of this problem you are trying to solve.  Transmitting and receiving characters require two different configurations.  Transmission requires a configuration that manipulates the output pin at specific points in time.  Receiving characters requires a configuration that samples the receive pin and measures the time between pin transitions.  The FTM and TPM have the modes listed in the following table: The FTM and TPM have four different modes that manipulate an output:  Output compare (no pulse), Output compare (with pulse), Edge-aligned PWM, and Center-aligned PWM.  Neither PWM mode is ideal for the requirements of the application.  This is because the PWM modes are designed to produce a continuous waveform and are always going to return to the initialized state once during the cycle of the waveform.  However, the UART protocol may have continuous 1's or 0's in the data without pin transitions between them. The output compare mode (high-true or low-true pulse modes) is designed to only manipulate the pin once, and only produces pulses that are one FTM/TPM clock cycle in duration.  So this is obviously not desirable for the application.  The output compare mode (Set/Clear/Toggle on match) is promising.  This mode manipulates the output pin every cycle.  There are three different options:  clear output on match, set output on match, and toggle output on match.  Neither "clear output on match" nor "set output on match" are ideal as either would require configuration changes during the transmission of a character.  The "toggle output on match", however, can be used and is the selected configuration mode for this sample application. To receive characters, there is only one mode that is intuitive:  "the input capture mode".  This mode records the timer count value on an edge transition of the selected input pin.  Similar to the output compare mode chosen for the transmit functionality, the input capture mode has three sub-modes:  capture on rising edge, capture of falling edge, and capture on either edge.  It is clear from the descriptions that capture on either edge should be selected. Transmit encoding The selection of the FTM/TPM mode is moderately intuitive, but using this mode to emulate a UART transmission is not.  There are two issues that make this a little tricky. 1) The output pin is initialized low. However, the UART protocol needs the pin to begin in a logical high state. 2) The pin transitions on every cycle provided the channel value is less than the value of the MOD register. Due to continuous strings of 1's or 0's, it is necessary to have periods where the pin does not transition. Both of these points have workarounds. Output pin initialization For the first issue, the channel interrupt is first enabled and the channel value register is loaded with a value much less than the value in the MOD register.  Then in the channel interrupt service routine, the pin is sampled to ensure that it is in the logic high state and the channel interrupt is disabled (and will not be re-enabled throughout the life of the application).  The code for this interrupt service routine is as follows. Output pin control For the second issue, a method of not transitioning the pin value while allowing the timer to continue counting normally is necessary.  The Output Compare mode uses the channel value register to determine when the pin transition occurs.  If a value greater than MOD is written to the channel value register, the channel value will never match the count register and thus, a pin transition will never occur.  So, when a series of continuous 1's or 0's need to be transmitted, a value greater than the value in the MOD register can be written to the channel value register to keep the output pin in its current state. However, when a value greater than MOD is written to the channel value register, no channel match will occur (which means channel interrupts will not occur).  So the timer overflow interrupt must be used to continue writing values.  This requires the updates to be output pin to be planned ahead of time and makes the transmission algorithm a little tricky.  The following diagram displays when which values should be written to the channel value register at which points in time to generate the appropriate pulses. Writing a function to translate a number into the appropriate series of MOD/2 and MOD+1 values can be a little tricky. To do this, we must first notice that MOD/2 needs to be written when changes on the transmission pin are need and MOD+1 needs to be written when pin transmissions are not desired.   So, what logical function can we use to determine when a change has happened?  XOR is the correct answer.  So what two values need to be XOR'd together?  One value is obviously the value that we want to send.  But what is the second value?  It turns out that the second value is a shifted version of the value that we want to send.  Specifically, the second value is the desired value to send shifted to the left by one.  (You can think of it as sort of a "future" value of the desired value).  The following pictures show how to determine the queue to use for the transmission. Receive decoding The receive functionality has an advantage over the transmit functions in that it is possible to use DMA for the reception of characters.  This is because the receive function takes advantage of the input capture functionality of the FTM / TPM and therefore can use the channel match interrupt.  The example application provided with this document implements a DMA method and a non-DMA method for reception. First, the non-DMA method will be discussed. Before discussing the specifics of gathering the input pulse widths, some details of the receive pin need to be discussed. Detecting the start bit The receive pin needs to be able to determine when the start of the packet transmission begins.  To do this, the receive pin is configured as an FTM / TPM pin. At the same time, the GPIO interrupt functionality is configured on the same pin for a falling edge interrupt.  The GPIO interrupt capabilities are enabled in any digital mode, so the GPIO interrupt will still be able to be routed to the Nested Vector Interrupt Controller (NVIC).  The pin interrupt is used to start the FTM / TPM clock when a new character reception begins. In the GPIO interrupt for this pin, the FTM / TPM counter register is reset and the clock to the FTM / TPM is turned on.  The code for the GPIO interrupt service routine is shown below.  Receiving characters without DMA Now, when receiving characters and not using DMA, the first thing to understand is that the Interrupt Service Routine (ISR) will be used and it will mainly be used to record the captured count values.  The interrupt service routine also tracks the current receive character length and resets the counter register.  This is so that the values in the receive queue reflect the time since the last pin transition.  The interrupt function for the non-DMA application is shown below. Notice that the first two actions in the ISR are resetting the count register, and clearing the channel event interrupt flag.  Then the channel value is stored in the receive pulse width array (this is simply an array that holds the receive pulse widths of the current character being received).  Next, recvQueueLength, the variable which holds the current length of the character being received, is updated to reflect the latest character length.  The next step is to determine if the full character has been received.  This is determined by comparing recvQueueLength to the RECV_QUEUE_THRESH, which is the threshold as determined by multiplying the number of expected bits by the expected bit width plus another bit width (for the start bit).  If the recvQueueLength is greater than the RECV_QUEUE_THRESH, then a semaphore is set, recvdChar, to indicate that a full character has been received.  The FTM / TPM clock is turned off, and the pin interrupt functionality of the receive pin is enabled.  The final step in the interrupt routine is to increment the receive queue index, recvQueueIndex.  This variable points to the current entry in the receive queue array. Using DMA to receive characters When using DMA, the receive FTM / TPM interrupt is much different. The interrupt routine simply needs to clear the channel interrupt flag, stop the FTM / TPM timer, disable the DMA channel, and set the received character semaphore.  The character is then decoded outside of the interrupt routine.  The interrupt function when using DMA is shown below: Decoding the received pulse widths Once the array of pulse widths has been populated, the received character needs to be translated into a single number.  This varies slightly when using DMA and when not using DMA. However, the basic principle is the same.  The number of bits in a single entry is determined by dividing by the expected bit width and this is translated into a temporary array that contains 1's and 0's, and then that is used to shift in the appropriate number of 1's and 0's into the returned char variable.  A temporary array is needed because the values are shifted into the UART LSB first, so the bit must be physically flipped from the first entry to the last.  There is no logical operation that will do this automatically. The algorithm to perform this translation is shown below.  In this algorithm, note that recvPulseWidth is the array that contains the raw count value of the pulse width.  The array tempRxChar holds the decoded character in reverse order and rxChar is a char variable that holds the received character. Conclusion This document provides an overview of the UART protocol and describes a method for creating a software UART using the timing features of the FTM or TPM peripheral.  This method allows for accurate timing and while not relying entirely on the CPU and the latency associated with the interrupt and the GPIO pins.  The receive function is open to further optimization by using DMA, which can provide further unloading of the CPU.

For Remote Control means, that is needed two computers - Server Computer and User Computer, which will be in connection. There are two types of connection, which can be used - HTTP or DCOM. There are two different ways how to set up the remote control in Windows. I made the tutorial, which describes both types of Remote Control. Ok - so, let´s start! HTTP Settings On the Server Computer side: 1. Plug the board to the Server Computer 2. Go to Remote Communication Server 3. Set HTTP connection and choose the right COM Port according the plugged board If the plugged board is on e.g. COM23, it is possible to edit number of Port in Device Manager On the User PC side: 1. Open FreeMASTER,  go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (HTTP) and type the IP address of the server, do not forget join to IP address :8080 3. And start communication by STOP button to successful connection DCOM Settings On the Server Computer side: 1. Plug board to the Server Computer 2. Launch DCOM in FreeMASTER Remote Server Choose COM according plugged board or edit COM according to step 2 - Server Computer in HTTP Connection (up). 3. Setting permissions for the user, User PC. Right click on Computer -> Manage. In Computer Management click to Distributed COM Users. In Distributed COM Users Properties add the user, User Computer. After that, set the permissions in Component Services. In cmd type dcomcnfg.exe In Component Services go to Computers -> My Computer -> DCOM Config -> MCB FreeMASTER Remote Server Application Right click on MCB FreeMASTER Remote Server Application and go to Properties. In Security Tab is possible to add the permissions. There are 3 types of permissions. First permission - Launch and Activation Permissions. There are 4 permission options. Local Launch and Remote Launch means, that user, User Computer can launch e.g. FM Remote Server Application. But for success communication is needed allowing Local Activation and Remote Activation. Second permission - Access Permissions. Click to Edit and Allow Local Access and Remote Access for the user. Do not forget that if there is a change of permissions, specifically allowing, it is necessary for User to log out and log in. On the User Computer side: 1. Open Freemaster, go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (DCOM) and for filling Connect string is possible to use Configure. Definitely, type the IP address of the server and ;Port Name. 3. And start communication by STOP button in FreeMASTER to successful connection And now.. you can do anything 🙂

The attached zip file contains software that accompanies the document UART Emulation Using the FTM or TPM.  It contains two sample applications:  one that uses the TPM, and one that uses the FTM. The TPM example targets the FRDM-KL26Z development board and is written in baremetal code.  The FTM example targets the TWR-K22F120M and FRDM-K22F and is written using the Kinetis SDK 1.0 release.  Installation instructions are contained within the zip package. Unzip the package to an empty folder and then copy the appropriate folders to the the appropriate locations on your PC per the instructions located in the zip file. 

New 32-bit MCUs designed to transform consumer and industrial applications currently using legacy 8- and 16-bit architectures SAN ANTONIO, Jun 19, 2012 (BUSINESS WIRE) -- Freescale Semiconductor FSL +0.80% is now offering alpha samples of its Kinetis L series, the industry's first microcontrollers (MCUs) built on the  ARM(R) Cortex(TM)-M0+ processor. Kinetis L series devices are on display this week at the Freescale        Technology Forum (FTF) Americas and were demonstrated during the event's opening keynote address. As machine-to-machine communication expands and network connectivity  becomes ubiquitous, many of today's standalone, entry-level applications will require more intelligence and functionality. With the Kinetis  L series , Freescale provides the ideal opportunity for users of legacy 8- and 16-bit architectures to migrate to 32-bit platforms and bring additional intelligence to everyday devices without increasing power  consumption and cost or sacrificing space. Applications, such as small  appliances, gaming accessories, portable medical systems, audio systems, smart meters, lighting and power control, can now leverage 32-bit capabilities and the scalability needed to expand future product lines -- all at 8- and 16-bit price and power consumption levels. "In our view, 8- and 16-bit development has reached the end of the road. Those architectures simply can't keep up as the Internet of Things gains traction," said Geoff Lees, vice president and general manager of Freescale's Industrial & Multi-Market MCU business. "Kinetis L series MCUs are ideal for the new wave of connected applications, combining the required energy efficiency, low price, development ease and small  footprint with the enhanced performance, peripherals, enablement and scalability of the Kinetis 32-bit portfolio." Extreme energy efficiency The ARM Cortex-M0+ processor consumes approximately one-third of the energy of any 8- or 16-bit processor available today, while delivering  between two to 40 times more performance. The Kinetis L series supplements the energy efficiency of the core with the latest in  low-power MCU platform design, operating modes and energy-saving peripherals. The result is an MCU that consumes just 50 uA/MHz* in very-low-power run (VLPR) mode and can rapidly wake from a reduced power state, process data and return to sleep, extending application battery life. These advantages are demonstrated in the FTF demo, which compares the energy-efficiency characteristics of the Kinetis L series against solutions from Freescale competitors in a CoreMark benchmark analysis.        The Kinetis L series is also part of the Freescale Energy-Efficient Solutions program. Kinetis L series energy-saving peripherals do more with less power by maintaining functionality even when the MCU is in deep sleep modes. In traditional MCUs, the main clock and processor core must be activated to perform even trivial tasks such as sending or receiving data, capturing or generating waveforms or sampling analog signals. Kinetis L series peripherals are able to perform these functions without involving the core or main system, drastically reducing power consumption and improving battery life. Built using Freescale's innovative, award-winning flash memory technology, the Kinetis L series offers the industry's lowest-power flash memory implementation. This improves upon the conventional silicon-based charge storage approach by creating nano-scale silicon islands to store charge instead of using continuous film, improving the flash memory's immunity to typical sources of data loss. "The Internet of Things needs very low-cost, low-power processors that        can deliver good performance," said Tom R. Halfhill, a senior analyst        with The Linley Group and senior editor of Microprocessor Report. "As  the first 32-bit microcontrollers to use ARM's Cortex-M0+ processor core, Freescale's Kinetis L-series MCUs will bring the energy efficiency and prices typically associated with 8- and 16-bit MCUs to a broad range of consumer and industrial applications." Development simplicity The Kinetis L series addresses the ease-of-use requirement critical for entry-level developers through innovations including: -- The Freescale Freedom development platform, a small, low-power, cost-efficient evaluation and development system for quick application prototyping and demonstration. It combines an industry-standard form factor with a rich set of third-party expansion board options. An integrated USB debug interface offers an easy-to-use mass-storage device mode flash programmer, a virtual serial port and classic programming and run-control capabilities. -- Processor Expert software, a GUI-based, device-aware software generation tool that eliminates the need to write peripheral start-up code or device drivers. Helps developers easily migrate from 8- and 16-bit to 32-bit solutions by simplifying the software architecture and  dramatically reducing application development time. --  The Kinetis MCU Solution Advisor, a web-based application with an interactive MCU product selector that helps identify the best-suited MCU by applying dynamic filters based on operating characteristics, packaging options, memory configuration and peripheral hardware library. Integration and scalability Each Kinetis L series family includes scalable flash memory options, pin-counts and analog, communication, timing and control peripherals, providing easy migration paths for end product line expansion. Features common to the Kinetis L series families include: --         48 MHz ARM Cortex-M0+ core --         High-speed 12/16-bit analog-to-digital converters --         12-bit digital-to-analog converters --         High-speed analog comparators --         Low-power touch sensing with wake-up on touch from reduced power states --         Powerful timers for a broad range of applications including motor control The first three Kinetis L series families: --         Kinetis L0 family -- the entry point into the Kinetis L series. Includes eight to 32 KB of flash memory and ultra-small 4mm x 4mm QFN packages. Pin-compatible with the Freescale 8-bit S08P family. Software- and tool-compatible with all other Kinetis L series families. --         Kinetis L1 family -- with 32 to 256 KB of flash memory and  additional communications and analog peripheral options. Compatible with the Kinetis K10 family. --         Kinetis L2 family -- adds USB 2.0 full-speed host/device/OTG. Compatible with the Kinetis K20 family. The Kinetis L series is pin- and software-compatible with the Kinetis  K series (built on the ARM Cortex-M4 processor), providing a migration path to DSP performance and advanced feature integration. Availability and pricing Kinetis L series alpha samples are available now, with broad market sample and tool availability planned for Q3. Pricing starts at a suggested resale price of 49 cents (USD) in 10,000-unit quantities. The Freescale Freedom development platform is planned for Q3 availability at  a suggested resale price of $12.95 (USD). For more information about Kinetis L series MCUs, visit   www.freescale.com/Kinetis/Lseries    . *Typical current at 25C, 3V supply, for Very Low Power Run at 4MHz core  frequency, 1MHz bus frequency running code from flash with all peripherals off. About the Freescale Technology Forum Created to drive innovation and collaboration, the Freescale Technology Forum (FTF) has become one of the developer events of the year for the embedded systems industry. The Forum has drawn more than 48,000 attendees at FTF events worldwide since its inception in 2005. Our annual flagship event, FTF Americas, takes place June 18-21, 2012, in San Antonio, Texas. About Freescale Semiconductor Freescale Semiconductor  FSL +0.80% is a global leader in embedded processing solutions, providing industry leading products that are advancing the automotive, consumer, industrial and networking markets. From microprocessors and microcontrollers to sensors, analog integrated  circuits and connectivity -- our technologies are the foundation for the innovations that make our world greener, safer, healthier and more connected. Some of our key applications and end-markets include automotive safety, hybrid and all-electric vehicles, next generation wireless infrastructure, smart energy management, portable medical  devices, consumer appliances and smart mobile devices. The company is  based in Austin, Texas, and has design, research and development,        manufacturing and sales operations around the world.   www.freescale.com Freescale, the Freescale logo, Energy Efficient Solutions logo, Kinetis  and Processor Expert are trademarks of Freescale Semiconductor, Inc.,  Reg. U.S. Pat. & Tm. Off. ARM is the registered trademark of ARM  Limited. Cortex is the trademark of ARM Limited. All other product or  service names are the property of their respective owners. (C) 2012   Freescale Semiconductor, Inc. Photos/Multimedia Gallery Available:   http://www.businesswire.com/cgi-bin/mmg.cgi?eid=50313420&lang=en SOURCE: Freescale Semiconductor

How to byte program SPI flash via QSPI QSPI module are used in many Kinetis MCU, like K8x, K27/28 and KL8x. QSPI expands the internal flash range and can run in a fast speed. Compared to DSPI, QSPI is very complex and often takes a lot of time to learn. In KSDK there are two QSPI demo which shows how to program SPI flash in DMA mode and polling mode. Both of them program the QSPI flash with a word type array. But can the QSPI module program SPI Flash in byte? Yes, this article shows how to do it. Device: FRDM_KL82Z Tool: MCUXpresso IDE Debug firmware: JLINK I build the test project base on KL82 SDK/driver_example/qspi/polling_transfer. To byte program SPI flash, a new LUT item must be added. uint32_t lut[FSL_FEATURE_QSPI_LUT_DEPTH] =    {/* Seq0 :Quad Read */          /* CMD:       0xEB - Quad Read, Single pad */          /* ADDR:       0x18 - 24bit address, Quad pads */          /* DUMMY:     0x06 - 6 clock cyles, Quad pads */          /* READ:       0x80 - Read 128 bytes, Quad pads */        …        …        [32] = QSPI_LUT_SEQ(QSPI_CMD, QSPI_PAD_1, 0x02, QSPI_ADDR, QSPI_PAD_1, 0x18),        [13] = QSPI_LUT_SEQ(QSPI_WRITE, QSPI_PAD_1, 0x1, 0, 0, 0),        …        /* Match MISRA rule */        [63] = 0}; This item tells system how to program a single byte. Then when we write the data to TxBuffer, we must write the byte 4 times. This is because a write transaction on the flash with data size of less than 32 bits will lead to the removal of four data entry from Txbuffer. The valid bit will be used and the rest of the bits will be discard. Then before we start programming, we must set the data size.      QSPI_SetIPCommandSize(EXAMPLE_QSPI,1);   After byte program, we can see the result from 0x68000000. Attachment is the demo project. You can find that 0x03 was written to 0x68000005 after running.

Customer requirement and making it happen This hands-on test is coming with the true customer requirement. Customer designs the battery powered device with SLCD display and lowest power consumption is the key requirement. Customer considers the KL43 and wonder the power consumption data about RTC & SLCD modules. So there with below requirements about the test: Run the RTC and SLCD in the lowest possible power mode Display time at SLCD with [00:00] and update every minute via RTC interrupt               One button shall turn on/off the SLCD display Measure the KL43 power consumption data KDS IDE with KSDK V2.0 software According to above requirement, which low power mode should be selected? RTC and SLCD modules should work at this low power mode. From the KL43 reference manual table 7-2 [Module operation in low power modes] with below info:      5. In VLLS0 the only clocking option is from RTC_CLKIN.      7. End of Frame wakeup not supported in LLS and VLLSx. RTC and SLCD modules could work at VLLS1 low power mode with Async operation. Using VLLS1 low power mode, the RTC and SLCD module clock could select OSC32KCLK with below clocking figure: KL43 wake up from VLLS1 low power mode following wake up reset and the software will check the system reset status register to check what kind of reset happens and print related info. LLWU module is used as VLLS1 lower power mode wake up module with two wake up source, one is RTC Alarm interrupt, the other one is PTC3 (SW3). The Reset pin (SW2) also could wake up the VLLS1 low power mode. Test environment introduction Hardware platform using FRDM-KL43Z board with below feature: MKL43Z256VLLZ4 MCU (48 MHz, 256 KB flash memory, 32 KB RAM, 16 KB ROM Dual role USB interface with mini-B USB connector OpenSDA Four-digit segment LCD module Capacitive touch slider Ambient light sensor MMA8451Q accelerometer MAG3110 magnetometer 2 user push buttons Battery-ready, power-measurement access points Arduino R3 compatibility Software platform bases on KSDK V2.0 for FRDM-KL43Z board, which could be downloaded from kex.nxp.com. Attached demo software default path is: C:\Freescale\SDK_2.0_FRDM-KL43Z\boards\frdmkl43z Test software code introduction Below is the software flow chart: Test result SLCD ON with power consumption 2.0uA SLCD OFF with power consumption 1.2uA

1. How Calibration works There are three main sub-blocks important in understanding how the Kinetis SAR module works.  There is a capacitive DAC, a comparator, and the SAR engine that controls the module. Of those blocks, the DAC is most susceptible to variations that can cause linearity problems in the SAR. The DAC is architected with three sets of binary weighted capacitors arrayed in banks, as in Figure 1. The capacitors that represent the most significant bits of the SAR (B15:B11) are connected directly to the inputs of the comparator. The next bank of five capacitors (B10:B6) is connected to the top plate of the MSB array through an intentionally oversized scaling capacitor. The final six capacitors that makeup the least significant bits of the SAR (B5:B0) are correspondingly connected to the top plate of the middle bank of capacitors through another scaling capacitor. Figure 1. Arrangement of DAC capacitors Only the MSB capacitor bank is calibrated. Because the first scaling capacitor is intentionally oversized, each of the non-calibrated MSB capacitors will have an effective capacitance too small to yield accurate results. However, because they are always too small, we can measure the amount oferror that each of those capacitors would cause individually, and add that back in to the result. Calibration starts with the smallest of the LSB capacitors, B11. The SAR samples Vrefl on all of the capacitors that are lower-than or equal-to the capacitor under test (CUT), while connecting all of the smaller capacitors to Vrefh. The top plate of all of the MSB capacitors is held at VDDA while this happens. After the sampling phase is complete, the top plates of the MSB capacitors are allowed to float, and the bottom plates of the MSBs not under test are connected to Vrefl. This allows charge to redistribute from the CUT to the smaller capacitors. Finally, an 11 bit SAR algorithm (corresponding with the 11 capacitors that are smaller than the MSB array) is performed which produces a result that indicates the amount of error that the CUT has compared to an ideally sized capacitor. This process is repeated for each of the five MSBs on both the plus side and minus side DACs and the five error values that are reported correspond to the five MSBs accordingly. All of these error values are about the same magnitude, with a unit of 16-bit LSBs. See Figure 2 for an example. Figure 2. Example of calibration on bit 11 The DAC MSB error is cumulative. That is, if bit 11 of the DAC is set, then the error is simply the error of that bit. However if bit 12 of the DAC is set, the total error is equivalent tothe error reported on bit 12, plus the error reported on bit 11. For each MSB the error is calculated as below, where Ex is the error found during the calibration for its corresponding MSB bit: When bit 11 of the DAC is set: CLx0 = E0. When bit 12 of the DAC is set: CLx1 = E0+E1. When bit 13 of the DAC is set: CLx2 = E2 + E1 + 2E0. When bit 14 of the DAC is set: CLx3 = E3 + E2 + 2E1 + 4E0. When bit 15 of the DAC is set: CLx4 = E4 + 2E3 + 4E2 + 8E1 + 16E0 Figure 3. Effect of calibration error on ADC response These are the values that are then placed in each of the CLxx calibration results registers. Figure 3 shows how the errors would accumulate if all of the CLxx registers were set to zero. The offset and gain registers are calculated based on these values as well. Because of this, the gain and offset registers calibrate only for errors internal to the SAR itself. Self calibration does not compensate for board or system level gain or offset issues. 2. Recommended Calibration Procedure From the above description it is evident that the calibration procedure is in effect several consecutive analog to digital conversions. These are susceptible to all of the same sources of error of any ADC conversion. Because what is primarily being measured is the error in the size of the MSB capacitors; the recommendation is to configure the SAR in such a way as to make for the most accurate conversions possible in the environment that the SAR is being calibrated in. Noise is the primary cause of run-to-run variation in this process,so steps should be taken to reduce the impact of noise during the calibration process. Such as: All digital IO should be silent and unnecessary modules should be disabled. The Vrefh should be as stable and high a voltage as possible, since higher Vrefh means larger ADC code widths. An isolated Vrefh pin would be ideal. Lacking that, using an isolated VDDA as the reference would be preferable to using VREFO. The clock used should be as noise free as possible, and less than or equal to 6 MHz. For this purpose the order of desirable clock sources for calibration would be OSC > PLL > FLL > ASYNC The hardware averaging should be set to the maximum 32 samples. The Low Power Conversion bit should be set to 0. The calibration should be done at room temperature. The High Speed Conversion and Sample Time Adder will not have much effect in most situations, and the Diff and Mode bits are completely ignored by the calibration routine. The calibration values should be taken for each instance of the SAR on a chip in the above conditions. They should be stored in nonvolatile memory and then written into their appropriate registers whenever the ADC register values are cleared. In some instances, the system noise present will still cause the calibration routine to exhibit greater than desired run-to-run variation. One rule of thumb would be to repeat calibration several times and look at the CLx0 registers. If the value reported in that register varies by more than three, the following procedure can be implemented. Run the calibration routine several times. Twenty to forty times. Place the value of each of the calibration registers into a corresponding array. Perform a bubble sort on each array and find the median value for each of the calibration registers. Use  these median values as described for typical calibration results.

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

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

Latest version of the AN2295 universal bootloader includes support for IAR 7.6 IDE. - added support for Kinetis E MCUs - Kinetis K,L,M,E,W,V support

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

This document explains a potential issue where interrupts appear to be disabled after enterring debug mode. This is as a result of the NMI being active when debug is enabled.