In the practical KE KEA usage, a lot of customers meet the watchdog can’t reset problems. Some customers find when they want to enable the watchdog, but can’t really enable the watchdog by set the EN bit in register WDOG_CS1; Some customers find when in debug mode, the EN bit WDOG_S1 register always be clear, but from the reference manual, this bit should be set after reset, even they check their code, and make sure they didn’t disable the watchdog;  There also have some customers find when they use the KEXX_DRIVERS_V1.2.1_DEVD code, and set the timeout value register by themselves, but the watchdog can’t reset in the timeout value. Now according to these problems, this document will analyze it and give the recommendation to avoid these problems.      From the above problem description, we can get that there actually mainly 2 reasons caused these problems: 1, software configuration; 2, debugger usage 1.  Software configuration   1) Start code disable the watchdog In the KE KEA sample code, after reset, the chip will enter in the start code at first, the start code always disable the watchdog at first, if the watchdog is disabled, the watchdog can’t be enable just by set the EN bit in register WDOG_CS1, because bit EN in register WDOG_CS1 is the write-once bit after reset. It only can be modified when the UPDATE bit is set and with 128 bus clocks after performing the unlock write sequence. Now how to find the disable code in the start code? Take KEXX_DRIVERS_V1.2.1_DEVD sample code as an example IAR: from crt0.s, will find the watchdog disable code WDOG_DisableWDOGEnableUpdate();  in the start function. The above IAR start picture is for KE, but in the KEA start file, you can’t see the start function in the KEA sample code which download from the freescale web, just find the __iar_program_start in cstartup_M_KEA128.s after the reset happens, but where is the __iar_program_start function, it can’t be searched in the whole project. Actually __iar_program_start is the default program entry function, it include the following function: You can find it will enter __low_level_init function, the watchdog disable code is just in  __low_level_init function. MDK:  From startup_MK0XZ4.s will find the watchdog disable code in the SystemInit function. Codewarrior: From __arm_start.c file, will find the watchdog disable code in __init_hardware function. 2) Codewarrior script init_kinetis.tcl disable the watchdog      To the Codewarrior, just comment the disable watchdog code in the __arm_start.c file is not enough to check the watchdog enable after reset, because in the codewarrior connect script init_kinetis.tcl, there also have the watchdog disable code.      If you want to find the state of EN bit in register WDOG_S1 after reset, you must disable all these watchdog disable code.   3) Timeout register configuration incorrect From the header file MKE02Z2.h, we can find the time out register define like this:   union {                                          /* offset: 0x4 */     __IO uint16_t TOVAL;                             /**< WDOG_TOVAL register., offset: 0x4 */     struct {                                         /* offset: 0x4 */       __IO uint8_t TOVALH;                             /**< Watchdog Timeout Value Register: High, offset: 0x4 */       __IO uint8_t TOVALL;                             /**< Watchdog Timeout Value Register: Low, offset: 0x5 */     } TOVAL8B; This structure means that customer can define the watchdog timeout value by separated unit8 TOVALH, TOVALL or just defined it with unint16 TOVAL. But actually in the IAR project usage, take an example, use 1khz as the clock source for watchdog, then want to set the timeout value as 1s, it means the timeout value should be 1000=0x03e8, so one of the customers configure it like this:    You can find, we need the TOVALL= 0XE8, TOVALH=0X03, but from the test result, the register is TOVALL= 0X03, TOVALH=0Xe8, this will cause the timeout value is much larger than 1000, that is why customer can’t reset the mcu after 1s, because the register configuration is not correct. It is caused by the IAR int16 store endian mode, the default IAR endian mode is little endian mode. So in the practical usage, it is recommended to use the separated time out value definition. 2. debugger usage When in debug mode with IDE, some customers find even they comment all the watchdog disable code, they still can’t reset the MCU by the watchdog. After check the register WDOG_S1, bit EN is 0, it means the watchdog is disabled. But from the reference manual, we get that after reset, the EN bit should be 1. What caused this? After test, we find this actually caused by the debugger, the debugger hardware which you are using. Eg, in the same project which already comment all the watchdog disable code, SEGGER JLINK will still disable the watchdog, but the PE opensda or PE multilink won’t do this, the EN bit is enabled by default, the following is the test picture, take codewarrior as an example: 1) JLINK 2) PE Opensda or PE multilink    So, if you want to test the watchdog in debug mode, and want the EN is set after reset, you can choose PE debugger tool instead of JLINK, but this JLINK feature is just influence the debug mode, after you download the code to the chip flash, and after reset, the EN bit in WDOG_S1 will still be set. Wish this document will help you get out the problem of watchdog can’t be reset.

