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

在电机控制，Audio等很多应用中，我们经常会用到一些常见的正余弦，矩阵变换，FFT等一些DSP函数，提到DSP库，通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准，包括针对内核操作的CMSIS-CORE API，针对DSP应用的CMSIS-DSP Library，针对RTOS的CMSIS-RTOS API，与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中，又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能，CMSIS-DSP部分提供了超过60多种功能的DSP算法库，尤其是随着Cortex-M4中集成了FPU硬件单元，CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持，然而在CodeWarrior中没有直接支持CMSIS，需要用户移植到自己的CW工程中，所以就需要使用者了解CMSIS的结构，手动添加库文件和头文件，并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元，有些不支持，在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中，FPU浮点运算单元也是一个可选的部件，只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能，如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元，整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片，编译器也设置了相应的 FPU 功能开启/关闭的选项，在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能，在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能，而芯片未开启 FPU 单元，程序运行到浮点语句时就会出现异常。相反，如果编译器未使能 FPU 功能，芯片即使开启了 FPU单元，程序还是会按照未使能 FPU 的代码进行处理。在本例程中，为对比分析是否采用FPU的编译指令差别以及在板的执行效率，选用Kinetis K70FN1M为实验对象。 硬件平台：TWR-K70F120M核心板      软件环境：CodeWarrior v10.5        CMSIS版本 ：V3.2 一. 准备工作： 下载CMSIS的库，当前最新的版本为V3.2，解压后名称为CMSIS-SP-00300-r3p2-00rel1，其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中，真正用到的文件包括CMSIS\Include中CM4相关的头文件，CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点)，以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤；      Step 1:    新建一个Baremental的工程，选择器件器件MK70FN1M0（支持硬件FPU）；     Step 2:    选择Floating Point浮点运算实现的类型，即指定编译器将C代码编译成汇编代码时使用的规则； 在Floating Point四个选项含义如下： Software选项：表示不使用FPU硬件，而是使用GCC的整数算术运算来模拟浮点运算； Handware(-mfloat –abi=hard) 选项：表示使用FPU硬件来进行浮点运算，函数的参数直接传递到FPU的寄存器(s0-d0)中； Handware(-mfloat –abi=softfp)选项：表示使用FPU硬件来进行浮点运算，但是函数的参数传递到整数寄存器(r0-r3）中，然后再传递到FPU中； Handware(-mfloat –abi=softfp –fshort -double)选项：其配置项同上，只不过使能了fshort  double功能，并且此处的double数据的宽度等同于float； 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章，在本例程中使用的是软浮点，所以选择Software项。需要注意的是：此配置选项仅出现支持FPU硬件单元的芯片工程中，如MK60FN1M0, MK60FX512等，否则默认没有此选项，默认为软件浮点。 Step 3:    点击“Next”进入下图，选择使用Processor Expert，点击“Finish“完成工程的建立； Step 4:    进入当前工程的文件夹，新建文件夹CMSIS，从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外，拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中； Step 5:    回到CodeWarrior主界面选择新建的工程文件，F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件，包括M0+/M3/M4的一些头文件；在Lib文件中是已经编译好的库文件，ARM文件夹是使用在KEIL IDE中的库文件，G++文件夹是使用在IAR中的库文件，而由于当前CW工程使用的GCC的编译器，所以GCC文件夹才是CW需要的，因此，为缩减工程大小可以删除ARM和G++文件夹；     Step 6:    打开工程属性框，选择Target Processor的Float ABI为No FPU； Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4； Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件，路径为：工程目录\CMSIS\Include； Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU，所以选择libarm_cortexM4l_math.a，此处需要特别注意，否则编译会报错； Step 10: 在ProcessorExpert.c文件中添加代码； #include <math.h> #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V，仅在 FPU 功能被使能时使用)，完成一个正弦计算； 至此，完成了不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元，移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元，移植CMSIS的DSP库到Codewarrior的方法有两种：一种是按照上面软浮点的方式Step By Step的建立工程，步骤和上面二的步骤基本一致，主要的两个区别在于：(1). Step 2要选择Handware(-mfloat –abi=hard) 选项，(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便，本教程采用第二种方案，完成在Codewarrior中调用CMSIS的DSP库，通过K70的FPU浮点运算单元执行浮点运算，即硬浮点。 Step 1:    打开工程属性对话框，选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard)； Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义：_VFPV4； Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则，把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"； Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU，所以选择libarm_cortexM4lf_math.a，此处需要特别注意，否则编译会报错； Step 5:    完成以上配置后，编译工程并下载调试（此处建议编译之前先Clean一下整个工程），同样，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V，仅在 FPU功能被使能时使用)，并且在Register观察窗口中也多了个FPU寄存器列表，感兴趣的读者可以对比一下和前面实验汇编出代码的差异，此处不再赘述； 至此，分别完成了使用和不适用K70的FPU浮点运算单元情况下， CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数，在项目中直接调用即可。下一步， Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是，前文中讲到使用FPU单元需要两步设置：(1). 在编译器中开启相应的 FPU 功能选项；(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤，然而第二个步骤呢？仔细查看_arm_atart.c文件，可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程，如下图，是一个条件编译函数，这也就解释了为什么在上面Step 2中定义了_VFPV4，其本质也就是使能芯片的FPU单元，其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif

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

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.

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

MAPS-KS22 Board Introduction: MAPS boards are localization evaluation boards for Chinese customers. The MAPS boards are suitable for NXP MCU product, with low coat, more flexibility and easy-copy features, which matching with local customer requirements and better for learning and product evaluation. MAPS board includes four parts board, which are MCU Board, Peripheral Board, Application Board & Socket Board. The naming of MAPS are using the four-part board initial letter. MCU board is NXP Kinetis MCU based evaluation main board with chip related special module interface/device, such as graphic LCD/ENET interface and etc. The MCU board fan out all MCU pins as test points for measuring. The MCU board also provide two 32-pin socket to connect external peripheral board or application board. Peripheral Board collects more general device into one board and using two 32-pin socket connects with MCU board. The MAPS-Dock is the first peripheral board, which with below configuration: Micor-SD card slot; six touch pads; USB FS interface; IrDA transceiver; one SPI Interface (SPI-Flash); two UART interface; four buttons; one I2S interface (audio codec); one CAN interface; two potentionmeter; one DAC output interface; 128x64 monochrome LCD; one 5-way button. It also with SWD debugger on board and USB CDC virtual COM. Application Board designed for special applications, such as motor control, IOT, Smart Home, Wireless Charger and etc. Socket Board provides interface for FreeDOM boards/Arduino boards/Customer defined boards. MAPS-KS22 board MCU board for KS22 chip evaluation. KS22 MCU is based on the ARM® Cortex®-M4 core with 120MHz MCUs with FPU, offering full-speed USB 2.0 OTG, in addition to other features like USB crystal-less functionality. MAPS-KS22 oobe demo porting process MAPS-KS22 oobe demo is based KSDK V1.0, which will show Freescale LOGO on the SPI color LCD and meanwhile use FlexIO I2S to play an audio on microphone. Step1: visit Kinetis Expert website (http://kex.nxp.com/en/welcome) to download MAPS-KS22 KSDK V2.0 software: Step2: download [Kinetis SDK Project Generator Tool] from below link and generate oobe demo project based on MAPS-KS22 SDK V2.0 software: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=KSDK-PROJECT-GENERATOR-TOOL&appType=file1&location=null&DOWNLOAD_ID=null Step 3: After that, open the oobe project, which located at default path: C:\Freescale\SDK_2.0_MAPS-KS22\boards\mapsks22\user_apps\oobe\iar The default project is based on <hello-world> demo, it need to add LED control code. Those part of code could be found at <main.c> file and related pin muxing code at <pin_mux.c> file. Step 4: Modify ili9341 related driver: For the oobe project with two major functions, the first one is to display Freescale LOGO at LCD. The MAPS-KS22 board graphic LCD is using ili9341 TFT LCD driver with SPI interface with KS22 chip. The previous oobe project is using GPIO pins emulate SPI communication, we will make the similar application with KSDK V2.0 driver. Most modification based on the GPIO pins control. Please check below code at <ili9341.h> file, which call KSDK V2.0 GPIO driver: #define ILI9341_CS_HIGH()       GPIO_SetPinsOutput(BOARD_LCD_CS_GPIO, 1U << BOARD_LCD_CS_PIN) #define ILI9341_CS_LOW()        GPIO_ClearPinsOutput(BOARD_LCD_CS_GPIO, 1U << BOARD_LCD_CS_PIN) #define ILI9341_CLK_HIGH()      GPIO_SetPinsOutput(BOARD_LCD_CLK_GPIO, 1U << BOARD_LCD_CLK_PIN)  #define ILI9341_CLK_LOW()       GPIO_ClearPinsOutput(BOARD_LCD_CLK_GPIO, 1U << BOARD_LCD_CLK_PIN) #define ILI9341_MOSI_HIGH()     GPIO_SetPinsOutput(BOARD_LCD_MOSI_GPIO, 1U << BOARD_LCD_MOSI_PIN) #define ILI9341_MOSI_LOW()      GPIO_ClearPinsOutput(BOARD_LCD_MOSI_GPIO, 1U << BOARD_LCD_MOSI_PIN)      #define ILI9341_MISO_HIGH()     GPIO_SetPinsOutput(BOARD_LCD_MISO_GPIO, 1U << BOARD_LCD_MISO_PIN) #define ILI9341_MISO_LOW()      GPIO_ClearPinsOutput(BOARD_LCD_MISO_GPIO, 1U << BOARD_LCD_MISO_PIN) And it also need to add ili9341 control pin muxing initialization code at <pin_mux.c> file. Step 5: We could modify the Freescale logo with new NXP logo, which could using [Embedded GUI Conversion Utility3.0] tool. This tool could be downloaded from below link:  http://tinyurl.com/eGUI-Convert  The conversion result of the graphic data is 16-bit array, which need be transfer to 8-bit array. After that, compile and download the image to the board, it with below result: Step 6: The oobe demo provide another function to play music with MAPS-DOCK board WM8960 codec chip, then using headphone will hear the sound. For the KS22 with FlexIO module, the demo will use FlexIO emulating I2S bus to transfer data to WM8960 codec chip. About I2S bus MCLK clock source, the MAPS-KS22 provide two selection, one is using TPM1_CH1 pin, the other one is using I2S0_MCLK pin with JP5 jumper selection. In oobe demo, we use TPM1_CH1 pin to generate 12MHz MCLK clock with TPM module output compare mode. Related code, please refer below tpm_init_output_compare() function at <main.c> file: //enable clock gating of tpm1 CLOCK_EnableClock(kCLOCK_Tpm1); //set TMP output compare mode TPM_SetupOutputCompare(BOARD_TPM_BASEADDR, BOARD_TPM_CHANNEL, kTPM_ToggleOnMatch, 1U); BOARD_TPM_BASEADDR->MOD = 0x1; TPM_StartTimer(BOARD_TPM_BASEADDR, kTPM_SystemClock);   //TPM counter increments on every TPM counter clock Step 7: WM8960 is a stereo CODEC chip provide I2C port for chip configuration. There need to initialization the WM8960 chip before using it with related driver <wm8960.c> & <wm8960.h> files. The MAPS-KS22 board using LPI2C0 module connects with WM8960 chip, so there need to port using LPI2C driver of KSDK V2.0 and modify the WM8960 driver related. The LPI2C module initialization code located at <main.c> with lpi2c_master_init() function. The WM8960 driver major modification with WOLFSON_WriteReg() function at <wm8960.c> file, calling the LPI2C driver of KSDK V2.0 with below code:  wolfson_status_t WOLFSON_WriteReg(uint8_t reg, uint16_t val) {       uint8_t cmd,buff;        status_t ret;        cmd = (reg << 1) | ((val >> 😎 & 0x0001);    // register address        buff = val & 0xFF;     //data        reg_cache[reg] = val;      // copy data to cache         uint8_t data[2];         data[0] = cmd;         data[1] = buff;         //start lpi2c tx operation                   ret = LPI2C_MasterStart(LPI2C0, WM8960_I2C_ADDR, kLPI2C_Write);           // send two data with register address and related value          ret = LPI2C_MasterSend(LPI2C0, data, 2);                //stop lpi2c tx operation                  ret = LPI2C_MasterStop(LPI2C0);               if(ret != kStatus_Success)          {  return kStatus_WOLFSON_I2CFail;  }          return kStatus_WOLFSON_Success; } After WM8960 chip driver modification, there could call related driver to initialize WM8960 chip and configure the communication interface with I2S bus. Following steps focus on how to transfer data to WM8960 codec with I2S bus. Step 8:  The FlexIO modul will simulate I2S bus call FlexIO_I2S_MasterInit() function in <main.c> file to initialize FlexIO module as I2S master. There using FXIO0_D4 pin as I2S bit clock pin, using FXIO0_D5 pin as I2S Transmit pin and using FXIO0_D6 pin as I2S Transmit Frame Sync pin. KSDK V2.0 provide FlexIO for I2S driver located at <fsl_flexio_i2s.h> file. Step 9: There will call eDMA with FlexIO module to reduce the core work load during the I2S data transfer. It will initialize the eDMA & DMAMUX modules for FlexIO. Related code located at <main.c> file with ConfigDMAforFlexIOI2STX() function: void ConfigDMAforFlexIOI2STX(void) { EDMA_GetDefaultConfig(&dmaConfig); EDMA_Init(EXAMPLE_DMA, &dmaConfig); EDMA_CreateHandle(&dmaHandle, EXAMPLE_DMA, EXAMPLE_CHANNEL); DMAMUX_Init(DMAMUX0); DMAMUX_SetSource(DMAMUX0, EXAMPLE_CHANNEL, EXAMPLE_DMA_SOURCE); DMAMUX_EnableChannel(DMAMUX0, EXAMPLE_CHANNEL); }    Step 10: KSDK V2.0 software provides FlexIO I2S eDMA driver located at <fsl_flexio_i2s_edma.c> file, with below codes to initialize FlexIO I2S master DMA handler and to configure the sample rate & audio data format to be transferred: FLEXIO_I2S_TransferTxCreateHandleEDMA(&base, &txHandle, callback, NULL, &dmaHandle); FLEXIO_I2S_TransferSetFormatEDMA(&base, &txHandle, &format, 48000000); Step 11: After above preparation, following action will start to transfer music data to WM8960 codec with below code. When the music data transfer finished, the callback function will be called to start next round data transferred. Then we could hear the sound with endless loop. static void callback(FLEXIO_I2S_Type *i2sBase, flexio_i2s_edma_handle_t *handle, status_t status, void *userData) {   // Initiate FlexIO I2S transfer again after previous transfer finished  FLEXIO_I2S_TransferSendEDMA(&base, &txHandle, &xfer); } About more detailed oobe demo software info, please check attached file. The default oobe demo located path is: C:\Freescale\SDK_2.0_MAPS-KS22\boards\mapsks22\user_apps\oobe

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

This hint will demonstrate how to verify ADC conversion rate (with oscilloscope) during testing phase.   Refer to the phenomenon descripted in"Figure 1. Voltage drops at ADC input during sampling process" of AN4373. If too large values is selected for the external RC components, serious voltage disturbances (voltage drops/peaks) at the ADC input (see Figure 1) can be observed. The disturbance at the ADC input in this case results from the basic principle of operation of the sample and hold (S/H) circuit inherent in a SAR ADC. Although we should avoid this happening, but it can be used to measure the ADC conversion rate with oscilloscope during testing phase.   According to the 'Table 30. 16-bit ADC operating conditions' of K64P144M120SF5, we can know that the max ADC conversion rate is 818.330 ksps. Here I create an example by using KDS3.2 with Processor Expert(See the attach file). After select same configuration according to that table, I got almost the same ADC conversion rate. The conversion time meet equation given in Reference Manual too. Now let's measure the ADC conversion rate on FRDM-K64F board with oscilloscope. After connected an external 1.5KΩ resistance, the value of external RC components is big enough to be observed. Below is the waveform observed with oscilloscope, the frequency between voltage drops at ADC input during sampling is about 818 ksps. This test result is consistent with the theoretical calculated value.

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

客户要求：K60 100MHz芯片作为SPI主机读取片外SPI Flash存储器内容（SPI Flash器件数据准备完成会触发K60 GPIO中断），要求在130~150微秒之间读取九个不连续地址上的数据，每个地址需要读取4个字节，SPI波特率为5MHz。读取SPI Flash存储器，需要使用读取命令（1个字节）外加地址（2个字节）。换言之，每读取一次K60需要发送7个字节（1字节读取命令+2字节地址+4字节空读数据）。同时要求减少内核负担。 Customer requirement: Use K60 100MHz product as SPI master communicate with external SPI Flash device (When data ready, SPI Flash device will trigger K60 GPIO interrupt), it need to read data from 9 discontinuous address, each address read 4 bytes within 130~150us. SPI  baud rate is 5MHz. Read data from SPI Flash, it need SPI master send 1byte read command and 2bytes address. In another word, K60 need to send 7bytes(1byte read command+2bytes address+4bytes dummy read) 9times within 130us. SPI communication baud rate is 5MHz. It also require to reduce core work load. 实现方法：使用DMA模块，其中一个DMA通道1用来装载SPI传输TX数据（触发源为SPI TFFF符号，SPI FIFO可装载），另外一个DMA通道0用来接收SPI数据（触发源为SPI RFDF符号，SPI 接收FIFO非空）。通过使用DMA引擎可以自动发起SPI传输，减少内核在SPI传输过程中的干预，达到降低内核工作负荷的效果。SPI模块采用中断方式。 Reality way: Use DMA module, DMA CH0 loads data for SPI transmit, DMA CH1 stores data for SPI receive.  DMA triggered by SPI module and SPI module works in interrupt way. 测试平台：TWR-K60D100M， TWR-MEM， IAR ARM Workbench V6.60 TWR-MEM板子提供SPI Flash设备（AT26DF081A），可以通过TWR-K60D100M SPI2模块进行访问。 Test platform: TWR-K60D100M ，TWR-MEM ， IAR ARM Workbench V6.60 SPI Flash AT26DF081A on TWR-MEM board, which could be accessed by TWR-K60D100M via SPI2 module. 测试场景一：读取AT26DF081A设备ID信息 Test scenario 1:  Read device ID AT26DF081A设备提供查询设备ID命令0x9F，返回4个字节设备ID信息（0x1F,0x45,0x01,0x00）。K60作为SPI主机发出查询命令，之后执行4次空写入操作用来读出设备ID信息。测试中SPI传输/接收数据帧大小设定为1个字节（8bit）。由于DSPI模块传输接收均提供4级FIFO，测试中使用两种方式进行SPI数据发送，一种方式使用DMA通道发送读取设备ID查询命令和4次空写入数据，另一种方式通过执行代码（需要内核干预）发送读取设备ID查询命令和4次空写入数据。SPI数据接收均使用DMA完成。为了便于测试使用DMA模块是否降低内核负荷，在DSPI通信同时，主程序在While循环中不停翻转GPIO引脚（PTD7）。 SPI Flash AT26DF081A provides read device ID command(0x9f), will feedback 4 bytes device ID info（0x1F,0x45,0x01,0x00）。K60 works as SPI master send read ID command, then send 4 dummy write data to read back device ID info. During test, SPI data frame size setting to 1byte(8 bit). For DSPI module TX/RX FIFO is 4 entries, so there using two ways do SPI data transfer, one is using DMA CH1 send data, the other way using software code send data. SPI RX using DMA CH0 and in main while loop it will toggle PTD7 pin to show if using DMA module will reduce core work load. 测试流程图（方法一: 使用DMA CH1发送SPI数据）： Test flow chart (Way1: Using DMA CH1 do SPI TX)： 测试结果（Test Result）： 执行一次读ID信息操作，需要花费12.96us，其中内核处理中断的时间为（2.56+2.72）= 5.28us。 根据客户要求，依照此方法每次发送3个字节，接收4个字节，SPI通信过程中内核负荷时间比率为 (5.28/16.16) =32.7% SPI read ID operation once, it will take 12.96us, includes core deal with interrupt time 5.28us. According to this way, customer want to TX 3bytes then RX 4bytes, during SPI communication core work load rate is 32.7% 测试流程图（方法二: 使用软件代码发送SPI数据）： Test flow chart (Way2: Using software code do SPI TX): 测试结果（Test Result）： 执行一次读ID信息操作，需要花费11.6us，其中内核处理中断的时间为（2.48+1.40）= 3.88us。 根据客户要求，依照此方法每次发送3个字节，接收4个字节，SPI通信过程中内核负荷时间比率为 (3.88/14.80) =26.2% SPI read ID operation once, it will take 11.6us, includes core deal with interrupt time 3.88us. According to this way, customer want to TX 3bytes then RX 4bytes, during SPI communication core work load rate is 26.2% 测试场景二：读取AT26DF081A设备9处不连续地址数据 Test scenario 2: Read 9 discontinue address data from AT26DF081A AT26DF081A设备提供读阵列命令（0x0B），可以连续读取多个字节数据。根据客户要求，测试读取9处不连续地址数据，每处读取4个字节。根据AT26DF081A设备要求，读阵列命令后需要再发送3个字节地址信息外加1个字节空写入数据，之后K60将会收到数据。即如果要读取4个字节数据，K60作为SPI主机需要发送9个字节数据（1个字节读阵列命令+3个字节地址+1个字节空写入+4个字节空写入）。测试中使用两个DMA通道进行SPI数据收发，两个DMA通道交替工作，DMA通道0（SPI接收）优先级高于DMA通道1（SPI发送）。完成9处数据采集后进入SPI中断，清除EOQ标志并且修正DMA通道配置，进行新的一轮9处数据读取测试。为了便于测试使用DMA模块是否降低内核负荷，在DSPI通信同时，主程序在While循环中不停翻转GPIO引脚（PTD7）。 SPI Flash AT26DF081A provides read array command (0x0B) to sequentially read a continuous stream of data out. With customer requirement, the test will read 9 discontinue address data, each address read 4 bytes data. AT26DF081A datasheet shows read array command with 3 bytes address and 1 dummy byte, then following will be data. In order to read 4 bytes data out, K60 as SPI master need TX 9 bytes data (1byte read array command + 3bytes address + 1byte dummy data + 4bytes dummy data). During the test, it using two DMA channels do SPI TX/RX, each channel alternatively work, DMA CH0（SPI RX） with higher priority than DMA CH1(SPI TX). When finish 9 discontinue address data receive, it will clear EOQ flag and refresh DMA CH0/1 setting in SPI interrupt for next round read 9 discontinue address data test. In main while loop it will toggle PTD7 pin to show if using DMA module will reduce core work load. 测试流程图(Test flow chart)： 测试结果（Test Result）: 读取AT26DF081A设备9处不连续地址数据，需要花费132.32us，其中内核处理中断的时间为2.6us。 根据客户要求，依照此方法每次发送3个字节，接收4个字节，重复9次。SPI通信过程中内核负荷时间比率为 (2.6/103.52) =2.5% SPI read ID operation once, it will take  132.32us , includes core deal with interrupt time 2.6us. According to this way, customer want to TX 3bytes then RX 4bytes, 9times，during SPI communication core work load rate is 2.5% DMA模块提供动态加载DMA传输控制描述符（TCD）功能，当需要连续多次执行SPI传输时，使用这种功能可以进一步减少内核负荷。 DMA module provides dynamic scatter/gather feature, which supports automatically loading a new TCD into a DMA channel. Using this feature will reduce core work load in SPI transfer continuously. 测试结果(使用DMA动态加载功能)： Test Result(Using DMA dynamic scatter/gather feature )： 读取AT26DF081A设备9处不连续地址数据，需要花费130.68us，其中内核处理中断的时间为0.76us。 根据客户要求，依照此方法每次发送3个字节，接收4个字节，重复9次。SPI通信过程中内核负荷时间比率为 (0.76/101.88) =0.75% SPI read ID operation once, it will take 130.68 us , includes core deal with interrupt time 0.76us. According to this way, customer want to TX 3bytes then RX 4bytes, 9times，during SPI communication core work load rate is 0.75% 测试结论（Test conclusion） SPI通信过程中DMA模块使用方式不同对于减轻内核负荷作用差异明显。通常SPI进行大量数据传输接收，使用DMA模块能有效减少内核负荷。鉴于客户需求，使用测试场景二的方法可以有效降低内核负荷。 How to use DMA module to reduce core work load, different way lead to different result. In general, using DMA module do amounts of SPI data transfer will reduce core work load . According customer requirement, using test scenario 2 way reduce core work load dramatically。 为什么每次读操作之间需要SPI片选无效 （Why need deassert CS signal between each read operation）？ 根据AT26DF081A手册要求，读ID命令和读阵列命令都需要使片选信号无效用以结束当前的读操作，换言之如果要开始新的读操作，需要结束之前的通信（使片选信号无效）。 AT26DF081A datasheet indicates deasserting the CS pin will terminate the read operation and put the SO pin into a high-impedance state. In order to start new read command operation, it need deassert the CS pin. 计算客户要求每次读命令间隔时间为SPI实际通信时间（以5MHz波特率发送7个字节重复9次 100.8us）加上内核处理中断时间。 According customer requirement SPI each read command interval time is SPI communication time (TX 7bytes 9times with 5MHz baud rate take 100.8us) add core deal with interrupt time. 测试代码（Test source code） 测试代码基于Kientis 100MHz Rev2例程中的[spi_demo]工程，将测试代码替换<spi_demo.c>和<isr.h>文件即可。 Test source code is based on KINETIS512_V2_SC (Kientis 100MHz Rev2 Example Project) [spi_demo] project, using test code instead of orignial <spi_demo.c>&<isr.h> files.

       所谓“知识产权保护”，其实就是在产品量产之后防止其芯片内部代码通过外部调试器被有效读取出来的手段，毕竟现在来说硬件电路是比较容易被复制的，如果软件再不设防的话，在山寨技术如此发达的今天（用发达来形容貌似不是很过分吧，呵呵）这个产品估计很快就会被淘汰了。        因为最近有很多客户问到关于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

   1.  K60 eDMA 16-channel implementation Local memory containing transfer control descriptors for each of the 16 channels 32-byte TCD stored in local memory for each channel    2.  DMA memory to memory performance In the traditional M2M data movement, performance is best expressed as the peak data transfer rates In most implementations, this transfer rate is limited by the speed of the source and destination address spaces.     3.  eDMA peak transfer rate   4. Performance test         With K60 100MHz (TWR-K60D100M), implement internal SRAM-SRAM eDMA data transfer. If  transfer size setting as 32-bit in TCD Transfer Attributes (DMA_TCD_ATTR), there will has one wait state during each read/write. That's why the DMA performance doesn't up to 200MB/s as the manual stated.       We highly recommend setting DMA transfer size to 16-byte at DMA_TCD_ATTR register, it will much increase the DMA performance.(Get 162MB/s transfer rate with TWR-K60D100M board.) 5.  Testing code attached.

Hi All, Embedded systems industry are tending to optimized their products to offers a better performance in power management, aiming for longer battery life, using low-power modes in the application without reducing functionality. With this in mind, it arises a requirement in these compact devices, power supply monitor. This document will include a brief description of some features available in different power modes of the Kinetis family and it will focus on how we can implement these features, using KSDK 2.0, to monitor power supply voltage and detect when this voltage has fallen at determined value. This document is based MCU K21 but the same principles can be applied to any Kinetis K and L family. It will use KDS 3.2 as IDE and TWR-K21F120M evaluation board as target.   Hope you can find it useful Best Regards Jorge Alcala

The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&amp;CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&amp;E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 

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)

Please note that the document shown above is an approximation of the original document.

Introduction What is a gated timer and why would I need one? A gated timer is a timer whose clock is enabled (or "gated") by some external signal.  This allows for a low code overhead method of synchronizing a timer with an event and/or measuring an event. This functionality is not commonly included on Freescale microcontroller devices (this functionality is only included on devices that are equipped with the upgraded TPM v2 peripheral; currently K66, K65, KL13, KL23, KL33, KL43, KL03) but can be useful in some situations.  Some applications which may find a gated timer useful include asynchronous digital sampling, pulse width duty cycle measurement, and battery charging. How do I implement a gated timer with my Kinetis FTM or TPM peripheral? To implement a true gated timer with a Kinetis device (that does not have the TPM v2 peripheral), additional hardware will be required to implement the enable/disable functionality of a gated timer.  This note will focus on two different ways (low-true and high-true) to implement a gated timer.  The method used will depend on the requirements of your application. Implementing a gated timer for Kinetis devices without the TPM v2 peripheral requires the use of a comparator and a resistive network to implement a gated functionality (NOTE:  Level shifters could be used to replace the resistive network described; however, a resistive network is likely more cost effective, and thus, is presented in this discussion).  Figure 1 below is the block diagram of how to implement a gated timer functionality.  The theory behind this configuration will be explained in later sections. Theory of Operation Comparator and resistive network implementation The comparator is the key piece to implementing this functionality. For those with little experience with comparators (or need a refresher), a comparator is represented by the following figure.  Notice that there are three terminals that will be of relevance in this application: a non-inverting input (labeled with a '+' sign), an inverting input (labeled with a '-' sign), and an output. A comparator does just what the name suggests: it compares two signals and adjusts the output based on the result of the comparison.  This is represented mathematically in the figure below. Considering the above figure, output of the comparator will be a  logic high when the non-inverting input is at a higher electric potential than the inverting input.  The output will be a logic low if the non-inverting input is at a lower electric potential than the inverting input.  The output will be unpredictable if the inputs are exactly the same (oscillations may even occur since comparators are designed to drive the output to a solid high or solid low).  This mechanism allows the clock enable functionality that is required to implement a gated timer function provided that either the non-inverting or inverting input is a clock waveform and the opposite input is a stable logic high or low (depending on the desired configuration) and neither input is ever exactly equal.  Comparator Configurations There are two basic signal configurations that an application can use to enable the clock output out of the comparator: low-true signals and high-true signals.  These two signals and some details on their implementation are explained in the following two sections.  Low-true enable A low-true enable is an enable signal that will have zero electric potential (relative to the microcontroller) or a "grounded" signal in the "active" state.  This configuration is a common implementation when using a push button or momentary switch to provide the enable signal.  When using this type of signal, you will want to connect the enable signal to the non-inverting input of the comparator, and connect the clock signal to the inverting input. The high level of the enable signal should be guaranteed to always be the highest voltage of the input clock plus the maximum input offset of the comparator. To find the maximum input offset of the comparator, consult the device specific datasheet.  See the figure below to see a graphical representation of areas where the signal will be on and off. The external hardware used should ensure that the low level of the enable signal never dips below the lowest voltage of the input clock plus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. High-true enable A high-true enable is an enable signal that will have an electric potential equal to VDD of the microcontroller in the "active" state.  This configuration is commonly implemented when the enable signal is provided by an active source or another microcontroller.  When interfacing with this type of signal, you will want to connect the enable signal to the inverting input of the comparator, and connect the clock signal to the non-inverting input.  When the comparator is in the inactive state, it should be at or below the lowest voltage of the clock signal minus the maximum input offset of the comparator.  Refer to the following figure for a diagram of the "on" and "off" regions of the high true configurations. The external hardware will need to guarantee that the when the enable signal is in the active state, it does not rise above the highest voltage of the clock signal minus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. Clocking Options Clocking waveform requirements will vary from application to application.  Specifying all of the possibilities is nearly impossible.  The point of this section is to inform what options are available from the Kinetis family and provide some insight as to when it might be relevant to investigate each option. The Kinetis family provides a clock output pin for most devices to allow an internal clock to be routed to a pin.  The uses for this option can vary.  In this particular scenario, it will be used to provide the source clock for the comparator clock input. Here are the most common clock output pin options across the Kinetis K series devices.  (NOTE:  If the application requires a clock frequency that the CLKOUT signal cannot provide, a separate FTM or TPM instance or another timer module can be used to generate the required clock.) In the Kinetis L series devices, the following options will be available. The clock option selected should be the slowest allowable clock for the application being designed.  This will minimize the power consumption of the application.  For applications that require high resolution, the Bus, Flash, or Flexbus clock should be selected (note that the Flexbus clock can provide an independently adjustable clock, if it is not being used in the application, as it is always running).  However, if the target application needs to be more power efficient, the LPO or MCGIRCLK should be used.  The LPO for the Kinetis devices is a fixed 1 kHz frequency and will, therefore, only be useful in applications that require millisecond resolutions.