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.

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.

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

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

Introduction This document is being written to communicate the need for serialization of memory operations and events in an end application.  In addition, directions will be provided to properly serialize memory operations in the end application.  Memory operations and event serialization applies to all Kinetis devices but is only necessary in specific scenarios. These scenarios include memory writes and reads, clearing status flags, and changing mode control operations. Serialization of memory operations Serialization of memory operations or events is the action of guaranteeing that said memory operations or events are executed in a specific order.  This action is required when making a change to a peripheral module when that change must complete before continuing with program execution.  Users often make the mistake of assuming that since a peripheral register has been written to, the change is in effect immediately.  However, this is not always the case.  The Kinetis series devices implement a crossbar and peripheral bridge interface system that allows masters (the CPU, DMA, etc.) to interface with the peripherals.  The crossbar allows multiple masters to access the individual peripherals on the bus, and the peripheral bridge functions as a bus protocol translator between the crossbar switch and the slave peripheral bus.  Wait states can be inserted at either stage of the communication channel (crossbar or peripheral bridge).  When a master attempts to access a slave and another master is already accessing this slave or the slave is busy, wait states will be inserted.  If the access is a write, then the master's write is simply pushed to the peripheral bus and the master continues.  However, if the access is a read, the master must wait for a response from the slave.  The slave may insert wait states in this communication as it must finish any commands (or writes) it was previously given before responding.    Peripheral module changes that require serialization actions include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  If the events or memory operations are not serialized in these situations, the CPU could go on to execute code with undesired effects. When do I need to serialize my memory operations and events? Memory operations and events require serialization anytime the program needs to guarantee that a peripheral access happens before code execution continues.  Examples of these situations includes: Exiting an interrupt service routine (ISR) Changing a clock mode or power mode Configuring a function Configuring a hardware change Software triggering a hardware event How do I serialize my memory operations and events? Memory operations are serialized by performing the following operations: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations By simply reading the register that was just written, the core is forced to wait for a response from the peripheral module that was written before code execution can continue.   In this manner, it is guaranteed that the peripheral module will have completed the desired operations. Example event serialization The following is an example of a function that services the LPTMR ISR flag and implements the event serialization discussed in this document.  void lptmr_isr(void) {   // Declare dummy variable to store the read of the LPTMR0_CSR register volatile int dummy_var; /****   STEP #1  ****/   // Clear the flag; enable interrupts; enable the timer   LPTMR0_CSR = ( LPTMR_CSR_TEN_MASK | LPTMR_CSR_TIE_MASK | LPTMR_CSR_TCF_MASK  );   /****  STEP #2  ****/    // Store CSR register in dummy_var to serialize the clearing of the TCF flag   dummy_var = LPTMR0_CSR; } Conclusion In conclusion, there are situations where code execution can continue before a peripheral change has taken effect. These situations include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  Sometimes these events can cause unexpected results or even cause your application to crash.  These situations call for the serialization of memory operations and events, which is simply the act of guaranteeing that events and code are executed in a specific order.  To serialize memory operations, simply follow these directions: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations Following these steps, you will be guaranteed that peripheral configurations have taken effect before continuing with the application. 

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

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.

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

