Encrypted QuadSPI image Implementation       The Kinetis family of MCU includes the system security and flash protection features that can be used to protect code and data from unauthorized access or modification. This application note discusses the usage of encrypted boot with the KBOOT and experiment with the FRDM-K82 board. FRDM-K82 board

As we know, uC/OS –II is a scalable, ROMable, preemptive real-time kernel that manages multiple tasks and it has been ported to more than 45 CPU architectures.  In this article, you can learn the steps of porting uC/OS –II to MAPS-22. Downloading uC/OS-II source code and application project To obtain the μC/OS-II source code and projects, simply point your favorite browser to: www.Micrium.com/Books/Micrium-uCOS-II. You will be required to register. This means that you’ll have to provide information about yourself. Download and execute the following file: Micrium-Book-uCOS-II-TWR-K53N512.exe. Fig 1 shows the directory structure created by this executable. All files are placed under the \Micrium directory. There are two main sub-directories: \Examples and \Software and they are described below. Fig 1 Directories and Files μC/OS-II is fairly easy to use once it is understood exactly which source files are needed to make up a μC/OS-II-based application. Fig 2 shows the μC/OS-II architecture and its relationship with hardware. Of course, in addition to the timer and interrupt controller, hardware would most likely contain such other devices as Universal Asynchronous Receiver Transmitters (UARTs), Analog to Digital Converters (ADCs), Ethernet controller(s) and more. Fig 2 F2-(1) The application code consists of project or product files. For convenience, these are simply called app.c and app.h, however an application can contain any number of files that do not have to be called app.*. The application code is typically where one would find the main(). F2-(2) The Board Support Package (BSP) code needed by μC/OS-II is typically quite simple and generally, μC/OS-II only requires that you initialize a periodic interrupt source which is used for time delays and timeouts. This functionality can be placed in a file called bsp.c along with its corresponding header file, bsp.h. Semiconductor manufacturers often provide library functions in source form for accessing the peripherals on their CPU or MCU. These libraries are also part of the BSP. F2-(3) This is the μC/OS-II processor-independent code. This code is written in highly portable ANSI C. F2-(4) This is the μC/OS-II code that is adapted to a specific CPU architecture and is called a port. F2-(5) Configuration files are used to define μC/OS-II features (os_cfg.h) to include in the application, specify the size of certain variables and data structures expected by μC/OS-II, such as idle task stack size and tick rate among others. Below is a summary of all directories and files involved in a μC/OS-II-based project (Fig 3). The“<-Cfg” on the far right indicates that these files are typically copied into the application directory and edited based on the project requirements. Fig 3 Porting Steps 1. Copy uC/OS-II source code to ~\MAPSK22_SC\Libraries which includes peripheral driver files, startup code and devices header 2. Copy os_cfg.h, app_cfg.h which reside in ~\Micrium-Book-uCOS-II-TWR-K53N512\Micrium\Examples\Freescale\TWR-K53N512\(project name) to ~\MAPSK22_SC\Project\MAPSK22\1-Template\src Summary: configuration files os_cfg.h, app_cfg.h should be adapt to the specific requirements of the application code 3. Copy lib_def.h which resides in ~\Micrium\Software\uC-LIB to ~\MAPSK22_SC\Libraries\drivers\K\inc 4. Adds systick timer initialization function in system_MK22F51212.c void SystemTickInit (void) {   uint32_t cpu_clk_freq;   uint32_t cnts;   cpu_clk_freq = SystemCoreClock;    cnts  = cpu_clk_freq / (uint32_t)OS_TICKS_PER_SEC;            OS_CPU_SysTickInit(cnts);     5. Modify the interrupt vector 6. Create uC/OS-II group in the workspace, then add the uC/OS-II source code and os_cfg.h, app_cfg.h 7. Add application code in the main.c and please check the attachment. 8. Modify the Include Directories    Run the uC/OS-II application After build the modified application code, then run it on MAPS-K22 board(Fig 4). Fig 4 You can find the LED3 and LED4 flash every 2s, however for the LED1 and LED2, it’s 1s. And some informations’re illustrated in the Hyper Terminal (Fig 5)

With the merger of NXP and Freescale, the NXP USB VID/PID program, which was previously deployed on LPC Microcontrollers, has been extended to Kinetis Microcontrollers and i.MX Application Processors. The USB VID/PID Program enables NXP customers without USB-IF membership to obtain free PIDs under the NXP VID. What is USB VID/PID Program? The NXP USB VID program will allow users to apply for the NXP VID and get up to 3 FREE PIDs. For more details, please review the application form and associated FAQ below. Steps to apply for the NXP USB VID/PID Program Step 1: Fill the application form with all relevant details including contact information. Step 2: NXP will review the application and if approved, will issue you the PIDs within 4 weeks FAQ for the USB VID/PID Program Can I use this VID for any microcontroller in the NXP portfolio? >> No. This program is intended only for the Cortex M based series of LPC Microcontrollers and Kinetis Microcontrollers, and Cortex A based series of i.MX Application Processors. What are the benefits of using the NXP VID/PID Program? >> USB-IF membership not required >> Useful for low volume production runs that do not exceed 10,000 units >> Quick time to market Can I use the NXP VID and issued PID/s for USB certification? >> You may submit a product using the NXP VID and issued PID/s for compliance testing to qualify to use the Certified USB logo in conjunction with the product, but you must provide written authorization to use the VID from NXP at the time of registration of your product for USB certification. Additionally, subject to prior approval by USB-IF, you can use the NXP VID and assigned PID/s for the purpose of verifying or enabling interoperability. What are the drawbacks of using the NXP VID/PID program? >> Production run cannot exceed 10,000 units. See NXP VID application for more details. >> Up to 3 PIDs can be issued from NXP per customer. If more than 3 PIDs are needed, you have to get your own VID from usb.org: http://www.usb.org/developers/vendor/ >> The USB integrators list is only visible to people who are members of USB-IF. NXP has full control on selecting which products will be visible on the USB integrators list. How do I get the VID if I don't use NXP’s VID? >> You can get your own VID from usb.org. Please visit http://www.usb.org/developers/vendor/ Do I also get the license to use the USB-IF’s trademarked and licensed logo if I use the NXP VID? >> No. No other privileges are provided other than those listed in the NXP legal agreement. If you wish to use USB-IF’s trademarked and licensed USB logo, please follow the below steps:                 1. The company must be a USB vendor (i.e. obtain a USB vendor ID).                 2. The company must execute the USB-IF Trademark License Agreement.                 3. The product bearing the logo must successfully pass USB-IF Compliance Testing and appear on the Integrators List under that company’s name. Can I submit my product for compliance testing using the NXP VID and assigned PIDs? >> Yes, you would be able to submit your products for USB-IF certification by using the NXP VID and assigned PID. However, if the product passes the compliance test and gets certified, it will be listed under “NXP Semiconductors” in the Integrators list. Also, you will not have access to use any of the USB-IF trademarked and licensed USB logos. How long does it take to obtain the PID from NXP? >> It can take up to 4 weeks to get the PIDs from NXP once the application is submitted. Are there any restrictions on the types of devices that can be developed using the NXP issued PIDs? >> This service requireds the USB microcontroller to be NXP products. Can I choose/request for a specific PID for my application? >> No. NXP will not be able to accommodate such requests.

分享自China-FAE team同事，在此谢过！ 有客户需要bootloader功能，于是从网上下到最新版本的AN2295，发现里面添加了很多的内容，包括支持了很多新的器件，比如KM系列，但是真正把它在板子上跑起来，却花了2天时间，为了减少大家工作量，不在重蹈覆辙，我在这里share给大家，目前该代码在FRDM_KL25以及TWR-K60D100M上跑起来了。遇到的问题主要有如下几点： 问题1： 在工程中使用除法命令： a =a /100; 会报错： Error[Li005]: no definition for "__aeabi_uidiv" [referenced from D:\Customer\XinRuiYang\an2295sw_Kl25\src\Kinetis\IAR_6_4\Kinetis L Debug\Obj\bootloader.o] 原因是： 这里Lib选择的是None，说明没有使用任何库，所以不能使用除法。 打开库后，可能会占用比较大的空间，所以不推荐使用。 问题2： FRDM_KL25使用默认代码频率，波特率有问题，发送data = 0但是实际发送值为0x80，通过更改主频为48M，然后分频解决。附件有参考代码。TWR-K60100DM没有此问题。 问题3： FRDM_KL25板子，如果不使能BOOTLOADER_AUTO_TRIMMING这个宏，即不调用SlaveFrequencyCalibration();函数时， 代码上电不能直接运行，而使能该函数后，会一直进行校准频率，上位机无法通讯，查找代码发现： 上版代码为         #if BOOTLOADER_AUTO_TRIMMING == 1                       if(UART_GetChar() != BOOT_CMD_ACK)              {                SlaveFrequencyCalibration();              }                                        #endif 本版代码为：         #if BOOTLOADER_AUTO_TRIMMING == 1                         SlaveFrequencyCalibration();                     #endif 修改为上版代码，可以正常运行并跑起来。 但是不使能BOOTLOADER_AUTO_TRIMMING这个宏，代码依旧跑不起来，现象就是仿真时没有问题，可以正常跑起来，但是如果是上电直接运行，就不能正常通讯： 这个问题出在了USB插拔瞬间，KL25会收到一个数据，该数据并不是上位机下发的FC码，如果不使能BOOTLOADER_AUTO_TRIMMING这个宏，代码会误认为自己进入 等待上位机下发数据的状态机，导致通讯错误。在SlaveFrequencyCalibration(); 函数中，有软件复位功能，会让插拔稳定后KL25不在接收到异常数据，以此保证状态机的正确。 问题4： 仿真时全速跑起来时，指针经常回到__main,说明波特率有问题，代码进入SlaveFrequencyCalibration中，复位了。 AN2295引导MQX Keil工程 AN2295的文档已经说明如何修改CW IAR的工程以便让Bootlaoder引导，但是没有Keil工程的说明，这个就只能自己动手啦。 首先肯定会想到修改scf文件： #define USERFLASH_BASE_ADDR    0x00060000 #define INTFLASH_BASE_ADDR     0x00000000 #define INTFLASH_SIZE          (USERFLASH_BASE_ADDR - INTFLASH_BASE_ADDR) #define MY_ALIGN(address, alignment) ((address + (alignment-1)) AND ~(alignment-1)) LOAD_REGION_INTFLASH INTFLASH_BASE_ADDR INTFLASH_SIZE {     VECTORS INTFLASH_BASE_ADDR     {         vectors.o (.vectors_rom,+FIRST)         vectors.o (.cfmconfig)     }     CODE +0     {         * (InRoot$$Sections)      ; All library sections for example, __main.o,                                   ; __scatter*.o, __dc*.o, and * Region$$Table         * (KERNEL)         * (TEXT)         * (+RO)     }     RAM_VECTORS 0x1FFF0000 ; For ram vector table. Used when  MQX_ROM_VECTORS is set to zero.     {         vectors.o (.vectors_ram)     }     NOUSER +0     {         * (.nouser)     }     ROUSER MY_ALIGN(ImageLimit(NOUSER), 32)     {         * (.rouser)     }     RWUSER MY_ALIGN(ImageLimit(ROUSER), 32)     {         * (.rwuser)     }     DATA MY_ALIGN(ImageLimit(RWUSER), 32)     {         * (+RW)         * (+ZI)     }     USB_BDT MY_ALIGN(ImageLimit(DATA), 512)     {         * (.usb_bdt)     }     KERNEL_DATA_START MY_ALIGN(ImageLimit(USB_BDT), 0x10)     {         * (KERNEL_DATA_START)     ; start of kernel data     }     KERNEL_DATA_END 0x2000FFF0      ; RAM_END     {         * (KERNEL_DATA_END)     ; end of kernel data     }     ; mem_init writes a storeblock_struct at the end of kernel data,     ; max size 32 bytes, so use 0x100 offset     BOOT_STACK_ADDR 0x2000FEF0     {         * (BOOT_STACK)     } } 都是按偏移算的，应该只改INTFLASH_BASE_ADDR     0x00004000就O了，找了个最简单的工程：mqx\examples\hello，编译生成S19文件，通过bootloader下载进片子， 按reset后看屏幕，始终木有出现hello world，没办法，只能上debug了。 打开AN2295工程，加载调试环境，然后在JumpToUserApplication函数上下断点，中断后，单步执行到在__asm("mov pc, r1"); 函数，继续在汇编窗口点单步执行，之后就完全跟crack有点类似，一直点，直到芯片复位，说明之前点那一下是key point，然后对照map文件，于是找到了复位点： init_hardware->_bsp_initialize_hardware->_bsp_watchdog_disable();执行后会复位 不管啦，直接把它屏蔽掉，反正之前就已经关闭看门狗了。 重新编译，继续上。 还是没看到期待已久的hello world，肿么办？ 重复上面的方法，发现又一个key point: _sched_start_internal 查看代码发现，这是一个系统call，应该是从vector 11调用的，查看下寄存器： SCB_VTOR 肿么变成0了，bootloader中已经改成0x4000了，什么时候变成0了....... 代码太多了，不知道从哪儿看起，内存断点是个好东西哈，IAR中没找见在哪儿下，算了，换Keil吧。 用Keil打开AN2295工程，加载调试，然后在0xE000ED08（SCB_VTOR ）下写断点，直接run，等待中断吧： _time_set_timer_vector函数修改了SCB_VTOR， 大概路径是_bsp_enable_card->BSP_INTERRUPT_VECTOR_TABLE->BSP_TIMER_INTERRUPT_VECTOR 哈哈，找代码看看： __VECTOR_TABLE_ROM_START 是这个宏搞的鬼。 仔细对比代码，发现__VECTOR_TABLE_ROM_START 这个宏是通过条件编译区分开的，IAR是通过icf文件定义的 而Keil是通过#define 来实现的。好了，修改对应的值为0x4000，重新编译，下载，搞定，可以看到hello world喽。 总结一下，使用AN2295引导MQX Keil工程需要做以下3点修改： 1.scf文件INTFLASH_BASE_ADDR     0x00000000改为0x00004000 2.屏蔽_bsp_watchdog_disable()该函数 3.修改__VECTOR_TABLE_ROM_START为0x00004000.

Here you can find both the code and project files for the Serial communication project, in this example the serial port (UART) is configured to establish communication between the computer using a serial terminal and the evaluation board. The default baud rate for the serial port is 9600 bauds. The code also implements an echo function, any key pressed in the computer's keyboard will be captured and displayed in the serial terminal. If your computer does not have a serial terminal you can download Tera Term from the following link: Tera Term Open Source Project The communication is established through the USB cable attached to the OpenSDA USB port. Code: #include "mbed.h" //Digital output declaration DigitalOut Blue(LED3); //Serial port (UART) configuration Serial pc(USBTX,USBRX); int main() {     Blue=1;     pc.printf("Serial code example\r\n");        while(1)     {         Blue=0;         pc.putc(pc.getc());     }    }

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

近期有客户提出需求，要求通过外部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

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.

     我想“超频”这个词估计大家都不会陌生，很多玩计算机的都会尝试去把自己电脑的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，再往上我就没有测试了，因为基本也用不到那么高的频率，还是要掌握好这个“度”的，想过把超频的瘾的可以试试看，呵呵~

Freescale Semiconductor is to demonstrate its Kinetis L series microcontrollers (MCUs) built on the ARM Cortex-M0+ processor at DESIGN West in San Jose, California, with alpha sampling due to start in the second quarter of 2012. Freescale  says the ability to demonstrate these devices is possible due to its  close partnership between ARM during the Cortex-M0+ core development  process and as a lead partner provided  input that helped ARM define and  develop the processor. The devices are slated for applications  such as domestic appliances, portable medical systems, smart meters,  lighting, power and motor control systems. "Our close partnership  with ARM throughout the design and development of their new core has  positioned us as the first MCU supplier to produce and demonstrate an MCU based on the Cortex-M0+ and continues our strategy of driving to  market new products based on the ARM architecture," said Reza  Kazerounian, senior vice president and general manager of Freescale’s  Automotive, Industrial and Multi-Market Solutions Group. Mike  Inglis, executive vice president and general manager of ARM’s Processor  Division, added "With the addition of the L series to their Kinetis  line, Freescale is creating one of the industry’s broadest, most  scalable ARM Cortex-M MCU portfolios, ranging from very low-cost,  entry-level products based on the ARM Cortex-M0+ processor, up to 4 MB,  200 MHz devices based on the Cortex-M4 processor." Manufactured  using Freescale’s low-leakage, 90 nm thin film storage (TFS) process  technology, the Kinetis L series will have a selection of on-chip flash  memory densities and analog, connectivity and HMI peripheral options. Upward  migration through the Kinetis portfolio is available via compatible Kinetis K series devices (built on the ARM Cortex-M4 processor) that  provide access to DSP performance and advanced feature integration. The  ARM Cortex-M0+ processor includes a reduced two-stage pipeline,  allowing faster branch instruction execution, single-cycle access to I/O  and critical peripherals, optimized access to program memory, linear 4  GB address space that removes the need for paging, reducing software  complexity and ensuring a more 8-bit-like user experience and a micro  trace buffer, providing a low-cost trace solution that allows faster bug  identification and correction without the need for additional I/O  resources. Freescale will demonstrate the ARM Cortex-M0+ core at its exhibition booth #1604 at DESIGN West , March 26-29 at the San Jose McEnery Convention Center.

Here you will find both the code and project files for the USB Mouse project. In this project the USB module is configured as a device, the X and Y coordinates to move the cursor are obtained from the accelerometer measurements. Once the code is loaded it is necessary to disconnect the USB cable from the J26 USB connector and plug it to the K64 USB connector. Once the device enumerates you can use it as an air mouse. The left and right click buttons have not been enabled. To compile the project you must import the following libraries: USBMouse.h FXOS8700Q.h Code: #include "mbed.h" #include "USBMouse.h" #include "FXOS8700Q.h" //I2C lines for FXOS8700Q accelerometer/magnetometer FXOS8700Q_acc acc( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); USBMouse mouse; int main() {     acc.enable();     float faX, faY, faZ;     int16_t x = 0;     int16_t y = 0;       while (1)     {         //acc.getAxis(acc_data);         acc.getX(&faX);         acc.getY(&faY);         x = 10*faX;         y = 10*faY;               mouse.move(x, y);         wait(0.001);     } }

This demo is about driving TFT LCD by FlexBus module on MAPS-K22 board.       MAPS-K22 brief description: High performance Freescale ARM Cortex™ M4 SoC MK22FN512VLL12​ with 120MHz core clock, 512KB Flash and 128K RAM. Support Graphic LCD by Flexbus interface. Power supply from Micro USB 5V. Support ISO7816 smart card by UART interface. Support connector for Peripheral, Application and Socket MAPS board. SDK 1.0 Software release FlexBus Overview       The FlexBus module is a hardware module that： Provides memory expansion and provides connection to external peripherals with a parallel bus Can be directly connected to the following asynchronous or synchronous slave-only devices with little or no additional circuitry： External ROMs Flash memories Programmable logic devices Other simple target (slave) devices Block diagram Pin functions Pins allocation Demo illustration       After run the demo, the TFT LCD will display the Freescale logo as below, and I’ve also attached the demo. Welcome to download it.

Hello Kinetis World, I just wanted to take this opportunity to share the press release for our newly announced WLCSP device.         http://finance.yahoo.com/news/thin-blade-grass-freescale-newest-120000684.html The Ultra Thin CSP, MK22FN512CBP12R, is equivalent to the standard height CSP, MK22FN512CBP12R.  Therefore, from Therefore, from a software enablement perspective, the MK22FN512CAP12 device can be selected as shown in the attached Processor Expert screenshot.  We're looking forward to seeing what amazing things you can accomplish using Kinetis technology!      

1. Introduction MCUboot is a common used bootloader for most of Kinetis and i.mx RT devices. It can support download application via UART/USB/CAN/I2C/SPI. It enables quick and easy programming of Kinetis MCUs and i.mx RT MPU through the entire product life cycle, including application development, final product manufacturing, and beyond. K64 is a very popular device in Kinetis family. It has a M4 core, 512k and above flash, 120M main frequency and plenty of interface, such as I2C/SPI/UART/CAN/USB/ENET. But it is a bit awkward that the MCUboot demo of K64 is not include CAN. Does K64’s CAN can’t support bootloader application? No, of course not. Here we are going to port CAN function to K64 bootloader. There are two kind of CAN peripheral in Kinetis family, FlexCAN and MSCAN. FlexCAN is more complex than MSCAN. K64 has a FlexCAN. To speed up our work, we can port FlexCAN driver and related code from TWR-KV46 bootloader. Hardware: two TWR-SER board two sets of TWR-ELEV TWR-K65F150M TWR-K64F120M   Software: MCUXpresso 11.0 MCUBoot 2.0.0 package SDK_2.6.0_TWR-K64F120M 2. Software porting Step 1, copy below files to twrk64f120m_tower_bootloader project. \drivers\fsl_flexcan.c \drivers\fsl_flexcan.h        \source\bootloader\src\flexcan_peripheral_interface.c   Step 2, modify the project to enable the FlexCAN.       In bootloader_config.h, change BL_CONFIG_CAN definition to 1.        In peripherals_MK64F12.c, add #if BL_CONFIG_CAN     // CAN0     {.typeMask = kPeripheralType_CAN,      .instance = 0,      .pinmuxConfig = can_pinmux_config,      .controlInterface = &g_flexcanControlInterface,      .byteInterface = &g_flexcanByteInterface,      .packetInterface = &g_framingPacketInterface }, #endif    // BL_CONFIG_CAN       Pin mux setting. In peripherals_pinmux.h, add #define BL_ENABLE_PINMUX_CAN0 (BL_CONFIG_CAN) //! CAN pinmux configurations #define CAN0_RX_PORT_BASE PORTB #define CAN0_RX_GPIO_PIN_NUM 18             // PIN 13 in the PTA group #define CAN0_RX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 RX functionality for pin 13 #define CAN0_TX_PORT_BASE PORTB #define CAN0_TX_GPIO_PIN_NUM 19             // PIN 12 in the PTA group #define CAN0_TX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 TX functionality for pin 12       Set clock. FlexCAN clock source can be OSCERCLK or bus clock. Here we use bus clock run at 48Mhz. In flexcan_peripheral.c, add these code. const flexcan_timing_config_t bit_rate_table48m[] = {     { 23, 3, 4, 4, 4 }, /* 125 kHz */     { 11, 3, 4, 4, 4 }, /* 250 kHz */     { 5, 3, 4, 4, 4 },  /* 500 kHz */     { 3, 3, 4, 4, 4 },  /* 750 kHz */     { 2, 3, 4, 4, 4 }   /* 1   MHz */ }; change line 621 FLEXCAN_SetTimingConfig((CAN_Type *)baseAddr, &bit_rate_table48m[s_flexcanInfo.baudrate]); Step 3, compile the project.   3. Function test Software preparation To connect bootloader via CAN bus, NXP has TWR-K65 as bridge. But its source code is not in K64 SDK. It is in MCUBoot2.0.0 package. User can download the package from https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuboot-mcu-bootloader-for-nxp-microcontrollers:MCUBOOT The bridge project is called buspal which can be found in NXP_Kinetis_Bootloader_2_0_0\apps\bus_pal\MK65F18. BusPal is an embedded software tool that is available as a companion to blhost. The tool acts as a bus translator with an established connection with blhost over UART and with the target device over I2C, SPI, or CAN, and assists blhost in carrying out commands and responses from the USB target device. The BusPal is available for selected platforms. The source code for BusPal is provided with the Kinetis bootloader release, it support FRDM-KL25, TWR-KV46F150M and TWR-K65F180M and can be customized to run on other platforms. More detail of buspal is in Kinetis blhost User's Guide appendix C.   Hardware connection TWR-SER has TJA1050 as transceiver. We can connect J7 on both boards. When construct the Tower system, user should take care the power. The power tree is very flexible. Improper setting may cause TJA1050 can’t work.   The Buspal project on TWR-K65F180M use UART1 to connect with computer. The port is on TWR-SER. To make the connection simple, we can share the openSDA UART port. The openSDA UART use UART2, we can jump UART1 signal to J33 and J34 on K65 tower board.     Testing: Open a command window, type >blhost -p com4,57600 –buspal can,0,321,123 – get-property 10 This command can check if the whole system work properly. Then, you can download the code to K64 now. Please type >blhost -p com4,57600 –buspal can,0,321,123 – flash-image xxxxxx.s19 erase

1.jicheng0622-AET-电子技术应用 2.wuyage-AET-电子技术应用 3.fanxi123-AET-电子技术应用

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;         }     } }

