Kinetisマイクロコントローラ・ナレッジ・ベース

ディスカッション

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.

The FRDM-KL25Z is an ultra-low-cost development platform enabled by Kinetis L Series KL1 and KL2 MCUs families built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL25Z is supported by a range of Freescale and third-party development software. Features MKL25Z128VLK4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP Capacitive touch “slider,” MMA8451Q accelerometer, tri-color LED Easy access to MCU I/O Sophisticated OpenSDA debug interface Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps P&E Multilink interface provides run-control debugging and compatibility with IDE tools Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit Take a look at these application notes: USB DFU boot loader for MCUs Developer’s Serial Bootloader. Low Cost Universal Motor Drive Using Kinetis L family . Writing your First MQXLite Application Learn more...

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.

下面简单介绍下Kinetis M0+相关的几大系列MCU: 1. Kinetis L Kinetis L系列MCU的最大特点是它具有非常出色的低功耗特性，L系列目前包含KL0X、KL1X、KL2X、KL3X、KL4X和KL8X六个子系列，除了KL8X的主频为72 Mhz以外，其他主频都为48 Mhz。KL0X系列是入门级MCU，它的Flash相对较小，引脚数量相对较少。KL1X系列是通用型MCU，KL2X系列带有USB功能，KL3X系列支持段式LCD，KL4X系列同时带有USB和支持段式LCD。KL8X系列具有很多Security相关的特性，包括篡改检测、真正的随机数生成器和低功耗可信加密引擎，支持AES、DES、3DES、SHA、RSA和ECC。 2. Kinetis E Kinetis E系列MCU的最大优势是电磁抗噪性能，Kinetis E系列是业界首款在Cortex M0+基础上构建5V (2.7~5.5V)MCU系统的产品，结合了低成本、高性能、先进的EMC和ESD保护功能，E系列目前包括KE02、KE04和KE06三个子系列，KE02主频有20M和40M两种，KE04和KE06都为48M，KE06相比KE02和KE04主要是多了1个CAN接口。 3. Kinetis V Kinetis V系列MCU专为BLDC、PMSM和ACIM电机控制以及数字电源转换应用而设计。V系列目前包含KV1X、KV3X、KV4X和KV5X四个系列，其中Kinetis KV1X系列是入门级产品，Cortex-M0+内核，采用75 MHz M0+内核及硬件平方根和除法模块，与同等级32位MCU相比，在无传感器PMSM控制应用中的性能提高27%。 4. Kinetis W Kinetis W系列集成了领先的Sub-GHz和2.4 GHz射频收发器，可创建可靠、安全、低功耗的嵌入式无线解决方案。W系列目前包含KW0X、KW2X 、KW3X和KW4X四个系列，其中KW0X是M0+内核，48 Mhz，Sub-GHz无线电，超低功耗无线微控制器，KW3X是M0+内核，48 Mhz，具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1射频连接。KW4X也是M0+内核，具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1和IEEE® 802.15.4-2011射频连接。 5. Kinetis M Kinetis M系列 MCU适用于单芯片1、2和3相电表和流量计，以及其它高精度测量应用。M系列目前包括KM1X、KM2X两个系列，KM1X主要用作计量，KM3X不仅具有计量功能，同时还有段式LCD控制器。选型的方法主要有以下几种： 1）如果您已经知道要查找的产品的基本信息,最常用的方法是在飞思卡尔官网主页进行查找； 2）如果您并不清楚需要查找的芯片基本信息，飞思卡尔还提供了一些辅助的选型工具来帮助用户进行芯片的选型，包括：i）参数选型工具; ii）选型神器Cross Check; iii）解决方案顾问; 具体的选型操作流程可以参考:针对飞思卡尔单片机的快速上手指南中的2.2小节，其中有非常详细的介绍。

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 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.

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.

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)

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 🙂

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

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

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:

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 & Longevity

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

Kinetisマイクロコントローラ・ナレッジ・ベース

Kinetis Microcontrollers Knowledge Base

ディスカッション

L-Series SPI GPIO CS/SS

Yes, OSDA can trim the reference of internal clock source!

Recordings

Introducing the Freescale Freedom Development Platform FRDM-KL25Z

Kinetis Hardware Design Tip & Tricks

Serialization of memory operations and events

Kinetis M0+ 芯片选型

USB MSD Bootloader Implementation

Port MCUBoot2.0.0 to TWR-K60D100

Programming the K32L3A MCU Flash IFR Fields

Porting uC/OS-II to MAPS-K22

External flash control via kinetis M series SPI module

FREEMASTER: Remote Server Tutorial

La serie Kinetis L de microcontroladores ARM Cortex-M0+

Kinetis K22_120 MHz devices

ADK Library (Based On FRDM-KL26Z Board.)

KL series LIN slave simply usage sharing

K20 USB device MSD bootloader

Kinetis Availability & Longevity

Kinetis System Clocks