Abstract MK60 is a popular MCU in Kinetis K family. NXP has prepared some kinds of bootloader for TWR-K60D100. But as we all know, MCUBoot2.0.0 is the most update bootloader for Kinetis family. It is a configurable flash programming utility that operates over a serial connection on Kinetis MCUs. It enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. But sinceTWR-K60D100 is a relatively old platform compare to K22 and K64/K65/K66, MCUBoot2.0.0 did not add MK60 to its target board. If customer don’t like those old bootloader, they have to port it by themselves. This article tries to guide user to port MCUBoot to TWR-K60D100 base on Chapter 10 in Kinetis Bootloader v2.0.0 Reference Manual. This time we use KDS. Software requirement: Kinetis Design Studio 3.2 MCUBootloader 2.0.0 (KBoot 2.0.0) MCUXpresso Config Tools v4.0 SDK_2.2_TWR-K60D100M Porting flow Step 1: First I copy NXP_Kinetis_Bootloader_2_0_0\targets\MK64F12 to NXP_Kinetis_Bootloader_2_0_0\targets\MK60D100. The reason I select MK64 is more likely to MK60 than other target, especially in clock distribution, system integration module and signal multiplexing. In mk60d100\src directory, rename the following files: clock_config_mk64f12.c —> clock_config_mk60d100.c hardware_init_mk64f12.c —> hardware_init _ mk60d100.c memory_map_mk64f12.c —> memory_map _ mk60d100.c peripherals_ mk64f12.c —> peripherals _ mk60d100.c Then copy system_MK60D10.c and system_MK60D10.h from SDK_2.2_TWR-K60D100M to mk60d100\src\startup, copy startup_MK60D10.S from SDK_2.2_TWR-K60D100M to mk60d100\src\startup\gcc. Step 3: Then I copy \src\platform\devices\MK64F12 to \src\platform\devices\mk60d100, copy SDK_2.2_TWR-K60D100M\devices\MK60D10\fsl_device_registers.h, MK60D10.h, and MK60D10_features.h to this new directory. Step 4: Open the KDS project in MK60D100 and replace above old file with new file. After that, I change some setting. Figure 1. Target Processor change   K64 has hardware FPU, but K60D100 hasn’t. So, Float ABI must be changed to software. There is a C/C++ preprocessor define that is used by the bootloader source to configure the bootloader based on the target MCU. This define must be updated to reference the correct set of device-specific header files. Figure 2. Preprocessor change   As to the link file, it needn’t to be change. We can use K64’s link file. TWR-K60D100 use an old version PE debugger. So, the debugger setting must be changed. Figure 3. Debug setting Step 5: MK60’s clock distribution structure is different with MK64. We must modify this part. As it is very complex, use MCUXpresso Config Tools to generate this config code is a sensible choice. Open the tools and step clock structure as below: Figure 4. clock setting After that, generate the code and save them to \src\platform\devices\mk60d100. Since MCUBoot2.0.0 is not base on SDK2.x, we must copy some related driver file from SDK2.x package, include fsl_smc.c, fsl_smc.h, fsl_rtc.c, fsl_rtc.h. Then add them to project. In clock_config_mk60d100.c line 168, the code is clock_mode_switch(s_currentClockMode, kClockMode_FEI_48MHz); Replace it with:      BOARD_BootClockUSB(); // this function was generated by MCUXpresso Config Tool Then add the head file of “clock_config.h”.   Step 6: TWR-K60D100 use UART5 as the debug UART port. Please refer to https://community.nxp.com/docs/DOC-340954 for detail. MCUBootloader2.0.0 do not support UART5. User must add its code in pinmux_utility_common.c.   Step 7: Modify usb_clock_init() in hardware_init_MK60D100.c as below bool usb_clock_init(void) {    SIM->SCGC4 &= ~SIM_SCGC4_USBOTG_MASK;      SIM->CLKDIV2 = (uint32_t)0x00L;    SIM->SOPT2 |= SIM_SOPT2_USBSRC_MASK | SIM_SOPT2_PLLFLLSEL(0x01);     //k60 PLLFLLSEL change from 3 to 1      SIM->SCGC4 |= SIM_SCGC4_USBOTG_MASK;   //   USB0->CLK_RECOVER_IRC_EN = 0x03; //   USB0->CLK_RECOVER_CTRL |= USB_CLK_RECOVER_CTRL_CLOCK_RECOVER_EN_MASK;   //   USB0->CLK_RECOVER_CTRL |= 0x20;      return true; }   Modify memory_map_MK60D100.c as below: memory_map_entry_t g_memoryMap[] = {    { 0x00000000, 0x0007ffff, kMemoryIsExecutable, &g_flashMemoryInterface },   // Flash array (512KB)    { 0x1fff0000, 0x2000ffff, kMemoryIsExecutable, &g_normalMemoryInterface }, // SRAM (256KB) { 0x40000000, 0x4007ffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // AIPS peripherals      { 0x400ff000, 0x400fffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // GPIO    { 0xe0000000, 0xe00fffff, kMemoryNotExecutable, &g_deviceMemoryInterface }, // M4 private peripherals    { 0 }                 // Terminator };   Modify bl_uart_irq_config_common.c as below: void UART_SetSystemIRQ(uint32_t instance, PeripheralSystemIRQSetting set) {    switch (instance)    {        case 0: #if (FSL_FEATURE_SOC_UART_COUNT > 1)        case 1: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 1) #if (FSL_FEATURE_SOC_UART_COUNT > 2)        case 2: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 2) #if (FSL_FEATURE_SOC_UART_COUNT > 3)        case 3: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 3) #if (FSL_FEATURE_SOC_UART_COUNT > 4)        case 4: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 4) #if (FSL_FEATURE_SOC_UART_COUNT > 5)          // add UART5 support        case 5: #endif // #if (FSL_FEATURE_SOC_UART_COUNT > 5)              if (set == kPeripheralEnableIRQ)            {                NVIC_EnableIRQ(uart_irqs[instance]);            }            else            {                NVIC_DisableIRQ(uart_irqs[instance]);            }            break;    } }   In target_config.h, modify kMaxCoreClock value to 100.   Step 8: After all of the above work, compile the project and download to TWR-K60D100 board. You’ll find KinetisFlashTool.exe can recognize the device by UART. If you establish a Tower system with TWR-SER board, KinetisFlashTool can also recognize the device by USB.   Conclusion: K60 is the base of many Kinetis K series MCU, include K10, K20, K61, K70. If you want to port MCUBoot2.0.0 to these MCU, you just want to update the clock_config file.

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

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

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 🙂

   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.

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:                  

  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   

