FFT presentation for metering customers, targeted especially for KM3x / KM3x_256 devices. It briefly describes: How to Use it, and Why to Use it.

Trimming internal reference clock of ICS (internal clock source) module using OSDA connection Pavel Šádek, Rožnov, Czech Republic   Simple apps does not require crystal driven clock precision. Internal reference clock based timing of MCU can be used instead.   Manufacturing process yealds to frequency deviation, that is why all MCU devices are factory programmed with a trim value in a reserved memory location. This value is uploaded to the ICS_C3 register and ICS_C4[SCFTRIM] during any reset initialization. For finer precision, trim the internal oscillator in the application and set ICS_C4[SCFTRIM] accordingly.   The TRIM bits effect the ICSOUT frequency if the ICS is in FLL engaged internal (FEI), FLL bypassed internal (FBI), or FLL bypassed internal low power (FBILP) mode.   The internal reference clock can be trimmed also in program time of the device to any value between 31.25 and 39.062kHz, this allows also achieving exotic bus frequencies.  The value applied in Processor Expert does not propagate into Pemicro connection manager. No matter if Processor expert is used or not , we need to configure it it by ourselves in connection of OSDA (same for debugging or programming). So this is a guide how to do so.   In the program initialization we need to initialize the ICS_C3 register and ICS_C4[SCFTRIM]. It can be done siply this way:   /* System clock initialization */   if ( *((uint8_t*) 0x03FFU) != 0xFFU) {     ICS_C3 = *((uint8_t*) 0x03FFU);     ICS_C4 = (ICS_C4 & 0xFEU) | ((*((uint8_t*) 0x03FEU)) & 0x01U);   }   Then hit   flag, choose debug configuration and you will see configuration of your connectons, I have here only OSDA for my Kinetis E Freedom board (it is similar across families of Kinetis, ColdFire or S08 just connection would be SWD, Jtag or BDM) You will get new window   Choose „Advanced Programming Options“ button     Enable calculating of Trim value and programming into Flash location. If the TRIM frequency is different from default, check the box to use custom one in valid range – the one you(or Processor Expert) have used for your timing calculations. Hit DONE and your effort is done!   Next, when you will launch debugging session by hitting bug on button these values will be applied.   My RESULT:   ICS_C3 was trimmed to value of 0x57 for 39.062kHz and 0x9B for 31.250kHz for my Kinetis E Freedom board. Precision is better then 1% in room temp. This is ok for serial comunication without need of crystal for example. Note: Values out from my discovered range of 0x57 – 0x9B leads to frequencies that are out of specification of ICS and should not be used for this exact device.  The limits will be slightly different for every single device.

