El proyecto está basado en Kinetis KL25Z, consiste en utilizar un tapete de 9 “Botones” y un nunchuck para rehabilitación en piernas y o entrenar sus capacidades sicomotrices llevarlo a cabo atravez de programas especiales en PC, bien esto se lleva acabo utilizando la función de HID de Processor Expert, en el caso del nunchuck funciona como mouse y el tapete como teclado, el joystick del nunchuck actúan como el desplazamiento del mouse y los dos botones con los que cuenta actúan como clic derecho e izquierdo y el tapete actúa como las teclas W, A, S, D, (están son configurables) más 5 teclas adicionales, el tapete está formado por sensores de presión que al pisarlos simulan las teclas correspondientes.     BodyPCcontrol Kinetis Challenge México 2013 - YouTube Original Attachment has been moved to: HID-KEYRUG-KL25Z.rar

  对于 Kinetis 芯片来说，发生在工程师调试，小批及量产阶段都经常发生的一个问题就是Kinetis Lock(锁住)，尤其是在刚用这个芯片设计及小批的客户身上，这个错误几乎都会遇 到。附件中的文档将对这个问题作出详细的讨论。

This example shows a FRDM-KL46Z interfacing with a Bluetooth-serial board BT_BOARD V1.05, it uses FREEMASTER to graph temperature and light sensor variables. Check how to connect, configure Bluetooth, and freemaster in attached document FRDM-KL46Z-Bluetooth-Freemaster.zip contains                            srec file                            firmware                            fremaster project (.pmp) Luis