在KE系列MCU中提供了多种寄存器用于实现GPIO的控制：    -PDOR寄存器，用于写入或读取IO的输出状态    -PSOR寄存器，用于置位IO口    -PCOR寄存器，用于清零IO口    -PTOR寄存器，用于翻转IO口    -PDIR寄存器，用于读取IO口的输入状态 当我们想要将PTA0置1时，有多种方法可以选择：    1. 直接操作寄存器，PDOR或PSOR都可以实现：          GPIOA->PDOR |= 0x0001；          GPIOA->PSOR |= 0x0001；          直接操作寄存器的效率更高，但可读性较差。    2. 使用官方的库函数操作       GPIO_PinSet(GPIOA, GPIO_PTA0);       库函数的可读性很好，但显得有些啰嗦，字符较多。 通过KE的BME来实现GPIO的操作能够很好的解决上面的问题，只用将附件中的头文件gpio_bitdef.h包含到工程里，再调用里边的宏定义就可以了。 对PTA0置位和清零可以使用下面的语句： POUTA0 = -1; POUTA0 = 0; 读取PTA0的输入状态则可以使用： tmp = PINA0; 上面的语句是不是看上去简洁了很多呢。 实际上上面GPIO的读写指令，是通过BME的BFI（位域插入）和BFX（位域提取）指令来实现的。 -其中ADDR是存储空间内的地址，我们最终操作的还是GPIO的寄存器，因此在两个指令中分别取GPIOA的PDOR寄存器地址和PDIR寄存器地址。 -bit则表示需要插入或提取位域的起始位置，由于这里是PTA0，PTA0位于寄存器的最低位，因此这里填入了0。 -width则表示需要插入或提取位域的宽度，我们只对单个管脚进行操作，也就是单个位进行操作，宽度自然就是1了。 需要注意的是，BFI（位域插入）指令在插入时，是将对应位插入到目的地址。因此，如果直接为POUTxx赋值为1的话，有可能出现错误。 POUTA0 = 0x01;//正确 POUTA1 = 0x02;//正确 POUTA2 = 0x04;//正确 POUTA1 = 0x01;//错误 为了避免这种情况，我们可以在IO口需要置位时，直接将POUTxx赋值为-1，即0xFFFF FFFF，这样保证了每一位的值都为1。 #define BME_BFI(ADDR,bit,width)        (*(volatile uint32_t *)((((uint32_t)ADDR&0xFFFF))   \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19)) #define BME_BFX(ADDR,bit,width)        (*(volatile uint32_t *)(((uint32_t)ADDR&0xFFFF)    \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19))  #define POUTA0 BME_BFI(&GPIOA->PDOR,0,1) #define PINA0 BME_BFX(&GPIOA->PDIR,0,1) ‍‍‍‍‍‍‍‍‍‍

