Kinetisマイクロコントローラ・ナレッジ・ベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Kinetis Microcontrollers Knowledge Base

ディスカッション

ソート順:
This document shows the implementation of the infrared on the UART0 using the FRDM-KE02Z platform. The FRDM-KE02Z platform is a developing platform for rapid prototyping. The board has a MKE02Z64VQH2 MCU a Kinetis E series MCU which is the first 5-Volt MCU built on the ARM Cortex-M0+ core. You can check the evaluation board in the Freescale’s webpage (FRDM-KE02Z: Kinetis E Series Freedom Development Platform) The Freedom Board has a lot of great features and one of this is an IrDA transmitter and receiver on it. Check this out! One of the features of the MCU is that the UART0 module can implement Infrared functions just following some tricks (MCU-magic tricks). According to the Reference Manual (Document Number: MKE02Z64M20SF0RM) this tricks are:      UART0_TX modulation: UART0_TX output can be modulated by FTM0 channel 0 PWM output      UART0_RX Tag: UART0_RX input can be tagged to FTM0 channel 1 or filtered by ACMP0 module For this example we are going to use the ACMP0 module to implement the UART0_RX functionality. Note1: The Core is configured to run at the maximum frequency: 20 Mhz Note2: Refer to the reference manual document for more information about the registers. Configuring the FTM0. The next lines show the configuration of the FTM0; the module is configured with a Frequency of 38 KHz which is the ideal frequency for an infrared led. The FTM0_CH0 is in Edge_Aligned PWM mode (EPWM).           #define IR_FREQUENCY       38000 //hz      #define FTM0_CLOCK                BUS_CLK_HZ      #define FTM0_MOD_VALUE            FTM0_CLOCK/IR_FREQUENCY      #define FTM0_C0V_VALUE            FTM0_MOD_VALUE/2      void FTM0CH0_Init( void )      {        SIM_SCGC |= SIM_SCGC_FTM0_MASK;             // Init FTM0 to PWM output,frequency is 38khz        FTM0_MOD= FTM0_MOD_VALUE;        FTM0_C0SC = 0x28;        FTM0_C0V = FTM0_C0V_VALUE;        FTM0_SC = 0x08; // bus clock divide by 2      } With this we accomplish the UART0_TX modulation through a PWM on the FTM0_CH0. Configuring the ACMP0. The configuration of the ACMP0 is using a DAC and allowing the ACMP0 can be driven by an analog input.      void ACMP_Init ( void )      {        SIM_SCGC |= SIM_SCGC_ACMP0_MASK;        ACMP0_C1 |= ACMP_C1_DACEN_MASK |                   ACMP_C1_DACREF_MASK|                   ACMP_C1_DACVAL(21);    // enable DAC        ACMP0_C0 |= ACMP_C0_ACPSEL(0x03)|                            ACMP_C0_ACNSEL(0x01);        ACMP0_C2 |= ACMP_C2_ACIPE(0x02);  // enable ACMP1 connect to PIN        ACMP0_CS |= ACMP_CS_ACE_MASK;     // enable ACMP                } With this we have now implemented the UART0_RX.     IrDA initialization. Now the important thing is to initialize the UART0 to work together with these tricks and implement the irDA functions. Basically we initialize the UART0 like when we use normal serial communication (this is not the topic of this post, refer to the project to see the UART_init function) and we write to the most important registers:         SIM_SOPT |= SIM_SOPT_RXDFE_MASK; UART0_RX input signal is filtered by ACMP, then injected to UART0.      SIM_SOPT |= SIM_SOPT_TXDME_MASK; UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout. The configuration is as follows:      void IrDA_Init( void )      { // initialize UART0, 2400 baudrate        UART_init(UART0_BASE_PTR,BUS_CLK_HZ/1000,2400);                  // clear RDRF flag        UART0_S1 |= UART_S1_RDRF_MASK;                  // initialize FTM0CH1 as 38k PWM output        FTM0CH0_Init();                      // enable ACMP        ACMP_Init(); SIM_SOPT |= SIM_SOPT_RXDFE_MASK;  //UART0_RX input signal is filtered by ACMP, then injected to UART0.        UART0_S2 &= ~UART_S2_RXINV_MASK;  //inverse data input SIM_SOPT |= SIM_SOPT_TXDME_MASK;  //UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout.      } With the irDA initialization we got the infrared features on the UART0. Philosophy of the Example In the attachments of this post you can find the example which shows the use of these functions in a basic application; the project was compiled in CodeWarrior 10.6 and the philosophy is: I hope that the information presented on this document could be useful for you. Thank you! Best Regards!
記事全体を表示
As K2 – The Next Generation of Kinetis Solutions continues to build momentum around new applications within the Internet of Things (IoT), the ARM® mbed™-enabled Freescale Freedom development platform, FRDM-K64F, is taking center stage. With the FRDM-K64F platform now in the hands of thousands of engineers across the globe, we already are learning about how this platform is powering new and inventive applications. To help illustrate this powerful and fun-sized platform, coming every Monday (beginning on Monday, May 19) for five consecutive Mondays, we invite you to join us for MountainMondays and scale K2 where we'll be giving away 20 FRDM-K64F development platforms each week - that's 100 in all! Join us to begin the ascent on Monday, May 19, by following Freescale's Facebook, Twitter and Google+ pages to find out what you have to do to win one of these development platforms! For complete contest rules, click here. Thanks to everyone who have participated in #MountainMondays! Great ideas from everyone! Below is our list of winners thus far for each week. If your name is on any of the following lists, be sure to email your shipping address to socialmedia@freescale.com and continue the ascent with us each Monday through June 16! Week 1 - May 19, 2014: Basecamp FRDM And the winners for week 1 are ... On Facebook ... Ahmed Felhi Naga Kishanmv Raleigh Sea Illgen Austin Chen Rahul Karnik Derrick Beaven David Pereira Anhell Barragán Valentín Korenblit Олег Лаврухин Hector Fabian Joanna Kurki Jozef Humaj Wojtek Stoduly Google+ ... Gurinder Singh Gill Mark McDonnell Niklas Stoyke Twitter ... kumisaappaat cledic evemuller92 Week 2 - May 26, 2014: Basecamp K And the winners for week 2 are ... From Facebook … Gaurav Chaudhary Bhuvanesh Nick Pyrosster Pyrosster Federico Lo Grasso Florencia Caruso Nick Defensor Laura Mándola SuperKing Tříska  From Twitter … Antonio Quevedo Jayprakash Shet Fahad Mirza Jonathan Chadwick Gordon Margulieux Hector Fabian C Zahir Parkar Attila Kozmári From Google+… Sergey Gridnewskiy Paul Nykiel Matías Dell'Oso Manishi Barosee Week 3 - June 2, 2014: Basecamp 6 And the winners for week 3 are ... From Facebook … Robert Bui Trong Nguyen Alexandre Ferri Michal Wertheim Petr Vítek Gerald Fry Jr Leśniewicz Wojciech Adriana Errico Trong Nguyen Emnics Erwin Kuhn Maliganis Nikolaos Dushyant Arora Štefan Knotek Hom Flann James Braga From Twitter… Gaurav Singh From Google+ … Soputtra San Clovis Fritzen Cristina Pérez Week 4 - June 9, 2014: Basecamp 4 And the winners for week 4 are ... From Facebook … Ivan Ruiz Robin Wohlers-Reichel Tony Anderson Łukasz Bittner Laura Chijlis Earl Orlando Jaime Pérez Rak San Gabriel Korenblit Tobiasz Dworak Sean Emerald Ghulam Mirosław Szymczyk Bhaumik Bhatt Jenius Nghia From Google+ … prithvi ganesh Evangelia Karagianni Vandy San Greg Steiert Titvirak San Joji John Varghese Week 5 - June 16, 2014: Basecamp F And the winners for week 5 are ... Evangelia Karagianni Shady Trần Kasia Michalowska Nghia Nguyen Saudin Dizdarevic Navin Bhaskar Thank you to everyone who has participated in the past five weeks of #MountainMondays – we’ve finally reached the summit of K2! Your energy, inventiveness and contributions have all been fantastic! Congratulations to all winners! We hope you enjoy your development platform and look forward to hearing about what you build using the FRDM-K64F platform. Happy designing!
記事全体を表示
中文版:     想到过使用飞思卡尔的Freedom平台当做昂贵的J-Link调试器吗,好吧,这次给你机会了,呵呵。昨天在去SEGGER官网查资料的时候看到了一个suprise,Segger刚刚为OpenSDA平台release了一个可以兼容Jlink功能的firmware。说白了,就是借用OpenSDA当做J-Link用,当然有部分功能是有所限制的,不过瑕不掩瑜,Jlink的高速、稳定及一些特有的功能一直让接触过它的开发者印象深刻,所以能用low-cost的OpenSDA实现高性能的Jlink实在是让人兴奋,包括在下,哈哈,所以还等什么,赶紧露胳膊抹袖子整整吧,呵呵~     其实这次SEGGER提供的firmware就是OpenSDA的一个Application(我已经上传到本博客最后的附件中了),类似MSD-APP和DBUG-APP等其他的OpenSDA应用,所以它的使用方法类似,具体可以参考我之前的一篇博客《尝鲜OpenSDA方式调试仿真Freedom平台》http://blog.chinaaet.com/detail/31795.html。     (1)将firmware更新到OpenSDA的平台之后,再回到normal mode,这样就可以把OpenSDA当J-Link用了。将硬件连接好之后,打开J-Link Commander,弹出的窗口如下图所示,看吧,有点如假包换的J-Link味道了吧,呵呵,而且还有正版的S/N序列号哦。     (2)当然在IAR环境下使用它还需要简单的设置几步,如下图所示,建议不使用flash loader而是使用jlink自带的调试下载引擎,更稳定且速度杠杠的,呵呵:     (3)一切都准备好之后,就可以按照J-Link的调试方法调试Kinetis了,呵呵。当然有个最大的好处是,借用J-Link的特性,使用OpenSDA也可以支持Live watch了,可以实时更新观察变量,这点灰常灰常给力,如下图: Limitations:     当然我们也会猜到SEGGER不会那么蠢到自断财路(OpenSDA平台可是非常low-cost的),不然谁还会用那么昂贵的正版J-Link啊,呵呵。所以使用SEGGER提供的这个firmware有以下几点限制: 1)只能用在飞思卡尔平台基于ARM的产品上; 2)只可以调试飞思卡尔的评估板,所以貌似如果用在自己画的板子上可能有问题; 3)还有一个比较遗憾的,那就是不支持使用J-Flash软件(我一直觉着J-Flash很好用); 4)SEGGER不提供技术支持(这个我觉着无所谓)。     总体来说,还是利好的消息的,我还是灰常灰常看好OpenSDA的应用前景的,连SEGGER都低头兼容了,看来飞思卡尔以后调试器短板有望得到弥补,加油吧,呵呵。     不聊了,附件为更新的固件,未完待续~ /*****************************************************************************************************************************************/ English Version:    It feels realy good to see that SEGGER has offered a firmware running on the FRDM OpenSDA platform which makes OpenSDA compatible to J-Link lite, allowing users to take advantage of most J-Link features. It means we can do the same things with high-performance by using the low-cost OpenSDA platform. 1) How to do?    The J-Link firmware SEGGER offered is just an OpenSDA Application, so put the FRDM board into Bootloader mode and update the firmware, which is enclosed in the attached, just like other OpenSDA applications. Then put it into normal mode and the J-Link driver will be installed. Open the J-Link Commander, and we will see the diagram below. In IAR IDE, some setup steps need to follow: 2) Why to do?     Most inland customers get used to J-Link to debug ARM based products since ARM7 time and the J-Link is realy good debugger by my experience, althougn the legal J-Link is expensive. So we can help the customer to develop and evaluata products with low-cost OpenSDA platform.    In addition, live watch in IAR, which can update the varibles in time, is only supported with J-Link engine, which is very important to customer.   3) Limitations     May be used with ARM based Freescale devices only;     Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed;     No production flash programming support;     Unlimited breakpoints in flash available for evaluation only;     No support is given. 4) Suggestions     OpenSDA is a very potential platform. USBDM has also released a firmware which is compatible to OpenSDA recently. So an open source OpenSDA  release from P&E is expected and to help customer to custom their own debugger hardware, which can help us to extend our Kinetis products more convenient. Voila, just give a try!
記事全体を表示
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....
記事全体を表示
USB secondary ISP bootloader for LPC11U68  Overview        A Secondary Bootloader (SBL) is a piece of code that allows a user application code to be downloaded using alternative channels other than the standard UART0 used by the internal bootloader (on chip). Possible secondary bootloaders can be written for USB, Ethernet, SPI, SSP, CAN, and even I/Os. The secondary bootloader utilizes IAP as a method to update the user’s application code.        The internal bootloader is the firmware that resides in the microcontroller’s boot ROM block and is executed on power-up and resets. After the boot ROM’s execution, the secondary bootloader would be executed, which will then execute the user application.      The purpose of this document is to use USB as an example for developing the secondary bootloader and the code was tested using the LPCXpresso 11U68 evaluation board.       The MSCD presents easy integration with a PC‘s operating systems. This class allows the embedded system’s flash memory space be represented as a folder in Windows/Linux. The user can update the flash with the binary image using drag and drop, so the following sections will present a guideline for development and implementation of the USB secondary bootloader design, configuration, and test.      USB secondary bootloader code is base on the USB Mass Storage Class demo. However in this application note, we do not attempt to explain how the Mass Storage Class is implemented. Fig 1 LPCXpresso Board for LPC11U68 Setup file (sbl_config.h)       This file configures the secondary bootloader. The user should change this according to their application.       Some definitions and explanation: MAX_USER_SECTOR – This parameter is device dependent. In a 256 KB device, it will be 29 sectors, however the size of the last 5 sectors become the 32 KB instead of the 4 KB, so in the application, MAX_USER_SECTOR chooses 23 (Fig 2). CRP – Code Read Protection. This parameter allows select the desired CRP level. Choosing CRP3, the primary bootloader’s entry mechanism check will be bypassed. Fig 3 for CRP details. Fig 2 Flash sectors in LPC11U68 Fig 3 Code Read Protection (CRP) Secondary bootloader entry        The boot sequence shown below is used when entering the secondary USB bootloader. Fig 4 Using an entry pin      The secondary USB bootloader will check the status of a GPIO pin to determine if it should enter into programming mode. This is the easiest way since no post processing is needed. And this secondary bootloader uses P0.16. Automatic secondary bootloader entry       If the secondary USB bootloader detects that no user application is present upon reset, it will automatically enter programming mode. ISP entry disabled     If the secondary USB bootloader detects that a user application has already been installed and that CRP is set to level 3, then it will not enter ISP mode. Bootloader size        Since the bootloader resides within user programmable flash, it should be designed as small as possible. The larger the secondary USB bootloader is the less flash space is available to the user application. By default, the USB bootloader has been designed to fit within the first two flash sectors (Sector 0-1) so that the user application can start from sector 2. Code placement in flash       The secondary bootloader is placed at the starting address 0x0 so that it will be executed by the LPC11U68 after reset. Flash programming is based on a sector-by-sector basis. This means that the code for the user application should not be stored in any of the same flash sectors as the secondary bootloader and for efficient use of the flash space, the user application should be flashed into the next available empty sector after the bootloader.        In the application, the start sector is 3 (0x0000_3000) which is used to store the user application code. User application execution        If the SW2 button is not depressed, the secondary bootloader will start the execution of the user application. Execution of the user application is performed by updating the stack pointer (SP) and program counter (PC) registers. The SP points to the new location where the user application has allocated the top of its stack .The PC on the other hand contains the location of the first executable instruction in the user application. From here on the CPU will continue normal execution and initializations specified on the user application. By default, the bootloader uses 2 flash sectors. Therefore, to utilize the remaining flash, the secondary bootloader will look for the user application at 0x00003000 Handing interrupts      The LPC11U68 contains a NVIC (Nested Vectored Interrupt Controller) that handles all interrupts. When an interrupt occurs the processor uses the vector table to locate the address of the handler.      On the LPC11U68 the vector table is located in the same area of flash memory as the secondary bootloader. The secondary bootloader is designed to be permanently resident in flash memory and therefore it is not possible to update the contents of the vector table every time a new application is downloaded.       The Cortex-M3 core allows the vector table to be remapped; however this is not the case with the Cortex-M0. Because of this, the secondary bootloader has been designed to redirect the processor to the handler listed in a vector table located in the application area of flash memory, see Fig 5. Fig 5 User application       To execute the user application the secondary USB bootloader will load the new SP and PC values into their respective registers, allowing the CPU to execute the new code correctly. Therefore, the user application must be built so that it can run from that starting address. In the application, this address is 0x00003E00. So relocate the user application storage area by following corresponding IDE’s User Guide.  Testing  Creating the binary file             In this application, I build the demos_switch_blinky which is from the LPCOpen library to create the binary which is compatible with the secondary USB bootloader. The binary see Table 1. 08 04 00 10 B5 09 00 00 07 07 00 00 9B 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A1 E1 FF EF 00 00 00 00 00 00 00 00 00 00 00 00 A7 09 00 00 00 00 00 00 00 00 00 00 E5 09 00 00 27 03 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 01 03 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E3 09 00 00 E1 09 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 38 B5 63 4C 25 68 28 07 07 D5 96 20 E0 60 61 48 00 78 00 28 01 D1 00 F0 F7 F8 20 68 0C 21 29 40 01 43 21 60 31 BD 38 B5 5A 4C A0 78 40 1C A0 70 C0 B2 65 28 34 DB 00 25 A5 70 20 78 00 28 2F D0 60 78 00 28 03 D0 02 28 16 D0 0A D3 20 E0 01 21 00 F0 CA F8 00 21 01 20 00 F0 C6 F8 00 21 02 20 13 E0 01 21 01 20 00 F0 BF F8 00 21 00 20 00 F0 BB F8 00 21 02 20 08 E0 01 21 00 F0 B5 F8 00 21 01 20 00 F0 B1 F8 00 21 01 20 00 F0 AD F8 00 E0 65 70 60 78 40 1C 60 70 C0 B2 03 28 00 DB 65 70 31 BD F8 B5 00 F0 36 F9 00 F0 C2 F8 3A 48 01 68 02 22 91 43 01 60 01 68 38 4A 0A 40 02 60 35 4F 01 20 38 70 36 48 00 68 0A 21 00 F0 2B F9 1E 21 00 F0 28 F9 40 1E 00 26 80 21 49 04 88 42 0C D2 30 49 48 60 30 48 02 68 12 02 12 0A C0 23 1B 06 13 43 03 60 8E 60 07 20 08 60 01 20 2B 49 08 60 23 4C 20 00 00 F0 18 F9 29 48 01 68 80 22 12 03 0A 43 02 60 20 68 01 21 01 43 21 60 20 68 01 21 88 43 20 60 20 68 80 21 88 43 20 60 A6 60 FA 20 80 00 60 60 20 68 40 21 01 43 21 60 20 68 80 21 01 43 21 60 20 68 80 20 80 04 1A 49 08 60 20 68 30 21 01 43 21 60 18 4D 28 78 00 28 12 D1 38 78 00 28 0E D0 00 21 00 20 00 F0 3E F8 00 21 01 20 00 F0 3A F8 00 21 02 20 00 F0 36 F8 FA 20 80 00 E0 60 3E 70 E8 7B 00 28 E6 D1 01 20 38 70 E3 E7 00 40 02 40 04 00 00 10 00 20 00 A0 FF FF FE FF 00 00 00 10 10 E0 00 E0 20 ED 00 E0 1C 80 04 40 14 82 04 40 00 E1 00 E0 01 00 00 A0 49 01 40 18 83 54 70 47 10 B5 32 4C 20 00 00 F0 BF F8 E1 21 49 02 20 00 00 F0 C7 F8 03 20 E0 60 81 20 A0 60 80 20 20 63 10 BD 00 00 03 28 00 DB 70 47 80 B5 01 23 4B 40 2D A1 0A 5C 2B A1 09 5C A0 20 00 06 FF F7 DC FF 01 BD 00 00 03 28 00 DB 70 47 10 B5 A0 21 09 06 24 A2 12 5C 92 00 89 18 8C 22 92 01 01 23 00 BF 21 A4 20 5C 83 40 8B 50 10 BD 00 00 F8 B5 FF F7 C7 FF A0 25 2D 06 28 00 00 F0 B6 F8 00 24 00 BF 18 A6 31 5D 88 00 28 18 80 22 92 01 80 18 00 BF 15 A2 12 5D 03 68 01 27 97 40 1F 43 07 60 01 23 28 00 FF F7 A9 FF 64 1C 03 2C EA DB F1 BD 00 00 80 B5 07 48 01 68 80 22 52 02 0A 43 02 60 19 22 0A A1 04 48 00 F0 98 F8 01 BD 00 00 00 80 00 40 80 80 04 40 00 40 04 40 80 B5 FF F7 E9 FF 00 F0 B1 F8 01 BD 02 02 02 00 11 10 12 00 00 03 81 00 00 04 81 00 00 05 81 00 00 08 81 00 00 09 81 00 00 0B 02 00 00 0C 02 00 00 0D 02 00 00 0E 02 00 00 12 81 00 00 13 81 00 00 17 01 00 01 09 01 00 01 0B 81 00 01 0E 81 00 01 14 82 00 01 15 82 00 01 16 81 00 01 17 82 00 01 1A 81 00 01 1B 81 00 01 1D 81 00 02 00 01 00 02 01 01 00 02 03 82 00 80 B5 00 F0 EF F8 01 49 08 60 01 BD 00 00 00 10 80 B5 03 4A 12 68 12 69 52 68 90 47 02 BD 00 00 F8 1F FF 1F 03 48 01 68 80 22 D2 05 0A 43 02 60 70 47 00 00 80 80 04 40 15 49 01 22 8A 61 0A 68 80 23 5B 01 13 43 0B 60 07 21 81 60 10 21 81 62 70 47 70 B5 04 00 0D 00 01 20 0E 49 08 60 00 F0 8F F8 06 00 29 01 FF F7 D3 FF 01 00 E0 68 80 22 02 43 E2 60 C8 B2 20 60 08 04 00 0E 60 60 E0 68 80 22 90 43 E0 60 30 00 FF F7 C2 FF 70 BD 00 00 80 80 04 40 98 80 04 40 02 48 01 68 40 22 0A 43 02 60 70 47 80 80 04 40 00 2A 00 D1 70 47 30 B4 0C 68 23 0C 25 0A E4 B2 00 2C 12 D0 02 2C 01 D0 0A D3 11 E0 ED B2 AC 00 04 19 02 2D 01 DB F4 25 00 E0 F0 25 63 51 07 E0 2D 06 AC 0D 04 19 23 66 02 E0 2D 06 AC 0D 03 51 09 1D 52 1E E0 D1 30 BC 70 47 FE E7 38 B5 20 20 00 F0 E8 F8 00 20 00 90 11 48 02 E0 00 99 49 1C 00 91 00 99 81 42 F9 DB 01 20 00 F0 1F F8 0D 48 01 68 01 24 03 22 91 43 21 43 01 60 80 20 00 F0 C7 F8 09 4D 23 20 28 60 80 20 00 F0 CB F8 68 68 C0 07 FC D5 2C 67 03 20 00 F0 10 F8 31 BD 00 00 C4 09 00 00 10 C0 03 40 08 80 04 40 42 49 FF E7 08 60 00 20 48 60 01 20 48 60 70 47 3F 49 F7 E7 43 A0 CA 05 12 0F 92 00 80 58 C9 06 C9 0E 49 1C 49 00 FF F7 49 FF 00 BD 00 B5 00 20 3B 49 03 22 8B 6E 13 40 11 D0 02 2B 11 D0 02 D3 03 2B 10 D0 00 BD 89 6B 0A 40 08 D0 01 2A 03 D0 03 2A 1A D1 31 48 00 E0 2F 48 00 68 00 BD 2D 48 00 BD C9 69 D6 E7 8B 6B 1A 40 08 D0 01 2A 03 D0 03 2A 05 D1 29 48 00 E0 27 48 00 68 00 E0 25 48 09 68 C9 06 C9 0E 49 1C 48 43 00 BD 00 00 00 00 10 B5 00 20 22 4C 03 21 A2 6E 0A 40 30 D0 02 2A 15 D0 21 D3 03 2A 2C D1 A2 6B 11 40 08 D0 01 29 03 D0 03 29 05 D1 19 48 00 E0 17 48 00 68 00 E0 14 48 21 68 C9 06 C9 0E 49 1C 48 43 19 E0 E1 69 14 A0 CA 05 12 0F 92 00 80 58 C9 06 C9 0E 49 1C 49 00 FF F7 EB FE 0C E0 A2 6B 11 40 08 D0 01 29 03 D0 03 29 05 D1 09 48 00 E0 07 48 00 68 00 E0 04 48 21 6F FF F7 DA FE 10 BD 00 00 40 80 04 40 70 80 04 40 00 1B B7 00 D0 09 00 00 D4 09 00 00 08 80 04 40 00 00 00 00 C0 27 09 00 90 05 10 00 C0 5C 15 00 F0 B3 1A 00 20 0B 20 00 00 9F 24 00 E0 32 29 00 C0 C6 2D 00 50 97 31 00 E0 67 35 00 70 38 39 00 00 09 3D 00 40 16 40 00 80 23 43 00 C0 30 46 00 0B 49 0A 68 10 43 09 4A 02 40 C8 20 00 02 10 43 08 60 70 47 06 49 0A 68 82 43 04 48 10 40 C8 22 12 02 02 43 0A 60 70 47 00 00 00 00 FF 25 00 00 38 82 04 40 70 B4 01 21 00 22 13 E0 04 68 00 1D 0C 42 02 D0 4D 46 6D 1E 64 19 22 60 24 1D 1B 1F 04 2B FA D2 25 00 9E 07 01 D5 22 80 AD 1C 0B 40 00 D0 2A 70 03 68 00 1D 00 2B E7 D1 70 BC 70 47 10 B5 07 49 79 44 18 31 06 4C 7C 44 16 34 04 E0 08 1D 0A 68 89 18 88 47 01 00 A1 42 F8 D1 10 BD 08 00 00 00 14 00 00 00 9D FF FF FF 08 00 00 00 00 00 00 10 00 00 00 00 00 F0 0B F8 00 28 01 D0 FF F7 DE FF 00 20 00 BF 00 BF FF F7 0C FD 00 F0 02 F8 01 20 70 47 80 B5 00 F0 02 F8 01 BD FE E7 07 46 38 46 00 F0 02 F8 FB E7 FE E7 20 21 09 03 26 31 18 20 AB BE F9 E7 01 48 80 47 01 48 00 47 D9 09 00 00 C5 09 00 00 00 BF 00 BF 00 BF 00 BF FF F7 D2 FF 00 1B B7 00 00 80 00 00 80 B5 FF F7 DF FD 01 BD FE E7 FE E7 FE E7                                                    Table 1 Drag and drop the binary file Running the secondary bootloader, and connect a USB cable between the PC and the J3, see Fig 6; Fig 6 Drag and drop the binary file to the driver, see Fig 7;    Fig 7 Review the values of the user application in the relative area , see Fig 8; Fig 8
記事全体を表示
Here you can find both the code and project files for the PWM project, in this example a single PWM channel belonging to the Flextimer 0 (PTC10/FTM_CH12) is enabled to provide a PWM signal with a 500ms period, the signal's duty cycle increases its period every 100ms, to visually observe the signal connect a led from the A5 pin in the J4 connector to GND (J3, pin 14). Code: #include "mbed.h" //PWM output channel PwmOut PWM1(A5); int main() {     PWM1.period_ms(500);     int x;     x=1;         while(1)     {         PWM1.pulsewidth_ms(x);         x=x+1;         wait(.1);         if(x==500)         {             x=1;         }     } }
記事全体を表示
  对于 Kinetis 芯片来说,发生在工程师调试,小批及量产阶段都经常发生的一个问题就是Kinetis Lock(锁住),尤其是在刚用这个芯片设计及小批的客户身上,这个错误几乎都会遇 到。附件中的文档将对这个问题作出详细的讨论。