Introduction The K32L3A60VPJ1AT MCU is a next generation Kinetis dual core device.  This device brings processing and multi-tasking capabilities that legacy Kinetis devices did not support.  In addition, the K32L3A60VPJ1AT offers improved power consumption and security features.   Some important aspects of these security features lie in a nonvolatile information register (IFR) memory region and how this region is programmed.  The IFR memory region is a memory space with restricted access separate from the main array and is comprised of an erasable IFR region and a non-erasable IFR region.  The non-erasable IFR region contains the program once identifier and the version identifier.  The erasable IFR region holds the flash security, flash options, mass erase enable, and other such features that governs how the device behaves.  In legacy Kinetis devices, certain fields of the main flash array (flash addresses 0x400 - 0x40F) configured the IFR at boot time.  In the K32L3A60VPJ1AT however, the IFR memory region is no longer controlled in this manner.  This presents challenges when trying to configure these settings.  The purpose of this document is to explain how these settings can be changed and provide some options of how to make these changes.   IFR Field Programming Process The first step in configuring the IFR fields is understanding how the these fields are programmed via the hardware. IFR fields are programmed using a special flash command called the Program Index Command. Once programmed, the flash configuration values cannot be reprogrammed without first erasing these fields.  The only way to erase these values is via a mass erase.  This provides security in that the IFR values cannot be changed without erasing the user code as well.  In addition, changes to the user code image cannot affect the bootloader operation, ensuring that a secure boot function can be executed.  The procedure for writing the erasable IFR values is described here:   Write FCCOB0 with the Program Index command (0x43). Write FCCOB1 with the Index to be programmed. The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 and FCCOB3 with 0x00 as they are not used with this command.  Write FCCOB4 - FCCOBB with the desired value.  (Note that not all of the indexes use all of the FCCOB fields.  Be sure to consult the Erasable IFR Map table for which FCCOB fields are used for the index you are programming). NOTE:  For 2 byte IFR fields that map to 2 bit wide register bit fields (i.e., SEC0, FSLACC, MEEN, and KEYEN fields which map to the FSEC register bit fields), the lower FCCOB register maps to the LSB of the bit field and the upper FCCOB register maps to the MSB of the bit field.  For example, to write 0b'10 to the FSEC field, FCCOB6 should be written to 0xFF and FCCOB7 should be written to 0x00 before executing the Flash command.  Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. (Note that this command MUST be a byte write.) Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the typical Program Index command completion time of 110us.)   After the IFR has been programmed, the IFR should be read back to verify that it completed correctly.  The process for this is as follows:   Write FCCOB0 with the Read Index command (0x41). Write FCCOB1 with the Index to be read.  The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 - FCCOBB with 0. The results will be stored in FCCOB4 - FCCOBB so, these should be cleared to ensure correct results are received. Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. Note that this command MUST be a byte write. Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the maximum Read Index command completion time of 35us.)   When using the Program Index Command, you must know which index you want to modify to create the correct flash commands.  The index list can be found in the IFR descriptions section of the Flash chapter in the K32L3A60VPJ1AT reference manual.     There are several different options for programming the FOPT fields. These options are: Using the Kinetis Flash Tool  Using blhost Debugger script Subroutine in user software   Option #1: Kinetis Flash Tool Using the Kinetis Flash Tool is likely the most convenient method to change the IFR values.  The Kinetis Flash Tool uses either the UART or USB protocol to interface with the K32L3A6 bootloader and write the IFR fields desired. One of the biggest advantages for the Kinetis Flash Tool is that it provides a graphical interface for users to easily program the IFR fields. The following figure is a picture of the Kinetis Flash Tool and highlights the important input controls and tabs to be used when programming the IFR fields:     This field is the Port set box.  It selects the interface (UART or USB) to be used when communicating to the bootloader.  This box also allows for configuration of the interface.  Consult the K32L3A6 reference manual for default configurations.   This is the Flash Utilities tab.  Select this tab to see the controls shown in this image.  This is the Index input field.  The Index of the IFR to program should be entered here.  This is the Hex digits field.  This value will be programmed at the IFR Index indicated in the Index field. The value here should be in hex format WITHOUT the preceding "0x".  Note that this will write to the FCCOBs in descending order.  For example, to write 0b'10 to the KEYEN field, FFFFFF00 should be written to the Hex digits field. Refer to the programming process outlined in the IFR Field Programming Process in this document for more information.    This is the Byte Count field.  This tells the utility how many bytes to program and must be the byte count of that IFR field.  Consult the Erasable IFR Map table in the reference manual for the value of the specific IFR index to be programmed.   This is the Program button.  After all of the fields have been filled out, click this button to program the desired IFR location.    Option #2: BLHOST The MCUBoot package also includes a command line executable to interface with the bootloader.  This tool, blhost, can be used to program the IFR fields as well.  The "flash-program-once" command should be used to program the desired IFR location.  The syntax of this command is as follows:   flash-program-once <index> <byteCount> <data>   So for example, if you want to program the FOPT IFR field (record index 0x84) with 0xFFFFF3FF, the correct syntax using this command would be   flash-program-once 0x84 4 FFFFF3FF   After programming, the "flash-read-once" command can be used to read back and verify the programmed IFR field(s).  Below is an example using the previous IFR locations   flash-read-once 0x84 4   Below is a full example of erasing the device, programming the FOPT IFR, and reading the FOPT IFR back from the command line using blhost.     When Programming two byte fields, blhost orders the bytes in descending FCCOBx order (just like the Kinetis Flash Tool).  The blhost utility also requires the input to be 4 or 8 byte aligned, but the flash-program-once command only uses the last 2 bytes.  The upper 4 bytes can be padded with 0's or F's. For example, to write the KEYEN field such that the KEYEN bit field is 0b'10, the command would be as follows: flash-program-once 0x83 4 FFFFFF00 Below is a full example of using the blhost command line to erase the device, program the KEYEN IFR, read the KEYEN IFR back, and evaluate the FSEC bit field using the Attach to Running Target function in a debugger.     After executing a pin reset and attaching to the running target:     Option #3: Debugger Script A simple debugger script is another convenient way to write the IFR values.  Debugger scripts are executed in the background of the debug session initiation process (therefore are hidden operations from the user) and typically can be edited easily using any text editor.  However, it can be cumbersome to change the value because this generally must done manually with each programming by the user. With that in mind, it is a good idea to have different connect scripts for different configurations   The first step in using a debugger script is writing a debugger script.  The capabilities and syntax of a debugger script are dependent on your toolchain. For the purposes of this document, we will focus on MCUXpresso IDE.  MCUXpresso IDE uses the PokeXX and PeekXX (where XX is 8, 16, or 32 depending on whether you want to byte access, half-word or word access to the desired register) commands, which are debugger agnostic. So the same commands that work on a device will continue to work whether you are debugging with a JLink or CMSIS-DAP, or whatever other debugger you are using. Below is an example of a MCUXpresso connect script which writes the FOPT register and then reads it back for printing to the debug log.    5140 REM ====================Program FOPT=================================== 5150 Poke32 this 0x40023004 0x43840000 5160 REM Stuff FCCOB registers with desired FOPT value 5170 Poke32 this 0x40023008 v% 5171 s% = Peek32 this 0x40023008 5172 Print "New Val ";~s% 5180 Poke32 this 0x4002300c 0x00000000 5180 Poke8 this 0x40023000 0x70 5190 Poke8 this 0x40023000 0x80 5200 wait 1000 6000 REM ================== Read FOPT ===================================== 6001 REM Now read the FOPT back 6010 Poke32 this 0x40023004 0x41840000 6020 Poke32 this 0x40023008 0x00000000 6030 Poke32 this 0x4002300c 0x00000000 6040 Poke8 this 0x40023000 0x70 6050 Poke8 this 0x40023000 0x80 6060 wait 1000 6070 s% = Peek32 this 0x40023008 6080 Print "New FOPT Val ";~s%   Note in the above script that v% is the desired FOPT value and it has been defined in sections of the script not shown (at line 164).    162 REM This is the value to be written to the FOPT 164 v% = 0xfffff3ff   After the script is written, MCUXpresso must be told to use the connect script.  This is done in the Debug Configurations window.  Assuming a debug configuration has already been created, click on the arrow next to the green bug icon and select Debug Configurations.       In the resulting dialog box, select the debug configuration you want to use, and select the Linkserver Debug tab.  In the Connect Script field, point MCUXpresso to the location of your connect script.       That's all that needs to be done in the IDE. The selected debug configuration should now be using the script which was written.     Some debuggers will allow standalone command line running of a script, such as a JLink debugger.  As the JLink is one of the more popular external debuggers that we encounter, an example of programming using this script has been provided below.     // Now Program the FOPT w4 0x40023004, 0x43840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0xfffff3ff // Write 0xFFFF_1FFF to boot the M4 from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Now Read the FOPT back w4 0x40023004, 0x41840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0x00000000 // Write 0xFFFF_F1FF to boot the M0+ from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Read the memory back to verify the FOPT settings that should be present after reset. mem32 40023000,4     Option #4: Subroutine in User Software Occasionally the requirements of your system will prevent implementation of any of the above methods to program the IFR values.  In these cases, you may need to implement your own subroutine to program the IFR.  The procedure to do this is essentially the same as in the debugger script methods, just written in code instead of an external script.  The flash drivers provided in the SDK aid in this process.  One key to remember is that you likely will need to erase the entire flash.  So this subroutine and flash drivers should be placed in RAM memory.  The SDK flash drivers also operate a little differently from the Kinetis flash tool and blhost.  The FCCOB registers will be loaded in ascending order.  For example, to write 0b'10 to the SEC0 bit field in the FSEC register, the command would be: result = FLASH_ProgramOnce(&s_flashDriver, 0x80, ifr2write, 0x2); where ifr2write is an array defined as uint8_t ifr2write[2] = {0x00, 0xFF}; The above will result in 0x00 being loaded to FCCOB6 and 0xFF being loaded to FCCOB7 and SEC0 will then be 0b'10 on the reset after the command is successfully executed.   Conclusion In summary, the IFR registers are nonvolatile information registers that govern certain behaviors of the K32L3A MCU.  The IFR is dividing into an erasable IFR space and non-erasable IFR space, both of which are not a part of the main flash array.  Programming these values requires the use of special flash commands and requires that these values haven't been previously written since the last mass erase.  There are, in general, four different methods of programming the FOPT register settings.  The four methods are:   Kinetis Flash Tool BLhost command line interface Debugger script  User software subroutine   Each method has its advantages, therefore, you should pick the one that meets your needs and is most convenient. However with any of the methods chosen, the IFR values must not have been programmed before writing erasable IFR fields. It is best to perform a mass erase (which can be done using any of the methods presented in this document) before attempting to program any IFR fields.     

