We always received a question as below: “Where can I find the Altium footprint for Kinetis device XYZ?” First you can download the CAD file from the link below: Kinetis Symbols, Footprints and Models|NXP    It need to download an Ultra Librarian tool and install it: On Kinetis Symbols, Footprints and Models|NXP  I search for my device: I select the device and download the BXL file: In the Ultra Librarian tool, I load that *.bxl file, select my CAD tool of choice (Eagle) and export it: After exporting, a report is shown with the information where the files are stored (the duplicated folders are strange?) and instructions how to import it into Eagle: Following these steps, I have now the footprint in Eagle : Summary Finally, I can get footprints from NXP for the Kinetis Devices. It requires downloading multiple files and a converter. But this is fine, as it offers flexible conversion to many different CAD and PCB Layout tools, including the popular Eagle and Altium.

The modularity of the tower system makes it great for prototyping, but for higher speed interfaces, there might be timing/signal integrity issues from having the TWR-MEM. For example, if you run the NFC demo from MQX 4.2: C:\Freescale\Freescale_MQX_4_2\mqx\examples\nandflash\build\iar\nandflash_twrk60f120m, It works well standalone, but with TWR-MEM connected. It failed when trying to read the data from nandflash. Because the NAND flash is on the TWR-K60F120M board, any time you access the NAND flash through NFC the signal will still travel all the way to the MRAM and reflect back which can distort the signals. Checking with the NFC driver code, you may find the high driven strength of NFC IOs has already been enabled. Decreasing the NFC module clock by setting SIM_CLKDIV4_NFCDIV to 31,  the demo still failed. How to fix it? Here we provide a trick/solution for this issue: Ｅｎａｂｌｅ　ｔｈｅ　ｉｎｔｅｒｎａｌ　ｐｕｌｌ－ｕｐｓ　ｏｎ　ＮＦＣ　ｉｎｔｅｒｆａｃｅ. then you may set a slower NFC clock by setting SIM_CLKDIV4_NFCDIV to 12, this value can be larger to make the communication more stable, but please note if you try to design a custom board, there is no reason it shouldn’t work at max frequency with a better layout. Hope that helps, -Kan

