Hi,   Attached USB Mass Storage Device Host Bootloader code is ported for KL25 / KL26.   Reference: AN4368 USB Mass Storage Device Host Bootloader   Thanks & Regards, Swaminathan.R

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

This file contains some codewarrior code examples migrated from the IAR examples in the sample code package available at the freescale webpage: blink_blue blink_red blink_rgb serial_test_19200 serial_test_115200 touch_toggle_leds Regards

When I developed the software of FSL Air Mouse based on kinetis KL16 , I need read and write more than 1 byte data from or to sensor by i2c. But I don't find any i2c driver which supports mutli-bytes accessing. So I write the i2c driver which supports mutli-bytes accessing. It can run on MCU KL1x series and you can modify it a little for Kinetis K series.

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.

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

by: Carlos Musich, Luis Garabito Microcontrollers Application Engineers with Freescale. This application note is intended to demonstrate http client implementation using Freescale MQX RTOS capabilities. The hardware used to illustrate this is the TWR-K60N512-KIT. The remote controlling and monitoring have become a need rather than an option in the embedded world. This application note takes advantage of two social media interfaces for these purposes. One is used to enter commands to the MCU; http://twitter.com/. The other one is used to pull out data from the MCU; https://www.supertweet.net/. It is important to focus in the fact that with these methods the MCU is reachable through Internet without the need of a public IP address or without mounting a HTTP server in the MCU. The application source code described in this document can be found in the AN4417SW.zip file. For a full description of Freescale MQX RTOS, please visit https://www.freescale.com. This application defines two tasks in MQX. The first task is main. It is meant to configure GPIO, the RTCS and create the second task. The name of this second task is httpclient. The purpose of this task is to carry out the communication with the Twitter server and read the commands to be executed. To retrieve the input commands, the httpclient task reads them from the last tweet published by a specific Twitter account. The command then is parsed and executed according to the implementation. The main task enters into an infinite loop where the httpclient is restarted in each loop to allow a cycle behavior for reading commands. The time for each loop is controlled by a sample rate value that can be configured by the user via a command. Get the full application note...

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