FINALISTAS Después de un profundo análisis de todos los proyectos, nuestros jueces realizaron la difícil selección de los finalistas del Kinetis L MCU Challenge México entre los que el público elegirá al ganador; gracias a la excelente respuesta decidimos nombrar 16 finalistas.  Ellos son: Project Name Contestan Name Description Video Sistema de monitoreo de la contaminación acústica #MonitoreoAcustico Lucio Canche Diseño de una placa para monitoreo de niveles de ruido utilizando un sensor de sonido. Permite el estudio detallado de los patrones de propagación del sonido. Movimiento de un carro controlado #CarroPelotasAntiestres Emilio Jiménez Auto de juguete controlado por medio de pulsaciones realizadas con 2 pelotas anti-estrés, el presionar una pelota hará que el vehículo avance hacia adelante y la otra hará que gire sobre su propio eje. Viking lever #VikingLever Ma. Fernanda Gutierrez Consiste en un sistema de una palanca con contrapeso; tendrá en la punta una pelota con una led que indicará cuando el usuario tiene que golpearla. Controlador para el suministro de agua de una vivienda #ControladorAgua Rogelio Rosales El objetivo es el ahorro de agua. En un tinaco se colocan 2 sensores, uno a nivel alto y el otro a nivel bajo de agua. Dependiendo del nivel del agua los sensores mandan la señal a la bomba para que se encienda o apague. Rehab glove #RehabGlove Alexis Castañón Guante que posee sensores de flexión en las articulaciones de los dedos y de fuerza en las yemas, con el fin de enviar instrucciones a algún aparato, mientras el usuario realiza ejercicios como cerrar el puño o tocar las yemas de los dedos con el pulgar. Tablet braile para invidentes #TabletBraille Andres Gafford Tableta para leer ebooks braile con botones para cambiar de página, apagar y encender, que sean fáciles de percatar por un invidente; así como botones interactivos que desplieguen opciones del menú. Tapete interactivo para discapacitados #TapeteInteractivo Angel Campoy Este tapete interactivo, contribuye al desarrollo motriz. El teclado cuenta con cuatro botones, los cuales tienen un led que se enciende indicando al paciente que debe presionar el boton. Si activo el boton indicado,se enciende un LED verde o rojo si se equivocó. Neck remote control wheel chair #NeckControl Francisco Javier Pérez Corona Silla de ruedas controlada moviendo el cuello a la izquierda o derecha, presionando un botón con la cabeza, que a su vez haga avanzar o girar. Control de sensores infrarrojos para silla de ruedas #SensoresSilla Jesús Lizárraga Silla de ruedas diseñado para personas con parálisis cerebral. El usuario debe colocar las dos manos al ifgual que los codos por encima de los espacios indicados, los sensores se activarán haciendo que la silla avance o gire hacia el lado en que la persona posicionó la mano. N-drid uleta #NdridRuleta Jorge Rodriguez Rodriguez Juego de ruleta de leds de 4 colores, el usuario acumulará puntos cada vez que logre presionar el botón del color en donde parará la ruleta. KMA #KMA Luis Castellanos Prototipo para silla de ruedas que será controlada con un dispositivo de fácil manejo,  comunicado a la silla por bluethooth. Sensilla #Sensilla Miguel Rogel Silla móvil manipulada por sensores y con esto lograr desplazarse de una manera más accesible a sus capacidades. Pest control using Freescale #PestControl Pablo Yerena Este proyecto consiste en el control de plagas de manera ecológica, con la implementación de un aparato electrónico que emite frecuencias ultrasónicas evitando que animales e insectos invadan espacios físicos. Tren de colores musical #TrenColores Ricardo Villaseñor Juguete donde se utiliza un sensor óptico para la lectura de pequeños cubos de colores, donde cada color es una nota musical. Al colocar el lector sobre el cubo de color se emitirá la nota correspondiente. Morse deaf-mute communication system #MorseDeafMute Roberto Vite Ruiz Dispositivo de escritura basado en el código morse. Se muestra un código morse para cada letra del alfabeto permitiendo a una persona sorda o muda darse a entender de manera escrita.       Casco acelerómetro #CascoAcelerometro José Ramón Rodriguez Dispositivo  para silla de ruedas que  permite al paciente transportarse autónomamente mediante una especie de casco que detecte la dirección deseada, además de que sea una manera recreativa de trasladarse Podrás participar calificando cada proyecto a través de redes sociales y la herramienta RankTab; la votación se abrirá el día del evento a partir de las 9:00am, espera las instrucciones a través de la Comunidad Freescale,  Facebook y durante el evento. A todos los finalistas los esperamos el 07 de Diciembre a las 8:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara, donde se develará el misterio y conoceremos al ganador del viaje al Freescale Technology Forum (FTF) en Dallas, Texas del 08 al 11 de Abril del 2014. Para solicitar mayor información, favor de enviar un correo a cristina.garcia@mclgx.comA

The SPI bus has the capability of addressing multiple slave devices by a single master. The Kinetis L series of devices feature either an 8-bit or 16-bit capable SPI module; however, there is only one dedicated CS/SS signal per instance of the module. Of course this signal is muxed to a few pin locations on the device. Unfortunately, there are not that many pins with the CS/SS muxing and they are most likely they are not near to each other physically. A solution to this issue is to use GPIO as CS/SS lines. This way you can take advantage of the SPI bus protocol and the Kinetis L series IOPORT interface (also known as FGPIO on Kinetis L). The Cortex-M0+ allows accesses to the IOPORT to occur in parallel with any instruction fetches; therefore, these accesses will complete in a single cycle. Core vs. SPI I'm sure many who have tried to use GPIO as CS/SS have written code similar to this pseudo code, I know I have: while(1) {      set_cs_low;      send_byte;      set_cs_high; } Logically this makes sense, but on an oscilloscope you will see the GPIO CS/SS line toggling at irregular intervals and out of sync with the SPI transfers. This is due to the nature of the 'send_byte' function or instruction. Simply transmitting a data packet will not prevent the core from waiting for the transmission to complete. The core will move on from writing data to the SPI data register, and execute the next instruction. If you have a core operating at 48 MHz and you are performing, at most depending on instance, 24 MHz SPI transfers the core will always move onto the next instruction before the data has left the module. The code must either implement a delay or wait for the transmission to complete. Incorporating an accurate delay can be tricky and can be interrupted by any interrupts occurring during the delay process. A more robust solution is to wait for the transmission to complete. However, there appears to be no Transmit Complete Flag (TCF) in the L-Series SPI module. The Solution Fortunately, there is a way to wait for transmit complete. Software must wait for the SPI read buffer full flag (SPRF) to be set in the SPI status register (SPIx_S) after writing data to the SPI data register (SPIx_D) . When the SPRF bit is set, software must read the SPIx_D. This procedure will ensure that the core does not move onto GPIO toggling, or other instructions, until the data has left the SPI module. The following function demonstrates how to write the above procedure in C using SPI0 and PTD0 as the CS/SS line: uint8_t SPI_send(uint8_t spiWrite) {     uint8_t spiRead;                        //Variable for storing SPI data     FGPIOD_PCOR |= (1 << 0);                //Toggle CS/SS line low     while(!(SPI0_S & SPI_S_SPTEF_MASK))     {         __asm("NOP");     }                                       //Wait for SPI transmit empty flag to set     SPI0_D = spiWrite;                            //Write data to SPI     while(!(SPI0_S & SPI_S_SPRF_MASK))     {         __asm("NOP");     }                                       //Wait for receive flag to set     spiRead = SPI0_D;                       //Read the SPI data register     FGPIOD_PSOR |= (1 << 0);                //Toggle CS/SS line high     return spiRead; } Please note that the GPIO CS/SS toggling need not be in the function. It should work just as well if the GPIO CS/SS toggles occur before and after the function is call, just remove the FGPIO instructions from the function and place them outside. I hope this document proves useful to those of you designing multiple slave SPI buses around Kinetis L series parts.

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