Customer requirement and making it happen This hands-on test is coming with the true customer requirement. Customer designs the battery powered device with SLCD display and lowest power consumption is the key requirement. Customer considers the KL43 and wonder the power consumption data about RTC & SLCD modules. So there with below requirements about the test: Run the RTC and SLCD in the lowest possible power mode Display time at SLCD with [00:00] and update every minute via RTC interrupt               One button shall turn on/off the SLCD display Measure the KL43 power consumption data KDS IDE with KSDK V2.0 software According to above requirement, which low power mode should be selected? RTC and SLCD modules should work at this low power mode. From the KL43 reference manual table 7-2 [Module operation in low power modes] with below info:      5. In VLLS0 the only clocking option is from RTC_CLKIN.      7. End of Frame wakeup not supported in LLS and VLLSx. RTC and SLCD modules could work at VLLS1 low power mode with Async operation. Using VLLS1 low power mode, the RTC and SLCD module clock could select OSC32KCLK with below clocking figure: KL43 wake up from VLLS1 low power mode following wake up reset and the software will check the system reset status register to check what kind of reset happens and print related info. LLWU module is used as VLLS1 lower power mode wake up module with two wake up source, one is RTC Alarm interrupt, the other one is PTC3 (SW3). The Reset pin (SW2) also could wake up the VLLS1 low power mode. Test environment introduction Hardware platform using FRDM-KL43Z board with below feature: MKL43Z256VLLZ4 MCU (48 MHz, 256 KB flash memory, 32 KB RAM, 16 KB ROM Dual role USB interface with mini-B USB connector OpenSDA Four-digit segment LCD module Capacitive touch slider Ambient light sensor MMA8451Q accelerometer MAG3110 magnetometer 2 user push buttons Battery-ready, power-measurement access points Arduino R3 compatibility Software platform bases on KSDK V2.0 for FRDM-KL43Z board, which could be downloaded from kex.nxp.com. Attached demo software default path is: C:\Freescale\SDK_2.0_FRDM-KL43Z\boards\frdmkl43z Test software code introduction Below is the software flow chart: Test result SLCD ON with power consumption 2.0uA SLCD OFF with power consumption 1.2uA

With the HMI developing, touch sensing is more and more popular. The GPIO-based method was developed as a low-cost way to do touch sensing. NXP had developed this sensing method and provide as TSS library (which combines support for GPIO and hardware-based touch sensing).The GPIO method uses the RC charge time in a capacitor (the electrode or touch pad)   Measurement Principles: TSI Method TSI method uses configurable current sources. The current sources are active outputs, making them far more robust against noise. Current sources are configurable, making it possible to configure sampling time. The signal slope depends on the applied current and the capacitance. When a finger approaches the electrode, frequency decreases. Another oscillator, uses a internal unchanging capacitor, this is our reference, we will configure it to oscillate faster than the external one. By comparing how many reference oscillations where counted by the TSI module per external reference scan, we can know when a touch happened.

Hi All, Embedded systems industry are tending to optimized their products to offers a better performance in power management, aiming for longer battery life, using low-power modes in the application without reducing functionality. With this in mind, it arises a requirement in these compact devices, power supply monitor. This document will include a brief description of some features available in different power modes of the Kinetis family and it will focus on how we can implement these features, using KSDK 2.0, to monitor power supply voltage and detect when this voltage has fallen at determined value. This document is based MCU K21 but the same principles can be applied to any Kinetis K and L family. It will use KDS 3.2 as IDE and TWR-K21F120M evaluation board as target.   Hope you can find it useful Best Regards Jorge Alcala

Hello All, Power consumption of devices and implications around designing on embedded systems is a common topic nowadays. Kinetis MCUs offer different power modes to fit user's needs. Among these low power modes, we can find the lowest consumption modes: Low-Leakage Stop (LLS) and Very Low-Leakage Stop modes (VLLS). Attached document provides a brief introduction/explanation on these modes and lists the steps needed to configure MCU to operate in any of these modes. It is a bare-board project for FRDM-KL26Z but same principle applies to other Kinetis families. Also, two projects for KDS v3.2 are attached for reference. I hope you can find them useful! Regards, Isaac

Encrypted QuadSPI image Implementation       The Kinetis family of MCU includes the system security and flash protection features that can be used to protect code and data from unauthorized access or modification. This application note discusses the usage of encrypted boot with the KBOOT and experiment with the FRDM-K82 board. FRDM-K82 board

Problem Analysis and solutions for booting from ROM BOOTLOADER in KL series 1 Abstract      When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, they have found a problem that if the code boot from the ROM instead of the flash, the application code about the LPUART and I2C will run in abnormal state, especially when use PTA1 as the  LPUART receive pin, UART transmit function has no problem, but when the PTA1 receive the UART data, the code will run to the abnormal area and can’t return back, the code will be crash. This problem only happens on booting from the ROM and the uart and i2c peripheral are enabled in BCA 0x3d0 address, uart peripheral enablement in BCA area will influence the application PTA1 uart receive, i2c peripheral enablement in BCA area will influence the i2c0 module in the application code. If booting from the flash or booting from ROM but the uart and I2C peripheral are disabled in the BCA 0x3d0 address, everything is working ok in the application code.      This document will take the UART problem as an example, give details of the problem reproduction, testing, analysis and the solutions. The I2C problem is the same when booting from the ROM bootloader. 2 Problem reproduction and analysis  Testing preparation: IDE: KDS 和IAR Hardware: FRDM-KL43 Software: 3.0 and KSDK2.0_FRDM-KL43      We mainly reproduce the uart receive problem in two ways: new KDS PE project based on KSDK1.3.0 and official newest sample code package KSDK2.0_FRDM-KL43. 2.1 Problem reproduction in new creating kds project Because the KSDK2.0 still doesn’t support the PE function in the KDS IDE, so we use the KSDK1.3.0 as the PE KSDK to create the new KDS project. 2.1.1 Create KDS KL43 project The new KDS PE project creating is very simple, here just describe the important points which is relate to the UART problem after booting from the ROM. At first create a new KDS PE project which is based on KSDK1.3.0, and choose the chip as MKL43Z256VLH4, select the MCG mode as HIRC, and configure core clock to 48Mhz, bus clock to 24Mhz. Then add the uart module fls_debug_console for testing, because the FRDM_KL43 is using PTA1 and PTA2, the console module can be configured like the following picture, after the module is configured, press the code generation button to generate the project code. Then add the simple code in file main.c main function for testing: char a; for(;;) {                 PRINTF(" test!\n");                 a= GETCHAR();                 PUTCHAR(a);               } The code function is: printf the “test!” to the COM port in the PC, then wait the uart data, if receive the data, then printf the received data back and run this loop function again.   2.1.2 Add the BCA area    From the KL43 reference manual, we can get that, BCA start address is 0X3C0:     The KDS newly created project didn’t contain the BCA area in the link file, so we need to add this area in the link file and add the BCA data in the start file by ourselves. 2.1.2.1 Divide the BCA flash are in .ld file Add the following code to define the BCA start flash address and the flash size in the ProcessorExpert.ld memory area: m_bca                 (RX)  : ORIGIN = 0x000003C0, LENGTH = 0x00000040 Then add this code in the SECTIONS area:   .bca :            {              . = ALIGN(4);              KEEP(*(.bca)) /* Bootloader Configuration Area (BCA) */              . = ALIGN(4);            } > m_bca At last, the ld file is like this: For the ld file protection, we can change the ld file properties to read-only, then this file won’t be changed to the initial one after building. 2.1.2.2 Add the BCA data in the start file      After add the BCA flash area divide code, we still need to define the BCA data in the start file:    /* BCA Area */     .section .bca, "a"                 .ascii "kcfg"                            // [00:03] tag                 .long 0xFFFFFFFF // [07:04] crcStartAddress                 .long 0xFFFFFFFF // [0B:08] crcByteCount                 .long 0xFFFFFFFF // [0F:0C] crcExpectedValue                 .byte 0x03                                             // [10] enabledPeripherals  I2C and UART                 .byte 0xFF                                              // [11] i2cSlaveAddress                 .short 3000                           // [13:12] peripheralDetectionTimeout (milliseconds)                 .short 0xFFFF                        // [15:14] usbVid                 .short 0xFFFF                        // [17:16] usbPid                 .long 0xFFFFFFFF  // [1B:18] usbStringsPointer                 .byte 0xFF                                              // [1C] clockFlags                 .byte 0xFF                                              // [1D] clockDivider                 .byte 0xFF                                              // [1E] bootFlags                 .byte 0xFF                                              // [1F] reserved*/    More details, please refer to this picture:       So far, we have create the FRDM-KL43 test project which contains the BCA area, and boot from the ROM that can be modified in the flash address 0X40D, bit 6-7 in 0X40D is the BOOTSRC_SEL bits, 00 boot from flash, 10 and 11 boot from ROM, more details about the FOPT, please refer to Table 6-2. Flash Option Register (FTFA_FOPT) definition in reference manual.     2.1.3 Test result and analysis       Now, list the test result after booting from ROM or flash, and boot from ROM but enable the peripherals. Boot from: ROM peripheral Test Result Flash XX OK ROM 0XFF, enable all NO, UART can’t receive 0X08, enable USB Yes, UART can receive 0X04, enable SPI Yes, UART can receive 0X02, enable I2C Yes, UART can receive 0X01, enable LPUART NO, UART can’t receive      From the test result, we can reproduce the problem. The UART receive problem just happens on booting from ROM and the LPUART is enabled, when we run it with debugger, and test it step by step, we can find after the PTA1 have received the data, the code will run to the abnormal area. Note: when debug this code, please choose the JLINK as the debugger, because the P&E tool will protect the FOPT area automatically in the KDS IDE when do debugging, the code will still run from flash, so if customer use the P&E tool, they will found the PTA1 still can receive the data, this is not the real result, but the JLINK won’t protect FOPT area in the KDS IDE, it can reflect the real result.      After using the JLINK as the debugger, and we have found after PTA1 getting data or pulling low, the code will enter to the abnormal area like this:      We can get that the code run to the defaultISR, and display with USB_IRQHander, but this is not really the USB_IRQHander, just caused by the PC abnormal. Normally, it is caused by the missing of interrupt service function.       Now, we test the NVIC data to check which module interrupt caused this, the following picture is the result by enabling the LPUART and I2C peripheral in the ROM BCA area. We can find, even we didn’t do the cpu and peripheral initialization after booting from ROM, there still have peripheral be enabled, what the interrupt is enabled? From the definitive guide to the ARM Cortex-M0.pdf: NVIC_ISER = 0x40000100, Vector46=IRQ30 and vector24=IRQ8 is enabled, it should be not disabled after booting from the ROM. Now check the KL43 reference manual, Table 3-2. Interrupt vector assignments, we can get that the I2C0 and PORTA interrupt is enabled. Checking the PORTA register before do the cpu and peripheral initialization, PTA1 is enabled the port interrupt, and choose Flag and Interrupt on falling-edge.     This can tell us why the PTA1 pin have the problem of uart receive data or give a falling edge in PTA1 will run abnormal, because in default, even we configure the PTA1 as the uart receive function, but the code didn’t clear IRQ and NVIC register, when the signal happens on PTA1 pin, it will caused the PORTA interrupt, but we didn’t add the PORTA interrupt ISR function, it is also not useful to us, then PC don’t know where to go, so it will run abnormal, enter the defaultISR, and can’t recover. If you have interest, you can add the PORTA_IRQHandler function, you will find the code will run to this function. 2.2 Problem reproduction in KSDK2.0 IAR project  Test project: SDK_2.0_FRDM-KL43Z\boards\frdmkl43z\demo_apps\hello_world  Test the official project just to make sure, it is really the chip hardware function, not only the problem from new generated code in KDS.   Because the IAR IDE will protect the 0X400 area, then if we want to modify the FOPT, we need to modify the .board, add –enable_config_write at first.    Then modify the FOPT in startup_MKL43Z.s: __FlashConfig         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFE   ; 0xFFFF3FFE   __FlashConfig_End   Because the BCA peripheral area is in default as 0XFF, it enables all the peripheral, we don’t need to define the BCA area independently.  For getting the real test result, we add the NVIC and PORTA_PCR1 register printf code in the main function,    PRINTF("PORTA_PCR1=%X \n", PORTA->PCR[1]);    PRINTF("NVIC=%X \n", NVIC->ICER[0U]); And download the modified KSDK sample code to the chip, after testing, we get this result: hello world. PORTA_PCR1=A0205 NVIC=40000100 It is the same result as the new created project after booting from the ROM, PORTA interrupt and I2C interrupt is enabled, and it caused the PTA1 receive data problem.  3 Solutions and test result 3.1 Solutions      From the Chapter 2 testing and analysis, we can get that UART receive problem is caused by the PORT interrupt and NVIC is enabled after booting from the ROM, this should be caused by exiting the ROM, the ROM forget to disable it. We also can find some descriptions from the KL43 reference manual page 211: So, if customer want to solve this problem, to avoid the application enter to the abnormal area, we can disable the NVIC in the application code like this, the I2C NVIC is the same:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt 3.2 Test result   From the test result after adding the NVIC I2C and PORTA disable code, we can get the uart can works ok, if you have interest to test, the I2C will also work ok. 4 Conclusion When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, and want to boot from the ROM and enable the LPUART and I2C in BCA area, please add the NVIC I2C(IRQ8) and PORTA(IRQ30) disable code in the application code:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt So far, I just find KL43, KL27 and KL17 which flash size is above 128K have this problem, other kinetis chip which have ROM bootloader don’t have this problem.

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

The documentation is only for eFlexPWM module of KV58, it describes the feature of nano-edge PWM, the mechanism of nano-edge PWM, and give the waveform which can describe the feature of nano-edge PWM. The attachment includes the brief introduction of nano edge PWM, the waveform of nano edge PWM, and the code which runs on TWR-KV58 and KDS3.0. Original Attachment has been moved to: eFlexPWMNanoEdgeKV58_2.rar

The SAI of Kinetis supports 4 modes:normal mode, network mode, I2S mode, AC97 mode, the documentation give the brief introduction about the 4 modes, give the waveform of the 4 modes.

With the merger of NXP and Freescale, the NXP USB VID/PID program, which was previously deployed on LPC Microcontrollers, has been extended to Kinetis Microcontrollers and i.MX Application Processors. The USB VID/PID Program enables NXP customers without USB-IF membership to obtain free PIDs under the NXP VID. What is USB VID/PID Program? The NXP USB VID program will allow users to apply for the NXP VID and get up to 3 FREE PIDs. For more details, please review the application form and associated FAQ below. Steps to apply for the NXP USB VID/PID Program Step 1: Fill the application form with all relevant details including contact information. Step 2: NXP will review the application and if approved, will issue you the PIDs within 4 weeks FAQ for the USB VID/PID Program Can I use this VID for any microcontroller in the NXP portfolio? >> No. This program is intended only for the Cortex M based series of LPC Microcontrollers and Kinetis Microcontrollers, and Cortex A based series of i.MX Application Processors. What are the benefits of using the NXP VID/PID Program? >> USB-IF membership not required >> Useful for low volume production runs that do not exceed 10,000 units >> Quick time to market Can I use the NXP VID and issued PID/s for USB certification? >> You may submit a product using the NXP VID and issued PID/s for compliance testing to qualify to use the Certified USB logo in conjunction with the product, but you must provide written authorization to use the VID from NXP at the time of registration of your product for USB certification. Additionally, subject to prior approval by USB-IF, you can use the NXP VID and assigned PID/s for the purpose of verifying or enabling interoperability. What are the drawbacks of using the NXP VID/PID program? >> Production run cannot exceed 10,000 units. See NXP VID application for more details. >> Up to 3 PIDs can be issued from NXP per customer. If more than 3 PIDs are needed, you have to get your own VID from usb.org: http://www.usb.org/developers/vendor/ >> The USB integrators list is only visible to people who are members of USB-IF. NXP has full control on selecting which products will be visible on the USB integrators list. How do I get the VID if I don't use NXP’s VID? >> You can get your own VID from usb.org. Please visit http://www.usb.org/developers/vendor/ Do I also get the license to use the USB-IF’s trademarked and licensed logo if I use the NXP VID? >> No. No other privileges are provided other than those listed in the NXP legal agreement. If you wish to use USB-IF’s trademarked and licensed USB logo, please follow the below steps:                 1. The company must be a USB vendor (i.e. obtain a USB vendor ID).                 2. The company must execute the USB-IF Trademark License Agreement.                 3. The product bearing the logo must successfully pass USB-IF Compliance Testing and appear on the Integrators List under that company’s name. Can I submit my product for compliance testing using the NXP VID and assigned PIDs? >> Yes, you would be able to submit your products for USB-IF certification by using the NXP VID and assigned PID. However, if the product passes the compliance test and gets certified, it will be listed under “NXP Semiconductors” in the Integrators list. Also, you will not have access to use any of the USB-IF trademarked and licensed USB logos. How long does it take to obtain the PID from NXP? >> It can take up to 4 weeks to get the PIDs from NXP once the application is submitted. Are there any restrictions on the types of devices that can be developed using the NXP issued PIDs? >> This service requireds the USB microcontroller to be NXP products. Can I choose/request for a specific PID for my application? >> No. NXP will not be able to accommodate such requests.

The Kinetis family has abundant low power mode. Customers may confused to figure out the different way to wake up from the low power mode. 1)  In VLPR, VLPW:  the NVIC remains sensitive to interrupts, so any interrupt will be serviced. 2)  In Stop, VLPS:  the device can be waked up by USB wake up interrupt only. 3)  In LLS, VLLSx:  the device won't be able to wake up from any USB source. 4)  LLWU is used to wake up, so customer would able to wake up from any of the available LLWU wake up sources. As for the USB module, there has two different interrupts for a USB resume event. One asynchronous to be able to wake from a low power mode, which is triggered by change in the state of the USB lines. The other is synchronous and is triggered only after 2.5 us of detecting a K state (D+ = 0, D- = 1, for Full Speed). The application is responsible to transition to the low power mode whenever it requires it, and for this purpose it must check the device state as reported by the USB stack. When a suspend condition is detected in the bus, the SLEEP interrupt triggers and the stack changes its state to suspend; then the application will transition to the low power mode. When this SLEEP interrupt occurs, the asynchronous wake interrupt is enabled, and is disabled when it is triggered (this is required by the module to clear the interrupt). In normal conditions, the synchronous resume interrupt or the reset interrupt will be triggered afterwards, causing the stack to transition its state to other than suspend. The application can then know that communication is active again and will avoid entering the low power mode again.

