Welcome to the FRDM-K64 mbed workshop, in this page you will find all the code examples we will review on this session. The program covers the following modules: GPIO Serial communication Interrupts PWM ADC I2C (Accelerometer) USB Ethernet Depending on how fast we advance during the session some of the modules might be skipped; however here you can find both the source code and binary files ready to be flashed into the FRDM-K64 development board. FRDM-K64Z120M The FRDM-K64 is fully compatible with the Arduino rapid prototyping system, the following image depicts the board's pinout, the green labels can be used directly into your mbed proyects, they have already been defined in the headers and libraries in order to make development easier. Sign up at mbed.org In order to create the projects covered on this session it is necessary to create an mbed user account, open the website and create a user account, if you have already signed up please log in. Mbed debugging application To enable the FRDM-K64 development board using the binary files generated by mbed it is necessary to update the board's firmware, follow the steps mentioned below in order to enable the board to be programmed: Press the board's reset button While pressing the reset button connect the board to your computer using the USB cable, it must be connected to the J26 USB connector. Once the unit has enumerated as "Bootloader", copy the 20140530_k20dx128_k64f_if_mbed.bin file into the unit Disconnect and reconnect the USB cable, the board must enumerate as "MBED" Serial communication driver To implement serial communication you need to install the serial driver in your computer, download the driver, once your board has enumerated as MBED execute the driver and wait for it to be finished, this might take a couple of minutes. Serial terminal In order to communicate with the board via serial port it is necessary to use a serial terminal, by default WIndows 7 and 8 do not have this application, XP does. If your OS does not feature a serial terminal, you can download the one at the bottom (Teraterm). ! Your board is now ready to be programmed using mbed!

分享自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.

When you go with your laptop to a public place and you don't have a wi-fi connection available you can connect your cellphone in the USB port of your computer, turn on the USB tethering feature of your smartphone and you get full acess to the internet using your carrier data plan. The USB tethering uses the the RNDIS protocol and is easy to implement on a laptop.   But how to connect a Kinetis to the internet using a cellphone?   I'm sharing the the first version of the implementation I made of the RNDIS protocol.It's based in the KSDK 1.3 + MQX + LwIP and it can be used for reference in other projects. It's only a first release and I plan some additional implementation, bugfixes and support for other Kinetis boards in the near future but it already can be useful in some projects. Initially it only supports FRDM-K22F and FRDM-K64F but it can be implemented in any MCU with USB controller and enough FLASH. It's a low-cost and simple way to connect your MCU to the internet when you don't have a Ethernet cable available or an Wi-fi connection or a 4G module available in your board.   Introduction   This project implements the RNDIS protocol on the top of the USB Host Stack and in the bottom of the LwIP (TCP/IP stack). When a cellphone is connected to a freedom board, it acts as a USB device and the Freedom board acts as a host.   * Software implementation * Cellphone connected to a FRDM-K64F providing internet connection to the board   The user can design his own software in the top of the TCP/IP stack (LwIP) like if it's connected through an ethernet cable.   Demonstration   To run the demo you will need the KDS 1.3 (www.nxp.com/kds).   To load all the projects needed to your project you have to extract the .zip file and in KDS go to File -> Import, Project of Projects -> Existing Project Sets, and browse to the *.wsd file present in the folder:   USB_RNDIS\KSDK_1.3.0\examples\[your board]\demo_apps\lwip\usb_tethering_demo\usb_tethering_demo_mqx\kds   It will import all the needed project in to your workspaces so you will be able to build all the projects and flash it into your board.   With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:     Connect your cellphone in to the USB of the MCU. After connect the phone turn on the USB tethering feature and wait some seconds:   The Freedom Board will be connected to the internet. As an example, this demo connects to an HTTP server in the internet, download to MCU some data (Lastest news from an newspaper website) and displays it through the Serial connection.   You can modify this demo for your own application, using the TCP/IP and UDP/IP provided by the LwIP.   Typical Aplications   - Low-cost temporary internet connectivity to the MCU. - Remote updat (i.e.: bootloader through USB downloading the new firmware direct from the web) - Remote control - Remote diagnostics   Known Issues and Limitations: - This first version was only full implemented for FRDM-K22F and FRDM-K64F. I can implement for other boards through requests. - It was tested on Android Phones (Samsung Galaxy, Motorola G, Motorola X). I don't have a iPhone to test yet. - Some cellphones need additional current to detect that is attached to a host.A external power is needed in this situation.For FRDM-K64F I suggest to use the J27 footprint to provide 5V and short the diode D13. - Not all the RNDIS messages was implemented yet, only the most fundamental ones. - There's a flash size limitation due the size of the TCP/IP stacks ( that requires a considerably space of flash). It can adapted in the future for stacks with smaller footprint. - Only support KDS 3.0 at this time. And it only supports MQX at this time.   Let me  know if you have any question. Hope it can be useful!   1-      With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:

最近搞了一个基于TWR-K20D50M的的USB MSD device bootloader, 可以打开文件夹CW中的K20D5下的.project来查看。 在原始的MSD的基础上移植了FAT过来。 其他IAR和Kinetis的其他chip没有测试，如果需要使用，一个是新增相关头文件，二是在bootloader.h中修改相应的MCU_K20D50M定义下的flash及ram配置

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

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

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

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

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

The USB OTG module in Kinetis parts uses a Buffer Descriptor Table (BDT) in system memory to manage USB endpoint communications, the BDT is a a 512-byte buffer and there are 3 registers in USB module to contain the base address for it, and it must be 512-byte aligned otherwise there would be issue during transfer. In USB stack ver 4.1.1, some Kinetis old parts like K60N512, K20D72M have the demo project basked on CodeWarrior ARM compiler, and in khci_kinetis.c, bdt is defined as following: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8_ptr bdt; but since the base address is defined as below: #define BDT_BASE               ((uint_32*)(bdt)) so the bdt definition is not correct , and we have to change it as below: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8 bdt[512];//uint_8_ptr bdt; and the definition for usb_dbt section can be found in MK20X256_flash.lcf. with above modification, we can make the demo of "msd_mfs_generic" work well as expected. Please kindly refer to the following result got from TWR-K20D72M. FAT demo Waiting for USB mass storage to be attached... Mass Storage Device Attached ****************************************************************************** * FATfs DEMO * * Configuration:  LNF Enabled, Code page =1258 * ****************************************************************************** ****************************************************************************** * DRIVER OPERATION * ****************************************************************************** 1. Demo function: f_mount   Initializing logical drive 0...   Initialization complete ----------------------------------------------------------------------------- 2. Demo functions:f_getfree, f_opendir, f_readdir getting drive 0 attributes............... Logical drive 0 attributes: FAT type = FAT16 Bytes/Cluster = 2048 Number of FATs = 2 Root DIR entries = 512 Sectors/FAT = 250 Number of clusters = 63858 FAT start (lba) = 36 DIR start (lba,clustor) = 536 Data start (lba) = 568 ... 127716 KB total disk space. 127624 KB available. ----------------------------------------------------------------------------- ****************************************************************************** * DRECTORY OPERATION * ****************************************************************************** 1. Demo functions:f_opendir, f_readdir Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 2. Demo functions:f_mkdir 2.0. Create <Directory_1> 2.1. Create <Directory_2> 2.2. Create <Sub1> as a sub directory of <Directory_1> 2.3. Directory list Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 3. Demo functions:f_getcwd, f_chdir 3.0. Get the current directory     CWD: 0:/ 3.1. Change current directory to <Directory_1> 3.2. Directory listing Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---- 2010/01/01 00:00         0  sub1 0    File(s),         0 bytes total 3    Dir(s) 3.3. Get the current directory     CWD: 0:/Directory_1 ----------------------------------------------------------------------------- 4. Demo functions:f_stat(File status), f_chmod, f_utime 4.1. Get directory information of <Directory_1>     DR--- 2010/12/25 23:30         0 Directory_1 4.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 4.3. Set Read Only Attribute to Directory_1 4.4. Get directory information (Directory_1)     DR--- 2010/12/25 23:30         0 Directory_1 ----------------------------------------------------------------------------- 5. Demo functions:f_rename Rename <sub1> to <sub1_renamed> and move it to <Directory_2> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---A 2010/01/01 00:00         0 SUB1_R~1 0    File(s),         0 bytes total 3    Dir(s) ----------------------------------------------------------------------------- 6. Demo functions:f_unlink Delete Directory_1/sub1_renamed Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) ****************************************************************************** * FILE OPERATION * ****************************************************************************** 1. Demo functions:f_open,f_write, f_printf, f_putc, f_puts, fclose 1.0. Create new file <New_File_1> (f_open)     File size =    0 1.1. Write data to <New_File_1>(f_write) 1.2. Flush cached data     File size =   52 1.3. Write data to <New_File_1> (f_printf) 1.4. Flush cached data     File size =  103 1.5. Write data to <New_File_1> (f_puts) 1.6. Flush cached data     File size =  152 1.7. Write data to <New_File_1> uses f_putc function 1.8. Flush cached data     File size =  199 1.9. Close file <New_File_1> ----------------------------------------------------------------------------- 2. Demo functions:f_open,f_read, f_seek, f_gets, f_close 2.0. Open <New_File_1> to read (f_open) 2.1. Get a string from file (f_gets)     Line 1: Write data to  file uses f_write function 2.2. Get the rest of file content (f_read)     Line 2: Write data to file uses f_printf function Line 3: Write data to file uses f_puts function Line 4: Write data to file uses f_putc functionûöF¬ â•:7Rz}™ yzjw8¸×áÀ—»ÃЭ¹òÍ­ ä‹Hïk¨Wã½c'     ²7këÞÑ%VrC×»Ô¼ÒSÈÑèR+NjD¡¾òû>ú3‰SËþo^ÎI Pë±ñ‰þ/Directory_1[1] 2.3. Close file (f_close) ----------------------------------------------------------------------------- 3. Demo functions:f_stat, f_utime, f_chmod 3.1. Get  information of <New_File_1> file (f_stat)     ----A 2010/01/01 00:00       199  New_File_1.dat 3.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 (f_utime) 3.3. Set Read Only Attribute to <New_File_1> (f_chmod) 3.4. Get directory information of <New_File_1> (f_stat)     -R--A 2010/12/25 23:30       199  New_File_1.dat 3.5. Clear Read Only Attribute of <New_File_1> (f_chmod) 3.6. Get directory information of <New_File_1>     ----A 2010/12/25 23:30       199  New_File_1.dat ----------------------------------------------------------------------------- 4. Demo functions:f_ulink Rename <New_File_1.dat> to  <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     ----A 2010/12/25 23:30       199  FILE_R~1.TXT 1    File(s),       199 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 5. Demo functions:f_truncate Truncate file <File_Renamed.txt> 5.0. Open <File_Renamed.txt> to write 5.1. Seek file pointer     Current file pointer:    0     File pointer after seeking:  102 5.2. Truncate file     File size =  102 5.3. Close file ----------------------------------------------------------------------------- 6. Demo functions:f_forward 6.0. Open <File_Renamed.txt> to read 6.1. Forward file to terminal Line 1: Write data to  file uses f_write function Line 2: Write data to file uses f_printf function 6.2. Close file ----------------------------------------------------------------------------- 7. Demo functions:f_ulink Delete <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) *------------------------------ DEMO COMPLETED    ------------------------ * ******************************************************************************

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.