Here you can find the code and project files for the Interrupt example, in this example 2 KBI interrupts are enabled, one assigned to SW2 and another to SW3, during the main routine the blue led is turned on, when the interrupt routines are triggered the blue led is turned off and the red or green led blink once, the interrupt was configured to detect falling edges only. Code: #include "mbed.h" DigitalOut Red(LED1); DigitalOut Blue(LED3); InterruptIn Interrupt(SW2); void blink() {     wait(.4);     Red=1;     Blue=0;     wait(.4);     Blue=1;     wait(.4); } int main() {     Interrupt.fall(&blink);     Blue=1;     while (1)     {         Red=!Red;         wait(.4);     } }

Hello, I've created a application of USB FLASH Drive acessing the 1MB internal FLASH of K64 using the Freescale's bareboard USB Stack 5.0 software + FRDM-K64F to be used by anyone as reference. It seems to be stable, I already wrote some files on that and checked the integrity of the volume. It can be very useful for datalogger application where the equipment can store data on the MCU FLASH using a internal filesystem, and read it through PC as it was a regular USB stick. It also very much cheaper than using a external SD Card, as it only needs the MCU + a external crystal and a USB connector.The only limitation so far is that it cannot exceed the number of the erase/write cycles of the device (of course!). Please see the file attached with the USB Stack and the example on the folder "{Installation Path}\Freescale_BM_USB_Stack_v5.0\Src\example\device\msd\bm\iar\dev_msd_disk_frdmk64f". The project was wrote using IAR. Also I have attached the srec file if you don't want to build the project by yourself. Any issues, doubts or suggestions, please let me know. Denis

       所谓“知识产权保护”，其实就是在产品量产之后防止其芯片内部代码通过外部调试器被有效读取出来的手段，毕竟现在来说硬件电路是比较容易被复制的，如果软件再不设防的话，在山寨技术如此发达的今天（用发达来形容貌似不是很过分吧，呵呵）这个产品估计很快就会被淘汰了。        因为最近有很多客户问到关于Kinetis的加密锁定问题，所以我觉着还是有必要对其细说说的。其实飞思卡尔对于知识产权保护方面还是做了很大的功夫的，而且使用起来也是比较方便的（这点很重要），具体可以参考Kinetis的Reference Manual中Security这一章，这里我就以在IAR环境下锁定K60为例介绍一下使用方法： 1. 首先简单介绍一下原理，即如果将K60置于Security状态（即锁定状态），则是不能通过Debug接口或者EzPort接口对芯片内部flash有任何操作的（CPU还是可以正常读写flash的，也就是说程序还是可以正常运行的，只不过是不能被外部非法读取了），当然“mass erase”命令除外（我们平时在Jlink Command窗口中敲入的unlock Kinetis命令就是触发这个命令给芯片的），通过“mass erase”命令可以再次将芯片擦除到出厂状态（即unsecure解锁的过程），这样芯片就又可以正常使用了（方便用户之后的程序升级）。咳咳，不过不用担心，解锁之后的芯片其内部的flash已经被完全擦除掉变为空片状态，也就是说内部的代码已经没有了，所以。。。懂的。。。呵呵； 2. 说完Security的原理，下面再聊聊K60实现security的process。我们可以通过K60的FTFL_FSEC寄存器中的SEC位来设定芯片的security状态，如下图所示，芯片默认出厂状态SEC位是为10的，即非加密锁定的，而如果将SEC位设定为00、01或者11任何一种情况，则芯片都将处于锁定状态（这就是我们接下来要干的事了，呵呵）。这里可能会有人疑问，在这个寄存器在重新上电之后会保存内容吗，我只能说“咳咳，都能抢答了”，哈哈，这正是我下面要说的； 3. K60在flash中0x00000400~0x0000040F这16个字节范围的地址定义为寄存器加载地址（Flash配置区），如下图所示，而这其中0x0000040C的地址内容在芯片上电之后会被自动加载到FTFT_FSEC寄存器中，也就是说我们只需要在烧写程序的时候把相应数据写到该flash地址即可在上电之后对芯片进行加密锁定，由此实现加密锁定。 4. 好了，原理和process都说完了，准备工作就做好了，下面就撸胳膊抹袖子开工干活吧，呵呵。其实飞思卡尔已经为我们做好了相关工作，只不过我们平时因为用不到没有注意到罢了。我们打开IAR环境，然后导入需要加密的代码工程，再打开工程目录下cpu文件组中的vectors.c和vectors.h（如果你的工程架构类似于飞思卡尔官方的sample code的话就在这个路径下）。在vectors.h里的最后部分我们会看到4个config段（共16个字节大小），如下图1，这四个段就是定义了上述0x400~0x40F的内容，其中CONFIG_4中最后的0xfe即为0x40C地址的内容（注意ARM处理器默认是little end模式的，所以0x40C在低地址），0xfe表明SEC位为10，即非加密状态，这样如果我把该0x40C地址的内容改成0xfc、0xfd或者0xff任意一个都可以实现对芯片的加密锁定。至于该四个配置段定义是如何映射到K60的flash区中的呢，去vectors.c文件中中断向量表vector_table[]的最后看看就知道了，如下图2； 5. 这里我们选择将CONFIG_4内容由原来的0xfffffffe改成0xfffffffd即可，然后保存编译通过之后，在查看其生成的s19文件中可以看到如下图所示，即0x40C地址的内容被修改成了0xfd，这样烧写文件就搞定了； 6. 当然到这一步实际上还没有完，其实在IAR的新版本之后（IAR6.6之后），其自带的flashloader默认是把0x400~0x40F这段保护起来的（防止误操作对芯片意外的security），即使如上面所述修改好相应内容，在烧写的过程中flashloader也不会对这段地址的内容做任何擦除和写入。为此还需要再额外对IAR的flashloader进行配置，具体步骤如下： （1）进入Options->Debugger->Download，选择如下： （2）点击“OK”，然后系统会提示保存该修改后的flashloader配置，建议把自己修改好的.board文件保存到自己的工程目录下，方便以后直接调用该flashloader。 7. 至此全部设置就搞定了，点击编译连接，然后下载，即可把加密后的代码烧写到芯片的flash里面去了。注意如果我们点击调试按钮的话，一旦程序烧进去之后调试器会自动复位芯片，此时加密状态位会被load到FTFT_FSEC[SEC]位中，芯片的调试端口就会被停掉，所以这时进入不到调试界面，而是弹出错误窗口，不用担心，因为此时程序已经正确烧到芯片中，我们重新插拔电源之后会看到程序已经正常执行，而此时的芯片已经处于加密状态。当然如果我们想再进入调试模式调试芯片的话，一种是通过Jlink Command窗口解锁，如下图1，另一种是再次点击调试按钮，会弹出解锁窗口，点击解锁即可，如下图2。 图1 图2