Some of our customers encountered clock stretching issue when using the I2C. Actually the first should been in mind is the clock stretching is usually done by the slave, not the master.  In the case for the Kinetis as master to connect with I2C device, the clock stretching should been done by the slave device. In this case the slave device should hold the clock signal low until it has data available. There isn’t anything that needs to be done to enable clock stretching on the master side. So how the code do with the clock stretching? The slave should toggling read_start high first and reading the data register to actually start the transfer. Be remember that the read from the data register is what actually triggers the transfer. Customer always missed this point.

The 5V Kinetis E series MCUs are designed to maintain high robustness for complex electrical noise environments and high-reliability applications. Kinetis EA series MCUs using the same architecture with automotive level operation temperature range, are various used for auto body electrical application. There was a reality customer requirement to let KEA core running the application (light a LED) within 20ms from power up. It need to know the whole startup processing for KE/KEA product. Please check below picture to get more info about boot sequence: During the power up phase, after VDD rising to VPOR voltage threshold, there with about 15us delay before internal IRC start oscillating. T2 interval is FLL acquisition time to make FLL generating clock. The Reset_b pin is released and then the system is released from reset. After that, the NVM starts internal initialization. Flash Controller is released from reset and begins initialization operations while the core is still halted before the flash initialization completes. When the flash Initialization completes (16 μs) , the core sets up the stack, program counter (PC), and link register (LR). The processor reads the start SP (SP_main) from vector-table offset 0. The core reads the start PC from vector-table offset 4. LR is set to 0xFFFF_FFFF. The CPU begin to execute the first instruction. Overview the whole power up processing, FLL acquisition time is the longest time interval almost 1ms, then following power up time about 0.1ms (using 17KV/sec VDD ramp-up slew rate). There seems a lot of time left to run the chip initialization code and application code. Customer requirement (power up to light a led within 20ms) should be matched without any problem. While, during customer test, there seems it need to take more than 30ms to find the LED be lighten after power up. In order to check the issue, we get the customer test code and find there with below clock initialization code: void Clk_Init() {                 ICS_C1|=ICS_C1_IRCLKEN_MASK; /* Enable the internal reference clock*/                 ICS_C3= 0x90;                                    /* Reference clock frequency = 31.25 KHz*/                       while(!(ICS_S & ICS_S_LOCK_MASK));  /* Wait for FLL lock, now running at 40 MHz (1280 * 31.25Khz) */                                               ICS_C2|=ICS_C2_BDIV(1)  ;                    /*BDIV=2, Bus clock = 20 MHz*/                 ICS_S |= ICS_S_LOCK_MASK ;              /* Clear Loss of lock sticky bit */      } We do a test to check the Clk_init() function execution time and find it will take almost 25ms. We toggle a GPIO pin and almost 25ms for checking ICS status register [LOCK] be asserted. KE/KEA product using ICS module as clock source, which default mode is FEI. In general, during the chip initialization, using ICS status register [LOCK] bit to check if the FLL cock is stable or not. From KE/KEA product datasheet, the Max. FLL acquisition time is 2ms. Why the ICS_S[LOCK] bit be asserted need take more than 25ms? After double check with ICS IP owner, we get below info: The FLL_S[LOCK] bit act as “LOCK detection”, the LOCK bit will be set if FLL clock frequency stays within the tolerance 6% for 20ms~30ms. After acquisition time (max. 2ms) FLL achieved clock accuracy as same as LOCK bit be asserted. After ICS configuration modified, customer can call a 2ms delay routine to make sure FLL acquisition clock successfully before executing the application code. 