How to byte program SPI flash via QSPI QSPI module are used in many Kinetis MCU, like K8x, K27/28 and KL8x. QSPI expands the internal flash range and can run in a fast speed. Compared to DSPI, QSPI is very complex and often takes a lot of time to learn. In KSDK there are two QSPI demo which shows how to program SPI flash in DMA mode and polling mode. Both of them program the QSPI flash with a word type array. But can the QSPI module program SPI Flash in byte? Yes, this article shows how to do it. Device: FRDM_KL82Z Tool: MCUXpresso IDE Debug firmware: JLINK I build the test project base on KL82 SDK/driver_example/qspi/polling_transfer. To byte program SPI flash, a new LUT item must be added. uint32_t lut[FSL_FEATURE_QSPI_LUT_DEPTH] =    {/* Seq0 :Quad Read */          /* CMD:       0xEB - Quad Read, Single pad */          /* ADDR:       0x18 - 24bit address, Quad pads */          /* DUMMY:     0x06 - 6 clock cyles, Quad pads */          /* READ:       0x80 - Read 128 bytes, Quad pads */        …        …        [32] = QSPI_LUT_SEQ(QSPI_CMD, QSPI_PAD_1, 0x02, QSPI_ADDR, QSPI_PAD_1, 0x18),        [13] = QSPI_LUT_SEQ(QSPI_WRITE, QSPI_PAD_1, 0x1, 0, 0, 0),        …        /* Match MISRA rule */        [63] = 0}; This item tells system how to program a single byte. Then when we write the data to TxBuffer, we must write the byte 4 times. This is because a write transaction on the flash with data size of less than 32 bits will lead to the removal of four data entry from Txbuffer. The valid bit will be used and the rest of the bits will be discard. Then before we start programming, we must set the data size.      QSPI_SetIPCommandSize(EXAMPLE_QSPI,1);   After byte program, we can see the result from 0x68000000. Attachment is the demo project. You can find that 0x03 was written to 0x68000005 after running.

作者 Shaozhong Liang         MQX4.0支持长文件名(Long FileName),但不支持中文长文件名。在MQX创建长文件名的文件时，只是简单地将文件名对应的字符串由转换为UNICODE编码。         如果使用的是拉丁字母，其编码将会被补全为2个字节，前面一个字节为0x00，例如字符“A”的编码是0x0041，是0x00接上字符对应的ASCII码。这个编码方式在英文字符串上编解码不成问题。         但是中文的表示方式是以GB2312编码方式，用2个字节来表示一个中文字。         例如中文字“啊”，对应的GB2312码为0xB0A1，MQX会将这2个字节拆分为0xB0和0xA1，然后分别进行UNICODE编码，这时候“啊”的编码将是0x00B0，0x00A1，变成4个字节的UNICODE编码。         最终将导致错误乱码，“啊”因此会被译码显示成  °  和  ¡         而实际上“啊”在UNICODE编码为0x554A，为了MQX能够支持中文长文件名，此时我们需要对GB2312和UNICODE进行转换。         我们需要对MFS源代码进行修改。现在修改后的代码只支持创建文件，暂时不支持修改已经存在的中文长文件名文件。         将附件中的文件替换原有的文件，重新编译MFS库和应用程序即可。         按照这种方法修改后，对中文字对应的GB2312编码范围进行UNICODE的转换，处理后文件名将支持中文，同时也可以实现中英文文件名的混用。 mfs\source\generic\mfs_entry.c 修改了函数MFS_create_directory_entry mfs\source\generic\mfs_lfn.c 增加了长文件名保存函数MFS_lfn_save 增加了oem字符集到unicode字符集的转换函数MFS_oem2unicode，用户层的代码直接使用中文文件名，有转换函数转换为对应的UNICODE编码。 由于GB2312全集占用空间太大，用户可以将gb2unicode.c的字符集表oem2unicode_table中数据进行精简。 mfs\source\include\mfs_prv.h 增加了上述函数声明。 Original Attachment has been moved to: lfn_mfs.rar

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