記事全体を表示
When using ADCs it is not enough to just configure the module, add a clock signal, apply the Nyquist criteria and hope for the best, because normally that is just not enough. Even if we use the best software configuration, sampling rate, conversion time, etc; we might end up with noisy conversions, and worst of all a low ENOB figure which sums up in a lousy, low resolution ADC application. To complement the software end you need to follow some basic hardware design rules, some of them might seem logical, other might even weird or excessive however they are the key to a successful conversion, I took the time to compile a short list of effective design best practices trying to cover the basics of ADC design. If you think I missed something feel free to comment and ask for more information. Ground Isolation Because ground is the power return for all digital circuits and analog circuits, one of the most basic design philosophies is to isolate digital and analog grounds. If the grounds are not isolated, the return from the analog circuitry will flow through the analog ground impedance and the digital ground current will flow through the analog ground, usually the digital ground current is typically much greater than the analog ground current.  As the frequency of digital circuits increases, the noise generated on the ground increases dramatically. CMOS logic families are of the saturating type; this means the logic transitions cause large transient currents on the power supply and ground. CMOS outputs connect the power to ground through a low impedance channel during the logic transitions. Digital logic waveforms are rectangular waves which imply many higher frequency harmonic components are induced by high speed transmission lines and clock signals.                              Figure 1: Typical mixed signal circuit grounding                              Figure 2: Isolated mixed signal circuit grounding Inductive decoupling Another potential problem is the coupling of signal from one circuit to another via mutual inductance and it does not matter if you think the signals are too weak to have a real effect, the amount of coupling will depend on the strength of the interference, the mutual inductance, the area enclosed by the signal loop (which is basically an antenna), and the frequency. It will also depend primarily on the physical proximity of the loops, as well as the permeability of the material. This inductive coupling is also known as crosstalk in data lines.                               Figure 3: Coupling induced noise It may seem logical to use a single trace as the return path for the two sources (dotted lines). However, this would cause the return currents for both signals to flow through the same impedance, in addition; it will maximize the area of the interference loops and increase the mutual inductance by moving the loops close together. This will increase the mutual noise inductance and the coupling between the circuits. Routing the traces in the manner shown below minimizes the area enclosed by the loops and separates the return paths, thus separating the circuits and, in turn, minimizing the mutual noise inductance.                               Figure 4: Inductance decoupling layout Power supply decoupling The idea after power decoupling is to create a low noise environment for the analog circuitry to operate. In any given circuit the power supply pin is really in series with the output, therefore, any high frequency energy on the power line will couple to the output directly, which makes it necessary to keep this high frequency energy from entering the analog circuitry. This is done by using a small capacitor to short the high frequency signals away from the chip to the circuit’s ground line. A disadvantage of high frequency decoupling is it makes a circuit more prone to low frequency noise however it is easily solved by adding a larger capacitor. Optimal power supply decoupling A large electrolytic capacitor (10 μF – 100 μF) no more than 2 in. away from the chip. A small capacitor (0.01 μF – 0.1 μF) as close to the power pins of the chip as possible. A small ferrite bead in series with the supply pin (Optional).                               Figure 5: Power supply decoupling layout Treat signal lines as transmission lines Although signal coupling can be minimized it cannot be avoided, the best approach to effectively counteract its effects on signal lines is to channel it into a conductor of our choice, in this case the circuit’s ground is the best choice to channel the effects of inductive coupling; we can accomplish this by routing ground lines along signal lines as close as manufacturing capabilities allow. An very effective way to accomplish this is routing signals in triplets, these works for both digital and analog signals.The advantages of doing so are an improved immunity not only to inductive coupling but also immunity to external noise. Optimal routing: Routing in “triplets” (S-G-S) provide good signal coupling with relatively low impact on routing density Ground trace needs to be connected to the ground pins on the source and destination devices for the signal traces Spacing should be as close as manufacturing will allow                               Figure 6: Transmission line routing Signal acquisition circuit To improve noise immunity an external RC acquisition circuit can be added to the ADC input, it consists of a resistor in series with the ADC input and a capacitor going from the input to the circuit’s ground as the figure below shows:                                                             Figure 7: ADC with an external acquisition circuit The external RC circuit values depend on the internal characteristics and configuration of the ADC you use, such as the availability of an internal gain amplifier or the ADC’s architecture; the equation and circuit shown here represents a simplified form of ADC used in Freescale devices. The equivalent sampling resistance RSH is represented by total serial resistance connected between sampling capacitance and analog input pin (sampling switch, multiplexor switches etc.). The sampling capacitance CSH is represented by total parallel capacitance. For example in a case of Freescale SAR ADC equivalent sampling capacitance contains bank of capacitances. The equation shown how to calculate the value of the input resistor based on the values of both the input and sample and hold circuit. It must be noted the mentioned figures could have an alternate designation in any given datasheet; the ones mentioned here are specific to Kinetis devices: TAQ=      Acquisition time (.5/ADC clock) CIN=       Input capacitance (33pF min) CSH=      Sample & Hold circuit capacitance ( CDAIN in datasheet) VIN=       Input voltage level VCSH0= Initial voltage across S&H circuit (0V) VSFR=    Full scale voltage (VDDA) N=           bit resolution Note:  Special care must be taken when performing the calculation since a deviation from the correct values will result in a significant conversion error due to signal distortion.
記事全体を表示
Hi Community members! Here you can find the source code of the MSD Host Bootloader implemented on the AN4368 document using the TWR-K70F120M and CodeWarrior 10.6 and a document that describes the migration process of the original source code for the TWR-K60N512 to a TWR-K70F120M and the steps to use the application. Attached you will find a image.s19 file created to be used with the bootloader application as an example. :smileyinfo: This document and code are intended to demonstrate the use of the AN4368 source code on a 120 MHz device and CodeWarrior 10.6 but is not replacing the work done on the application note. I hope this can be helpful for you! Best Regards, Adrian :smileyplus: If it was useful for you do not forget to click on the Like button. It would be nice!
記事全体を表示
Hey there Kinetis lovers!  We in the Systems Engineering team for Kinetis Microcontrollers see all kinds of situations that customers get into, and none can be particularly troubling like how the reset pin is handled.  The purpose of this document is to provide a list of Frequency Asked Questions (FAQ) that we get here in the Kinetis Systems Engineering department.  This is intended to be a living list and as such, may in no way be complete.  However we hope that you will find the below questions and answers useful.   Q:  Do I need to connect the reset signal to be able to debug a Kinetis device?   This is a commonly asked question. Strictly speaking, you do not need to connect the device reset line of a Kinetis device to the debug connector to be able to debug. The debug port MDM-AP register allows the processor to be held in reset by means of setting the System Reset Request bit using just the SWD_CLK and SWD_DIO lines.   However, before deciding to omit the reset line from your debug connector you should give some careful thought to how this may impact the ability to program and debug the device in certain scenarios. Does the debugger/flash programmer or external debug pod require the reset pin? It may be that the specific tool you are using only supports resetting the device by means of the reset line and does not offer the ability to reset the device by means of the MDM-AP. Have you changed the default function of the debug signals? You may need to use the SWD_CLK and/or the SWD_DIO signals for some other function in your application. This is especially true in low pin count packages. Once the function is changed (by means of the PORTx_PCRy registers) you will no longer have access to the MDM-AP via those signals. If you do not have access to the reset signal then you have no way of preventing the core from executing the code that will disable the SWD function of the pins. So you will not be able to re-program the device. In order to prevent this type of situation you need to either: Setup your code to change the function of the SWD pins several seconds after reset is released so that the debugger can halt the core before this happens. Put some kind of “backdoor” mechanism in your code that does not re-program the SWD function, or re-enables the SWD function, on these pins. For example, a specific character sequence sent via a UART or SPI interface.   Some Kinetis devices allow the reset function of the reset pin to be disabled. In this case you can only use the SWD signals as a means of resetting the device via the MDM-AP. If you change the SWD pin function in addition to disabling the reset pin then you must provide a backdoor means of re-enabling the SWD function if you want to be able to reprogram the device.
記事全体を表示
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 document covers some of the more common questions about the new Kinetis K8x family. Any new specific issues or questions should be posted into it's own thread, and will be added to this document as appropriate. Kinetis K80 Basics What is the K8x family? It is a new Kinetis family of Cortex-M4F devices, running up to 150MHz, that include 256K of Flash and 256K of SRAM. It features FS USB, SDRAM, QuadSPI, SPI, I2C, LPUART, and much much more. How does the Kinetis K8x family differ from other Kinetis K families? The K8x family offers the same advantages and compatibility as other Kinetis K families, but also offers several new features not found on other Kinetis K families: QuadSPI Support Dual Voltage Domains (independent VDDIO domain down to 1.8V for QuadSPI or other interfaces) EMVSIM (Euro, MasterCard, Visa Serial Interface Module) FlexIO Additionally the K81 and K82 families offer the following new security modules: LTC (Low Power Trusted Cryptography) Encryption / Decryption algorithms in hardware (as opposed to using mmCAU s/w libs) OTFAD (On The Fly AES Decryption) Zero latency decryption when executing encrypted code from QuadSPI Secure RAM 2KB of Secure Session RAM Because of the addition of a second voltage domain and QuadSPI, there is no hardware pin compatibility with previous Kinetis derivatives. However there is significant module and enablement re-use, so if you’re familiar with other Kinetis devices, it will be easy to get started with the K80. Where can I find reference manuals, datasheets, and errata? These can be found on the K8x documentation pages. Detailed information on the K81 is under NDA, so please contact your NXP sales representative for those documents. What’s the difference between the different K8x devices? K80 is the base version, which includes QuadSPI controller, SDRAM controller, FS USB, and much more. K81 adds DryIce Tamper Detect and the LTC/OTFAD modules K82 adds just the LTC/OTFAD modules K80 and K82 families have the same pin out for their respective packages. The pinout for K81 is slightly different but can still be compatible. What boards are available to evaluate the K80 family? FRDM-K82F: A Freedom board with a 100LQFP K82 device. Also includes dual QuadSPI, touch pad, Arduino compatible footprint, and FlexIO header compatible with OV7670 camera. TWR-K80F150M: A Tower board with 121XFBGA K80 device. Includes dual QuadSPI, SDRAM, EVMSIM, SDCard holder, touch pads, and more. TWR-POS-K81: A Point of Sale reference design board in tower form factor. This board is only available via your NXP sales representative. The K8x MCU Family Hardware Tools selection guide has more details on board differences. What packages are available? The 100 LQFP and 121 XFBGA packages are lead packages available today. The 144 LQFP package and the WLCSP are part of the Package Your Way (PYW) program, and you should contact your NXP sales representative if interested in those packages. What is the difference between K8x and KL8x families? The KL8x family shares many of the same features as the K8x family. The biggest differences are that the KL8x family uses the Cortex-M0+ core (instead of Cortex-M4F), has a lower max clock speed, and has less internal Flash and RAM. It also reduces the instances of peripherals available, but still includes QuadSPI, FlexIO, LTC, and BootROM peripherals like on the K80. See the KL8x Fact Sheet for more details. KL8x devices will be available in the first quarter of 2016. Software/Tools Where can I find instructions and details on the hardware used to evaluate the K8x family? FRDM-K82F: http://nxp.com/frdm-k82f/startnow​ TWR-K80F150M: http://nxp.com/twr-k80f150m/startnow ​ Which version of Kinetis SDK supports the K8x family? Kinetis Software Development Kit (KSDK) support is split depending on the evaluation platform. For TWR-K80F150M, support can be found in the Kinetis SDK 1.3 Mainline Release. For FRDM-K82F, support can be found in the Kinetis SDK FRDM-K82F Stand-alone release. Note that the FRDM-K82 standalone release is truly standalone, and does not require the mainline release to be installed. How do I run the FRDM-K82F OV7670 camera demo? See this Community post: https://community.freescale.com/docs/DOC-329438 How can I use the micro SD card reader on the TWR-K80F150M? Because the SD card signals are shared with the QuadSPI signals, the SD card slot is not connected by default. See section 3.14 of the TWR-K80F150M User Guide for details on how to connect it, with the understanding that QuadSPI will not be available on the board while using SDHC. How do I use the SDRAM on the TWR-K80F150M? See section 3.9 of the TWR-K80F150M User Guide. Due to the layout of the board, the OpenSDA UART feature cannot be used while running the SDRAM as jumpers J6 and J8 need to be removed. QuadSPI What is QuadSPI Flash? Why should I use it? QuadSPI is a name for a popular type of serial NOR flash memory that is SPI compatible, but also allows for multiple data lines (up to 4 per device, or 8 if done in parallel) with bi-directional data for increased memory bandwidth. The QuadSPI controller on the K8x also allows for Execute-In-Place (XIP) mode so that code can be executed out of this external memory. QuadSPI memory can be used for either extra memory storage or for extra code space, or a combination of both. After initialization, it appears as a readable area of memory starting at 0x6800_0000 (as well as at the alias regions). How can I program the QuadSPI? There is an example application in Kinetis SDK that shows how to program the QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\driver_examples\qspi For programming an entire application, the ROM bootloader can be used. Details are in the K80 Bootloader Tools Package. The Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. There is also an example Kinetis SDK application that runs out of QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi_alias What performance tips are there if doing QuadSPI XIP? A few key performance factors: Ensure both the data and instruction cache is enabled Use as many data lines as possible (4, or 8 if available in dual/octal modes) Use DDR mode Any critical code should be placed in Flash/RAM for fastest performance If using XIP, code should be executed out of the QuadSPI aliased address space which starts at 0x0400_0000. A more detailed app note is under development. How do I debug code located in QuadSPI? You must make use of the aliased QuadSPI address space at 0x0400_0000. There is an example of this in the hello_world_qspi_alias example in Kinetis SDK. Due to the architecture of the M4 core on Kinetis, breakpoints cannot be set in the 6800_0000 address space, which is why the alias address space is provided. What app notes are available for the QuadSPI? Because the QuadSPI module found on the K8x family has also been used on other NXP devices, there are some app notes available that can be useful for QuadSPI development. Note that some of the implementation details and features as described in the app notes will be different for K8x, so please use the K8x reference manual for full details. AN4186​ AN4512​ AN4777​ ROM Bootloader Where can I find more information on the bootloader that comes built into the silicon of the K8x family? Download the K80 Bootloader Tools package. If interested in QuadSPI, the Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. The other information found on the Kinetis Bootloader website is also useful as this is what the ROM Bootloader is based off of. What interfaces does the ROM Bootloader support? The ROM Bootloader on the K8x family can interface via LPUART, I2C, SPI, or USB HID (via BLHost) to erase and program both the internal flash and/or QuadSPI flash. This is the same bootloader found on other Kinetis devices, but also includes some more advanced features to support QuadSPI. How can I enter bootloader mode? By default, when using a Kinetis SDK project, the bootloader is disabled and the code immediately jumps to the address in Flash pointed at location 0x4. By asserting the NMI pin at reset though, the part can be forced to enter bootloader mode. This is useful for programming the QuadSPI or interfacing with the bootloader in other ways. This feature is controlled via the FOPT[BOOTPIN_OPT] bit, which the Kinetis SDK code sets to '0' to enable the NMI pin to enter bootloader mode. The NMI button on each board is: FRDM-K82F: SW2 TWR-K80F150M: SW2 The FOPT register (at 0x40C) can be modified to always go into Bootloader mode if desired. Details are in boot chapter of the K80 reference manual. Where is the bootloader configuration data found in Kinetis SDK? The Bootloader Configuration Area (BCA), which begins at address 0x3C0, is defined in C:\Freescale\KSDK_1.3.0\platform\devices\MK80F25615\startup\system_MK80F25615.c starting on line 133. You must also add the define BOOTLOADER_CONFIG in the project settings to let the linker files know to program this BCA area. The FOPT configuration register (at 0x40D) is defined in C:\Freescale\KSDK_1.3.0_K82\platform\devices\MK82F25615\startup\<compiler>\startup_MK80F25615.s and by default is set to 0x3D which disables the bootloader, but does enable the option to enter bootloader via the NMI pin at reset (see previous question) How can I use the UART port on the FRDM-K82F with the BootROM? The OpenSDA/UART lines on the FRDM-K82F use LPUART4, which is not used by the BootROM. If you would like to use the serial UART lines to interact with the BootROM, you can blue wire a connection from either J24 or J1, and connect to R32 (RX) and R36 (TX). This was due to muxing trade-offs. The OpenSDA/UART lines on the TWR-K80F150M are connected to UART1 and thus no modification is necessary for that board. Also keep in mind that you can use the USB interface with the BLHost tool on both boards with no modification. The examples in Kinetis SDK setup the QuadSPI Configuration Block (QCB) data using a qspi_config.bin file. How can I generate my own custom QCB file? There is a C file that come as part of Kinetis SDK (C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi\qspi_config_block_generator.c) or in the KBoot zip file, that can be compiled with various toolchains on a host computer, that will then produce a .bin file. You could import this file, and then after compilation, run it, and it will write out the new .bin to your hard drive. There is a tool under development that simplifies this process by reading in that example .bin file and then you can modify the fields in the app, and then it will write out the modified .bin file. Can I jump directly to QuadSPI for Execute in Place (XiP) after booting? Yes. However note that you must still put the Bootloader Configuration Area (BCA) into internal flash. And you also may want to put the QuadSPI Configuration Block (QCB) in flash as well since it needs to be read before the QuadSPI is setup. Thus even if all your code is in QuadSPI address space, the internal flash must also be written at least once to put in the configuration data. Once you have that set though, then you can develop code by only programming the QuadSPI address space. Troubleshooting I’m having debugger connection issues when using an external debugger, like a Segger JLink. Why? It’s likely that the OpenSDA circuit is interfering, and thus needs to be isolated via jumpers on the board. For TWR-K80F150M: Pull J16 and J17 For FRDM-K82F: Pull J6 and J7 Also make sure you are using the correct debug header for the K8x device on the board: For TWR-K80F150M: J11 For FRDM-K82F: J19 Where is the CMSIS-DAP/OpenOCD debug configuration for the K8x family in Kinetis Design Studio? KDS 3.0 does not support programming the K8x family via the CMSIS-DAP interface. You will need to change the OpenSDA app on the board to either J-Link or P&E as described in the K8x Getting Started guides (Part 3). I can't get OpenSDA on the FRDM-K82F into bootloader mode. Make sure jumper J23 is on pins 1-2 to connect the reset signal to the OpenSDA circuit. On some early versions of the board this was incorrectly installed on pins 2-3 instead. When using IAR with the default CMSIS-DAP debug interface, I sometimes get the error: “Fatal error: CPU did not power up” This is an issue in some older versions of IAR. Upgrade to at least version 7.40.5 which fixes this. When using KDS with the JLink interface with the FRDM-K82F board, I get an error. If you see the error "The selected device 'MK82FN256XXX15' is unknown to this version of the J-Link software." it's because the J-Link driver that comes with KDS 3.0.0 does not know about the K82 family. You can either select a MK80FN256XXX15 device (which is compatible with the K82 on the board) or update the JLink software by downloading and installing the latest JLink Software and documentation pack. At the end of the installation process it will ask to update the DLLs used by the IDEs installed on your computer, so make sure to check the KDS checkbox on that screen. I’m using the P&E OpenSDA App and debugging is not working. I get either "Error reading data from OpenSDA hardware. E17925" or “The system tried to join a drive to a directory on a joined drive” in KDS If using IAR, make sure you have the latest version (7.40.7 or later) If using KDS, you need to update the P&E plugin in KDS. Go to Help->Check for Updates, and select the P&E debug update. Make sure not to select the other debugger updates as it will break it in KDS 3.0.0 (see this thread)
記事全体を表示
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
記事全体を表示
Hello Kinetis fans, This time I bring to you a document which explains what is and how to configure channel linking feature which is present in the Enhanced Direct Memory Access (eDMA). If you are interested in the scatter/gather feature, please take a look into the document What is and how to configure the eDMA scatter/gather feature. I hope you find this document useful. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors
記事全体を表示
FINALISTAS Después de un profundo análisis de todos los proyectos, nuestros jueces realizaron la difícil selección de los finalistas del Kinetis L MCU Challenge México entre los que el público elegirá al ganador; gracias a la excelente respuesta decidimos nombrar 16 finalistas.  Ellos son: Project Name Contestan Name Description Video Sistema de monitoreo de la contaminación acústica #MonitoreoAcustico Lucio Canche Diseño de una placa para monitoreo de niveles de ruido utilizando un sensor de sonido. Permite el estudio detallado de los patrones de propagación del sonido. Movimiento de un carro controlado #CarroPelotasAntiestres Emilio Jiménez Auto de juguete controlado por medio de pulsaciones realizadas con 2 pelotas anti-estrés, el presionar una pelota hará que el vehículo avance hacia adelante y la otra hará que gire sobre su propio eje. Viking lever #VikingLever Ma. Fernanda Gutierrez Consiste en un sistema de una palanca con contrapeso; tendrá en la punta una pelota con una led que indicará cuando el usuario tiene que golpearla. Controlador para el suministro de agua de una vivienda #ControladorAgua Rogelio Rosales El objetivo es el ahorro de agua. En un tinaco se colocan 2 sensores, uno a nivel alto y el otro a nivel bajo de agua. Dependiendo del nivel del agua los sensores mandan la señal a la bomba para que se encienda o apague. Rehab glove #RehabGlove Alexis Castañón Guante que posee sensores de flexión en las articulaciones de los dedos y de fuerza en las yemas, con el fin de enviar instrucciones a algún aparato, mientras el usuario realiza ejercicios como cerrar el puño o tocar las yemas de los dedos con el pulgar. Tablet braile para invidentes #TabletBraille Andres Gafford Tableta para leer ebooks braile con botones para cambiar de página, apagar y encender, que sean fáciles de percatar por un invidente; así como botones interactivos que desplieguen opciones del menú. Tapete interactivo para discapacitados #TapeteInteractivo Angel Campoy Este tapete interactivo, contribuye al desarrollo motriz. El teclado cuenta con cuatro botones, los cuales tienen un led que se enciende indicando al paciente que debe presionar el boton. Si activo el boton indicado,se enciende un LED verde o rojo si se equivocó. Neck remote control wheel chair #NeckControl Francisco Javier Pérez Corona Silla de ruedas controlada moviendo el cuello a la izquierda o derecha, presionando un botón con la cabeza, que a su vez haga avanzar o girar. Control de sensores infrarrojos para silla de ruedas #SensoresSilla Jesús Lizárraga Silla de ruedas diseñado para personas con parálisis cerebral. El usuario debe colocar las dos manos al ifgual que los codos por encima de los espacios indicados, los sensores se activarán haciendo que la silla avance o gire hacia el lado en que la persona posicionó la mano. N-drid uleta #NdridRuleta Jorge Rodriguez Rodriguez Juego de ruleta de leds de 4 colores, el usuario acumulará puntos cada vez que logre presionar el botón del color en donde parará la ruleta. KMA #KMA Luis Castellanos Prototipo para silla de ruedas que será controlada con un dispositivo de fácil manejo,  comunicado a la silla por bluethooth. Sensilla #Sensilla Miguel Rogel Silla móvil manipulada por sensores y con esto lograr desplazarse de una manera más accesible a sus capacidades. Pest control using Freescale #PestControl Pablo Yerena Este proyecto consiste en el control de plagas de manera ecológica, con la implementación de un aparato electrónico que emite frecuencias ultrasónicas evitando que animales e insectos invadan espacios físicos. Tren de colores musical #TrenColores Ricardo Villaseñor Juguete donde se utiliza un sensor óptico para la lectura de pequeños cubos de colores, donde cada color es una nota musical. Al colocar el lector sobre el cubo de color se emitirá la nota correspondiente. Morse deaf-mute communication system #MorseDeafMute Roberto Vite Ruiz Dispositivo de escritura basado en el código morse. Se muestra un código morse para cada letra del alfabeto permitiendo a una persona sorda o muda darse a entender de manera escrita.       Casco acelerómetro #CascoAcelerometro José Ramón Rodriguez Dispositivo  para silla de ruedas que  permite al paciente transportarse autónomamente mediante una especie de casco que detecte la dirección deseada, además de que sea una manera recreativa de trasladarse Podrás participar calificando cada proyecto a través de redes sociales y la herramienta RankTab; la votación se abrirá el día del evento a partir de las 9:00am, espera las instrucciones a través de la Comunidad Freescale,  Facebook y durante el evento. A todos los finalistas los esperamos el 07 de Diciembre a las 8:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara, donde se develará el misterio y conoceremos al ganador del viaje al Freescale Technology Forum (FTF) en Dallas, Texas del 08 al 11 de Abril del 2014. Para solicitar mayor información, favor de enviar un correo a cristina.garcia@mclgx.comA
記事全体を表示
Since the mbed Ethernet library and interface for FRDM-K64 have not yet been fully tested, instead of using mbed we will use one of the latest demo codes from MQX specifically developed for the FRDM-K64 platform. Before starting please make sure you have the following files and software installed in your computer: CodeWarrior 10.6 (professional or evaluation edition) MQX 4.1 for FRDM-K64 (it is not necessary to install full MQX 4.1) JLink_OpenSDA_V2.bin (this is the debugger application) * If you don't have a valid license, you can find a temporary license below, it will only be valid until 7/30/2014 and it will only be available online until 7/05/2014. Building the project The first step to use an MQX project is to compile the target/IDE libraries for the specific platform: 1. Open CodeWarrior and drag the file from the following path C:\Freescale\Freescale_MQX_4_1_FRDMK64F\build\frdmk64f\cw10gcc onto your project area: This will load all the necessary libraries to build the project, once they are loaded build them it is necessary to modify a couple of paths on the BSP: 2. Right click on the BSP project and then click on properties 3. Once the properties are displayed, expand the C/C++ Build option, click on settings, on the right pane expand the ARM Ltd Windows GCC Assembler and select the directories folder, this will display all the libraries paths the compiler is using 4. Double click on the "C\Freescale\CW MCU v10.6\MCU\ProcessorExpert\lib\Kinetis\pdd_100331\inc" path to modify it, once the editor window is open, change the path from "pdd_100331" to "pdd" 5. Repeat steps 2 and 3 for the ARM Ltd Windows GCC Compiler 6. Now you can build the libraries, build them one at a time by right clicking on the library and selecting build project, build them in the following order, it is imperative you do it in that order. BSP PSP MFS RTCS SHELL USBD USBH 7. Once all the libraries are built, import the web hvac demo, do it by dragging the .project file to your project area; the project is located in the following directory:                     C:\Freescale\Freescale_MQX_4_1_FRDMK64F\demo\web_hvac\build\cw10gcc\web_hvac_frdmk64f 8. Once the project is loaded, build it by right clicking on the project folder and select Build project Debugging the project To debug the project it is necessary to update the FRDM-K64 debugging application: Press the reset button on the board and connect the USB cable Once the board enumerates as "BOOTLOADER" copy the JLink_OpenSDA_vs.bin file to the unit Disconnect and reconnect the board On CodeWarrior (having previously compiled the libraries and project) click on debug configurations 5. Select the connection and click on debug 6. Open HVAC.h and change the IP Address to 192.168.1.202 Now the demo code has been downloaded to the platform you will need the following to access all the demo features: Router Ethernet Cable Serial Terminal The code enables a shell access through the serial terminal, it also provides web server access with a series of options to simulate an Heating Air Conditioning Ventilation System, the system was implemented using MQX and a series of tasks, for more details on how the task are created, the information regarding how to modify the code please check the attached document: Freescale MQX RTOS Example guide.
記事全体を表示
You can put the code directory in the SDK_2.6.0_FRDM-K64F\boards\frdmk64f to use. 1、Introduction As is known to all, we use debugger to download the program or debug the device. FRDMK64 have the opsenSDA interface on the board, so wo do not need other’s debugger. But if we want to design a board without debugger but can download the program, we can use the bootloader. The bootloader is a small program designed to update the program with the interface such as UART,I2C,SPI and so on. This document will describe a simple bootloader based on the FRDMK64F.The board uses SD card to update the application. User can put the binary file into the card. When the card insert to the board ,the board will update the application automatically. The bootloader code and application code are all provided so that you can test it on your own board.   2、Bootloader’s implementation   The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK.You can download the SDK in our website. The link is “mcuxpresso.nxp.com”. The bootloader uses SDHC and fafts file system. So we should add files to support it.                   Figure 2.The support file   In main code, the program will wait until the card has inserted. Then it will find the file named “a000.bin” in sd card to update the application. If the file do not exist, the board will directly execute the application. If there is no application, the program will end. The following code shows how the program wait for inserting sd card. It will also check if the address has the application’s address.                      Figure 3.The code -- wait for inserting card   The following code shows how the program opens the binary file. If sd card doesn’t have the file, the program will go to the application. Figure 4.Open the binary file   If the program opens the file normally, the update will begin. It will erase 200k’s space from 0xa000. You can adjust it according to your project. Now I will explain update’s method in detail. Our data is written to the buffer called “rBUff”. The buffer size is 4K. Before write data to it, it is cleared.  Please note that when we erase or program the flash, we should disable all interrupts and when the operations finish we should enable the interrupts.  The file size will decide which way to write the data to flash.  1、If the size < 4k ,we just read the file’s data to buffer and judge if its size aligned with 8 byte. If not , we increase the size of “readSize” to read more data in our data buffer called “rBuffer”. The more data we read is just 0.    2、If the size > 4K, we use “remainSize” to record how much data is left. We read 4k each time until its size is smaller than 4k and then repeat step 1. When finish the operation at a  time, we should clear the buffer and increase the sector numer to prepare the next transmission. Figure 5.Write flash operation code   The way to clear the space is shown in the figure. It will initialize the flash and erase the given size from the given address.  “SectorNum” is used to show which sector to erase. Figure 6.Erase operation code   The following figure shows how to write the data to flash.              Figure 7.Program operation code    Before we go to the application, we should modify the configuration we did in the bootloader.     Close the systick, clear its value.     Set the VTOR to default value.     Our bootloader runs in PEE mode. So we should change it to FEI mode.     Disable the all pins. You should disable the global interrupt when run these codes. And don’t forget to enable the global interrupt. Figure 8.Deinitalization code   Then we can go to the application. Figure 9.Go to Application   3、Memory relocation The FRDMK64 has the 1M flash, from 0x00000000 to 0x00100000.As shown in figure 10,we use the 0xa000 as the application’s start address.            Figure 10.The memory map   Now, I will show you how to modify the link file for user application in different IDE. In IAR                                    Figure 11.IAR’s ICF In MDK Figure 12.MDK’s SCF   In MCUXpresso Figure 13.MCUXpresso’s flash configuration 4、Run the demo 1) Download the bootloader first. 2) Prepare a user application program. We use the “led blinky” as an example. 3) Modify the Link file. 4) Generate the binary file with your IDE, please name it as “a000.bin”. 5) Put it into the sd card like figure 5. Figure 14.SD card’s content        6) Insert the card. And power on. Wait for a moment, the application will execute automatically. 5、Reference 1) Kinetis MCU的bootloader解决方案 2) KEA128_can_bootloader
記事全体を表示
The FRDM-KL25Z is an ultra-low-cost development platform enabled by Kinetis L Series KL1 and KL2 MCUs families built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL25Z is supported by a range of Freescale and third-party development software. Features MKL25Z128VLK4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP Capacitive touch “slider,” MMA8451Q accelerometer, tri-color LED Easy access to MCU I/O Sophisticated OpenSDA debug interface Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps P&E Multilink interface provides run-control debugging and compatibility with IDE tools Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit Take a look at these application notes: USB DFU boot loader for MCUs Developer’s Serial Bootloader. Low Cost Universal Motor Drive Using Kinetis L family . Writing your First MQXLite Application Learn more...
記事全体を表示
Introduction The K32L3A60VPJ1AT MCU is a next generation Kinetis dual core device.  This device brings processing and multi-tasking capabilities that legacy Kinetis devices did not support.  In addition, the K32L3A60VPJ1AT offers improved power consumption and security features.   Some important aspects of these security features lie in a nonvolatile information register (IFR) memory region and how this region is programmed.  The IFR memory region is a memory space with restricted access separate from the main array and is comprised of an erasable IFR region and a non-erasable IFR region.  The non-erasable IFR region contains the program once identifier and the version identifier.  The erasable IFR region holds the flash security, flash options, mass erase enable, and other such features that governs how the device behaves.  In legacy Kinetis devices, certain fields of the main flash array (flash addresses 0x400 - 0x40F) configured the IFR at boot time.  In the K32L3A60VPJ1AT however, the IFR memory region is no longer controlled in this manner.  This presents challenges when trying to configure these settings.  The purpose of this document is to explain how these settings can be changed and provide some options of how to make these changes.   IFR Field Programming Process The first step in configuring the IFR fields is understanding how the these fields are programmed via the hardware. IFR fields are programmed using a special flash command called the Program Index Command. Once programmed, the flash configuration values cannot be reprogrammed without first erasing these fields.  The only way to erase these values is via a mass erase.  This provides security in that the IFR values cannot be changed without erasing the user code as well.  In addition, changes to the user code image cannot affect the bootloader operation, ensuring that a secure boot function can be executed.  The procedure for writing the erasable IFR values is described here:   Write FCCOB0 with the Program Index command (0x43). Write FCCOB1 with the Index to be programmed. The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 and FCCOB3 with 0x00 as they are not used with this command.  Write FCCOB4 - FCCOBB with the desired value.  (Note that not all of the indexes use all of the FCCOB fields.  Be sure to consult the Erasable IFR Map table for which FCCOB fields are used for the index you are programming). NOTE:  For 2 byte IFR fields that map to 2 bit wide register bit fields (i.e., SEC0, FSLACC, MEEN, and KEYEN fields which map to the FSEC register bit fields), the lower FCCOB register maps to the LSB of the bit field and the upper FCCOB register maps to the MSB of the bit field.  For example, to write 0b'10 to the FSEC field, FCCOB6 should be written to 0xFF and FCCOB7 should be written to 0x00 before executing the Flash command.  Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. (Note that this command MUST be a byte write.) Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the typical Program Index command completion time of 110us.)   After the IFR has been programmed, the IFR should be read back to verify that it completed correctly.  The process for this is as follows:   Write FCCOB0 with the Read Index command (0x41). Write FCCOB1 with the Index to be read.  The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 - FCCOBB with 0. The results will be stored in FCCOB4 - FCCOBB so, these should be cleared to ensure correct results are received. Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. Note that this command MUST be a byte write. Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the maximum Read Index command completion time of 35us.)   When using the Program Index Command, you must know which index you want to modify to create the correct flash commands.  The index list can be found in the IFR descriptions section of the Flash chapter in the K32L3A60VPJ1AT reference manual.     There are several different options for programming the FOPT fields. These options are: Using the Kinetis Flash Tool  Using blhost Debugger script Subroutine in user software   Option #1: Kinetis Flash Tool Using the Kinetis Flash Tool is likely the most convenient method to change the IFR values.  The Kinetis Flash Tool uses either the UART or USB protocol to interface with the K32L3A6 bootloader and write the IFR fields desired. One of the biggest advantages for the Kinetis Flash Tool is that it provides a graphical interface for users to easily program the IFR fields. The following figure is a picture of the Kinetis Flash Tool and highlights the important input controls and tabs to be used when programming the IFR fields:     This field is the Port set box.  It selects the interface (UART or USB) to be used when communicating to the bootloader.  This box also allows for configuration of the interface.  Consult the K32L3A6 reference manual for default configurations.   This is the Flash Utilities tab.  Select this tab to see the controls shown in this image.  This is the Index input field.  The Index of the IFR to program should be entered here.  This is the Hex digits field.  This value will be programmed at the IFR Index indicated in the Index field. The value here should be in hex format WITHOUT the preceding "0x".  Note that this will write to the FCCOBs in descending order.  For example, to write 0b'10 to the KEYEN field, FFFFFF00 should be written to the Hex digits field. Refer to the programming process outlined in the IFR Field Programming Process in this document for more information.    This is the Byte Count field.  This tells the utility how many bytes to program and must be the byte count of that IFR field.  Consult the Erasable IFR Map table in the reference manual for the value of the specific IFR index to be programmed.   This is the Program button.  After all of the fields have been filled out, click this button to program the desired IFR location.    Option #2: BLHOST The MCUBoot package also includes a command line executable to interface with the bootloader.  This tool, blhost, can be used to program the IFR fields as well.  The "flash-program-once" command should be used to program the desired IFR location.  The syntax of this command is as follows:   flash-program-once <index> <byteCount> <data>   So for example, if you want to program the FOPT IFR field (record index 0x84) with 0xFFFFF3FF, the correct syntax using this command would be   flash-program-once 0x84 4 FFFFF3FF   After programming, the "flash-read-once" command can be used to read back and verify the programmed IFR field(s).  Below is an example using the previous IFR locations   flash-read-once 0x84 4   Below is a full example of erasing the device, programming the FOPT IFR, and reading the FOPT IFR back from the command line using blhost.     When Programming two byte fields, blhost orders the bytes in descending FCCOBx order (just like the Kinetis Flash Tool).  The blhost utility also requires the input to be 4 or 8 byte aligned, but the flash-program-once command only uses the last 2 bytes.  The upper 4 bytes can be padded with 0's or F's. For example, to write the KEYEN field such that the KEYEN bit field is 0b'10, the command would be as follows: flash-program-once 0x83 4 FFFFFF00 Below is a full example of using the blhost command line to erase the device, program the KEYEN IFR, read the KEYEN IFR back, and evaluate the FSEC bit field using the Attach to Running Target function in a debugger.     After executing a pin reset and attaching to the running target:     Option #3: Debugger Script A simple debugger script is another convenient way to write the IFR values.  Debugger scripts are executed in the background of the debug session initiation process (therefore are hidden operations from the user) and typically can be edited easily using any text editor.  However, it can be cumbersome to change the value because this generally must done manually with each programming by the user. With that in mind, it is a good idea to have different connect scripts for different configurations   The first step in using a debugger script is writing a debugger script.  The capabilities and syntax of a debugger script are dependent on your toolchain. For the purposes of this document, we will focus on MCUXpresso IDE.  MCUXpresso IDE uses the PokeXX and PeekXX (where XX is 8, 16, or 32 depending on whether you want to byte access, half-word or word access to the desired register) commands, which are debugger agnostic. So the same commands that work on a device will continue to work whether you are debugging with a JLink or CMSIS-DAP, or whatever other debugger you are using. Below is an example of a MCUXpresso connect script which writes the FOPT register and then reads it back for printing to the debug log.    5140 REM ====================Program FOPT=================================== 5150 Poke32 this 0x40023004 0x43840000 5160 REM Stuff FCCOB registers with desired FOPT value 5170 Poke32 this 0x40023008 v% 5171 s% = Peek32 this 0x40023008 5172 Print "New Val ";~s% 5180 Poke32 this 0x4002300c 0x00000000 5180 Poke8 this 0x40023000 0x70 5190 Poke8 this 0x40023000 0x80 5200 wait 1000 6000 REM ================== Read FOPT ===================================== 6001 REM Now read the FOPT back 6010 Poke32 this 0x40023004 0x41840000 6020 Poke32 this 0x40023008 0x00000000 6030 Poke32 this 0x4002300c 0x00000000 6040 Poke8 this 0x40023000 0x70 6050 Poke8 this 0x40023000 0x80 6060 wait 1000 6070 s% = Peek32 this 0x40023008 6080 Print "New FOPT Val ";~s%   Note in the above script that v% is the desired FOPT value and it has been defined in sections of the script not shown (at line 164).    162 REM This is the value to be written to the FOPT 164 v% = 0xfffff3ff   After the script is written, MCUXpresso must be told to use the connect script.  This is done in the Debug Configurations window.  Assuming a debug configuration has already been created, click on the arrow next to the green bug icon and select Debug Configurations.       In the resulting dialog box, select the debug configuration you want to use, and select the Linkserver Debug tab.  In the Connect Script field, point MCUXpresso to the location of your connect script.       That's all that needs to be done in the IDE. The selected debug configuration should now be using the script which was written.     Some debuggers will allow standalone command line running of a script, such as a JLink debugger.  As the JLink is one of the more popular external debuggers that we encounter, an example of programming using this script has been provided below.     // Now Program the FOPT w4 0x40023004, 0x43840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0xfffff3ff // Write 0xFFFF_1FFF to boot the M4 from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Now Read the FOPT back w4 0x40023004, 0x41840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0x00000000 // Write 0xFFFF_F1FF to boot the M0+ from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Read the memory back to verify the FOPT settings that should be present after reset. mem32 40023000,4     Option #4: Subroutine in User Software Occasionally the requirements of your system will prevent implementation of any of the above methods to program the IFR values.  In these cases, you may need to implement your own subroutine to program the IFR.  The procedure to do this is essentially the same as in the debugger script methods, just written in code instead of an external script.  The flash drivers provided in the SDK aid in this process.  One key to remember is that you likely will need to erase the entire flash.  So this subroutine and flash drivers should be placed in RAM memory.  The SDK flash drivers also operate a little differently from the Kinetis flash tool and blhost.  The FCCOB registers will be loaded in ascending order.  For example, to write 0b'10 to the SEC0 bit field in the FSEC register, the command would be: result = FLASH_ProgramOnce(&s_flashDriver, 0x80, ifr2write, 0x2); where ifr2write is an array defined as uint8_t ifr2write[2] = {0x00, 0xFF}; The above will result in 0x00 being loaded to FCCOB6 and 0xFF being loaded to FCCOB7 and SEC0 will then be 0b'10 on the reset after the command is successfully executed.   Conclusion In summary, the IFR registers are nonvolatile information registers that govern certain behaviors of the K32L3A MCU.  The IFR is dividing into an erasable IFR space and non-erasable IFR space, both of which are not a part of the main flash array.  Programming these values requires the use of special flash commands and requires that these values haven't been previously written since the last mass erase.  There are, in general, four different methods of programming the FOPT register settings.  The four methods are:   Kinetis Flash Tool BLhost command line interface Debugger script  User software subroutine   Each method has its advantages, therefore, you should pick the one that meets your needs and is most convenient. However with any of the methods chosen, the IFR values must not have been programmed before writing erasable IFR fields. It is best to perform a mass erase (which can be done using any of the methods presented in this document) before attempting to program any IFR fields.     
記事全体を表示
下面简单介绍下Kinetis M0+相关的几大系列MCU: 1. Kinetis L    Kinetis L系列MCU的最大特点是它具有非常出色的低功耗特性,L系列目前包含KL0X、KL1X、KL2X、KL3X、KL4X和KL8X六个子系列,除了KL8X的主频为72 Mhz以外,其他主频都为48 Mhz。KL0X系列是入门级MCU,它的Flash相对较小,引脚数量相对较少。KL1X系列是通用型MCU,KL2X系列带有USB功能,KL3X系列支持段式LCD,KL4X系列同时带有USB和支持段式LCD。KL8X系列具有很多Security相关的特性,包括篡改检测、真正的随机数生成器和低功耗可信加密引擎,支持AES、DES、3DES、SHA、RSA和ECC。 2. Kinetis E    Kinetis E系列MCU的最大优势是电磁抗噪性能,Kinetis E系列是业界首款在Cortex M0+基础上构建5V (2.7~5.5V)MCU系统的产品,结合了低成本、高性能、先进的EMC和ESD保护功能,E系列目前包括KE02、KE04和KE06三个子系列,KE02主频有20M和40M两种,KE04和KE06都为48M,KE06相比KE02和KE04主要是多了1个CAN接口。 3. Kinetis V    Kinetis V系列MCU专为BLDC、PMSM和ACIM电机控制以及数字电源转换应用而设计。V系列目前包含KV1X、KV3X、KV4X和KV5X四 个系列,其中Kinetis KV1X系列是入门级产品,Cortex-M0+内核,采用75 MHz M0+内核及硬件平方根和除法模块,与同等级32位MCU相比,在无传感器PMSM控制应用中的性能提高27%。 4. Kinetis W Kinetis W系列集成了领先的Sub-GHz和2.4 GHz射频收发器,可创建可靠、安全、低功耗的嵌入式无线解决方案。W系列目前包含KW0X、KW2X 、KW3X和KW4X四个系列,其中KW0X是M0+内核,48 Mhz,Sub-GHz无线电,超低功耗无线微控制器,KW3X是M0+内核,48 Mhz,具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1射频连接。KW4X也是M0+内核,具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1和IEEE® 802.15.4-2011射频连接。 5. Kinetis M      Kinetis M系列 MCU适用于单芯片1、2和3相电表和流量计,以及其它高精度测量应用。M系列目前包括KM1X、KM2X两个系列,KM1X主要用作计量,KM3X不仅具有计量功能,同时还有段式LCD控制器。 选型的方法主要有以下几种: 1)如果您已经知道要查找的产品的基本信息,最常用的方法是在飞思卡尔官网主页进行查找; 2)如果您并不清楚需要查找的芯片基本信息,飞思卡尔还提供了一些辅助的选型工具来帮助用户进行芯片的选型,包括:i)参数选型工具;   ii)选型神器Cross Check;  iii)解决方案顾问; 具体的选型操作流程可以参考:针对飞思卡尔单片机的快速上手指南中的2.2小节,其中有非常详细的介绍。
記事全体を表示