在EEfocus上有一个关于Debug模式和正常工作模式下进入低功耗模式的问题，总结了一下，Post过来Share给大家。 问题现象：使用串口接收中断，主函数进入睡眠。在调试过程中发现：只有在连接jlink调试下，串口可以正常收发数据，串口收到数据可以唤醒mcu。但在断开jlink情况下，不能正常收发数据。 所做尝试：尝试过不在VLPS模式下，串口是可以正常中断接收数据的，也可以正常发送数据。另外，在使用过程中采用的是内部晶振，串口的时钟源是FLL。 主函数代码： while(1) { enter_vlps();  //进入vlps模式 out_char(c); //串口接收中断函数把字符赋给c } 解答： 首先，在VLPS模式下，FLL不能工作，也就无法输出clock时钟到UART，所以进入VLPS模式后UART不可以用FLL做时钟。 其次，在连J-Link调试时其实没有进入VLPS模式，而是进入了STOP模式，此时FLL是有输出的。在数据手册上的MDM-AP Status Register部分关于LP有讲到:Usage intended for debug operation in which Run to VLPS is attempted. Per debug definition, the system actually enters the Stop state. 所以造成了连接J-link从表面上看起来是进入了VLPS模式(其实是进入Stop模式)，不连接J-link就无法正常工作了。

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

    MMA9553L是飞思卡尔的一款计步传感器，本文就如何快速使用该传感器做一个简单介绍。    你可能还见到过MMA955xL， 它与MMA9553L是什么关系呢？简单的来说MMA955xL是一个统称，它包括MMA9550L、MMA9551L、MMA9553L和MMA9559L这几个具体型号，其实这四种传感器在硬件上都是一样的。其内部主要由ColdFire 内核、模拟前端、Flash、IIC和SPI接口等部分组成，原理框图如下图所示：    它们的不同之处在于内部的Firmware不同，Firmware在芯片出厂时就已经固化在芯片里面了，不同的Firmware对于不同的功能。这里介绍的MMA9553L主要就用作计步器功能。        MMA9553L和MCU之间可以通过IIC接口或者SPI接口通讯，所以使用MMA9553L的首要前提是把MCU的IIC或者SPI调通。接口调通之后就可以来操作此传感器了。这里以IIC为例来说明。附件为参考代码。 测试平台：IAR7.2 + FRDM_KL25Z+FRDM-FXS-MULTI FRDM-FXS-MULTI开发板上带有MMA9553L，将FRDM-FXS-MULTI开发板和FRDM_KL25Z连接在一起就可以使用了。     下面分析一下源代码：        首先是调用初始化函数pedometer_init()，此函数主要调用以下几个函数：      pedometer_write_config();       // config     pedometer_enable();         // enable pedometer     pedometer_int0_enable();    // enable INT_O pin     pedometer_active();         // active MMA9553 pedometer_wakeup();   // wakeup 在此重点分析前两个函数。第一个函数 pedometer_write_config()，该函数的具体实现如下： void pedometer_write_config(void) {     unsigned char Buf[]={0x15,0x20,0x00,0x10,                            0x0C,0xE0,                            0x13,0x20,                            0x00,0x96,                            0x60,0x50,                            0xAF,0x50,                            0x04,0x03,                            0x05,0x01,                            0x00,0x00};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 20); } 此函数很简单，就是通过IIC给9553发送一条命令，命令的内容Buf数组中的20个字节    的数据。 dvMMA9553_Write()函数的第一个参数代表MMA9553L的地址，为0x4C。datasheet中有说明。 #define MMA9553_Slave_Addr  0x4C dvMMA9553_Write()函数的第二个参数代表寄存器地址，为0x00。 #define MMA9553_Sub_Addr    0x00 发送的这一串命令：0x15,0x20,0x00,0x10,0x0C,0xE0,0x13,0x20,0x00,0x96,0x60,0x50,0xAF,0x50,0x04,0x03,0x05,0x01,0x00,0x00 具体是什么含义呢？ 0x15：表示Application ID，计步器的Application ID就是0x15 0x20：表示这条命令是Write Config command，即这条命令是用来写Configuration 寄存器的。 0x00：表示配置寄存器的偏移地址。 0x10：表示要写16字节的内容。 0x0C,0xE0,0x13,0x20,0x00,0x96,0x60,0x50,0xAF,0x50,0x04,0x03,0x05,0x01,0x00,0x00 这16字节就是写入配置寄存器中的具体内容。 配置寄存器共用8个，分别是Sleep Minimum register，Sleep Maximum register，Sleep Count Threshold register，Configuration/Step Length register，Height/Weight register，Filter register，Speed Period/Step Coalesce register，Activity Count Threshold register，每个寄存器为16 bit（2 字节），所以总共16字节。 第二个函数 pedometer_enable()，该函数的具体实现如下： void pedometer_enable(void) {     unsigned char Buf[]={0x17,0x20,0x05,0x01,0x00};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 5); } 这次写入的命令是0x17,0x20,0x05,0x01,0x00 0x17：表示Application ID 0x20：表示这条命令是Write Config command 0x05,0x01,0x00 这三个表示在偏移地址0x5处，写入一个字节的数据0x00 其他几个函数也类似，都是写入一条命令，对某种Application的配置寄存进行设置。 初始化完了，现在就可以读取步数了。 通过调用pedometer_main() 函数就可以读取到步数。 该函数的实现如下： void pedometer_main(void) {     unsigned char Buf[20];     pedometer_cmd_readstatus(); // read  status      while(1)         {            dvMMA9553_Read(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 2);            if(Buf[1]==0x80)            {               dvMMA9553_Read(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 16);               break;             }         }         m_status.StepCount = Buf[6] * 256 + Buf[7];         m_status.Distance  = Buf[8] * 256 + Buf[9];         m_status.Calories  = Buf[12] * 256 + Buf[13]; } 主要调用了两个函数，一是pedometer_cmd_readstatus()，这个函数的实现如下： void pedometer_cmd_readstatus(void) {     unsigned char Buf[]={0x15,0x30,0x00,0x0C};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 4 ); } 它是发送了0x15,0x30,0x00,0x0C这条命令 0x15：表示Application ID 0x30：表示Read Status command 0x00：表示偏移地址 0x0C：表示需要读的字节数为12 之后调用dvMMA9553_Read()函数，通过IIC读取16字节的数据（4字节起始信息+12字节status register内容），读到的16字节数据如下： Step count register寄存器如下，通过其值可以算出步数来。    另外还可以读取三轴加速度的值，过程与读取步数是类似的，也是先写配置寄存器，然后再读取状态寄存器。   总的来说操作MMA955L的关键搞清楚有两个重要的寄存器：配置寄存器和状态寄存器。配置寄存器可读可写，状态寄存器只可读。 写配置寄存器，格式是： APP_ID+0x20+offset+number+number字节的内容 读配置寄存器，格式为： 先发送：APP_ID+0x10+offset+number， 再通过IIC读number+4字节的内容，前4字节为起始信息。 读状态寄存器,格式为： 先发送：APP_ID+0x30+offset+number，再通过IIC读number+4字节的内容，前4字节为起始信息。 读Command 回的内容如下：

底层驱动源码，mdk5.0打开。 另有移植好了的ucGUI的源码。

1 Abstract Stepper motor can be controlled by the electrical pulse signal with the open loop system, it use the electrical pulse signal realize the angular movement or linear movement.  The speed and position of the stepper motor is determined by the pulse frequent and the pulse number. Stepper motor can be used in the low speed area application, with higher work efficiency and low noise. KE02 is the 5V kinetis E series MCU, it is based on ARM Cortex M0+ core, KE series are designed to maintain high robustness for complex electrical noise environment and high reliability application. For these advantages, KE02 is fit the Stepper motor control application. This document is mainly about how use the KE02 realize the Stepper motor speed, step and direction control. It can use the UART in the PC to control the Stepper motor speed. The following picture is the control diagram.                                                                              Fig.1 2. Motor control parameter calculation      Just as Fig.1 shows, KE02 should control the EN, DIR, PWM signal to the motor driver, then realize the stepper motor control. EN is the motor driver enable signal, 0 is enable, 1 is disable; DIR is the stepper motor direction control, 0, clockwise, 1 anticlockwise; PWM is the pulse signal to control the step and speed for the stepper motor.       Stepper motor is 1.8’, it means a round have 360’/1.8’= 200 steps. But because the Motor driver have the divider, it is 32, so one stepper motor round should have 200*32 = 6400 steps.       KE02 system, it use the external 10Mhz crystal, and configure both core and bus frequent to 20Mhz,  it use FTM0 module as the motor pulse generate module, bus clock with 32 prescale used as the FTM0 clock source, choose up counter. If need to change the motor speed and control step, just control the FTM PWM frequent and PWM counter. For Stepper motor, one FTM period means one motor step. From the reference manual of KE02, we get that, the FTM period in up counting mode is: (MOD-CNTIN+1)*period of the FTM counter clock, if want to change the frequent of motor, just calculate the MOD of FTM is ok, then count the number of the FTM cycle, now assume CNTIN =0, then: Tftm= (32/20Mhz)*(MOD+1) From the Stepper Motor and it’s driver, we get that one step time is : Tmstep= 60/(V*6400) V is the speed of Motor, the unit is round/minute. Because Tftm=Tmstep, then we know: MOD= (60/(V*6400))*(20Mhz/32)-1                     (F1) In this document, we calculate the speed of 150 round/minute, 110 round/minute, 80 round/minute, 50 round/minute and 0.1 round/minute, according to (F1), we can get the MOD for each speed as the following: 150 round/minute   MOD=38 110 round/minute   MOD=52 80 round/minute     MOD=72 50 round/minute     MOD=116 0.1 round/minute    MOD=58592 If each speed need to do 10 Stepper motor round, then just control the speed counter number to: 10*6400=64000. 3. MCU pin assignment PTF0 : DIR PTF1 : EN PTA0 : PWM PTC6 : UART1_RX PTC7 : UART1_TX 4. code writing (1)FTM initial code void STEEPMOTOR_PWM_Init(uint16 MODdata) {                    SIM_SCGC |= SIM_SCGC_FTM0_MASK;                 FTM0_SC = 0;                 FTM0_C0SC = 0 ;                 FTM0_C0SC = FTM_CnSC_MSB_MASK |FTM_CnSC_ELSA_MASK ;                 FTM0_C0V = 0;                 FTM0_C0V = MODdata>>1;                 FTM0_MOD=MODdata;                 FTM0_SC |=FTM_SC_CLKS(1) | FTM_SC_PS(5) | FTM_SC_TOIE_MASK                 enable_irq(17); //enable interrupt } MODdata can choose the different Stepper motor speed, eg, 150 round/minute, MODdata is 38. (2) interrupt service function void FTM0_IRQHandler(void) {                                 FTM0_SC  &= ~FTM_SC_TOF_MASK;//clear the TOF flag. roundcount++;                 if(roundcount >= 64000) {FTM0_C0SC = 0x00; FTM0_SC &= ~(FTM_SC_TOIE_MASK);} } It can used for the step counter, and when reach the 10round, then stop the motor( stop the FTM output). (3)Speed choose with UART input void Motor_Speed_GPIO_CTRL_30round(void) {                 char motormode=0;                 uint32 COMPDATA=0;                                 printf("\n 1 for 150 round/minute\n\r");                 printf("\n 2 for 110 round/minute\n\r");                 printf("\n 3 for 80 round/minute\n\r");                    printf("\n 4 for 50 round/minute\n\r");                    printf("\n 5 for 0.1 round/minute\n\r");                 motormode = UART_getchar(PC_TERM_PORT);                                     switch(motormode)                                 {                                    case '1':                                                       STEEPMOTOR_PWM_Init(38);//150 round/minute                                                         break;                                   case '2':                                                       STEEPMOTOR_PWM_Init(52);//110 round/minute                                                         break;                                   case '3':                                                                       STEEPMOTOR_PWM_Init(72);//80 round/minute                                                          break;                                   case '4':                                                                       STEEPMOTOR_PWM_Init(116);//50 round/minute                                                         break;                                   case '5':                                                                       STEEPMOTOR_PWM_Init(58592);//0.1 round/minute                                                         break;                                                                                default: break;                                 }                                 while( roundcount < 64000 ) {} //10 round                                 Disable_PWM;                                 printf("\n %c 10round PWM is finished ", motormode);                                 roundcount=0; } 5 DEMO About the test code, please find it from the attachment.

The modularity of the tower system makes it great for prototyping, but for higher speed interfaces, there might be timing/signal integrity issues from having the TWR-MEM. For example, if you run the NFC demo from MQX 4.2: C:\Freescale\Freescale_MQX_4_2\mqx\examples\nandflash\build\iar\nandflash_twrk60f120m, It works well standalone, but with TWR-MEM connected. It failed when trying to read the data from nandflash. Because the NAND flash is on the TWR-K60F120M board, any time you access the NAND flash through NFC the signal will still travel all the way to the MRAM and reflect back which can distort the signals. Checking with the NFC driver code, you may find the high driven strength of NFC IOs has already been enabled. Decreasing the NFC module clock by setting SIM_CLKDIV4_NFCDIV to 31,  the demo still failed. How to fix it? Here we provide a trick/solution for this issue: Ｅｎａｂｌｅ　ｔｈｅ　ｉｎｔｅｒｎａｌ　ｐｕｌｌ－ｕｐｓ　ｏｎ　ＮＦＣ　ｉｎｔｅｒｆａｃｅ. then you may set a slower NFC clock by setting SIM_CLKDIV4_NFCDIV to 12, this value can be larger to make the communication more stable, but please note if you try to design a custom board, there is no reason it shouldn’t work at max frequency with a better layout. Hope that helps, -Kan

To do: The development platform is Eclipse. The EVAL Board is the Kinetis Tower TWR K60. On the Tower, you find 2 pushbuttons and 4 LEDs. a) Generate a hexadecimal random number from 0x0 to 0xF as long as pushbutton1 is pressed. Display the result with the 4 LEDs for about 3 seconds. b) Replace the code for recognizing a pressed key by a macro "KEY1_PRESSED". c) Replace the access to the 4 LEDs by a macro "LEDx_TOGGLE" with x = 0...3". Use active wait loops instead of the timer in this Kinetis exercise. Result: TWR_K60_RANDOM.zip

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.

This project is for neck's physical therapy and for a wheel chair that will move just with two buttons. This project is intended to be for persons who cannot move arms to do stuff.Instead of having a little joystick to move, they will just have to press one button turn around on the wheel chair or press the other button to make it advance. Because of the time we have to present this project, we will for now apply this idea to a toy car that will help children to do physical therapy on the neck.   Silla de Ruedas controlada por movimientos del cuello - YouTube   Facebook Original Attachment has been moved to: Code.zip