Fat File System for SD card using SPI for Kinetis-K60, K22 and K20

Using five channels from FTM2 module of the KE02 microcontroller included on the FRDM-KE02Z board for controlling a robotic arm powered by five servomotors. Each servomotor is controlled by a couple of buttons of a matrix keyboard, which is connected to eigth GPIOs. Interrupts are not used in this example. The code was generated and compiled on CodeWarrior for Microcontrollers v10.5.

Heart rate monitors measure the heart rate during exercise or vigorous activity and gauge how hard the patient is working. Newer heart rate monitors consist of two main components: a signal acquisition sensor/transmitter and a receiver (wrist watch or smart phone). In some cases, the signal acquisition is integrated into fabric worn by the user or patient. MCUs analyze the ECG signal and determine the heat rate, while an 8-bit MCU can suffice for a simple heart rate monitor. For more complex analysis, such as heart rate variability, activity level and breathing rate, a high-end 32-bit MCU may be used. Furthermore, low power wireless technologies are used to allow the sensor to communicate to the receiver. Freescale offers 8-bit and 32-bit MCUs that are applicable across the entire spectrum of heart rate monitors. In addition, the Freescale portfolio includes inertial sensors or accelerometers for activity monitoring and ZigBee® and proprietary wireless solutions to enable communication between the sensors and the receiver. For more information go to freescale.com/APLHRM

Timer PWM Module presented by Ali Piña. Module Explanation Connection Diagram Output compare Configuration Hands-On Input Campture Configuration Hands-On Overflow Configuration Hands-On Modulo de Timer y PWM presentado por Ali Piña. Explicación del modulo. Diagrama de conexión. Configuración para output compare. Hands-on Configuración como Input Capture. Hands-On Configuración del Overflow. Hands-On