The board used: FRDM-KE02 SWD: The ARM Serial Wire Debug interface uses a single bidirectional data connection(SWDIO) and a separate clock (SWDCLK) to transfer data synchronously. An operation on the wire consists of two or three phases: Packet request       The external host debugger issues a request to the DP. The DP is the target of the request. Acknowledge response   The target sends an acknowledge response to the host. Data transfer phase First enter into SWD mode: Send at least 50 SWCLKTCK cycles with SWDIOTMS HIGH and 0xE79E. This ensures that the current interface is in its reset state and enable the SWD mode. uint8_t SWJ_JTAG2SWD(void) {     uint32_t i;     SWDIO_SET();     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWJ_SendData(0xE79E);//SWJ_SendData(0xB76D);以后遇到再加     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWDIO_CLR();     for(i = 0; i < 16; i++)     {         SW_CLOCK_CYCLE();     }     return 0; } Then write DP/AP register. A successful write operation is as below: DP Register: Address     Read              Write 0x00        IDCODE           ABORT 0x04        CTRL/STAT      CTRL/STAT 0x08        RESEND           SELECT 0x0C        RDBUFF           N/A Address     Read              Write 0x00         CSW               CSW 0x04         TAR               TAR 0x08         N/A                N/A 0x0C         DRW              DRW 0xFC         IDR                N/A Read IDCODE： uint8_t SWJ_ReadDP(uint8_t adr, uint32_t *val) {     uint32_t tmp_in;     uint8_t ack;     uint8_t err;     tmp_in = SWD_REG_DP | SWD_REG_R | SWD_REG_ADR(adr);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; } uint8_t SWJ_ReadAP(uint32_t adr, uint32_t *val) {     uint8_t tmp_in, ack, err;     uint32_t apsel = adr & APSEL;     uint32_t bank_sel = adr & APBANKSEL;     if(SWJ_WriteDP(DP_SELECT, apsel | bank_sel))     {         return 1;     } tmp_in = SWD_REG_AP | SWD_REG_R | SWD_REG_ADR(adr);     /* first dummy read */     ack = SWD_Transfer(tmp_in, val);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; }

Hello all,      So, this time there is a query on implementing IRDA communication by bit banging the GPIOs. So, I come up with an experiment to do so. Before that, why bit banging when KE02 supports IR communication right away by using FTM at TX and ACMP at RX? something similar to this Implementing infrared functions on UART0 with FRDM-KE02Z platform.        The answer lies in the waveform attached. In the code from the above discussion, the PWM modulation is performed on FTM channel for transmission, while the communication that customer required was different and the waveform required is the one attached.                                                                                           Note that the IRDA transmitter on FRDM-KE02Z is connected to UART0. But, in the attached code, UART0 is not configured for IRDA_TX. while ACMP is used for RX.      This post is intended to be a reference to those who want to implement IRDA with 3/16th bit width by bit banging.      Here is the schematic snapshot of the FRDM-KE02.   There are 2 sets of codes attached. 1. FRDM_KE02_singleboard_IRDA_BITBANGING_TX_RX - IRDA on a single board. 2. FRDM_KE02_interboard_IRDA_BITBANGING_TX_RX - IRDA between 2 boards.   To run a single board demo, the orientation of IRDA Transmitter and IRDA receiver is already taken care as both are on the same board. But, to run the second demo, the orientation is supposed to be something like this.   Both the demos are configured for 9600baud to communicate with PC. And the IRDA communication is at 2400baud.      The figure in page 13 of this document is referred while development. http://www.vishay.com/docs/82513/physical.pdf                                                                            Transmission - 1. The bit width is calculated depending on the required IRDA baud and PIT1 modulo is adjusted accordingly. There are 3 MOD values initialized one after the other to generate required IR frame. 2. The data to be transmitted is sent over the HyperTerminal @ 9600baud. This data is accordingly transmitted on PTB1.      The green waveform in the below oscilloscope snap is the IR frame from the above picture. The data being sent is 'e', the hex value of which is 0x65 which can be made out from the waveform. 0x65 is 0xa6 in reverse since LSB is sent out first in the IRDA protocol[The first logic high is the start bit. In IRDA transmission, logic low is data '1' and logic high is data '0'].                                                                                      Reception - 1. ACMP0 is configured to generate interrupts on either the rising edge or the falling edge. 2. The falling edge of the start bit triggers ACMP. 3. The logic received on PTA1 is decoded to arrive at the received data. 4. The falling edge on ACMP channel decides logic 0 and the PIT0 interrupt decides the logic 1.      The below waveform is the one probed at PTA1.                                                                     Thanks, Pramod TM

To do: In this exercise, you realize a windscreen wiper with the Tower. The LEDs simulate the moving wiper by running from left to right and back again. The user interface is simple: With pushbutton1, the time delay interval is increased in steps of 1 second starting from 5 seconds delay down to 1 second and further to continuous wiping. With pushbutton2 the delay is decreased in the same way. If the delay is decreased, the wiper should start immediately, because right now there is a need for wiping. This is not true for increasing the delay. In this case, wait till the current delay time is over, set the new delay. In technical terms: Use asynchronous interval reset for decrease and synchronous reset for increase. Use active wait loops instead of the timer in this Kinetis exercise. Hint: Have you already switched a case? Result: TWR_K60_wiper_poll.zip

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

为了提高我们FAE对客户支持的效率，我们有必要将我们在客户支持过程中遇到的问题和解决方法以FAQ的形式列出来，方便大家查阅和参考。FAQ的形式比较灵活，大家可以以简单问答的形式言简意赅的描述，也可以是参考文章的链接，众人拾柴火焰高，希望大家能多收集问题并及时更新到该帖子中。 版本更新说明： Version 22: Rename "软件和例程" with "软件和文档", Add "常用的应用笔记" into "软件和文档" list; Version 20, 21: Remove "WIFI" solution, Add "SPI接口读写SD卡"; Version 19: Replace "iBeacon" with "BLE"; More version informations, please go to "Kinetis M0+ FAQ 版本更新历史" FAQ使用规范 1.FAQ Notes(Internal Use Only) 芯片选型 1.Kinetis L、E、V、W、M系列选型指南 软硬件开发环境 1.调试工具 2.量产工具 3.开源工具 4.IDE开发环境 5.开发板 硬件设计 1.电路设计注意事项 软件和文档 1.外设模块相关 2.Kinetis SDK 3.Kinetis Bootloader 4. 常用的应用笔记​ 参考设计及解决方案 1.Wireless Charging 2.Motor Control 3.BLE​ 4.M0+ 与Android手机通讯(基于AOAP协议) 5.SPI接口读写SD卡​ 常用网站资料 1.Amobbs（阿莫电子技术论坛） 2.与非网飞思卡尔技术社区 3.21IC飞思卡尔论坛 4.苏州大学教材光盘资料下载区 5.针对飞思卡尔单片机的快速上手指南 6.飞思卡尔MAPS开发板资料​ 7.FAE Technical Blogs​

Project Summary MonkeyListen uses the FRDM-K20D50 board (which has a Cortex M4 core with DSP instructions) with the FRDM-OLED shield so you can  make your very own spectrum analyzer display  The end result will be a functional DSP system that will analyze incoming audio content via an electret microphone on FRDM-OLED board and display the spectral content.   The example code will also show you how to plot time domain data (a simple audio scope!),  Frequency domain data (via an FFT) and a time-frequency plot (spectrogram).  Extra I/O are provided to hack the code and create your own DMM or oscilloscope. The FRDM-OLED shield also has an optional RS-485 interface for doing cool things like driving a DMX lighting system! Skills Developed: Spectral Analysis via FFT OLED display interfacing Electret microphone Interfacing Soldering SOIC8 and 1206 surface mount devices Cortex CMSIS DSP Library Materials: FRDM-K20D50 FRDM-OLED Development Tools Install Codewarrior 10.5 for Microcontrollers (Eclipse) Special Edition to your  machine Example Code Get the latest copy from Github Prerequisite Videos: All of the videos are organized on a Youtube playlist: H.I.T. #2: MonkeyListen - YouTube MonkeyListen WatchMe1st MonkeyListen Demo: Time Domain + FFT Mode MonkeyListen Demo: Spectrogram Mode Spectral Analysis for Embedded Systems Part 1 & Part 2 Getting Started with the ARM CMSIS DSP FFT library Introduction to Fixed Point Math for Embedded Systems Part 1, 2 and 3 The q31_t (Q.31) number format for the CMSIS DSP libraries FRDM-OLED Overview EEVblog #611 - Electret Microphone Design Loading and Configuring the MonkeyListen Example Software Step 1:  Get a FRDM-OLED      You can order raw PCBs yourself from OSHPark or your favorite PCB vendor.      The bill of materials for the FRDM-OLED is included with the build package on the FRDM-OLED page.     Please let us know if you are interested in a pre-assembled version.   If there is enough demand we will get some built via a Kickstarter campaign   Don't be afraid to build it yourself,  Soldering is fun!  There is plenty of good stuff on the web on how to do SMT soldering.   All of the parts on the board are fairly simply once you get the hang of it and everything can be hand soldered  The key is having some decent tools. Step 2: Put it Together Attach  The FRDM-OLED to the FRDM-K20D50.   The FRDM-K20D50 comes with female headers that you can solder on so the boards can be easily separated. Step 3: Download Download the example software.   The video "Loading and Configuring the MonkeyListen Example Software" will step you though downloading the program and doing some basic configuration. Step 4: Say Something Speak, Sing and Yell.... Step 5: Hack! Do something else cool.....  Make a DMM,  or an o-scope....

Here you can find the code and project files for the GPIO example, in this example the 3 colors of the RGB led are turned on sequentially when the SW2 push button is pressed, the led pin definition is shared throughout all the freedom platforms. The wait function can be defined in seconds, miliseconds or microseconds. Code: #include "mbed.h" //Delay declared in seconds /*GPIO declaration*/ DigitalOut Red(LED1);         DigitalOut Green(LED2); DigitalOut Blue(LED3); DigitalIn sw2(SW2); int main() {     /*Leds OFF*/     Red=1;     Green=1;     Blue=1;         while(1)     {         if(sw2==0)         {             Red = 0;             wait(.2);             Red = 1;             wait(1);                                Green=0;             wait(.2);             Green=1;             wait(1);                         Blue=0;             wait(.2);             Blue=1;             wait(1);         }     } }

CONVOCATORIA Freescale Semiconductor, Inc. Convoca al primer concurso de proyectos “Kinetis L MCU Challenge México” “Kinetis L MCU Challenge México” es una competencia de proyectos tecnológicos basado en la herramienta de desarrollo Kinetis Freedom en la cual el participante construye una aplicación alineada a una de las futuras tres tendencias Salud y Seguridad, Efecto Net o Going Green. Los proyectos finalistas serán presentados durante la final del Freescale Cup 2013 el día 7 de Diciembre, a las 9:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara.  Si resultas ganador, viajarás con todos los gastos pagados al Freescale Technology Forum (FTF) en Dallas, Texas. ¿Cómo puedo participar? Regístrate en Kinetis Challenge antes del 15 de Noviembre de 2013 Crea una aplicación utilizando la herramienta de desarrollo Freedom (en caso de no contar con ella, puedes adquirirla a través de Element 14 (entrega al siguiente día laborable), Mouser (entrega en 4 semanas), o Digikey (entrega de 3 a 5 días hábiles) . Tienes hasta el 15 de Noviembre para subir la información de tu aplicación a la comunidad de Freescale (es necesario hacer log in con tu cuenta en www.freescale.com😞 Nombre de la aplicación 1 párrafo descriptivo de la aplicación Un video descriptivo de hasta 2 minutos El código fuente en formato .zip Subir el proyecto como documento en la sección de Kinetis Microcontrollers en el siguiente formato:  https://community.freescale.com/docs/DOC-94067 El proyecto deberá contener el tag: "Kinetis L MCU Challenge México" para ser identificado como proyecto participante del concurso. Freescale seleccionará 10 proyectos finalistas basándose en los criterios descritos en la convocatoria. Éstos se presentarán en el evento Freescale Cup 2013 el próximo 7 de Diciembre de 2013. Para conocer a los finalistas ingresa aquí. El proyecto ganador, será elegido durante el evento Freescale Cup 2013 por los asistentes al evento, a través de la comunidad Freescale y redes sociales, basándose en los criterios descritos en la convocatoria. El anuncio del proyecto ganador y la entrega de certificados será el  día del evento. La elección del ganador está en tus manos, sigue las instrucciones aquí. ¡Descubre quién es el ganador aquí! Links de interés: Acerca de Otros Recursos Registro Freedom Development Platform Ejemplos de proyectos con Kinetis www.electronicosonline.net/kinetischallenge FRDM-KL25Z Compra de FRDM-KL25Z en Element14 Kinetis L Microcontrollers Compra de FRDM-KL25Z en Mouser Freescale Cup 2013 Compra de FRDM-KL25Z en Digikey FTF Americas 2014 Cómo subir tu proyecto

The documentation points out that the Figure 32-1. Multipurpose Clock Generator (MCG) block diagram in KV5xP144M240RM.pdf is incorrect, the  /2 divider is NOT included in the feedback loop. It gives the formula to compute the VCO and MCGPLLCLK clock frequency and corresponding code.

近期有客户提出需求，要求通过外部Flash编程工具烧写Flash Program Flash IFR区域。 目前P&E Cyclone MAX和Segger J-Flash均无法实现对IFR区域编程。 客户可以使用软件的方式来编程IFR提供的单次烧写区域，存储客户产品信息，例如MAC地址等。 Program Flash单次烧写区域提供了64个字节，只允许烧写一次，通过Program Once和Read Once命令来读写这个区域。 下图为单次烧写区域在Prgoram Flash IFR的具体位置， IFR独立于FTFL Flash空间，可以理解成另外一个Flash模块。 Program Once和Read Once命令每次调用可以读取Program Flash单次烧写区域的4个字节，通过命令参数的数据索引号可以通过多次操作遍历整个64个字节。 附件中的例程使用Program Once命令编写MAC地址到单次烧写区域，之后通过Read Once命令读取MAC地址信息。 例程环境： IAR Workbench + TWR-K60D100M

Hi,All Our team have developed the K60's peripheral derives lib which is open source and open source firmware library. the The open source lib have these feature just as follow: 1\The setup code based on the CMSIS Standard; 2\The lib include most of peripherals of K60 such as ADC,DAC,DMA,CAN,FTM,LPTMR, ENET,FLASH,FLexBUS,GPIO,IIC,MCG,PDB,SPI,USB,TSI,UART,WDOG,SDHC,PIT,etc. 3\All of the peripheral initiate function are based on the a structure variable Struct format. 4\Add parts of Freescale USB Stack into the lib such as USB CDC and USB HID mouse. 5\We also develop relative example projects to demonstrate how to use the library for the peripheral. All of the project are created by the IAR for ARM Ver.6.4. The attach is the code. We divide the code into two parts. One part is driver lib, and another part is project. PS 1:All of the code comments are Chinese, please forgive. PS 2:All of drivers is on the \lib\LPLD\HW.      The K60 project need Unzip into the \porject\. PS 3:The code has many place that need update and improve. if you have any doubt and opinions,please contact us.support[AT]lpld.cn Best Regards Wang

Hello, The below attachment is the code for UART with the input data as a character..But i need the input data to be a STRING...Can anyone please post the code for UART with input as a string using MK22D5.

By Paolo Alcantara RTAC Americas Mexico 2012 USB device firmware update (DFU) bootloader provides an easy and reliable way to load new user applications to devices having preloaded the USB DFU bootloader. After loaded, the new user application is be able to run in the MCU. The USB DFU bootloader requires an application running on a PC (USB DFU PC application). The DFU PC application supports loading the firmware to the device by using specific requests as stated in the USB DFU specification class. The USB DFU bootloader is able to enumerate in two ways: -USB composite device mode: also know as run time mode. It’s formed of a DFU device plus another USB device class. For this implementation, human interface device (HID) mouse device is used to avoid increasing the bootloader memory size. The MCU must be in the following conditions prior to enter to this mode: MCU doesn’t contain a valid firmware image or doesn’t contain firmware. An external action is applied to MCU such as pressing a button during a reset event. This is dependant of the USB DFU bootloader implementation. -DFU device mode: used when DFU is ready to upload or download firmware images by a request made from the USB DFU PC Application. Prior to this mode, the MCU was in USB composite device mode. A bootloader is a small application that is used to load new user applications to devices. Therefore, the bootloader needs to be able to run in both, the user application and bootloader mode. As an example: After reset, the device attempts to run the user application. If the user application is not found or corrupted, the device automatically runs into bootloader mode. In case the application is valid and user wants to run bootloader program, external intervention is required such as pressing a specific key at reset time to force the device entering to bootloader mode. Full application note and software attached.

There with phase shifting when using two different FTM modules to output PWM signals. Although the two FTM modules using the same clock source (bus clock), there still exists the phase shifting status. Please check attached video about phase shifting. FTM Global Time Base(GTB) introduction The global time base (GTB) is a FTM function that allows the synchronization of multiple FTM modules on a chip. The following figure shows an example of the GTB feature used to synchronize two FTM modules. In this case, the FTM A and B channels can behave as if just one FTM module was used, that is, a global time base. K65’s FTM0 provides the only source for the FTM global time base. The other FTM modules can share the time base as shown in the following figure: The code description:    // Configure ftm params with frequency 2MHz for CLK        ftm_pwm_param_t ftmParamCLK = {             .mode                   = kFtmEdgeAlignedPWM,   //PWM mode             .edgeMode               = kFtmLowTrue,           //PWM Low-true pulses (clear Output on match-on)             .uFrequencyHZ           = 200000u,         //2MHz clock frequency             .uDutyCyclePercent      = 50,                //Duty cycle 50%             .uFirstEdgeDelayPercent = 0,                        };    //using FTM0 & FTM3 GTB feature    FTM_HAL_SetClockSource (FTM0, kClock_source_FTM_None);   //disable FTM0 clock source    FTM_HAL_SetClockSource (FTM3, kClock_source_FTM_None);   //disable FTM3 clock source      FTM_HAL_SetGlobalTimeBaseCmd(FTM0, true);   //enable FTM0 GTBEEN    FTM_HAL_SetBdmMode(FTM0, kFtmBdmMode_11);   //enable FTM0 BDMMODE    FTM_HAL_SetGlobalTimeBaseCmd(FTM3, true);   //enable FTM3 GTBEEN    FTM_HAL_SetBdmMode(FTM3, kFtmBdmMode_11);   //enable FTM3 BDMMODE        FTM_HAL_SetClockSource (FTM0, kClock_source_FTM_SystemClk);   //disable FTM0 clock source    FTM_HAL_SetClockSource (FTM3, kClock_source_FTM_SystemClk);   //disable FTM3 clock source      FTM_HAL_SetCounter(FTM0, 0U);        //clear TFM0 counter value to 0    FTM_HAL_SetCounter(FTM3, 0U);        //clear FTM3 counter value to 0      FTM_HAL_SetGlobalTimeBaseOutputCmd(FTM0, true);      //enale FTM0 GTBEOUT Please check attached video about after using GTB feature, the FTM0_CH4 and FTM3_CH1 PWM output signals. How to output two PWM output signals at one FTM module with KSDK? The two PWM output signal will provides the same clock frequency with different duty cycle. The two PWM output signal need use the same PWM mode. Please check below code to enable K65’s FTM0 module output two PWM signals. // Configure ftm params with frequency 2MHz for CLK        ftm_pwm_param_t ftmParamCLK = {             .mode                   = kFtmEdgeAlignedPWM,   //PWM mode             .edgeMode               = kFtmLowTrue,           //PWM Low-true pulses (clear Output on match-on)             .uFrequencyHZ           = 200000u,         //2MHz clock frequency             .uDutyCyclePercent      = 50,                //Duty cycle 50%             .uFirstEdgeDelayPercent = 0,                        }; // Configure ftm params with frequency 2MHz for CLK                ftm_pwm_param_t ftmParamSH =         {              .mode                   = kFtmEdgeAlignedPWM,   //PWM mode              .edgeMode               = kFtmLowTrue,   //PWM Low-true pulses (clear Output on match-on)              .uFrequencyHZ           = 200000u,        //2MHz clock frequency              .uDutyCyclePercent      = 75,     //Duty cycle 75%              .uFirstEdgeDelayPercent = 0,         };     // Initialize FTM module,     // configure for software trigger.     memset(&ftmInfo, 0, sizeof(ftmInfo));     ftmInfo.syncMethod = kFtmUseSoftwareTrig;  //Using software trigger PWM synchronization     FTM_DRV_Init(BOARD_FTM_INSTANCE, &ftmInfo);  //FTM0 initialization     FTM_DRV_SetClock(BOARD_FTM_INSTANCE, kClock_source_FTM_SystemClk, kFtmDividedBy1); //Enable FTM0 counter clock     FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamCLK, BOARD_FTM_CHANNEL); //Enable PWM output at FTM0_CH4     FTM_HAL_SetClockSource(FTM0, kClock_source_FTM_None); //Disable FTM0 counter clock     FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamSH, BOARD_FTM_CHANNEL5);   //Enable PWM output at FTM0_CH5 The tested code also be attached, please using it with KSDK V1.2 software. Wish it helps.

OpenSDA/OpenSDAv2 is a serial and debug adapter that is built into several Freescale evaluation boards. It provides a bridge between your computer (or other USB host) and the embedded target processor, which can be used for debugging, flash programming, and serial communication, all over a simple USB cable.   The OpenSDA hardware consists of a circuit featuring a Freescale Kinetis K20 microcontroller (MCU) with an integrated USB controller. On the software side, it implements a mass storage device bootloader which offers a quick and easy way to load OpenSDA applications such as flash programmers, run-control debug interfaces, serial to USB converters, and more. Details on OpenSDA can be found in the OpenSDA User Guide.     The bootloader and app firmware that lay on top of the original OpenSDA circuit was proprietary.  But recently ARM decided to open source their CMSIS-DAP interface, and now a truly open debug platform could be created. This new open-sourced firmware solution is known as OpenSDAv2.   OpenSDAv2: OpenSDAv2 uses the exact same hardware circuit as the original OpenSDA solution, and out of the box it still provides a debugger, drag-and-drop flash programmer, and virtual serial port over a single USB cable.   The difference is the firmware implementation: OpenSDA: Programmed with the proprietary P&E Micro developed bootloader. P&E Micro is the default debug interface app. OpenSDAv2: Programmed with the open-sourced CMSIS-DAP/mbed bootloader. CMSIS-DAP is the default debug interface app.       Firmware Developer Kinetis K20 Based Hardware Circuit Default Debug Interface Drag-and-drop Target MCU Flash Programming Virtual Serial Port Source Code Available OpenSDA P&E Micro x P&E Micro .srec/.s19 x   OpenSDAv2 ARM/mbed.org x CMSIS-DAP .bin x x   The bootloader and app firmware used by OpenSDAv2 is developed by the community at mbed.org, and is known as “CMSIS-DAP Interface Firmware”. If you explore that site, you will find that this firmware was also ported to run on other hardware, but the combination of this mbed.org firmware with the Kinetis K20 MCU is known as OpenSDAv2.   It is important to understand however that it is possible to run a P&E Micro debug app on the CMSIS-DAP/mbed bootloader found on OpenSDAv2. Likewise it is possible to run a CMSIS-DAP debug app on the P&E Micro bootloader found on OpenSDA. The debug application used needs to be targeted towards a specific bootloader though, as a single binary cannot be used on both the OpenSDA and OpenSDAv2 bootloaders.   OpenSDAv2.1: During development of OpenSDAv2 features and bug fixes, it was found that the reserved bootloader space was too small. Thus a new version of OpenSDAv2 had to be created, which was named OpenSDAv2.1. The difference between the OpenSDAv2.0 and v2.1 is the address where the debug application starts: for OpenSDAv2.0 it expects the application at address 0x5000, while OpenSDAv2.1 expects the application to start at address 0x8000.   The only board with OpenSDAv2.0 is the FRDM-K64F. All other OpenSDAv2 boards (such as the just released FRDM-K22F) use OpenSDAv2.1.   Unfortunately this means that new OpenSDAv2 apps are needed. From a user perspective this mostly affects the JLink app since it was shared across all boards. Make sure you download the correct app for your board based on the OpenSDAv2 version.   OpenSDAv2 Apps: mbed CMSIS-DAP for FRDM-K64F mbed CMSIS-DAP for FRDM-K22F P&E Micro  (use the Firmware Apps link) Segger JLink (look at bottom of page for OpenSDAv2.0 or OpenSDAv2.1 app)   OpenSDAv2 Bootloader: The key difference between OpenSDA and OpenSDAv2 is the bootloader. Boards with OpenSDA use a proprietary bootloader developed by P&E Micro, and it cannot be erased or reprogrammed by an external debugger due to the security restrictions in the firmware. Boards with OpenSDAv2 use the open-source bootloader developed by mbed.org, and it can be erased and reprogrammed with an external debugger.   Apps need to be specifically created to work with either the P&E bootloader (Original OpenSDA) or the CMSIS-DAP/mbed bootloader (OpenSDAv2/OpenSDAv2.1) as the bootloader memory map is different.  Thus it’s important to know which type of bootloader is on your board to determine which version of an app to load.   You can determine the bootloader version by holding the reset button while plugging in a USB cable into the OpenSDA USB port. A BOOTLOADER drive will appear for both OpenSDA and OpenSDAv2.   The OpenSDAv2.0 bootloader (may also be called the CMSIS-DAP/mbed bootloader) developed by mbed.org will have the following files inside.  Viewing the HTML source of the bootload.htm file with Notepad will tell you the build version, date, and git hash commit. For the OpenSDAv2.1 bootloader, this file will be named mbed.htm instead.     The OpenSDAv1 bootloader developed by P&E Micro will have the following inside. Clicking on SDA_INFO.HTM will take you to the P&E website.       Using CMSIS-DAP: When you connect a Freedom board that has OpenSDAv2 (such as the FRDM-K64F) to your computer with a USB cable, it will begin running the default CMSIS_DAP/mbed application which has three main features.   1. Drag and Drop MSD Flash Programming You will see a new disk drive appear labeled “MBED”.   You can then drag-and-drop binary (.bin) files onto the virtual hard disk to program the internal flash of the target MCU.   2.Virtual Serial Port OpenSDAv2 will also enumerate as a virtual serial port, which you can use a terminal program , such as TeraTerm (shown below), to connect to. You may need to install the mbed Windows serial port driver first before the serial port will enumerate on Windows properly. It should work without a driver for MacOS and Linux.   3. Debugging The CMSIS-DAP app also allows you to debug the target MCU via the CMSIS-DAP interface. Select the CMSIS-DAP interface in your IDE of choice, and inside the CMSIS-DAP options select the Single Wire Debug (SWD) option:   Kinetis Design Studio (KDS): Note: OpenOCD with CMSIS-DAP for FRDM-K22F is not supported in KDS V1.1.0. You must use either the P&E app instructions or the JLink app instructions to use KDS with the FRDM-K22F at this time. This will be fixed over the next few weeks. OpenSDAv2 uses the OpenOCD debug interface which uses the CMSIS-DAP protocol. Make sure '-f kinetis.cfg' is specified as 'Other Options':   IAR     Keil:         Resources CMSIS-DAP Interface Firmware mbed.org FRDM-K64 Page FRDM-K64 User Guide OpenSDAv2 on MCU on Eclipse blog OpenSDA User Guide KDS Debugging   Appendix A: Building the CMSIS-DAP Debug Application The open source CMSIS-DAP Interface Firmware app is the default app used on boards with OpenSDAv2. It provides: Debugging via the CMSIS-DAP interface Drag-and-drop flash programming Virtual Serial Port providing USB-to-Serial convertor   While binaries of this app are provided for supported boards, some developers would like to build the CMSIS-DAP debug application themselves.   This debug application can be built for either the OpenSDAv2/mbed bootloader, or for the original OpenSDA bootloader developed by P&E Micro. If you are not sure which bootloader your board has, refer to the bootloader section in this document.   Building the CMSIS-DAP debug application requires Keil MDK. You will also need to have the “Legacy Support for Cortex-M Devices” software pack installed for Keil.   You will also need Python 2.x installed. Due to the python script used, Python 3.x will not work.   The code is found in the MBED git repository, so it can be downloaded using a git clone command: “git clone https://github.com/mbedmicro/CMSIS-DAP.git” Note that there is a Download Zip option, but you will run into a issue when trying to compile that version, so you must download it via git instead.   The source code can be seen below:   This repository contains the files for both the bootloader and the CMSIS-DAP debug interface application. We will concentrate on the interface application at the moment.   Open up Keil MDK, and open up the project file located at \CMSIS-DAP\interface\mdk\k20dx128\k20dx128_interface.uvproj In the project configuration drop-down box, you will notice there are a lot of options. Since different chips may have slightly different flash programming algorithms, there is a target for each specific evaluation board. In this case, we will be building for the FRDM-K64F board. Scroll down until you get to that selection:   Notice there are three options for the K64: k20dx128_k64f_if: Used for debugging the CMSIS-DAP application with Keil. Code starts at address 0x0000_0000 k20dx128_k64_if_openSDA_bootloader: Creates a binary to drag-and-drop on the P&E developed bootloader (Original OpenSDA) k20dx128_k64_if_mbed_bootloader: Creates a binary to drag-and-drop onto the CMSIS-DAP/mbed developed bootloader (OpenSDAv2)   Since the FRDM-K64F comes with the OpenSDAv2 bootloader, we will use the 3 rd option. If we were building the mbed app for another Freedom board which had the original OpenSDA bootloader, we would choose the 2 nd option instead.   Now click on the compile icon. You may get some errors If you get an error similar to the one shown below, make sure you have installed the Legacy pack for ARM as previously described earlier:           compiling RTX_Config.c...             ..\..\Common\src\RTX_Config.c(184): error:  #5: cannot open source input file "RTX_lib.c": No such file or directory            and           compiling usb_config.c...             ..\..\..\shared\USBStack\INC\usb_lib.c(18): error:  #5: cannot open source input file "..\..\RL\USB\INC\usb.h": No such file or directory   If you get an error regarding a missing version_git.h file, make sure that Python 2.x and git are in your path. A Python build script fetches that file. It's called from the User tab in the project options, under "Run User Programs Before Build/Rebuild". If there is a warning about “invalid syntax” when running the Python script, make sure your using Python 2.x. Python 3.x will not work with the build script.   Now recompile again, and it should successfully compile. If you look now in \CMSIS-DAP\interface\mdk\k20dx128 you will see a new k20dx128_k64f_if_mbed.bin file   If you compiled the project for the OpenSDA bootloader, there would be a new k20dx128_k64f_if_openSDA.S19 file instead.   Loading the CMSIS-DAP Debug Application: Now take the Freedom board, press and hold the reset button as you plug in the USB cable. Then, drag-and-drop the .bin file (for OpenSDAv2) or .S19 file (for OpenSDA) into the BOOTLOADER drive that enumerated.   Perform a power cycle, and you should see a drive called “MBED” come up and you can start using the CMSIS-DAP debug interface, as well as drag-and-drop programming and virtual serial port as described earlier in this document.   Appendix B: Building the CMSIS-DAP Bootloader All Freedom boards already come with a bootloader pre-flashed onto the K20.  But for those building their own boards that would like to use CMSIS-DAP, or those who would like to tinker with the bootloader, it possible to flash it to the Kinetis K20 device. Flashing the bootloader will require an external debugger, such as the Keil ULink programmer or Segger JLink.   Also note that the OpenSDA/PE Micro Bootloader cannot be erased! Due to the proprietary nature of the P&E firmware used by the original OpenSDA, it can only be programmed at the board manufacturer and JTAG is disabled. So these instructions are applicable for boards with OpenSDAv2 only.   First, open up the bootloader project which is located at \CMSIS-DAP\bootloader\mdk\k20dx128\k20dx128_bootloader.uvproj   There is only one target available because all OpenSDAv2 boards will use the same bootloader firmware as the hardware circuitry is the same.   Click on the compile icon and it should compile successfully. If you see errors about a missing version_git.h file, note that Python 2.x must be in the path to run a pre-build script which fetches that file.   Now connect a Keil ULink to J10 and then insert a USB cable to provide power to J26. Note that if you have the 20-pin connector, you’ll want to use the first 10 pins.   Then for Keil 5 you will need to change some debug options (CMSIS-DAP is built under Keil 4.x).   Right click on the bootloader project, and go to the Debug tab and next to ULINK Pro Cortex Debugger, click on Settings:   Then under “Cortex-M Target Driver Setup”, change the “Connect” drop down box to “under Reset” and “Reset” dropdown box to “HW RESET”. Hit OK to save the settings.     Then in Keil, click on Flash->Erase.   And then on Flash->Download.   If you get an “Invalid ROM Table” error when flashing the CMSIS-DAP bootloader, make sure you made the changes to the debugger settings listed above.   After some text scrolls by, you should see:   Now power cycle while holding down the reset button, and you should see the bootloader drive come up. You’ll then need to drag and drop the mbed application built earlier onto it. And that’s all there is to it!   The binaries for the bootloader and CMSIS-DAP debug app for the FRDM-K64F board created in writing this guide are attached. Original Attachment has been moved to: k20dx128_bootloader.axf.zip Original Attachment has been moved to: k20dx128_k64f_mbed.bin.zip

       RSA is a major cryptosystem in the public key cryptography. It is wildly used nowadays.  But why are we interested in elliptic    curve cryptography?   1. The smaller parameters can be used in elliptic curve cryptography (ECC) than with  RSA systems at a given security level.       2. In particular, private-key operations (such as signature generation and decryption) for ECC are many times more efficient        than RSA private-key operations.     3. Public-key operations (such as signature verification and encryption) for ECC are more efficient than RSA if a  bigger       encryption exponent e is selected for RSA.           The advantages offered by ECC can be important in environments where processing     power, storage, bandwidth, or power consumption is constrained.              KL26Z MCU is 48 MHz ARM Cortex-M0+ core, there are only 128K ROM and 16K RAM on chip. When you want to use the    public key cryptography, the elliptic curve cryptography may be a good choice for this low cost MCU.        This example implements a simple ECC certification from PC to USB.  After certification,     USB can get encrypted data from PC and decrypt these data to plain text.   KL26-Freedom : 1.   Open the porject file at folder kecc/build/cw/KECC/kl26_ecc/test   2.  Build the image and flush it with OpenSDA.   3. Open the Tera Term and start running image on KL26Z     PC running environment:     1. Install  these packets on PC:         python-2.7.3.msi, pycrypto-2.6.win32-py2.7.exe, pyserial-2.7.win32.exe and pywin32-219.win32-py2.7         2. Connect USB cable to KL26Z Freedom and install the CDC driver with       Freescale_CDC_Driver_Kinetis.inf driver     3. Open the application folder and run the usbkey.py.                 4. If USB admits  PC certification message, then PC can put encrypted data to USB.               This  demo only tested on WIN7 64bit. IF you can't open the CDC port, you need reset the KL26Z freedom board and restart the usbkey.py.     This ECC demo uses a library including some security toolkits for ECC certification.     1. Signature and verify : ECDSA     2. Key exchanging         :ECCRYPT    3.  Digest                         : SHA1    4. Symmetric   cipher     : AES and base64      All tools and codes are in following KECC.zip. Original Attachment has been moved to: kecc.zip

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