Overview          KBOOT v2.0 had been released in the Q2 of the 2016 and it has a lot of new features versus the previous version. For instance, the USB peripheral can work as Mass Storage Class device mode now, not just only supports the HID interface. And in following, USB MSD Bootloader implementation will be illustrated. Preparation FRDM-K64F board Fig1 FRDM-K64F KBOOT v2.0 downloading: KBOOT v2.0 IDE: IAR v7.50 Application demo: KSDK v2.0   Flash-resident bootloader           The K64_120 doesn’t contain the ROM-based bootloader, so the flash-resident bootloader need to be programmed in the K64 and the flash-resident bootloader can be used to download and program an initial application image into a blank area on the flash, and to later update the application.         I. Open the the bootloader project, for instance, using the IAR and select the freedom_bootloader demo         The Fig 2 illustrates the bootloader project for K64 which resides in ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloade r_2_0_0\targets\MK64F12. Fig 2      II. After compiles the demo, then clicks the  button to program the demo to the K64 Linker file modification       According to the freedom_bootloader demo, the vector table relocation address of the application demo has been adapted to the 0xa000 (Table 1), however the default start address of the application is 0x0000_0000. So it’s necessary to modify the linker file to fit the freedom_bootloader and the Table 2 illustrates what the modifications are.                                                     Table 1 // The bootloader will check this address for the application vector table upon startup. #if !defined(BL_APP_VECTOR_TABLE_ADDRESS) #define BL_APP_VECTOR_TABLE_ADDRESS 0xa000 #endif                                                   Table 2 define symbol __ram_vector_table_size__ = isdefinedsymbol(__ram_vector_table__) ? 0x00000400 : 0; define symbol __ram_vector_table_offset__ = isdefinedsymbol(__ram_vector_table__) ? 0x000003FF : 0; //define symbol m_interrupts_start       = 0x00000000; //define symbol m_interrupts_end         = 0x000003FF; define symbol m_interrupts_start       = 0x0000a000; define symbol m_interrupts_end         = 0x0000a3FF; //define symbol m_flash_config_start     = 0x00000400; //define symbol m_flash_config_end       = 0x0000040F; define symbol m_flash_config_start     = 0x0000a400; define symbol m_flash_config_end       = 0x0000a40F; //define symbol m_text_start             = 0x00000410; define symbol m_text_start             = 0x0000a410; define symbol m_text_end               = 0x000FFFFF; define symbol m_interrupts_ram_start   = 0x1FFF0000; define symbol m_interrupts_ram_end     = 0x1FFF0000 + __ram_vector_table_offset__; define symbol m_data_start             = m_interrupts_ram_start + __ram_vector_table_size__; define symbol m_data_end               = 0x1FFFFFFF; define symbol m_data_2_start           = 0x20000000; define symbol m_data_2_end             = 0x2002FFFF; /* Sizes */ if (isdefinedsymbol(__stack_size__)) {   define symbol __size_cstack__        = __stack_size__; } else {   define symbol __size_cstack__        = 0x0400; } if (isdefinedsymbol(__heap_size__)) {   define symbol __size_heap__          = __heap_size__; } else {   define symbol __size_heap__          = 0x0400; } define exported symbol __VECTOR_TABLE  = m_interrupts_start; define exported symbol __VECTOR_RAM    = isdefinedsymbol(__ram_vector_table__) ? m_interrupts_ram_start : m_interrupts_start; define exported symbol __RAM_VECTOR_TABLE_SIZE = __ram_vector_table_size__; define memory mem with size = 4G; define region m_flash_config_region = mem:[from m_flash_config_start to m_flash_config_end]; define region TEXT_region = mem:[from m_interrupts_start to m_interrupts_end]                           | mem:[from m_text_start to m_text_end]; define region DATA_region = mem:[from m_data_start to m_data_end]                           | mem:[from m_data_2_start to m_data_2_end-__size_cstack__]; define region CSTACK_region = mem:[from m_data_2_end-__size_cstack__+1 to m_data_2_end]; define region m_interrupts_ram_region = mem:[from m_interrupts_ram_start to m_interrupts_ram_end]; define block CSTACK    with alignment = 8, size = __size_cstack__   { }; define block HEAP      with alignment = 8, size = __size_heap__     { }; define block RW        { readwrite }; define block ZI        { zi }; initialize by copy { readwrite, section .textrw }; do not initialize  { section .noinit }; place at address mem: m_interrupts_start    { readonly section .intvec }; place in m_flash_config_region              { section FlashConfig }; place in TEXT_region                        { readonly }; place in DATA_region                        { block RW }; place in DATA_region                        { block ZI }; place in DATA_region                        { last block HEAP }; place in CSTACK_region                      { block CSTACK }; place in m_interrupts_ram_region            { section m_interrupts_ram }; SB file generation     I. Brief introduction of SB file         The Kinetis bootloader supports loading of the SB files. The SB file is a Freescale-defined boot file format designed to ease the boot process. The file is generated using the Freescale elftosb tool. The format supports loading of elf or srec files in a controlled manner, using boot commands such as load, jump, fill, erase, and so on. The boot commands are prescribed in the input command file (boot descriptor .bd) to the elftosb tool. The format also supports encryption of the boot image using AES-128 input key.          And right now, the USB MSD bootloader only support SB file drag and drop.    II. Generate the BIN file         After open the hello_world demo in the IAR, using project options dialog select the "Output Converter" and change the output format to "binary" for outputting .BIN format image (Fig 3). Next, build the application demo, then the .BIN file will be generated after the building completes. Fig 3      III. Create BD file There is a template BD file which resides in the ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\src. Next, adapt the BD file by referring to the Kinetis Elftosb User's Guide, the following table shows the BD file content.                                                    Table 3 sources {         # BIN File path         myBINFile = "hello_world.bin"; } section (0) {         #1. Erase the internal flash         erase 0x0000a000..0x0010000;         #2. Load BIN File to internal flash         load myBINFile > 0xa000;         #3. Reset target.         reset; }      IV.  SB file generation          After creating the BD file shown in the following figure, copy the "hello_world.bin", elftosb.exe, and the BD file into the same directory. Then, open the window with command prompt and invoke elftosb such as “elftosb –V –c FRDM-K64F.bd –o image.sb”. The elftosb processes the FRDM-K64F.bd file and generates an image.sb file. Elftosb also outputs the commands list as shown in Fig 4. Fig 4     V. Application code updating       Plug a USB cable from the PC to the USB connector J26 to power the board , then keep holding the button SW2 down until press and release the Reset button SW1, it can force the K64_120 enter the BOOTLOADER mode. Next, plug another USB cable from the PC to the USB connector J22 (Fig 5), the FSL Loader will come out after completes the enumeration and it will appear as a removable storage driver (Fig 6).  Copy & paste or drag & drop the image.sb to the FSL Loader drive to update the application code, and the Fig 7 illustrates the result of application code runs. Fig 5 Fig 6 Fig 7

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