Making and Downloading Security Image for Kinetis Device   Introduction KINETIS devices have Flash base bootloader or ROM bootloader. They have same structure and same download tools. MCUBOOT shows supported device. The bootloader not only support plaintext image, but also encrypted image which is encrypted by AES. This can protect user’s application code from unauthorized using. Due to different internal Flash structure, security image making, key download and image download flow is a bit different to each Kinetis devices. This hands-on will introduce Flash base bootloader and ROM base bootloader security image making and downloading.   2 Security image to Flash bootloader Many NXP Kinetis device SDK have integrated bootloader. Take FRDM-K64F as example, the bootloader project is in SDK_2.8.0_FRDM-K64F\boards\frdmk64f\bootloader_examples\freedom_bootloader The bootloader support security format image by default. User can download security format image via UART and USB interface. In K64 bootloader, the key is stored in 0xb000. But the application code is start from 0xa000. That means each time the application is upgraded, key file need to be download again.   2.1 Generate key The elftosb tool can generate a key. But of course, you can take any string as key.     2.2 Image encryption Use the key to encrypt application image. Here is the bd file. options {  flags = 0x4; // 0x8 encrypted + signed, 0x4 encrypted  buildNumber = 0x1;  productVersion = "1.00.00";  componentVersion = "1.00.00";  keyCount = 1; }   sources {  inputFile = extern(0);  sbkey = extern(1); }   section (0) {  erase 0xa000..0xF6000; load inputFile > 0xa000; }       2.3 Download key and image Connect FRDM-K64F openSDA usb port. Then download key and image.     2.4 Download key with KinetisFlashTool Use keyboard to input key is really annoying. There is a GUI tool named KinetisFlashTool which can download image same as blhost.exe. To download encrypted image by this tool, we can make a sb file to download key first. Here is the bd file.   sources { } section (0) {        erase 0xb000..0xc000;        load {{E0BAA2C8231283CAF1D327CEDB82AFF9}} > 0xb000; }   Using elftosb to generate the sb file. The elftosb command line is as below \>Elftosb -V -c program_key.bd -o program_key.sb   This sb file should be download at first, then download the encrypted application image. When customer want to download security image via USB MSC or HID, this is the only way to download key. There is a limitation in those bootloader which version is lower or equal to v2.7.0. MSC function and HID function can’t be enabled together. Otherwise bootloader will fail when copy encrypted sb file to MSC disk.   2.5 About the key But it is really strange that key file should always come with encrypted file. It is reasonable to keep the key in secure status, for example, an untouched place in flash. K64 has a program once field which is located in program flash IFR. This is a standalone space different from main space. It’s address is from 0x3C0 to 0x3FF. MCU core can read or write this area by special flash command. We can put the AES key here. Again, we can use sb file to download this key. sources { } section (0) {        load ifr 0xE0BAA2C8 > 0x3c0;        load ifr 0x231283CA > 0x3c1;        load ifr 0xF1D327CE > 0x3c2;        load ifr 0xDB82AFF9 > 0x3c3; } Then we should modify sbloader_init() in sbloader.c. The source code only read key form 0xb000. We should have it read key from IFR.   Security image to ROM bootloader Some Kinetis device has ROM bootloader. They are different with flash base bootloader. This document use FRDM-K32L2A as example.   3.1 Generate AES key and download the key The key can be set as 0x112233445566778899aabbccddeeff00. Besides sb file, it can also be programmed to IFR by blhost command. \>blhost -p COM9 – flash-program-once 0x30 4 11223344 msb \>blhost -p COM9 – flash-program-once 0x31 4 55667788 msb \>blhost -p COM9 – flash-program-once 0x32 4 99aabbcc msb \>blhost -p COM9 – flash-program-once 0x33 4 ddeeff00 msb If you do not write anything to IFR, the ROM bootloader will use all-zero key. Here I use all-zero key.   3.2 Encryption algorithm The ROM bootloader hasn’t encryption algorithm. Application should include algorithm code and assign the address to bootloader, or preprogram BCA table and MMCAU code into flash. You can find MMCAU code (mmcau_cm0p.bin) and BCA(BCA_mmcau_cm0p.bin) table in MCUBoot2.0.0 package. Before you program these code into flash, new address must be written into it. For example, we put MMCAU code into 0x7f800, then we should modify the BCA table as below     And then, according this new address, modify the MMCAU_function_info structure in mmcau_cm0p.bin.   After that, download BCA to 0x3c0 and mmcau_cm0p.bin to 0x7f800.   In order to avoid using manual operation in production, above steps can be integrate in a single sb file.   3.3 Encrypt the image and download The bd file in K64 example can be reused, just need to change the image address to 0x00.   Press the reset button, after 5 second, the led will blink.   References: Kinetis Bootloader v2.0.0 Reference Manual Kinetis Elftosb User's Guide Kinetis Bootloader QuadSPI User's Guide Kinetis blhost User's Guide

  1 Introduction    Previously we used sd card to upgrade the program. We have to insert the sd card into the computer every time, copy the program to the sd card, and then insert it into the sd card slot of mcu to update the program. This method seems to be a bit troublesome, so we implemented a more convenient method. It no longer needs to insert or remove the SD card from PC and MCU. Use the usb function of mcu to recognize mcu as a storage U disk. When we need to update the program, connect the MCU’s usb interface to PC. After the computer recognizes it, copy the program that needs to be burned in. Then the bootloader will recognize the file and then upgrade the application. Bootloader detects changes of the file, not the existence of the file. In other words, if the a000.bin file has already existed in the sd card, the application will not be updated. When this a000.bin is overwritten with another a000.bin, the operation of updating the application will be performed.   2  Bootloader’s implementation The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1. Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK. You can download the SDK in our website. The link is “mcuxpresso.nxp.com”.   The schematic for USB is shown below.                                                                                                        Figure 2. Schematic of USB   Bootloader uses SDHC, fatfs, usb, flash, So we should add files to support them. Our code is based on the example “usb_device_msc_sdcard_lite” that belongs to usb example.   In main code, the program will initialize the usb, sd and fatfs. Then the computer will communicate will MCU. Finally, PC will recognize the mcu as a u-disk.                Figure 3.u-disk The method of how to update the program and prepare the application has written in this document. You can refer it. https://community.nxp.com/docs/DOC-344903   Use a variable “wrFlag” to check the modification of the file. When we put file into the u-disk, this variable will be set.                                           Figure 4. Modification of flag When this variable is set, the program will open the “a000.bin”. Then update the application. Finally, go to the application.                      Figure 5. Update the application   3  Run the demo     Download this bootloader     Prepare a user application program. We use the “led blinky” as an example. Use it to generate the binary file. Name it as “a000.bin”. Put it into the u-disk. You will see some log in the uart.       The application will execute automatically

Microgenios viabilizou a realização de videos de treinamentos de curta duração para ensinar os primeiros passos com o microcontrolador Kinetis L como parte do Road Show de Microcontroladores ARM cortex-M0+ (Kinetis L Freescale), projeto realizado em parceria pela a Freescale em 10 cidades espalhadas pelo Brasil. Veja os videos para iniciar seu projeto com Kinetis L: Neste vídeo aprenderemos o processo de download e instalação do CodeWarrior V10.3 e outros pacotes de softwares Freescale: http://www.youtube.com/watch?v=bjtsLHMImDY Neste vídeo aprenderemos o processo de atualização do CodeWarrior V10 (baseado no Eclipse) e conheceremos as pastas criadas na instalação: http://www.youtube.com/watch?v=Sslf0nF0Td8 Neste vídeo conheceremos a ferramenta de hardware Freedom Board da Freescale com microcontrolador ARM cortex-M0+; e entenderemos a utilização da interface de gravação e depuração OpenSDA: http://www.youtube.com/watch?v=jeuq7ErvTGQ Neste vídeo aprenderemos a criar nosso primeiro projeto com a Freedom Board (FRDM-KL25Z), que possui microcontrolador da família Kinetis L (núcleo ARM cortex-M0+) da Freescal; utilizaremos como ferramenta de software o CodeWarrior V10.3 e o Processor Expert: http://www.youtube.com/watch?v=sx2tpDBWDt8 Neste vídeo conheceremos a IDE cloud mbed, que possibilita desenvolvimento e aplicações diretamente no navegador: http://www.youtube.com/watch?v=N7qMvO_R6Sc Mais informações visite: http://www.microgenios.com.br/website/index.php/hands-on-freescale

Actually the latest FSL USB stack has become part of KSDK , so it is recommended customer design USB application based on KSDK, while there are some old parts like K70, K60F and KL25 are still not supported in KSDK yet, so USB stack ver 4.1.1 is somewhat of help for those who still develop application based on those parts. USB stack ver 4.1.1 supports K70 instead of K60F, but since they are both Kinetis 120MHz parts, so the porting is very easy, here I provide a porting guide for this part. The porting is based on K70 USB examples, either Host or Device. 1. Replace the device header file. Use MK60F12.h instead, which may be extracted from KINETIS_120MHz_SC(Kinetis 120MHz bare metal sample code) , and put this header file in the folder of "C:\Freescale\Freescale USB Stack v4.1.1\Source\Host\source\bsp\P3" for Host or "C:\Freescale\Freescale USB Stack v4.1.1\Source\Device\app\common\kinetis" for device, and modify derivative.h as  below: 2. Macro definition changes in MK60F12.h, MCU_MK60F12 is defined instead of MCU_MK70F12, so in this step we will have to change some code snippet related with MCU_MK70F12. Firstly search MCU_MK70F12 in the project, for example ， in the Host demo USB_MSD project based on IAR, you may do that as below: and you may find some macro like "#ifdef MCU_MK70F12" or "#ifndef MCU_MK70F12", and change them as below: #ifdef MCU_MK70F12 ----> #if (defined MCU_MK60F12) || (defined MCU_MK70F12) #ifndef MCU_MK70F12 ----> #if (!defined MCU_MK60F12) && (!defined MCU_MK70F12) 3. IO driver modification. Since TWR-K70F120 has almost the same hardware as TWR-K60F120, there is no need to change the driver code after replacing the header file, except the serial port driver, referring to USB_MSD demo, the serial driver is in sci_kinetis.c, TWR-K70F120M uses PTE16 and PTE17(UART2) as the console, while TWR-K60F120M use PTE8 and PTE9(UART5) instead, so you have to change the driver as below to make printf work properly. void sci2_init(){ #if (defined MCU_MK60F12) || (defined MCU_MK70F12)     register uint_16 sbr, brfa;     uint_8 temp; #ifdef MCU_MK70F12     /* Enable the UART2_TXD function on PTD3 */     PORTE_PCR16 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the UART2_RXD function on PTD2 */     PORTE_PCR17 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the clock  */     SIM_SCGC4 |= SIM_SCGC4_UART2_MASK;     /* Make sure that the transmitter and receiver are disabled while we      * change settings.      */     UART_C2_REG(UART2_BASE_PTR) &= ~(UART_C2_TE_MASK | UART_C2_RE_MASK);     /* Configure the UART for 8-bit mode, no parity */     UART_C1_REG(UART2_BASE_PTR) = 0;    /* We need all default settings, so entire register is cleared */     /* Calculate baud settings */     sbr = (uint_16)((SYSCLK*1000)/(UART_BAUDRATE * 16));     /* Save off the current value of the UARTx_BDH except for the SBR field */     temp = UART_BDH_REG(UART2_BASE_PTR) & ~(UART_BDH_SBR(0x1F));     UART_BDH_REG(UART2_BASE_PTR) = temp |  UART_BDH_SBR(((sbr & 0x1F00) >> 8));     UART_BDL_REG(UART2_BASE_PTR) = (uint_8)(sbr & UART_BDL_SBR_MASK);     /* Determine if a fractional divider is needed to get closer to the baud rate */     brfa = (((SYSCLK*32000)/(UART_BAUDRATE * 16)) - (sbr * 32));     /* Save off the current value of the UARTx_C4 register except for the BRFA field */     temp = UART_C4_REG(UART2_BASE_PTR) & ~(UART_C4_BRFA(0x1F));     UART_C4_REG(UART2_BASE_PTR) = temp |  UART_C4_BRFA(brfa);       /* Enable receiver and transmitter */     UART_C2_REG(UART2_BASE_PTR) |= (UART_C2_TE_MASK    | UART_C2_RE_MASK); #else   //MCU_MK60F12         /* Enable the UART2_TXD function on PTE8 */     PORTE_PCR8 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the UART2_RXD function on PTE9 */     PORTE_PCR9 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin                /* Enable the clock  */     SIM_SCGC1 |= SIM_SCGC1_UART5_MASK;     /* Make sure that the transmitter and receiver are disabled while we      * change settings.      */     UART_C2_REG(UART5_BASE_PTR) &= ~(UART_C2_TE_MASK | UART_C2_RE_MASK);     /* Configure the UART for 8-bit mode, no parity */     UART_C1_REG(UART5_BASE_PTR) = 0;    /* We need all default settings, so entire register is cleared */     /* Calculate baud settings */     sbr = (uint_16)((SYSCLK*1000)/(UART_BAUDRATE * 16));     /* Save off the current value of the UARTx_BDH except for the SBR field */     temp = UART_BDH_REG(UART5_BASE_PTR) & ~(UART_BDH_SBR(0x1F));     UART_BDH_REG(UART5_BASE_PTR) = temp |  UART_BDH_SBR(((sbr & 0x1F00) >> 8));     UART_BDL_REG(UART5_BASE_PTR) = (uint_8)(sbr & UART_BDL_SBR_MASK);     /* Determine if a fractional divider is needed to get closer to the baud rate */     brfa = (((SYSCLK*32000)/(UART_BAUDRATE * 16)) - (sbr * 32));     /* Save off the current value of the UARTx_C4 register except for the BRFA field */     temp = UART_C4_REG(UART5_BASE_PTR) & ~(UART_C4_BRFA(0x1F));     UART_C4_REG(UART5_BASE_PTR) = temp |  UART_C4_BRFA(brfa);        /* Enable receiver and transmitter */     UART_C2_REG(UART5_BASE_PTR) |= (UART_C2_TE_MASK    | UART_C2_RE_MASK); #endif        #endif } #ifdef __CC_ARM int sendchar (int ch) #else void TERMIO_PutChar (char ch) #endif { #if (!defined MCU_MK60F12) && (!defined MCU_MK70F12)     #if (defined MCU_MK20D5) || (defined MCU_MK20D7) || (defined MCU_MK40D7)         /* Wait until space is available in the FIFO */         while(!(UART1_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART1_D = (uint_8)ch;       #elif(defined MCU_MK21D5)         while(!(UART2_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART2_D = (uint_8)ch;       #elif(defined MCU_MKL25Z4) || (defined MCU_MKL46Z4)         /* Wait until space is available in the FIFO */         while(!(UART0_S1 & UART_S1_TDRE_MASK)){};        /* Send the character */        UART0_D = (uint_8)ch;       #else         /* Wait until space is available in the FIFO */         while(!(UART3_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART3_D = (uint_8)ch;     #endif   #else #ifdef MCU_MK70F12     /* Wait until space is available in the FIFO */     while(!(UART2_S1 & UART_S1_TDRE_MASK)){};     /* Send the character */     UART2_D = (uint_8)ch; #else      /* Wait until space is available in the FIFO */     while(!(UART5_S1 & UART_S1_TDRE_MASK)){};     /* Send the character */     UART5_D = (uint_8)ch; #endif #endif } 4. Set the correct device type in IDE settings. For IAR, change the device family in view of project options. Now, you can start to run the USB demos on TWR-K60F120M, please note the above steps is ok for USB device stack, but USB Host stack has some code issue , as mentioned in [USB stack ver 4.1.1] a code issue in msd_mfs_generic host demo , so please fix the issue before going further. Hope that helps, Best Regards, Kan

在EEfocus上有一个关于Debug模式和正常工作模式下进入低功耗模式的问题，总结了一下，Post过来Share给大家。 问题现象：使用串口接收中断，主函数进入睡眠。在调试过程中发现：只有在连接jlink调试下，串口可以正常收发数据，串口收到数据可以唤醒mcu。但在断开jlink情况下，不能正常收发数据。 所做尝试：尝试过不在VLPS模式下，串口是可以正常中断接收数据的，也可以正常发送数据。另外，在使用过程中采用的是内部晶振，串口的时钟源是FLL。 主函数代码： while(1) { enter_vlps();  //进入vlps模式 out_char(c); //串口接收中断函数把字符赋给c } 解答： 首先，在VLPS模式下，FLL不能工作，也就无法输出clock时钟到UART，所以进入VLPS模式后UART不可以用FLL做时钟。 其次，在连J-Link调试时其实没有进入VLPS模式，而是进入了STOP模式，此时FLL是有输出的。在数据手册上的MDM-AP Status Register部分关于LP有讲到:Usage intended for debug operation in which Run to VLPS is attempted. Per debug definition, the system actually enters the Stop state. 所以造成了连接J-link从表面上看起来是进入了VLPS模式(其实是进入Stop模式)，不连接J-link就无法正常工作了。

Hey All, Check out the unboxing video for UAV Drone designed using Kinetis V series MCUs to be showcased in Freescale Technology Forum 2015 at booth 249. The Kinetis V series 32-bit MCUs are based on ARM Cortex M cores and specially designed to enable motor control and power conversion applications. Please visit Kinetis V Series Webpage for more information. This drone is powered by Kinetis KV5x MCU (First Kinetis MCU with the latest ARM Cortex M7 Core). The Kinetis KV5x is used in Electronic Speed Control (ESC) unit and a single Kinetis KV5x MCU chip is used to control 4 Brushless DC motors which typically is controlled by four 8 bit MCUs. Along with controlling four motors, the KV5x MCU has enough performance and peripheral headroom so that it can be used as a flight controller and communication interface with connectivity features such as CAN and Ethernet. Kinetis KV5x is ideal solution for industrial IOT with the applications such high performance motor control and power conversion and real time control. Please visit Kinetis KV5x Series Webpage for more information. There is another drone in the Analog section at Freescale Technology Forum based on Kinetis KV4x MCU (based on ARM Cortex M4 core) and Freescale GD3000 3-Phase Brushless DC Gate driver. The Kinetis KV4x MCU is used to control 4 Brushless DC motors and is the cost optimized version of Kinetis KV5x MCUs. Please check out the Kinetis based drone demo as well as other cool demos at Freescale Technology Forum. PS: I apologize for the quality of the video. Working on the better video and editing skills.  Thanks, Mohit Kedia

The document describes how to port yaffs2 file system for MQX. The detailed porting user guide can refer to the attached doc which use TWR-K70F120M as example. The reference code can be found in the attached source code package. Now, the yaffs2 for MQX can support NFC and non-NFC at the same time, the only difference is NAND driver. For NFC, you should use NFC driver and for non-NFC, you should use softnand driver. In yaffs2 porting package, include the files which should be modified in MQX release package. user_config.h should be placed at \config\platform name\ init_nandflash.c should be placed at \mqx\source\bsp\platform name\ \nandflash is the NAND driver, should be at \mqx\source\io\ \yaffs2 is the yaffs2 porting codes should be at the root directory of MQX release package softnand2K.c is the NAND driver for non-NFC(simulated by flexbus).

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.

The Multipurpose Clock Generator module explained by Ali Piña, Freescale TIC. MCG Module Explanation Connection Diagram Operation Modes Hands On Toggle a LED in FEI (FLL engaged Internal) switch to PEE (PLL Engaged External). Watch changes. Switch from different operation modes. El Módulo de MCG (Multipurpose Clock Generator) presentado por Ali Piña, Freescale TIC. Explicación del Modulo MCG. Diagrama de conexiones Modos de operación. Hands-On Togglear un LED en modo FEI (FLL engaged Internal) y cambiar a PEE(PLL Engaged External). Observar cambios. Moverse entre varios modos de operación

To do: The development platform is Eclipse. The EVAL Board is the Kinetis Tower TWR K60. On the Tower, you find 2 pushbuttons and 4 LEDs. a) Generate a hexadecimal random number from 0x0 to 0xF as long as pushbutton1 is pressed. Display the result with the 4 LEDs for about 3 seconds. b) Replace the code for recognizing a pressed key by a macro "KEY1_PRESSED". c) Replace the access to the 4 LEDs by a macro "LEDx_TOGGLE" with x = 0...3". Use active wait loops instead of the timer in this Kinetis exercise. Result: TWR_K60_RANDOM.zip

介绍通过使用Kinetis KL系列以及K系列通过不同方式驱动液晶。

This manual explains how to create a project in CW and add components to Processor Expert. It also includes a couple of examples to print and get data with the printf and scanf functions from the stdio library by using Serial component (UART).