Hello Kinetis friends! The launch of new Kinetis devices and development tools called "Kinetis K2" brought some new K22_120 MHz devices to the K22 family portfolio. :smileyinfo: Please notice the name "Kinetis K2" only refers to the Kinetis generation, but it is not related to part number (e.g. K63/K64 are part of K2 generation). Previously existing Kinetis portfolio already had some K22_120 MHz devices, so this  caused confusion regarding the documentation, header files, features, development boards and others, because the part numbers are very similar. I created the next reference table outlining the existing K22_120 MHz parts with their corresponding files and boards. The last column is an overview of the features or peripherals that are either missing or added in each device. :smileyalert: IMPORTANT NOTES:           - I gathered and put together this information as reference, but it is not official. For the most accurate information please visit our webpage www.nxp.com.           - Header files MK22F12.h and MK22FA12.h apply for legacy K22_120 devices. However TWR-K21F120M(A) board has a K21_120 part, so use MK21F12.h or MK21FA12.h instead.      Colleague Carlos Chavez released an Engineering Bulletin (EB811) with good information related to this document:      http://cache.nxp.com/files/microcontrollers/doc/eng_bulletin/EB811.pdf Regards! Jorge Gonzalez

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

La serie Kinetis L es una combinación de eficiencia energética, escalabilidad, valor y facilidad de uso que revolucionará el mercado de microcontroladores de nivel básico. Ofrece a los usuarios de arquitecturas heredadas de 8 y 16 bits una ruta de migración hacia la gama de microcontroladores Kinetis de 32 bits y les permite aumentar el rendimiento y ampliar la funcionalidad de sus productos finales sin incrementar el consumo de energía ni los costes del sistema. La serie Kinetis L se compone de cinco familias de microcontroladores: KL0, KL1, KL2, KL3 y KL4. Cada familia combina excelentes corrientes dinámicas y de parada con una capacidad extraordinaria de procesamiento, una amplia selección de memorias flash y una gran variedad de opciones analógicas, de conectividad y de periféricos HMI. La familia KL0 es compatible en pines con la familia S08Px de 8 bits (lo que tiende un puente entre el desarrollo de 8 bits y la cartera Kinetis) y compatible en software con otras familias de la serie Kinetis L. Las familias KL1, KL2, KL3 y KL4 presentan una compatibilidad mutua en hardware y software, además de ser compatibles con sus equivalentes de la serie Kinetis K basada en el Cortex-M4 (KL1 -> K10, KL2 -> K20…). De este modo, los desarrolladores disponen de una ruta de migración ascendente/descendente hacia mayor/menor rendimiento, memoria y funcionalidad integrada, lo que les permite reutilizar el hardware y el software en todas las plataformas de productos finales y reducir el tiempo necesario para la comercialización. Las primeras familias disponibles en el mercado serán KL0, KL1 y KL2 a finales de septiembre de 2012. La disponibilidad de las familias KL3 y KL4 está prevista para el primer trimestre de 2013. Procesador ARM Cortex-M0+ El procesador ARM Cortex-M0+ ofrece niveles más altos de eficiencia energética y de rendimiento y es más fácil de usar que su antecesor, el Cortex-M0. En cuanto a las instrucciones, mantiene plena compatibilidad con todos los demás procesadores de la clase Cortex-M (Cortex-M0/3/4), por lo que los desarrolladores pueden reutilizar sus compiladores y herramientas de depuración existentes. Principales características: 1,77 coremarks/MHz: entre 2 y 40 veces más que los microcontroladores de 8/16 bits, un 9 % más que el Cortex-M0. Coremarks/mA: entre 2 y 50 veces más que los microcontroladores de 8/16 bits, un 25 % más que el Cortex M0. Pipeline de 2 etapas: reducidos ciclos por instrucción (CPI), lo que permite instrucciones de bifurcación y entradas ISR más rápidas. MTB (Micro Trace Buffer): solución ligera y no intrusiva; la información del rastreo se guarda en una pequeña área de la SRAM del microcontrolador (tamaño definido por el programador), lectura a través de SWD/JTAG. Amplio soporte para el entorno ARM. Acceso E/S monociclo: frecuencia de conmutación de la interfaz GPIO un 50 % más alta que la de la E/S estándar, lo que mejora el tiempo de respuesta a eventos externos y permite manipular bits (bit-banding) y emular protocolos de software. Espacio de direcciones lineal de 4 GB: elimina esquemas de paginación complejos y simplifica la arquitectura de software. Solamente 56 instrucciones: mayoritariamente codificadas en 16 bits; opción para MUL rápida de 32 x 32 bits en un ciclo. Conjunto de instrucciones: totalmente compatible con el procesador Cortex-M0, subconjunto de instrucciones del procesador Cortex-M3/4. La mejor densidad de códigos de su categoría en comparación con arquitecturas de 8/16 bits; menor tamaño de memoria flash y reducción del consumo de energía; mayor rendimiento que sus equivalentes de 8 y 16 bits. Acceso a la memoria del programa; reducción del consumo de energía. Familias de microcontroladores de la serie Kinetis L Los microcontroladores de la serie Kinetis L se basan en la funcionalidad del procesador ARM Cortex-M0+, que presenta un diseño de plataforma de bajo consumo energético así como modos operativos y dispositivos periféricos que ahorran energía. El resultado es un microcontrolador que ofrece la mejor eficiencia energética de la industria, consume menos de 50 μA/MHz en el modo VLPR (Very Low Power Run) y puede despertarse rápidamente desde el estado de reposo, procesar datos y restablecer el modo de reposo, lo cual alarga la vida útil de la batería en las aplicaciones. Para ver una demostración de la eficiencia energética de la serie Kinetis L, visite www.freescale.com/ftf. Familias de microcontroladores: Familia KL0: la puerta de entrada a la serie Kinetis L; microcontroladores de 8-32 kB y de 24-48 pines, compatibles en pines con la familia S08P de 8 bits y en software con todas las demás familias de la serie Kinetis L. Familia KL1: microcontroladores de 32-256 kB y de 32-80 pines con comunicaciones adicionales y periféricos analógicos, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K10 (CM4) de la serie K. Familia KL2: microcontroladores de 32-256 kB y de 32-121 pines con USB 2.0 de máxima velocidad tipo host/device/OTG, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K20 (CM4) de la serie K. Características comunes a todas las familias de microcontroladores de la serie Kinetis L: Procesamiento extremadamente eficiente Procesador ARM Cortex-M0+ de 48 MHz Tecnología flash de bajo consumo de energía: 90 nm Funciones de manipulación de bits < 50 μA/MHz; 35,4 coremarks/mA Barra cruzada de puente periférico Controlador de memoria flash con estado de espera cero Modos de consumo de energía ultrabajo Tecnología flash con baja fuga: 90 nm Múltiples modos RUN, WAIT y STOP Activación en 4,6 μs desde el modo de reposo profundo Bloqueo de reloj y de potencia (clock & power gating), opciones de arranque con bajo consumo de energía Reloj VLPR: precisión con un 3 % máximo de margen de error, que normalmente es del 0,3-0,7 % Consumo de corriente en modo de reposo profundo: 1,4 μA con retención de registros; LVD activo y activación en 4,3μs Periféricos que ahorran energía Los periféricos funcionan en modos de reposo profundo y son capaces de tomar decisiones inteligentes y de procesar datos sin despertar al núcleo: ADMA, UART, temporizadores, convertidor analógico-digital (ADC), pantalla LCD con segmentos, sensores táctiles... ADC de 12/16 bits Convertidor digital-analógico (DAC) de 12 bits Comparadores analógicos de alta velocidad Temporizadores de alta capacidad para una gran variedad de aplicaciones, incluyendo el control de motor Para tener más información del fabricante y de los servicios, por favor visiten nuestra microsite. Via Arrow Europe