When using ADCs it is not enough to just configure the module, add a clock signal, apply the Nyquist criteria and hope for the best, because normally that is just not enough. Even if we use the best software configuration, sampling rate, conversion time, etc; we might end up with noisy conversions, and worst of all a low ENOB figure which sums up in a lousy, low resolution ADC application. To complement the software end you need to follow some basic hardware design rules, some of them might seem logical, other might even weird or excessive however they are the key to a successful conversion, I took the time to compile a short list of effective design best practices trying to cover the basics of ADC design. If you think I missed something feel free to comment and ask for more information. Ground Isolation Because ground is the power return for all digital circuits and analog circuits, one of the most basic design philosophies is to isolate digital and analog grounds. If the grounds are not isolated, the return from the analog circuitry will flow through the analog ground impedance and the digital ground current will flow through the analog ground, usually the digital ground current is typically much greater than the analog ground current.  As the frequency of digital circuits increases, the noise generated on the ground increases dramatically. CMOS logic families are of the saturating type; this means the logic transitions cause large transient currents on the power supply and ground. CMOS outputs connect the power to ground through a low impedance channel during the logic transitions. Digital logic waveforms are rectangular waves which imply many higher frequency harmonic components are induced by high speed transmission lines and clock signals.                              Figure 1: Typical mixed signal circuit grounding                              Figure 2: Isolated mixed signal circuit grounding Inductive decoupling Another potential problem is the coupling of signal from one circuit to another via mutual inductance and it does not matter if you think the signals are too weak to have a real effect, the amount of coupling will depend on the strength of the interference, the mutual inductance, the area enclosed by the signal loop (which is basically an antenna), and the frequency. It will also depend primarily on the physical proximity of the loops, as well as the permeability of the material. This inductive coupling is also known as crosstalk in data lines.                               Figure 3: Coupling induced noise It may seem logical to use a single trace as the return path for the two sources (dotted lines). However, this would cause the return currents for both signals to flow through the same impedance, in addition; it will maximize the area of the interference loops and increase the mutual inductance by moving the loops close together. This will increase the mutual noise inductance and the coupling between the circuits. Routing the traces in the manner shown below minimizes the area enclosed by the loops and separates the return paths, thus separating the circuits and, in turn, minimizing the mutual noise inductance.                               Figure 4: Inductance decoupling layout Power supply decoupling The idea after power decoupling is to create a low noise environment for the analog circuitry to operate. In any given circuit the power supply pin is really in series with the output, therefore, any high frequency energy on the power line will couple to the output directly, which makes it necessary to keep this high frequency energy from entering the analog circuitry. This is done by using a small capacitor to short the high frequency signals away from the chip to the circuit’s ground line. A disadvantage of high frequency decoupling is it makes a circuit more prone to low frequency noise however it is easily solved by adding a larger capacitor. Optimal power supply decoupling A large electrolytic capacitor (10 μF – 100 μF) no more than 2 in. away from the chip. A small capacitor (0.01 μF – 0.1 μF) as close to the power pins of the chip as possible. A small ferrite bead in series with the supply pin (Optional).                               Figure 5: Power supply decoupling layout Treat signal lines as transmission lines Although signal coupling can be minimized it cannot be avoided, the best approach to effectively counteract its effects on signal lines is to channel it into a conductor of our choice, in this case the circuit’s ground is the best choice to channel the effects of inductive coupling; we can accomplish this by routing ground lines along signal lines as close as manufacturing capabilities allow. An very effective way to accomplish this is routing signals in triplets, these works for both digital and analog signals.The advantages of doing so are an improved immunity not only to inductive coupling but also immunity to external noise. Optimal routing: Routing in “triplets” (S-G-S) provide good signal coupling with relatively low impact on routing density Ground trace needs to be connected to the ground pins on the source and destination devices for the signal traces Spacing should be as close as manufacturing will allow                               Figure 6: Transmission line routing Signal acquisition circuit To improve noise immunity an external RC acquisition circuit can be added to the ADC input, it consists of a resistor in series with the ADC input and a capacitor going from the input to the circuit’s ground as the figure below shows:                                                             Figure 7: ADC with an external acquisition circuit The external RC circuit values depend on the internal characteristics and configuration of the ADC you use, such as the availability of an internal gain amplifier or the ADC’s architecture; the equation and circuit shown here represents a simplified form of ADC used in Freescale devices. The equivalent sampling resistance RSH is represented by total serial resistance connected between sampling capacitance and analog input pin (sampling switch, multiplexor switches etc.). The sampling capacitance CSH is represented by total parallel capacitance. For example in a case of Freescale SAR ADC equivalent sampling capacitance contains bank of capacitances. The equation shown how to calculate the value of the input resistor based on the values of both the input and sample and hold circuit. It must be noted the mentioned figures could have an alternate designation in any given datasheet; the ones mentioned here are specific to Kinetis devices: TAQ=      Acquisition time (.5/ADC clock) CIN=       Input capacitance (33pF min) CSH=      Sample & Hold circuit capacitance ( CDAIN in datasheet) VIN=       Input voltage level VCSH0= Initial voltage across S&H circuit (0V) VSFR=    Full scale voltage (VDDA) N=           bit resolution Note:  Special care must be taken when performing the calculation since a deviation from the correct values will result in a significant conversion error due to signal distortion.

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 article describes how to do in-system reprogramming of Kinetis for Cortex-M4 core devices using standard communication media such as SCI. Most of the codes are written in C so that make it easy to migrate to other MCUs. The solution has been adopted by customers. This bootloader is based on FRDM-K22 demo board and KDS3.0. The bootloader and user application source codes are provided. GUI is also provided. Customer can make their own bootloader applications based on them. The application can be used to upgrade single target board and multi boards connected through networks such as RS485. The bootloader application checks the availability of the nodes between the input address range, and upgrades firmware nodes one by one automatically. Key features of the bootloader: Able to update (or just verify) multiple devices in a network. Application code and bootloader code are in separated projects, convenient for mass production and firmware upgrading. Bootloader code size is small, only around 3k, which reduces on chip memory resources. Source code available, easy for reading and migrating. For Cortex-M0+ products, please refer to here :Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+ , it based on FRDM-KL26. The main difference between Cortex-M4 and Cortex-M0+ is the FLASH program routine. - In Cotex-M4 core kinetis, we need copy the Flash operating routines to RAM. In the bootloader code, the copy to ram code is realized in the function of “FLASH_Initialization()”: Byte buffer[200]={0}; - In Cotex M0+ core kinetis, we do not need to copy the Flash operating routines to RAM. Platform Control Register (MCM_PLACR) is added. The MCM_PLACR register selects the arbitration policy for the crossbar masters and configures the flash memory controller. Enabling ESFC bit can stall flash controller when flash is busy.  Setting ESFC bit can well-balance time sequence of Flash reading and writing – when writing Flash, reading Flash instruction can wait, and vice versa. Using ESFC bit can make our flash programming easier. Thus one Flash can write itself, which is not possible for other one Flash MCU without ESFC bit control. ESFC bit is easy to be set in C code: For more information, please see attached document and code. User can also download the document and source code from Github: https://github.com/jenniezhjun/Kinetis-Bootloader.git