MAPS-KS22 Board Introduction: MAPS boards are localization evaluation boards for Chinese customers. The MAPS boards are suitable for NXP MCU product, with low coat, more flexibility and easy-copy features, which matching with local customer requirements and better for learning and product evaluation. MAPS board includes four parts board, which are MCU Board, Peripheral Board, Application Board & Socket Board. The naming of MAPS are using the four-part board initial letter. MCU board is NXP Kinetis MCU based evaluation main board with chip related special module interface/device, such as graphic LCD/ENET interface and etc. The MCU board fan out all MCU pins as test points for measuring. The MCU board also provide two 32-pin socket to connect external peripheral board or application board. Peripheral Board collects more general device into one board and using two 32-pin socket connects with MCU board. The MAPS-Dock is the first peripheral board, which with below configuration: Micor-SD card slot; six touch pads; USB FS interface; IrDA transceiver; one SPI Interface (SPI-Flash); two UART interface; four buttons; one I2S interface (audio codec); one CAN interface; two potentionmeter; one DAC output interface; 128x64 monochrome LCD; one 5-way button. It also with SWD debugger on board and USB CDC virtual COM. Application Board designed for special applications, such as motor control, IOT, Smart Home, Wireless Charger and etc. Socket Board provides interface for FreeDOM boards/Arduino boards/Customer defined boards. MAPS-KS22 board MCU board for KS22 chip evaluation. KS22 MCU is based on the ARM® Cortex®-M4 core with 120MHz MCUs with FPU, offering full-speed USB 2.0 OTG, in addition to other features like USB crystal-less functionality. MAPS-KS22 oobe demo porting process MAPS-KS22 oobe demo is based KSDK V1.0, which will show Freescale LOGO on the SPI color LCD and meanwhile use FlexIO I2S to play an audio on microphone. Step1: visit Kinetis Expert website (http://kex.nxp.com/en/welcome) to download MAPS-KS22 KSDK V2.0 software: Step2: download [Kinetis SDK Project Generator Tool] from below link and generate oobe demo project based on MAPS-KS22 SDK V2.0 software: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=KSDK-PROJECT-GENERATOR-TOOL&appType=file1&location=null&DOWNLOAD_ID=null Step 3: After that, open the oobe project, which located at default path: C:\Freescale\SDK_2.0_MAPS-KS22\boards\mapsks22\user_apps\oobe\iar The default project is based on <hello-world> demo, it need to add LED control code. Those part of code could be found at <main.c> file and related pin muxing code at <pin_mux.c> file. Step 4: Modify ili9341 related driver: For the oobe project with two major functions, the first one is to display Freescale LOGO at LCD. The MAPS-KS22 board graphic LCD is using ili9341 TFT LCD driver with SPI interface with KS22 chip. The previous oobe project is using GPIO pins emulate SPI communication, we will make the similar application with KSDK V2.0 driver. Most modification based on the GPIO pins control. Please check below code at <ili9341.h> file, which call KSDK V2.0 GPIO driver: #define ILI9341_CS_HIGH()       GPIO_SetPinsOutput(BOARD_LCD_CS_GPIO, 1U << BOARD_LCD_CS_PIN) #define ILI9341_CS_LOW()        GPIO_ClearPinsOutput(BOARD_LCD_CS_GPIO, 1U << BOARD_LCD_CS_PIN) #define ILI9341_CLK_HIGH()      GPIO_SetPinsOutput(BOARD_LCD_CLK_GPIO, 1U << BOARD_LCD_CLK_PIN)  #define ILI9341_CLK_LOW()       GPIO_ClearPinsOutput(BOARD_LCD_CLK_GPIO, 1U << BOARD_LCD_CLK_PIN) #define ILI9341_MOSI_HIGH()     GPIO_SetPinsOutput(BOARD_LCD_MOSI_GPIO, 1U << BOARD_LCD_MOSI_PIN) #define ILI9341_MOSI_LOW()      GPIO_ClearPinsOutput(BOARD_LCD_MOSI_GPIO, 1U << BOARD_LCD_MOSI_PIN)      #define ILI9341_MISO_HIGH()     GPIO_SetPinsOutput(BOARD_LCD_MISO_GPIO, 1U << BOARD_LCD_MISO_PIN) #define ILI9341_MISO_LOW()      GPIO_ClearPinsOutput(BOARD_LCD_MISO_GPIO, 1U << BOARD_LCD_MISO_PIN) And it also need to add ili9341 control pin muxing initialization code at <pin_mux.c> file. Step 5: We could modify the Freescale logo with new NXP logo, which could using [Embedded GUI Conversion Utility3.0] tool. This tool could be downloaded from below link:  http://tinyurl.com/eGUI-Convert  The conversion result of the graphic data is 16-bit array, which need be transfer to 8-bit array. After that, compile and download the image to the board, it with below result: Step 6: The oobe demo provide another function to play music with MAPS-DOCK board WM8960 codec chip, then using headphone will hear the sound. For the KS22 with FlexIO module, the demo will use FlexIO emulating I2S bus to transfer data to WM8960 codec chip. About I2S bus MCLK clock source, the MAPS-KS22 provide two selection, one is using TPM1_CH1 pin, the other one is using I2S0_MCLK pin with JP5 jumper selection. In oobe demo, we use TPM1_CH1 pin to generate 12MHz MCLK clock with TPM module output compare mode. Related code, please refer below tpm_init_output_compare() function at <main.c> file: //enable clock gating of tpm1 CLOCK_EnableClock(kCLOCK_Tpm1); //set TMP output compare mode TPM_SetupOutputCompare(BOARD_TPM_BASEADDR, BOARD_TPM_CHANNEL, kTPM_ToggleOnMatch, 1U); BOARD_TPM_BASEADDR->MOD = 0x1; TPM_StartTimer(BOARD_TPM_BASEADDR, kTPM_SystemClock);   //TPM counter increments on every TPM counter clock Step 7: WM8960 is a stereo CODEC chip provide I2C port for chip configuration. There need to initialization the WM8960 chip before using it with related driver <wm8960.c> & <wm8960.h> files. The MAPS-KS22 board using LPI2C0 module connects with WM8960 chip, so there need to port using LPI2C driver of KSDK V2.0 and modify the WM8960 driver related. The LPI2C module initialization code located at <main.c> with lpi2c_master_init() function. The WM8960 driver major modification with WOLFSON_WriteReg() function at <wm8960.c> file, calling the LPI2C driver of KSDK V2.0 with below code:  wolfson_status_t WOLFSON_WriteReg(uint8_t reg, uint16_t val) {       uint8_t cmd,buff;        status_t ret;        cmd = (reg << 1) | ((val >> 😎 & 0x0001);    // register address        buff = val & 0xFF;     //data        reg_cache[reg] = val;      // copy data to cache         uint8_t data[2];         data[0] = cmd;         data[1] = buff;         //start lpi2c tx operation                   ret = LPI2C_MasterStart(LPI2C0, WM8960_I2C_ADDR, kLPI2C_Write);           // send two data with register address and related value          ret = LPI2C_MasterSend(LPI2C0, data, 2);                //stop lpi2c tx operation                  ret = LPI2C_MasterStop(LPI2C0);               if(ret != kStatus_Success)          {  return kStatus_WOLFSON_I2CFail;  }          return kStatus_WOLFSON_Success; } After WM8960 chip driver modification, there could call related driver to initialize WM8960 chip and configure the communication interface with I2S bus. Following steps focus on how to transfer data to WM8960 codec with I2S bus. Step 8:  The FlexIO modul will simulate I2S bus call FlexIO_I2S_MasterInit() function in <main.c> file to initialize FlexIO module as I2S master. There using FXIO0_D4 pin as I2S bit clock pin, using FXIO0_D5 pin as I2S Transmit pin and using FXIO0_D6 pin as I2S Transmit Frame Sync pin. KSDK V2.0 provide FlexIO for I2S driver located at <fsl_flexio_i2s.h> file. Step 9: There will call eDMA with FlexIO module to reduce the core work load during the I2S data transfer. It will initialize the eDMA & DMAMUX modules for FlexIO. Related code located at <main.c> file with ConfigDMAforFlexIOI2STX() function: void ConfigDMAforFlexIOI2STX(void) { EDMA_GetDefaultConfig(&dmaConfig); EDMA_Init(EXAMPLE_DMA, &dmaConfig); EDMA_CreateHandle(&dmaHandle, EXAMPLE_DMA, EXAMPLE_CHANNEL); DMAMUX_Init(DMAMUX0); DMAMUX_SetSource(DMAMUX0, EXAMPLE_CHANNEL, EXAMPLE_DMA_SOURCE); DMAMUX_EnableChannel(DMAMUX0, EXAMPLE_CHANNEL); }    Step 10: KSDK V2.0 software provides FlexIO I2S eDMA driver located at <fsl_flexio_i2s_edma.c> file, with below codes to initialize FlexIO I2S master DMA handler and to configure the sample rate & audio data format to be transferred: FLEXIO_I2S_TransferTxCreateHandleEDMA(&base, &txHandle, callback, NULL, &dmaHandle); FLEXIO_I2S_TransferSetFormatEDMA(&base, &txHandle, &format, 48000000); Step 11: After above preparation, following action will start to transfer music data to WM8960 codec with below code. When the music data transfer finished, the callback function will be called to start next round data transferred. Then we could hear the sound with endless loop. static void callback(FLEXIO_I2S_Type *i2sBase, flexio_i2s_edma_handle_t *handle, status_t status, void *userData) {   // Initiate FlexIO I2S transfer again after previous transfer finished  FLEXIO_I2S_TransferSendEDMA(&base, &txHandle, &xfer); } About more detailed oobe demo software info, please check attached file. The default oobe demo located path is: C:\Freescale\SDK_2.0_MAPS-KS22\boards\mapsks22\user_apps\oobe

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

Porting FatFs file system to KL26 SPI SD card code 1 Abstract      Without the SDHC module, Kinetis KL series need to use the SPI interface to communicate with the SD card. Normally, when customer use the SD card, they are not only want to write and read the SD card, but also prefer to create files(eg, text file, csv file,etc.) in the SD card to record some important data. Use the file to record the data, then the data can be read easily by the PC. MCU need to use the file system to operate the files, the file system should realize the function of file creating, file deleting, file reading and writing, etc. FatFs is a generic FAT/exFAT file system module for small embedded systems. This document mainly describe how to port a FatFs file system to the KL26 SPI SD card code, SD card SPI interface hardware circuit and the SD card basic operation code. 2 FatFs file system introduction 2.1 FatFs feature Windows compatible FAT/exFAT file system. Platform independent. Easy to port. Very small footprint for program code and work area. Various configuration options to support for: Multiple volumes (physical drives and partitions). Multiple ANSI/OEM code pages including DBCS. Long file name in ANSI/OEM or Unicode. exFAT file system. RTOS envilonment. Fixed or variable sector size. Read-only, optional API, I/O buffer and etc... 2.2 FatFs file system organizations   From the above pictures, we can see that in a project with Fatfs module, there mainly 4 parts: application, Fatfs, Disk I/O layer and the Media(SD card). (1) Application, user just need to call the FatFs API function to realize the file creation, read, write and delete. (2) FatFs module, this module contains 6 important files which customer need to use, it is: diskio.c, diskio.h, ff.c, ff.h, ffconf.h, integer.h.  diskio.c and diskio.h is used to call the SD card operation function from the Disk I/O layer, user need to modify this file to match the disk I/O layer, or write the disk I/O layer match this file. ff.c,ff.h is the FatFs file system layer, it defines the API function, user don’t need to modify it. ffconf.h is the system configuration file. integer.h is the data type define file, user don’t need to modify these two files. (3) Disk I/O layer, there has mmc.c and spi.c, actually, the detail name can be defined by the user, it is not fixed. Mmc.c is used to realize the SD card function, eg, SD initialization, SD block writing and reading.  Spi.c is the MCU SPI interface file, it realize the SPI communication function, because the Kinetis series don’t have the SDHC interface, then it use the SPI interface to communicate with the SD card. (4) Media, it can be SD,MMC, USB, NAND flash, here we use the SD card. More details, please refer to FatFs Module application note. 2.3 Common API function f_mount - Register/Unregister a work area of a volume f_open - Open/Create a file f_close - Close an open file f_read - Read data f_write - Write data f_lseek - Move read/write pointer, Expand size f_truncate - Truncate size f_sync - Flush cached data More functions, please go to this link: http://elm-chan.org/fsw/ff/00index_e.html 3 SPI SD operation 3.1 Hardware       This document use the YL_KL26 as the testing board, customer also can add an external SD card circuit to the FRDM-KL26 board. The board is using the TF card, SD SPI interface circuit is:   The pin assignment in the YL-KL26 board is defined as follows: KL26 pin SPI name PTC4 SPI_CS0 PTC5 SPI_SCK PTC6 SPI_MOSI PTC7 SPI_MISO 3.2 Softwave      The test code project is based on the MDK5.1x. 3.3 SD I/O Layer 3.3.1 SD card initialization The communication speed for SD card initialization can’t exceed 400kb/s, if the speed is higher than 400kbps, user need to add the delay in the initialization code, otherwise the initialization will be failure. After the initialization is successful, user can increase the SD card communication speed. Initialization process: (1)  Initialize the SPI interface which connect to the SD card, down to low speed. (2)  Power on delay 72clks, wait for the SD card ready (3)  Go idle state, CMD0, this command will trigger the SD card to use the SPI interface. (4)  Get SD card information, CMD8, get the SD card version. (5) Active the SD card,  with CMD55+CMD41 (6) Read OCR data,CMD59. (7) Set SD card block size to 512Byte. CMD16 (8) Read CSD, get other information, CMD9 (9) Change to high speed and disable the CS uint8 MMCInit(void) {                 uint8 i = 0,k = 0,tmp = 0;                 uint16 cnt=0;                 uint8  buff[512];                                 SSP0LowSpeed();                                      // low speed                 MMCDelayUs(5000);                                                                                   for (i=0; i<0x0F; i++)                               {                    Send_Byte(0xFF);          // send 72 clocks                 }                 // Send Command CMD0 to SD/SD Card  enter idle                 do                 {                     tmp = MMCWriteCmd(CMD0,0x00,0x95);   // CMD0                      k++;                 }while ((tmp != 1) && (k < 200));                                   if(k == 0)                 {                   MMCCS(1);           //cs pullup, disconnect                   Send_Byte(0xFF);                   printf("\n SD reset fail");                   return 1;//                 }                                              //get SD card version                  tmp = MMCWriteCmd( CMD8,0x1AA,0x87 );                  printf( "SD_CMD8  return  %d........\n\n", tmp );  if(tmp == 1)// 2.0 card {          cnt=0xffff;                    do    {     MMCWriteCmd( CMD55, 0, 0xff );     tmp = MMCWriteCmd( CMD41,0x40000000, 0xff);//CMD41      cnt--;    } while ((tmp) && (cnt));                  //Get OCR information                  tmp = MMCWriteCmd(CMD58, 0, 0 );    if ( tmp != 0x00 )    {                   MMCCS(1);           //cs pullup, SD card disconnect                                 printf( "\nSD_CMD58 return  %d....\n", tmp );                   return 1;//    }      for ( i = 0; i < 4; i++ )    {     buff[ i ] = Get_Byte();    }    MMCCS(1);    printf( "OCR return: %x %x %x %x....\n\n", buff[0],buff[1],buff[2],buff[3] );      if ( buff[0] & 0x40 )    {                                  SD_Type = SD_TYPE_V2HC;      printf( "card is V2.0 SDHC.....\n\n" );    }    else {                                  SD_Type = SD_TYPE_V2;      printf( "card is V2.0.....\n\n" );    }              while(MMCWriteCmd(CMD16,512,0xff)!=0);                  MMCWriteCmd(CMD9,0,0xff);   }                 SSP0HighSpeed();                    //back to high speed                 MMCCS(1);                             return 0;                        } 3.3.2 Read one SD card block The block size is 512Byte, the read process is: Send CMD17 and wait the response Receive the start token 0XFE Receive the 512Byte data Receive 2 bytes CRC Disable the CS pin   uint8 MMCReadSingleBolck(uint32 addr,uint8 *buf) {                 uint16 i;                 uint8 sta;                 if(SD_Type!=SD_TYPE_V2HC)                 {                       addr= addr<<9;                 }                 sta = MMCWriteCmd(CMD17,addr,0x01);                 while(sta !=0)                 {                   sta = MMCWriteCmd(CMD17,addr,0x01);                 }                   while (Get_Byte() != 0xFE){;}                   if(sta == 0)                 {                   for (i=0; i<512; i++)                        {                     buf[i] = Send_Byte(0xFF);                   }                            }                 Send_Byte(0xFF);                                                                  Send_Byte(0xFF);                 MMCCS(1);                 return 0; } 3.3.3 Read multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {          uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                     addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE){;}                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 3.3.4 Write one SD card block The procedure is: Send CMD24 and wait the response Receive the start token 0XFE Send the 512Byte data Send 2 bytes CRC Disable the CS pin   uint8 MMCWriteSingleBlock(uint32 addr,const uint8 *buf) {                 uint16 i,retry ;                 uint8  temp;                                 if(SD_Type!=SD_TYPE_V2HC)                 {                      addr=addr<<9 ;                 }                                              if (MMCWriteCmd(CMD24,addr,0x01) != 0x00)                         {                     return 1;                                                  }                 MMCCS(0);                 //wait SD card ready                 Send_Byte(0xFF);                          Send_Byte(0xFF);                 Send_Byte(0xFF);                 Send_Byte(0xFE);                               for (i=0; i<512; i++)                                 {                     Send_Byte(buf[i]);                 }                 //Dummy CRC                 Send_Byte(0xFF);                                                                              Send_Byte(0xFF);                 temp = Send_Byte(0xFF);                                                        temp &= 0x1F;                        if (temp != 0x05)                 {                     MMCCS(1);                     return 1;                                                                                                  }                                                 while (Send_Byte(0xFF) == 0x00)                 {                      retry++;                      if(retry>0xfffe)                     {                       MMCCS(1);                        return 1 ;                      }                 }                 MMCCS(1);                 Send_Byte(0xFF);                 return 0; } 3.3.5 Write multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {     uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                                   addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE)                     {                         ;                                                                                    }                                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 4 FatFs file system porting 4.1 FatFs source code download Go to FatFs official website download the source code, the link is: http://elm-chan.org/fsw/ff/00index_e.html The latest version is FatFs R0.12.    Unzip it, like the following picture, just need 6 files, user can copy it to the project SPI driver folder, and create a new folder named as fatfs. 4.2 Modify diskio.c file We need to modify these functions: disk_initialize：Disk initialize disk_status     ：Get the Disk status disk_read       ：Read Disk block disk_write      ：Write Disk block disk_ioctl       ：control device character get_fattime    ：Get current time 4.2.1 disk_initialize function DSTATUS disk_initialize (                 BYTE pdrv                                                 ) {                 DSTATUS stat;                    stat=MMCInit();  //SD card initialization                  if(stat == STA_NODISK)                    {                         return STA_NODISK;                     }                 else if(stat != 0)                   {                         return STA_NOINIT;                   }               else                {                      return 0;                         } } 4.2.2 disk_status  function DSTATUS disk_status (                 BYTE pdrv                 /* Physical drive nmuber to identify the drive */ ) {        if(pdrv)     {         return STA_NOINIT;      }                 return RES_OK; } 4.2.3 disk_read function DRESULT disk_read (                 BYTE pdrv,                                /* Physical drive nmuber to identify the drive */                 BYTE *buff,                               /* Data buffer to store read data */                 DWORD sector,        /* Sector address in LBA */                 UINT count                               /* Number of sectors to read */ ) {     DRESULT res;     if (pdrv || !count)     {            return RES_PARERR;      }                           if (count == 1)                  {                                 res = MMCReadSingleBolck(sector,buff);                 }                 else                           {                                 res = MMCReadMultipleBolck(sector,buff,count);                 }     if(res == 0x00)     {         return RES_OK;     }     else     {         return RES_ERROR;     } } 4.2.4 disk_write function DRESULT disk_write (                 BYTE pdrv,                                                /* Physical drive nmuber to identify the drive */                 const BYTE *buff,      /* Data to be written */                 DWORD sector,                        /* Sector address in LBA */                 UINT count                                               /* Number of sectors to write */ ) {                 DRESULT res;                   if (pdrv || !count)     {            return RES_PARERR;      }     if(count == 1)     {         res = MMCWriteSingleBlock(sector, buff);     }     else     {         res = MMCWriteMultipleBlock(sector, buff, count);     }     if(res == 0)     {         return RES_OK;     }     else     {         return RES_ERROR;     } }   4.2.5 disk_ioctl function DRESULT disk_ioctl (                 BYTE pdrv,                                /* Physical drive nmuber (0..) */                 BYTE cmd,                /* Control code */                 void *buff                /* Buffer to send/receive control data */ ) {                 DRESULT res;                 BYTE n, csd[16];                 DWORD csize;                  if (pdrv)                  {                         return RES_PARERR;                  }                 res = RES_ERROR;                 switch (cmd)                 {                     case CTRL_SYNC       : res = RES_OK; break;                     case GET_SECTOR_COUNT: /* Get number of sectors on the disk (WORD) */                                                                 if((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd))                                                                 {                                                                 if((csd[0] >> 6) == 1) /* SDC ver 2.00 */                                                                 {                                                                 csize = csd[9] + ((WORD)csd[8] << 😎 + 1;                                                                 *(DWORD*)buff = (DWORD)csize << 10;                                                                 }                                                                 else /* MMC or SDC ver 1.XX */                                                                 {                                                                 n = (csd[5] & 15) + ((csd[10] & 128) >> 7) + ((csd[9] & 3) << 1) + 2;                                                                 csize = (csd[8] >> 6) + ((WORD)csd[7] << 2) + ((WORD)(csd[6] & 3) << 10) + 1;                                                                 *(DWORD*)buff = (DWORD)csize << (n - 9);                                                                 }                                                                 res = RES_OK;                                                                 }                                                                 break;                     case GET_SECTOR_SIZE : /* Get sectors on the disk (WORD) */                                                                    *(WORD*)buff = 512;                                                                    res = RES_OK;                                                                    break;                     case GET_BLOCK_SIZE  :                                                             if ((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd)) /* Read CSD */                                                        {                              *(DWORD*)buff = (((csd[10] & 63) << 1) + ((WORD)(csd[11] & 128) >> 7) + 1) << ((csd[13] >> 6) - 1);                                                                        res = RES_OK;                                                        }                                            break;                       default              : res = RES_PARERR; break;                 }                   return res; } 4.2.6 Get_fattime function   This function is used to get the current time, and write it in the file attribute when create, modify the files. It should associate with the RTC, this project didn’t add this function, so just write the code like this: DWORD get_fattime (void) { return 0; } 4.2.7 include SD.h file Comment usb, ATA include files, and add the user SD.h file, this is the SD card IO layer header file. #include "diskio.h"                   /* FatFs lower layer API */ //#include "usbdisk.h"              /* Example: Header file of existing USB MSD control module */ //#include "atadrive.h"            /* Example: Header file of existing ATA harddisk control module */ //#include "sdcard.h"                               /* Example: Header file of existing MMC/SDC contorl module */ #include "SD.h" /* Definitions of physical drive number for each drive */ //#define ATA                           0              /* Example: Map ATA harddisk to physical drive 0 */ //#define MMC                        1              /* Example: Map MMC/SD card to physical drive 1 */ //#define USB                          2              /* Example: Map USB MSD to physical drive 2 */ 4.3 Modify main function This project function is to create two files: Test.csv and Test.txt.  Write four items in these files: Test1, Test2, Test3, Test4. int main (void) {                 uint16 i,j;                 FATFS fs;                               FRESULT fr;                 FIL          fil;                                                            UINT bw;                 char file_name1[12]="Test.csv";                 char file_name2[12]="Test.txt";                 System_init();                 spiInit(SPI0_BASE_PTR , Master);                 fr= f_mount(&fs,file_name1,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                 fr = f_open(&fil, file_name1, FA_WRITE | FA_OPEN_ALWAYS);//create csv file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the excel file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                  fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }                 fr= f_mount(&fs,file_name2,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                              fr = f_open(&fil, file_name2, FA_WRITE | FA_OPEN_ALWAYS);//create txt file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the txt file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                 fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }            while(1)                 {                          for(i=0;i<10;i++) for(j=0;j<65535;j++);                         printf("\ntest_sd\n");//                 } } Add FatFs header files in the main.h. #include "spi.h" #include "SD.h" #include "diskio.h" #include "ff.h" 5 Test result     After download the code to the KL26 board, then insert a 8G microSD card which already format with the Fat32, press the reset button on the board, user can find the following printf log from the com port: It means the SD card is identified.      Now, take out the SD card and insert it to the PC, user will find there has two files: Test.csv and Test.txt. Open these files, data Test1, Test2, Test3, Test4 can be find in it,  it means the FatFs file system is porting successfully.

It has been reported that OpenSDA v2/2.1 bootloader could be corrupted when the board is plugged into a Windows 10 machine. An updated OpenSDA bootloader that fixes this issue is available at www.NXP.com/openSDA. There is also a blog article by Arm addressing this issue. To reprogram the bootloader on affected boards, you will require an external debugger, such as Segger JLink or Keil ULink programmer attached to the JTAG port connected to the K20 OpenSDA MCU. For your convenience, the binaries of the OpenSDA v2.2 bootloader is attached at the bottom of this post. If using a Segger JLink, download the latest JLink Software and Documentation pack and use the following JLink.exe commands to connect to the K20 OpenSDA MCU: Connect MK20DX128xxx5 S 4000 And then use the following commands to reflash the bootloader: erase loadbin <your Bootloader Binary> 0x00000000 Here is another post on how to recover bricked OpenSDA boards and to prevent it getting re-bricked. To check more information regarding OpenSDA on your boards, please go to www.nxp.com/opensda.

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