CONVOCATORIA Freescale Semiconductor, Inc. Convoca al primer concurso de proyectos “Kinetis L MCU Challenge México” “Kinetis L MCU Challenge México” es una competencia de proyectos tecnológicos basado en la herramienta de desarrollo Kinetis Freedom en la cual el participante construye una aplicación alineada a una de las futuras tres tendencias Salud y Seguridad, Efecto Net o Going Green. Los proyectos finalistas serán presentados durante la final del Freescale Cup 2013 el día 7 de Diciembre, a las 9:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara.  Si resultas ganador, viajarás con todos los gastos pagados al Freescale Technology Forum (FTF) en Dallas, Texas. ¿Cómo puedo participar? Regístrate en Kinetis Challenge antes del 15 de Noviembre de 2013 Crea una aplicación utilizando la herramienta de desarrollo Freedom (en caso de no contar con ella, puedes adquirirla a través de Element 14 (entrega al siguiente día laborable), Mouser (entrega en 4 semanas), o Digikey (entrega de 3 a 5 días hábiles) . Tienes hasta el 15 de Noviembre para subir la información de tu aplicación a la comunidad de Freescale (es necesario hacer log in con tu cuenta en www.freescale.com😞 Nombre de la aplicación 1 párrafo descriptivo de la aplicación Un video descriptivo de hasta 2 minutos El código fuente en formato .zip Subir el proyecto como documento en la sección de Kinetis Microcontrollers en el siguiente formato:  https://community.freescale.com/docs/DOC-94067 El proyecto deberá contener el tag: "Kinetis L MCU Challenge México" para ser identificado como proyecto participante del concurso. Freescale seleccionará 10 proyectos finalistas basándose en los criterios descritos en la convocatoria. Éstos se presentarán en el evento Freescale Cup 2013 el próximo 7 de Diciembre de 2013. Para conocer a los finalistas ingresa aquí. El proyecto ganador, será elegido durante el evento Freescale Cup 2013 por los asistentes al evento, a través de la comunidad Freescale y redes sociales, basándose en los criterios descritos en la convocatoria. El anuncio del proyecto ganador y la entrega de certificados será el  día del evento. La elección del ganador está en tus manos, sigue las instrucciones aquí. ¡Descubre quién es el ganador aquí! Links de interés: Acerca de Otros Recursos Registro Freedom Development Platform Ejemplos de proyectos con Kinetis www.electronicosonline.net/kinetischallenge FRDM-KL25Z Compra de FRDM-KL25Z en Element14 Kinetis L Microcontrollers Compra de FRDM-KL25Z en Mouser Freescale Cup 2013 Compra de FRDM-KL25Z en Digikey FTF Americas 2014 Cómo subir tu proyecto

   Android Open Accessory support allows external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special accessory mode. When an Android-powered powered device is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates devices) and the Android-powered device acts in the USB accessory role. This ADK library is based on Freescale Kinetis KL26 MCU, It implements some functions to communicate with android phone.

Share some information on how to use micro-trace buffer.

1 Abstract      LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive multiplex networks. LIN is based on the UART/SCT protocol. It can be used in the area of automotive, home appliance, office equipment, etc. The UART module in NXP kinetis L series contains the LIN slave function, it can be used as the LIN slave device in the LIN bus. Because there is few LIN slave KL sample code for the customer’s reference in our website, now this document mainly take KL43 as an example, explain how to use the FRDM-KL43 board as the LIN slave node to communicate with the LIN master device. LIN master use the specific LIN module: PCAN-USB Pro FD. Master send the publisher ID and subscriber ID, slave give the according LIN data response. This document will share the according code, hardware connection and the test result. 2 LIN bus basic knowledge review         For the convenient to understand the LIN bus, this chapter simply describe the basic knowledge for LIN bus. Mainly about the LIN topology and the LIN frame. 2.1 LIN bus topology structure       LIN bus just use the simple low cost single-wire, it uses single master to communicate with multiple slaves. The bus voltage is 12V, the speed can up to 20 kbit/s. LIN network can connect 16 nodes, but in the practical usage, normally use below 12 nodes. Figure 2-1. LIN bus topology 2.2 LIN bus frame structure          LIN Frame consists of a header (provided by the master task) and a response (provided by a slave task).     Master send publisher frame: Master send header+ data +checksum; slave just receive.     Master send subscriber frame: Master send header; slave receive send data +checksum.     The following figure is the structure of a LIN frame: Figure 2-2. LIN frame structure      LIN frame is constructed of one Break field, sync byte field (0X55), PID, data and checksum. 2.2.1 Break filed and break delimiter Break filed is consist of break and break delimiter. Break should at least 13 nominal bit times of dominant value (low voltage). The break delimiter shall be at least one nominal bit time long (high voltage). Figure 2-3. break field 2.2.2 Sync byte field Sync is a byte field with the data value 0X55. The byte field is the standard UART protocol. Figure 2-4. The sync byte field 2.2.3 Protected identifier field A protected identifier field consists of two sub-fields: the frame identifier and the parity. Bits 0 to 5 are the frame identifier and bits 6 and 7 are the parity.     ID value range: 0x00-0x3f, 64 IDs in total. It determine the frame categories and direction. Figure 2-5. The sync byte field P0 = ID0 xor ID1 xor ID2 xor ID4 P1 = -(ID1 xor ID3 xor ID4 xor ID5) -is NOT。  ID can be split in three categories:   Frame categories Frame ID Signal carrying frame Unconditional frame 0x00-0x3B Event triggered frame Sporadic frame Diagnostic frame Master request frame 0x3c Slave response frame 0x3d Reserved frame   0x3e,0x3f     2.2.4 DATA       A frame carries between one and eight bytes of data. The number of data contained in a frame with a specific frame identifier shall be agreed by the publisher and all subscribers.      For data entities longer than one byte, the entity LSB is contained in the byte sent first and the entity MSB in the byte sent last (little-endian). The data fields are labeled data 1, data 2,... up to maximum data 8. 2.2.5 checksum  The checksum contains the inverted eight bits sum with carry over all data bytes or all data bytes and the protected identifier.        Classic checksum: Checksum calculation over the data bytes. Enhanced checksum: Checksum calculation over the data bytes and the protected identifier byte.  Method: eight bits sum with carry is equivalent to sum all values and subtract 255 every time the sum is greater or equal to 256, at last, the sum data do bitwise invert.  In the receive side, do the same sum, but at last, don’t do invert, then add the received checksum data, if the result is 0XFF, it is correct, otherwise, it is wrong. 3 KL43 LIN slave example    This chapter use KL43 as the LIN slave, and communicate with the specific LIN master device, realize the LIN data sending and receiving. 3.1 Hardware prepare Hardware: FRDM-KL43，TRK-KEA8，PCAN-USB Pro FD       LIN bus voltage is 12V, but the FRDM-KL43 don’t have the LIN transceiver, so we need the external LIN transceiver connect the KL43 uart, to realize the LIN voltage switch. Here we use the TRK-KEA8 on board LIN transceiver MC33662LEF for the KL43. The MC33662LEF circuit is like this:    Figure 3-1. LIN transceiver schematic 3.1.1 FRDM-KL43 and TRK-KEA8 connections      FRDM-KL43 need to connect the UART port to the LIN transceiver. The connection shows in this table: No. FRDM-KL43 TRK-KEA8 note 1 J1-2 J10-5 UART0_RX 2 J1-4 J10-6 UART0_TX 3 J3-14 J14-1 GND 3.1.2 TRK-KEA8 and LIN master connections         LIN bus is using the signal wire.  TRK-KEA8 J14_4 is the LIN wire, it should connect with the LIN wire in PCAN-USB Pro FD. GND also need to connect together.        TRK-KEA8 P1 need a 12V DC supplier. Master also need 12V DC supplier. 3.1.3 Object connection picture   Figure 3-2. Object connections 3.2 Software flow chart and code      Now describe how to realize the LIN master and the LIN slave data transfer. LIN master send a publisher frame, the slave will receive the according data. LIN master send a subscriber frame, the slave will send the data to the master. The code is based on the KSDK2.2_FRDM-KL43 lpuart, add the LIN operation code.  3.2.1 Software flow chart         Figure 3-3. Software flow chart   3.2.2 software code     Code is based on KSDK2.2_FRDM-KL43 lpuart project, add the LIN operation code, the added code is list as follows: void LPUART0_IRQHandler(void) {      if(LPUART0->STAT & LPUART_STAT_LBKDIF_MASK)      {        LPUART0->STAT |= LPUART_STAT_LBKDIF_MASK;// clear the bit        Lin_BKflag = 1;        cnt = 0;        state = RECV_SYN;        DisableLinBreak;          }     if(LPUART0->STAT & LPUART_STAT_RDRF_MASK)      {                  rxbuff[cnt] = (uint8_t)((LPUART0->DATA) & 0xff);                  switch(state)          {             case RECV_SYN:                           if(0x55 == rxbuff[cnt])                           {                               state = RECV_PID;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_PID:                           if(0xAD == rxbuff[cnt])                           {                               state = RECV_DATA;                           }                           else if(0XEC == rxbuff[cnt])                           {                               state = SEND_DATA;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_DATA:                           recdatacnt++;                           if(recdatacnt >= 4) // 3 Bytes data + 1 Bytes checksum                           {                               recdatacnt=0;                               state = RECV_SYN;                               EnableLinBreak;                           }                           break;          default:break;                                    }                  cnt++;      }     } void uart_LIN_break(void) {     LPUART0->CTRL &= ~(LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);   //Disable UART0 first     LPUART0->STAT |= LPUART_STAT_BRK13_MASK; //13 bit times LPUART0->STAT |= LPUART_STAT_LBKDE_MASK;//LIN break detection enable LPUART0->BAUD |= LPUART_BAUD_LBKDIE_MASK;         LPUART0->CTRL |= (LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);     LPUART0->CTRL |= LPUART_CTRL_RIE_MASK;     EnableIRQ(LPUART0_IRQn);    } int main(void) {     uint8_t ch;     lpuart_config_t config;     BOARD_InitPins();     BOARD_BootClockRUN();     CLOCK_SetLpuart0Clock(0x1U);     LPUART_GetDefaultConfig(&config);     config.baudRate_Bps = BOARD_DEBUG_UART_BAUDRATE;     config.enableTx = true;     config.enableRx = true;     LPUART_Init(DEMO_LPUART, &config, DEMO_LPUART_CLK_FREQ);     uart_LIN_break();     while (1)     {        if(state == SEND_DATA)        {           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X01;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X02;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X10;//Checksum   0X10 correct, 0xaa is wrong           recdatacnt=0;           state = RECV_SYN;           EnableLinBreak;        }     } }     4 KL43 LIN slave test result   Master defines two frames: Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c    Now, master send 0X2C and 0X2D data, give the test result and the according waveform. 4.1 LIN master configuration Uart baud rate is: 9600bps 4.2  Send ID 0X2C and 0X2D frame       From the PC software of LIN master, we can find 0X2D ID can send the data successfully, and 0X2C ID can receive the correct data (0x01, 0x02) and checksum (0x10) from the KL43 LIN slave side. 4.2.1 0X2D ID frame oscilloscope waveform and debug result      From the debug result, we can find the buff can receive the correct ID, data and checksum from the LIN master.    4.2.2 0X2C ID frame oscilloscope waveform 4.2.3 0X2C ID SLAVE send back the wrong checksum     From the PC software, we can find if the KL43 code modify the checksum to the wrong data 0XAA, then the PC software will display the checksum error. This is the according oscilloscope waveform for the wrong checksum data. From all the above test result. We can find, KL43 as the LIN slave, it can receive the correct data from the LIN master, and when LIN master send the subscriber ID, kl43 also can send back the correct LIN data to the master. More detail, please check the attached code project. BTW, LIN spec can be downloaded from this link: http://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf   Attached is the code and the pdf version of this document:                  

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

Abstract         Kinetis M series MCU is Freescale’s Metrology microcontrollers based on ARM Cortex M0+ cores. The SPI module of KM provides for full-duplex, synchronous, serial communication between the MCU and peripheral devices, it also has programmable 8 or 16 bit data transmission length, 64bit FIFO mode for data transfers, DMA transmit and receive features, single wire bidirectional mode, etc. This document is mainly use the KM34Z256VLQ7 SPI module realize the erase, program and read operation in external flash MX25L6404EM2I, it also gives sample code of the detail command external flash operation, and at last, print the testing code via UART. 1.SPI pin assignment and basic code (1) SPI pin assignment SPI signal Pin name Description SPI_SS PTD1 Slave select SPI_SCK PTD2 SPI serial clock SPI_MOSI PTD3 Master data out, slave data in SPI_MISO PTD4 Master data in, slave data out External flash MX25L6404EM2I circuit: (2) SPI initialization   SPI initialization configuration the SPI pin, SPI module baud, master or slave mode, module enable, etc. the code just as following: SIM_SCGC4 |= SIM_SCGC4_SPI0_MASK|SIM_SCGC4_SPI1_MASK;                             SIM_SCGC5 |= SIM_SCGC5_PORTD_MASK; void serial_flash_init(void) {     PORTD_PCR1 &= ~PORT_PCR_MUX_MASK;            PORTD_PCR1 |= PORT_PCR_MUX(1) |0X03;                                           //Use PTD1 as SPI0_SS  // configure it as the GPIO     PORTD_PCR2 &= ~PORT_PCR_MUX_MASK;     PORTD_PCR2 |= PORT_PCR_MUX(3) |0X03;                                           //Use PTD2 as SPI0_SCK     PORTD_PCR3 &= ~PORT_PCR_MUX_MASK;     PORTD_PCR3 |= PORT_PCR_MUX(3) |0X03;                                           //Use PTD3 as SPI0_MOSI      PORTD_PCR4 &= ~PORT_PCR_MUX_MASK;     PORTD_PCR4 = PORT_PCR_MUX(3) |0X03;                                            //Use PTD4 as SPI0_MISO     GPIOD_PDDR |=  0X02; // SS pin output     GPIOD_PDOR |=  0X02; //  SS pin high     SPI0_C1 |= SPI_C1_MSTR_MASK; // SPI0 master mode                             SPI0_BR = 0x43;  //SPPR = 4, SPR = 3, bps div = (SPPR+1)*2^(SPR+1) = 80, baudrate= 24Mhz/80=300khz     SPI0_C1 |= SPI_C1_SSOE_MASK;                              SPI0_C1 &= (~SPI_C1_CPHA_MASK);  // clock polarity     SPI0_C1 &= (~SPI_C1_CPOL_MASK);  //clock phase     SPI0_C1 &= (~SPI_C1_LSBFE_MASK);  // LSB:most significant     SPI0_C1 &= (~SPI_C1_SPIE_MASK);                  //Disable RX interrrupt      SPI0_C1 &= (~SPI_C1_SPTIE_MASK);         //Disable the transmit interrupt     SPI0_C2 |= SPI_C2_MODFEN_MASK;             SPI0_C1 |= SPI_C1_SPE_MASK;  // enable SPI module } (3) One byte transfer code uint8 hal_spi_transfer_one_byte(uint8 v) {    int dummy =0;    char buff=0;    while ((SPI0_S & SPI_S_SPTEF_MASK) == 0)  // wait for transmit buffer empty    {                 dummy++;     }    dummy = SPI0_S;    SPI0_DL = v;   // send one byte to transmit buffer    while ((SPI0_S & SPI_S_SPRF_MASK) == 0); // wait ready buffer full    buff = SPI0_DL;  // read one received byte    return buff;         // return the received byte   } 3 Code realization for external flash operation command     At first, refer to the external flash program / erase flow, then I will give the according command code realization one by one. Take flash sector erase flow as an example, the according code is : void hal_spi_dev_flash_erase_sector(uint8 addr) { write_enable();      // WREN command spi_wait(WEL);     // RDSR command and wait WEL=1 hal_spi_transfe_start();    // enable CS pin , CS=0 hal_spi_transfer_one_byte(CMD_SECTOR_ERASE);   // erase one sector (4KByte)command hal_spi_transfer_one_byte(addr>>16);  // address hal_spi_transfer_one_byte(addr>>8); hal_spi_transfer_one_byte(addr>>0); hal_spi_transfe_stop();  // disable CS pin, CS=1 spi_wait(WIP);    // RDSR command and wait WIP=0;   } (1)Write enable (WREN) command : 0X06 static void write_enable(void) {     hal_spi_transfe_start();  // enable CS pin , CS=0     hal_spi_transfer_one_byte(CMD_WRITE_EN);  // Send WREN command     hal_spi_transfe_stop();  // disable CS pin, CS=1   } (2)Read status register (RDSR) sequence: 0X05 static void spi_wait(uint8 CMD) { if(CMD == WEL) while(get_sr()&0x02 != 0x02); // wait until WEL bit =1 else if(CMD == WIP) while(get_sr()&0x01 != 0x00); // wait until WIP bit =0 } static uint8 get_sr(void) {     uint8 v;     hal_spi_transfe_start(); // enable CS pin , CS=0     hal_spi_transfer_one_byte(CMD_GET_SR);  // Send RDSR command     v = hal_spi_transfer_one_byte(0x00); // read states register data     hal_spi_transfe_stop();    // disable CS pin, CS=1     return v;   } (3) Sector erase (SE) sequence: 0X20 hal_spi_transfe_start();    // enable CS pin , CS=0 hal_spi_transfer_one_byte(CMD_SECTOR_ERASE);   // erase one sector (4KByte)command hal_spi_transfer_one_byte(addr>>16);  // address hal_spi_transfer_one_byte(addr>>8); hal_spi_transfer_one_byte(addr>>0);   hal_spi_transfe_stop();  // disable CS pin, CS=1 (4) Page program (PP) sequence : 0x02 #define PAGE_SIZE 256       hal_spi_transfe_start();// enable CS pin , CS=0 hal_spi_transfer_one_byte(CMD_PROGRAM); //send flash program command hal_spi_transfer_one_byte(addr>>16); // flash page base address hal_spi_transfer_one_byte(addr>>8); hal_spi_transfer_one_byte(addr>>0); for(i=0;i<(PAGE_SIZE-1);i++) // send program data to the flash page hal_spi_transfer_one_byte(buf[i]); hal_spi_transfer_one_byte(buf[i]);   hal_spi_transfe_stop();// disable CS pin, CS=1 (5) Read at higher Speed(FAST_READ) Sequence: 0X0B void hal_spi_dev_flash_read_page(uint8 addr, char *buf) { int i; hal_spi_transfe_start();  // enable CS pin , CS=0 hal_spi_transfer_one_byte(CMD_READ); // read command hal_spi_transfer_one_byte(addr>>16);  // base address hal_spi_transfer_one_byte(addr>>8); hal_spi_transfer_one_byte(addr>>0); hal_spi_transfer_one_byte(0x00); // dummy byte for(i=0;i<(PAGE_SIZE-1);i++)    // read data back from the flash buf[i] = hal_spi_transfer_one_byte(0x00); buf[i] = hal_spi_transfer_one_byte(0x00); hal_spi_transfe_stop();  // disable CS pin, CS=1   } 4 Experimental result The test code function is to realize one sector (4KB) erasing, then read one page (256Byte) and print it out, after that, program one page , read and print it out to check the data. (1)The main function code is : static char buf[256]; int i; serial_flash_init();  // SPI initialization hal_spi_dev_flash_erase_sector(0); // erase one sector(4KByte) printf("reading page...\n"); hal_spi_dev_flash_read_page(0,buf); // read one page(256Byte) print_buf(buf,PAGE_SIZE);  // print the read data out printf("programing a page...\n"); for(i=0;i<256;i++) buf[i] = i;     // define the data which will write to the flash hal_spi_dev_flash_program_page(0,buf); // write 256BYTE to the flash page0 printf("clearing buffer..\n"); for(i=0;i<256;i++)    // clear buff buf[i] = 0; printf("reading page...\n"); hal_spi_dev_flash_read_page(0,buf); // read the page0 data out print_buf(buf,PAGE_SIZE);  // print the read data out   printf("demo end.\n"); (2) print test data reading page... 0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  0xFF,0xFF,0xFF,0xFF,  programing a page... clearing buffer.. reading page... 0x0,0x1,0x2,0x3,  0x4,0x5,0x6,0x7,  0x8,0x9,0xA,0xB,  0xC,0xD,0xE,0xF,  0x10,0x11,0x12,0x13,  0x14,0x15,0x16,0x17,  0x18,0x19,0x1A,0x1B,  0x1C,0x1D,0x1E,0x1F,  0x20,0x21,0x22,0x23,  0x24,0x25,0x26,0x27,  0x28,0x29,0x2A,0x2B,  0x2C,0x2D,0x2E,0x2F,  0x30,0x31,0x32,0x33,  0x34,0x35,0x36,0x37,  0x38,0x39,0x3A,0x3B,  0x3C,0x3D,0x3E,0x3F,  0x40,0x41,0x42,0x43,  0x44,0x45,0x46,0x47,  0x48,0x49,0x4A,0x4B,  0x4C,0x4D,0x4E,0x4F,  0x50,0x51,0x52,0x53,  0x54,0x55,0x56,0x57,  0x58,0x59,0x5A,0x5B,  0x5C,0x5D,0x5E,0x5F,  0x60,0x61,0x62,0x63,  0x64,0x65,0x66,0x67,  0x68,0x69,0x6A,0x6B,  0x6C,0x6D,0x6E,0x6F,  0x70,0x71,0x72,0x73,  0x74,0x75,0x76,0x77,  0x78,0x79,0x7A,0x7B,  0x7C,0x7D,0x7E,0x7F,  0x80,0x81,0x82,0x83,  0x84,0x85,0x86,0x87,  0x88,0x89,0x8A,0x8B,  0x8C,0x8D,0x8E,0x8F,  0x90,0x91,0x92,0x93,  0x94,0x95,0x96,0x97,  0x98,0x99,0x9A,0x9B,  0x9C,0x9D,0x9E,0x9F,  0xA0,0xA1,0xA2,0xA3,  0xA4,0xA5,0xA6,0xA7,  0xA8,0xA9,0xAA,0xAB,  0xAC,0xAD,0xAE,0xAF,  0xB0,0xB1,0xB2,0xB3,  0xB4,0xB5,0xB6,0xB7,  0xB8,0xB9,0xBA,0xBB,  0xBC,0xBD,0xBE,0xBF,  0xC0,0xC1,0xC2,0xC3,  0xC4,0xC5,0xC6,0xC7,  0xC8,0xC9,0xCA,0xCB,  0xCC,0xCD,0xCE,0xCF,  0xD0,0xD1,0xD2,0xD3,  0xD4,0xD5,0xD6,0xD7,  0xD8,0xD9,0xDA,0xDB,  0xDC,0xDD,0xDE,0xDF,  0xE0,0xE1,0xE2,0xE3,  0xE4,0xE5,0xE6,0xE7,  0xE8,0xE9,0xEA,0xEB,  0xEC,0xED,0xEE,0xEF,  0xF0,0xF1,0xF2,0xF3,  0xF4,0xF5,0xF6,0xF7,  0xF8,0xF9,0xFA,0xFB,  0xFC,0xFD,0xFE,0xFF,    demo end From the print data, we can find the code can realize flash sector erasing , flash program and flash data read out, and the test result is correct. The following wave is the page read data out after flash page program. The attachment is the testing code.

For Remote Control means, that is needed two computers - Server Computer and User Computer, which will be in connection. There are two types of connection, which can be used - HTTP or DCOM. There are two different ways how to set up the remote control in Windows. I made the tutorial, which describes both types of Remote Control. Ok - so, let´s start! HTTP Settings On the Server Computer side: 1. Plug the board to the Server Computer 2. Go to Remote Communication Server 3. Set HTTP connection and choose the right COM Port according the plugged board If the plugged board is on e.g. COM23, it is possible to edit number of Port in Device Manager On the User PC side: 1. Open FreeMASTER,  go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (HTTP) and type the IP address of the server, do not forget join to IP address :8080 3. And start communication by STOP button to successful connection DCOM Settings On the Server Computer side: 1. Plug board to the Server Computer 2. Launch DCOM in FreeMASTER Remote Server Choose COM according plugged board or edit COM according to step 2 - Server Computer in HTTP Connection (up). 3. Setting permissions for the user, User PC. Right click on Computer -> Manage. In Computer Management click to Distributed COM Users. In Distributed COM Users Properties add the user, User Computer. After that, set the permissions in Component Services. In cmd type dcomcnfg.exe In Component Services go to Computers -> My Computer -> DCOM Config -> MCB FreeMASTER Remote Server Application Right click on MCB FreeMASTER Remote Server Application and go to Properties. In Security Tab is possible to add the permissions. There are 3 types of permissions. First permission - Launch and Activation Permissions. There are 4 permission options. Local Launch and Remote Launch means, that user, User Computer can launch e.g. FM Remote Server Application. But for success communication is needed allowing Local Activation and Remote Activation. Second permission - Access Permissions. Click to Edit and Allow Local Access and Remote Access for the user. Do not forget that if there is a change of permissions, specifically allowing, it is necessary for User to log out and log in. On the User Computer side: 1. Open Freemaster, go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (DCOM) and for filling Connect string is possible to use Configure. Definitely, type the IP address of the server and ;Port Name. 3. And start communication by STOP button in FreeMASTER to successful connection And now.. you can do anything 🙂

What is it KSDK? = Kinetis Software Development Kit Kinetis SDK v2 is a collection of comprehensive software enablement for NXP Kinetis Microcontrollers that includes: •system startup •peripheral drivers •USB and connectivity stacks •Middleware •Real-time operating system (RTOS) kernels. Documents – Release Note, API Reference Manual, Getting Started with KSDK, for USB – User Guide, USB Composite Device Guide, USB Device Reference Manual and USB Host Reference Manual. All these documents is possible to find at Software Development Kit for Kinetis MCUs|NXP or <ksdk_path>\SDK_2.0_selected_device\docs KSDK Structure Diagram KSDK Features •ARM® and DSP standard libraries, and CMSIS-compliant device header files which provide direct access to the peripheral registers •Open-source peripheral drivers •Open-source RTOS wrapper driver •Real time operation systems (RTOS) including FreeRTOS OS, μC/OS-II, and μC/OS-III •Stacks and middleware in source or object formats including: − CMSIS-DSP -  a suite of common signal processing functions − FatFs - a FatFile System for small embedded systems − mmCAU - Memory-Mapped Cryptographic Acceleration Unit − SDMMC - software component supporting SD Cards and eMMC − DMA Manager - software component used for managing on-chip DMA channel resources − mbedTLS and WolfSSL - cryptographic SSL/TLS libraries − lwIP and USB Stack - a light-weight TCP/IP stack KSDK Evolution KSDK v1/v2 – what new features KSDK 2.0 brings •MQX Kernel removed from KSDK -> focus on FreeRTOS •MQX RTCS Ethernet and MFS File System Stacks -> lwIP and FatFS •OSA, Power Manager and Clock Manager -> no longer required by the drivers •USB Stack re-write -> BSD licensed solution •No platform library -> single project with all needed files •Mbed TLS now included as part of the accelerated cryptography drivers •Eliminates separate HAL and Peripheral Driver -> single driver for each peripheral •Processor Expert -> Kinetis Expert Tool •Updates for KDS -> via online update tool •Installation of KSDK -> KEX Tool (smaller download & sizes) •KEX Tool -> pin muxing selection & generation, clock configuration, low power estimation Simplified folder structure KSDK highlights & benefits •Collection of software enablement offered by free •KSDK is fully supported in these IDE: − Atollic® TrueSTUDIO® − GNU toolchain for ARM® Cortex® -M with CMake build system − IAR Embedded Workbench − Keil™ MDK-ARM − Kinetis Design Studio IDE •KSDK supports most of Kinetis MCUs •Created examples for drivers, USB, RTOS, demo applications •Start with development without device register knowledge Support & download Official support of KSDK: Kinetis Software Development Kit Create new SR according to: How to submit a new question for NXP Support More about KSDK... KSDK Official Website www.nxp.com/ksdk Introducing Kinetis SDK v2 https://community.freescale.com/docs/DOC-329783 Kinetis SDK 2.0 Transition Guide Kinetis SDK 2.0 Transition Guide KSDK Community https://community.freescale.com/community/kinetis/kinetis-software-development-kit Let´s continue in reading! See Let´s start with FreeMASTER!​

Hi All, This Kinetis Design Tips and Tricks document is used for those needing to have a checklist or troubleshooting document for their Kinetis hardware designs.  This will be a living document that is updated as needed. Enjoy all! Please give any and all feedback on this forum. Mike Steffen

Hello everyone, I have attached the audio recordings of the seminar. Each of them fits the presentations uploaded in the previous post.

The board used: FRDM-KE02 SWD: The ARM Serial Wire Debug interface uses a single bidirectional data connection(SWDIO) and a separate clock (SWDCLK) to transfer data synchronously. An operation on the wire consists of two or three phases: Packet request       The external host debugger issues a request to the DP. The DP is the target of the request. Acknowledge response   The target sends an acknowledge response to the host. Data transfer phase First enter into SWD mode: Send at least 50 SWCLKTCK cycles with SWDIOTMS HIGH and 0xE79E. This ensures that the current interface is in its reset state and enable the SWD mode. uint8_t SWJ_JTAG2SWD(void) {     uint32_t i;     SWDIO_SET();     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWJ_SendData(0xE79E);//SWJ_SendData(0xB76D);以后遇到再加     for(i = 0; i < 56; i++)     {         SW_CLOCK_CYCLE();     }     SWDIO_CLR();     for(i = 0; i < 16; i++)     {         SW_CLOCK_CYCLE();     }     return 0; } Then write DP/AP register. A successful write operation is as below: DP Register: Address     Read              Write 0x00        IDCODE           ABORT 0x04        CTRL/STAT      CTRL/STAT 0x08        RESEND           SELECT 0x0C        RDBUFF           N/A Address     Read              Write 0x00         CSW               CSW 0x04         TAR               TAR 0x08         N/A                N/A 0x0C         DRW              DRW 0xFC         IDR                N/A Read IDCODE： uint8_t SWJ_ReadDP(uint8_t adr, uint32_t *val) {     uint32_t tmp_in;     uint8_t ack;     uint8_t err;     tmp_in = SWD_REG_DP | SWD_REG_R | SWD_REG_ADR(adr);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; } uint8_t SWJ_ReadAP(uint32_t adr, uint32_t *val) {     uint8_t tmp_in, ack, err;     uint32_t apsel = adr & APSEL;     uint32_t bank_sel = adr & APBANKSEL;     if(SWJ_WriteDP(DP_SELECT, apsel | bank_sel))     {         return 1;     } tmp_in = SWD_REG_AP | SWD_REG_R | SWD_REG_ADR(adr);     /* first dummy read */     ack = SWD_Transfer(tmp_in, val);     ack = SWD_Transfer(tmp_in, val);     (ack == DAP_TRANSFER_OK) ? (err = 0) : (err = 1);     return err; }

I’ve noticed some comments about Kinetis MCUs availability and status that I’d like to address for the entire community. The Kinetis MCU portfolio has seen significant growth in the mass market and is on track for continued strong growth in the coming years. Due to this growth, the demand on the Kinetis MCUs has outstripped the available supply, leading to extended leadtimes.  We have invested additional resources across the manufacturing line for 2018 and beyond to increase overall capacity and are pleased to be able to communicate that the lead time is being reduced from 39 weeks to low 30's this month.  It is anticipated there will be further reduction in Q3 2018 with a target of being back to a typical 12-14wk lead time in Q1 2019.  Additionally, we have increased our product longevity commitment on Kinetis K, L, E, V, M and W MCUs to 15 years to support the strong pipeline of design-in activity across the Kinetis portfolio that we are seeing in the market.  This document was generated from the following discussion: Kinetis Availability &amp; Longevity

Introduction: User can modify the value of internal reference clock (IRC) by using the Trimming capability of programmers. There are two registers (ICS_C3 & ICS_C4) which contains the trim and fine trim value of the clock respectively. By default, devices comes with a factory programmed trim value which is automatically passed into these registers during reset initialization when not in debug mode. These registers needs to be passed with appropriate value to get the required clock value. This is where programmers come into picture, they generally have this capability to find the accurate trim and fine trim values corresponding to required clock. Now the catch here is that the customized trim value calculated by programmers is stored at reserved flash location (eg-0x000003ff and 0x000003fe for Ke02) and have to be copied to trim registers( ICS_C3 &C4) manually by user during code initialization. Using this process to trim the clock will give accurate desired clock without any deviation between samples. Process:  There is an option in programmers( like I am using PEmicro Multilink universal ) for enabling and setting the trimming feature in the configuration settings as below:         After enabling this option, the programmer will find the best trim value and store at internal memory location:   0x03ff for trim internal reference value 0x03fe for fine trim internal reference value   Below snapshot from console shows this process:       Next step is to copy these value from above locations and pass it to ICS_C3 and ICS_C4 manually in our application code. You can use below code lines:       ICS->C3 = *((uint8_t*) 0x03FF); // trim internal reference clock     ICS->C4 |= ICS_C4_SCFTRIM(*((uint8_t*) 0x03FE)); // fine trim internal reference clock   What the above logic does is – it copies the trimmed value from the factory programmer into your ICS register – not dependent on a constant value but dynamically update the register as per the tuning happening by the programmer. Similar option is there in production programmers also to take care of the trimming process. Note: Above steps are with reference to KE series, for other series user has to check the device reference manual for specific address and register. Also attaching a code with the above mentioned things added into it for ease of understanding. Thanks Madhur

  This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on the Kinetis devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: Kinetis:  FRDM-K64F Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. Kinetis platforms The Kinetis devices have a main module called Multipurpose Clock Generator (MCG) this module controls which clock source is used to derive the system clocks. A high-level description diagram is shown below: Figure 1. Multipurpose Clock Generator External clock sources can provide a frequency signal as the System oscillator module or the RTC oscillator module, also the MCG module has internal clock generators that the System integration module (SIM) manages, the SIM module provides module-specific clock gating to allow granular shutoff of modules. For more detailed information about the SIM module, refer to “Chapter 12. System Integration Module(SIM)” from the K64 Sub-Family Reference Manual.  The following clock diagram shows all the multiplexers, dividers, and clock gates that can be controlled by the MCG, however, we will focus on the external and internal clock sources and the MCG outputs. Figure 2. Oscillators,  MCG and SIM modules At ‘MCGOUTCLK’ line, the primary clocks for the system are generated, the circuitry provides fixed clock dividers for the Core clock, Bus clock, FlexBus clock, and the Flash Clock. This allows for trade-offs between performance and power dissipation. It’s important to know that the MCG has 9 states of operation shown in the following figure.    Figure 3. MCG operation states In the previous image, the arrows indicate the permitted MCG state transitions, for example, if the current MCG state is BLPI(Bypassed Low Power Internal) and the desired state is BLPE(Bypassed Low Power External) the shortest and allowed path to follow is first switch to FBI(FLL Bypassed Internal) then to FBE(FLL Bypassed External), and finally to the BLPE MCG state. These switching mode restrictions exist due to certain MCG configuration bits that must be changed to properly move from one mode to another. For example, in the K64 family, the MCG state after a power-on reset is FEI(FLL Engaged Internal) mode, the MCGOUTCLK is derived from the FLL clock that is controlled by the 32kHz Internal Reference Clock (IRC), the following table shows the output frequency values for this specific MCG state. Source Frequency MCGOUTCLK 20.97MHZ Core/System clocks 20.97MHz Bus clock 10.48MHz FlexBus clock 6.99MHz Flash clock 4.19MHz Table 1. K64 default MCG configuration after reset: FEI (FLL Engaged Internal) The following image shows the blocks used for the FEI state using Clocks Tool from MCUXpresso IDE. Figure 4. View of FEI state from Clock Tools For more detailed information, refer to “Chapter 25. Multipurpose Clock Generator (MCG)” from the K64 Sub-Family Reference Manual.  External Clock Sources     System oscillator The System Oscillator module is a crystal oscillator. The module, in conjunction with an external crystal or resonator, generates a reference clock for the MCU.  Supports 32 kHz crystals (Low Range mode) and supports 3–8 MHz, 8–32 MHz crystals and resonators (High Range mode) For more detailed information, refer to Chapter 26. Oscillator(OSC) at K64 Sub-Family Reference Manual.   RTC oscillator The RTC oscillator module, in conjunction with an external crystal, generates a reference clock source of 1Hz and 32.768KHz, supports 32 kHz crystals with very low power. For more detailed information, refer to Chapter 27. RTC Oscillator(OSC32K) at K64 Sub-Family Reference Manual.   Internal Clock Sources    IRC oscillators Internal clock driven by the Fast Internal Reference (FIR) @4MHz or the Slow Internal Reference (SIR) @32kHz.  IRC internal oscillator Internal 48 MHz oscillator that can be used as a reference to the MCG and also may clock some on-chip modules. PLL Phase-locked loop circuit that in conjunction with an external clock source can achieve higher and stable frequencies.   FLL Frequency-locked loop circuit that in conjunction with an internal/external clock source provides module-specific clock and achieves higher frequencies. Modifying MCG state from FEI to FBI state If the current system clock does not fit with our timing requirements we can modify it by changing the state of the MCG module, in this case, if the user requires a lower system clock frequency @32.7KHz(Slow IRC) or @4MHz(Fast IRC) instead @21MHz(FLL Engaged Internal ‘FEI’ default state) and a low power option of the MCG module, the FLL Bypass Internal (FBI) state is an option to reach these requirements. 1.1 Configure MCG mode The FBI state allows us to use the Fast IRC together with its frequency divider achieving frequencies between 31.25KHz to 4MHz, for this example the final core clock is @2MHz. Follow the next steps to change to the FBI state and select a 2MHz clock using the Clock-Tools tool from MCUXpresso IDE.        At the MCUXpresso QuickStart Panel select MCUXpresso Config Tools >> Open Clocks Figure 5. Open Config Tools        At the left top of the screen select the MCG mode to “FBI(FLL Bypassed Internal)” Figure 6. Selection of MCG Mode        Select the frequency divider block(FCRDIV) right-click on it and select “Edit settings of: FCRDIV” Figure 7. FCRDIV block        Modify the divider value from 1 to 2. Figure 8. FCRDIV divider value        Finally, the next image shows how the MCG state and the new yellow paths get modified. The Core and system clocks are @2MHz. Figure 9. FBI MCG state @2MHz 1.2 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. In the previous example, we configured the MCG state to FBI mode, this is translated to the following instructions in source code: “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();”  Figure 10. Source code view of FBI MCG configuration Another way to change the MCG state is by directly modifying the internal MCG registers. The blocks shown in the following image need to be modified to switch from the default FEI state to the FBI state. Figure 11. Blocks in FEI state to modify at MCG registers Note. MCG registers can only be written in supervisor mode. The ARM core runs in privileged(supervisor mode) out of reset, it is controlled by [nPRIV] bit in CONTROL core register. For more detailed information visit the Cortex-M4 ARM Documentation Reference Manual.        Internal Reference Source Multiplexor (IREFS), selects the reference source clock for the FLL.  1 is written to C1[IREFS]. The slow internal reference is selected.        PLL Select  Multiplexor(PLLS) Controls whether the PLL or FLL output is selected. 0 is written to C6[PLLS] The FLL output is selected as the MCG source, the PLL is disabled.        Clock Source Select Multiplexor(CLKS), selects the clock source for the MCGOUTCLK  line. 01 is written to C1[CLKS].  The internal reference clock is selected at the CLKS multiplexor.        Fast Clock Internal Reference Divider(FCRDIV), selects the Fast Internal Reference Clock divider, the resulting frequency can be in the range of 31.25KHz to 4MHz. 001 is written to SC[FCRDIV]. The dividing factor is 2 since the desired frequency is @2MHz and the source clock is @4MHz.        Internal Reference Clock Select (IRCS). Selects between the fast or slow internal reference clock source.  x is written to C2[IRCS]. Write 0 for Slow IRC or 1 for Fast IRC.        Finally, to enable the low power when neither the PLL nor FLL are used, a register in C2[LP] is modified. x is written to C2[LP]. Enable, or Disable the PLL & FLL in all the bypass modes.     This is translated to the following instructions in source code in “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();” functions:  Figure 12. Source code view of Internal MCG Registers Note. C1, C2, C6, and SC registers are part of the internal MCG control registers.  References K64 Sub-Family Reference Manual Also visit LPC's System Clocks