Dear all :      I would like to share an IoT application note to you. The note will help us to setup a FRDM-K64F to connect to Microsoft Azure and get alarm message from Azure. Detail please refer to attachment. Demonstration : IoT client (FRDM-K64F) report data to Cloud (Microsoft Azure) IoT client receive data from Cloud Could computing IoT client data and take action Tools : FRDM-K64F ( http://www.freescale.com/FRDM-K64F ) Device Explorer ( http://aka.ms/iot-hub-how-to-use-device-explorer ) Visual Studio 2015 SSH client ( PuTTY  or Tera Term ) mbed  ( http://www.mbed.com ) Microsoft Azure ( https://azure.microsoft.com )

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

Introduction What is a gated timer and why would I need one? A gated timer is a timer whose clock is enabled (or "gated") by some external signal.  This allows for a low code overhead method of synchronizing a timer with an event and/or measuring an event. This functionality is not commonly included on Freescale microcontroller devices (this functionality is only included on devices that are equipped with the upgraded TPM v2 peripheral; currently K66, K65, KL13, KL23, KL33, KL43, KL03) but can be useful in some situations.  Some applications which may find a gated timer useful include asynchronous digital sampling, pulse width duty cycle measurement, and battery charging. How do I implement a gated timer with my Kinetis FTM or TPM peripheral? To implement a true gated timer with a Kinetis device (that does not have the TPM v2 peripheral), additional hardware will be required to implement the enable/disable functionality of a gated timer.  This note will focus on two different ways (low-true and high-true) to implement a gated timer.  The method used will depend on the requirements of your application. Implementing a gated timer for Kinetis devices without the TPM v2 peripheral requires the use of a comparator and a resistive network to implement a gated functionality (NOTE:  Level shifters could be used to replace the resistive network described; however, a resistive network is likely more cost effective, and thus, is presented in this discussion).  Figure 1 below is the block diagram of how to implement a gated timer functionality.  The theory behind this configuration will be explained in later sections. Theory of Operation Comparator and resistive network implementation The comparator is the key piece to implementing this functionality. For those with little experience with comparators (or need a refresher), a comparator is represented by the following figure.  Notice that there are three terminals that will be of relevance in this application: a non-inverting input (labeled with a '+' sign), an inverting input (labeled with a '-' sign), and an output. A comparator does just what the name suggests: it compares two signals and adjusts the output based on the result of the comparison.  This is represented mathematically in the figure below. Considering the above figure, output of the comparator will be a  logic high when the non-inverting input is at a higher electric potential than the inverting input.  The output will be a logic low if the non-inverting input is at a lower electric potential than the inverting input.  The output will be unpredictable if the inputs are exactly the same (oscillations may even occur since comparators are designed to drive the output to a solid high or solid low).  This mechanism allows the clock enable functionality that is required to implement a gated timer function provided that either the non-inverting or inverting input is a clock waveform and the opposite input is a stable logic high or low (depending on the desired configuration) and neither input is ever exactly equal.  Comparator Configurations There are two basic signal configurations that an application can use to enable the clock output out of the comparator: low-true signals and high-true signals.  These two signals and some details on their implementation are explained in the following two sections.  Low-true enable A low-true enable is an enable signal that will have zero electric potential (relative to the microcontroller) or a "grounded" signal in the "active" state.  This configuration is a common implementation when using a push button or momentary switch to provide the enable signal.  When using this type of signal, you will want to connect the enable signal to the non-inverting input of the comparator, and connect the clock signal to the inverting input. The high level of the enable signal should be guaranteed to always be the highest voltage of the input clock plus the maximum input offset of the comparator. To find the maximum input offset of the comparator, consult the device specific datasheet.  See the figure below to see a graphical representation of areas where the signal will be on and off. The external hardware used should ensure that the low level of the enable signal never dips below the lowest voltage of the input clock plus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. High-true enable A high-true enable is an enable signal that will have an electric potential equal to VDD of the microcontroller in the "active" state.  This configuration is commonly implemented when the enable signal is provided by an active source or another microcontroller.  When interfacing with this type of signal, you will want to connect the enable signal to the inverting input of the comparator, and connect the clock signal to the non-inverting input.  When the comparator is in the inactive state, it should be at or below the lowest voltage of the clock signal minus the maximum input offset of the comparator.  Refer to the following figure for a diagram of the "on" and "off" regions of the high true configurations. The external hardware will need to guarantee that the when the enable signal is in the active state, it does not rise above the highest voltage of the clock signal minus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. Clocking Options Clocking waveform requirements will vary from application to application.  Specifying all of the possibilities is nearly impossible.  The point of this section is to inform what options are available from the Kinetis family and provide some insight as to when it might be relevant to investigate each option. The Kinetis family provides a clock output pin for most devices to allow an internal clock to be routed to a pin.  The uses for this option can vary.  In this particular scenario, it will be used to provide the source clock for the comparator clock input. Here are the most common clock output pin options across the Kinetis K series devices.  (NOTE:  If the application requires a clock frequency that the CLKOUT signal cannot provide, a separate FTM or TPM instance or another timer module can be used to generate the required clock.) In the Kinetis L series devices, the following options will be available. The clock option selected should be the slowest allowable clock for the application being designed.  This will minimize the power consumption of the application.  For applications that require high resolution, the Bus, Flash, or Flexbus clock should be selected (note that the Flexbus clock can provide an independently adjustable clock, if it is not being used in the application, as it is always running).  However, if the target application needs to be more power efficient, the LPO or MCGIRCLK should be used.  The LPO for the Kinetis devices is a fixed 1 kHz frequency and will, therefore, only be useful in applications that require millisecond resolutions.

What's eCos eCos is a free open source real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint. With provided configuration tools (configtool and ecosconfig) it is possible to build configurations that scale from minimal that require less than 32KiB memory to reach full featured operating system with networking, file system, serial communication, etc. eCos for Kinetis Currently the Kinetis eCos support includes: UART; Ethernet - with TCP/IP through either lwIP or BSD stack; Flash - program and erase; eDMA library; DSPI - including MMC/SD card support; Real Time Clock. Cache; DDRAM; FlexBus; Following features are available for testing: I2C; CAN; Watchdog. Configuring eCos for Kinetis Start the graphical configuration tool configtool, then from menu select Build->Templates. In Hardware selection box select your board: In our case we select TWR-K70F120M. Save the configuration and select Build->Library. configtool will build a customised eCos library and extract headers for you. Now you are ready for your "Hello world". Further reading You shall find complete eCos documentation at eCos Documentation

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

Hi All, I designed one multi-uarts bootloader project for customers, with which the customers can improve their production efficency in factory. The attached files is the host machine and slave machine bootloader programs and a document for reference. Now the programs can work smoothly on K64 freedom board with three uarts broadcust function. Anybody who has such request can refer to my new program. Best regards David

The USB OTG module in Kinetis parts uses a Buffer Descriptor Table (BDT) in system memory to manage USB endpoint communications, the BDT is a a 512-byte buffer and there are 3 registers in USB module to contain the base address for it, and it must be 512-byte aligned otherwise there would be issue during transfer. In USB stack ver 4.1.1, some Kinetis old parts like K60N512, K20D72M have the demo project basked on CodeWarrior ARM compiler, and in khci_kinetis.c, bdt is defined as following: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8_ptr bdt; but since the base address is defined as below: #define BDT_BASE               ((uint_32*)(bdt)) so the bdt definition is not correct , and we have to change it as below: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8 bdt[512];//uint_8_ptr bdt; and the definition for usb_dbt section can be found in MK20X256_flash.lcf. with above modification, we can make the demo of "msd_mfs_generic" work well as expected. Please kindly refer to the following result got from TWR-K20D72M. FAT demo Waiting for USB mass storage to be attached... Mass Storage Device Attached ****************************************************************************** * FATfs DEMO * * Configuration:  LNF Enabled, Code page =1258 * ****************************************************************************** ****************************************************************************** * DRIVER OPERATION * ****************************************************************************** 1. Demo function: f_mount   Initializing logical drive 0...   Initialization complete ----------------------------------------------------------------------------- 2. Demo functions:f_getfree, f_opendir, f_readdir getting drive 0 attributes............... Logical drive 0 attributes: FAT type = FAT16 Bytes/Cluster = 2048 Number of FATs = 2 Root DIR entries = 512 Sectors/FAT = 250 Number of clusters = 63858 FAT start (lba) = 36 DIR start (lba,clustor) = 536 Data start (lba) = 568 ... 127716 KB total disk space. 127624 KB available. ----------------------------------------------------------------------------- ****************************************************************************** * DRECTORY OPERATION * ****************************************************************************** 1. Demo functions:f_opendir, f_readdir Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 2. Demo functions:f_mkdir 2.0. Create <Directory_1> 2.1. Create <Directory_2> 2.2. Create <Sub1> as a sub directory of <Directory_1> 2.3. Directory list Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 3. Demo functions:f_getcwd, f_chdir 3.0. Get the current directory     CWD: 0:/ 3.1. Change current directory to <Directory_1> 3.2. Directory listing Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---- 2010/01/01 00:00         0  sub1 0    File(s),         0 bytes total 3    Dir(s) 3.3. Get the current directory     CWD: 0:/Directory_1 ----------------------------------------------------------------------------- 4. Demo functions:f_stat(File status), f_chmod, f_utime 4.1. Get directory information of <Directory_1>     DR--- 2010/12/25 23:30         0 Directory_1 4.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 4.3. Set Read Only Attribute to Directory_1 4.4. Get directory information (Directory_1)     DR--- 2010/12/25 23:30         0 Directory_1 ----------------------------------------------------------------------------- 5. Demo functions:f_rename Rename <sub1> to <sub1_renamed> and move it to <Directory_2> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---A 2010/01/01 00:00         0 SUB1_R~1 0    File(s),         0 bytes total 3    Dir(s) ----------------------------------------------------------------------------- 6. Demo functions:f_unlink Delete Directory_1/sub1_renamed Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) ****************************************************************************** * FILE OPERATION * ****************************************************************************** 1. Demo functions:f_open,f_write, f_printf, f_putc, f_puts, fclose 1.0. Create new file <New_File_1> (f_open)     File size =    0 1.1. Write data to <New_File_1>(f_write) 1.2. Flush cached data     File size =   52 1.3. Write data to <New_File_1> (f_printf) 1.4. Flush cached data     File size =  103 1.5. Write data to <New_File_1> (f_puts) 1.6. Flush cached data     File size =  152 1.7. Write data to <New_File_1> uses f_putc function 1.8. Flush cached data     File size =  199 1.9. Close file <New_File_1> ----------------------------------------------------------------------------- 2. Demo functions:f_open,f_read, f_seek, f_gets, f_close 2.0. Open <New_File_1> to read (f_open) 2.1. Get a string from file (f_gets)     Line 1: Write data to  file uses f_write function 2.2. Get the rest of file content (f_read)     Line 2: Write data to file uses f_printf function Line 3: Write data to file uses f_puts function Line 4: Write data to file uses f_putc functionûöF¬ â•:7Rz}™ yzjw8¸×áÀ—»ÃЭ¹òÍ­ ä‹Hïk¨Wã½c'     ²7këÞÑ%VrC×»Ô¼ÒSÈÑèR+NjD¡¾òû>ú3‰SËþo^ÎI Pë±ñ‰þ/Directory_1[1] 2.3. Close file (f_close) ----------------------------------------------------------------------------- 3. Demo functions:f_stat, f_utime, f_chmod 3.1. Get  information of <New_File_1> file (f_stat)     ----A 2010/01/01 00:00       199  New_File_1.dat 3.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 (f_utime) 3.3. Set Read Only Attribute to <New_File_1> (f_chmod) 3.4. Get directory information of <New_File_1> (f_stat)     -R--A 2010/12/25 23:30       199  New_File_1.dat 3.5. Clear Read Only Attribute of <New_File_1> (f_chmod) 3.6. Get directory information of <New_File_1>     ----A 2010/12/25 23:30       199  New_File_1.dat ----------------------------------------------------------------------------- 4. Demo functions:f_ulink Rename <New_File_1.dat> to  <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     ----A 2010/12/25 23:30       199  FILE_R~1.TXT 1    File(s),       199 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 5. Demo functions:f_truncate Truncate file <File_Renamed.txt> 5.0. Open <File_Renamed.txt> to write 5.1. Seek file pointer     Current file pointer:    0     File pointer after seeking:  102 5.2. Truncate file     File size =  102 5.3. Close file ----------------------------------------------------------------------------- 6. Demo functions:f_forward 6.0. Open <File_Renamed.txt> to read 6.1. Forward file to terminal Line 1: Write data to  file uses f_write function Line 2: Write data to file uses f_printf function 6.2. Close file ----------------------------------------------------------------------------- 7. Demo functions:f_ulink Delete <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) *------------------------------ DEMO COMPLETED    ------------------------ * ******************************************************************************

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

There with phase shifting when using two different FTM modules to output PWM signals. Although the two FTM modules using the same clock source (bus clock), there still exists the phase shifting status. Please check attached video about phase shifting. FTM Global Time Base(GTB) introduction The global time base (GTB) is a FTM function that allows the synchronization of multiple FTM modules on a chip. The following figure shows an example of the GTB feature used to synchronize two FTM modules. In this case, the FTM A and B channels can behave as if just one FTM module was used, that is, a global time base. K65’s FTM0 provides the only source for the FTM global time base. The other FTM modules can share the time base as shown in the following figure: The code description:    // Configure ftm params with frequency 2MHz for CLK        ftm_pwm_param_t ftmParamCLK = {             .mode                   = kFtmEdgeAlignedPWM,   //PWM mode             .edgeMode               = kFtmLowTrue,           //PWM Low-true pulses (clear Output on match-on)             .uFrequencyHZ           = 200000u,         //2MHz clock frequency             .uDutyCyclePercent      = 50,                //Duty cycle 50%             .uFirstEdgeDelayPercent = 0,                        };    //using FTM0 & FTM3 GTB feature    FTM_HAL_SetClockSource (FTM0, kClock_source_FTM_None);   //disable FTM0 clock source    FTM_HAL_SetClockSource (FTM3, kClock_source_FTM_None);   //disable FTM3 clock source      FTM_HAL_SetGlobalTimeBaseCmd(FTM0, true);   //enable FTM0 GTBEEN    FTM_HAL_SetBdmMode(FTM0, kFtmBdmMode_11);   //enable FTM0 BDMMODE    FTM_HAL_SetGlobalTimeBaseCmd(FTM3, true);   //enable FTM3 GTBEEN    FTM_HAL_SetBdmMode(FTM3, kFtmBdmMode_11);   //enable FTM3 BDMMODE        FTM_HAL_SetClockSource (FTM0, kClock_source_FTM_SystemClk);   //disable FTM0 clock source    FTM_HAL_SetClockSource (FTM3, kClock_source_FTM_SystemClk);   //disable FTM3 clock source      FTM_HAL_SetCounter(FTM0, 0U);        //clear TFM0 counter value to 0    FTM_HAL_SetCounter(FTM3, 0U);        //clear FTM3 counter value to 0      FTM_HAL_SetGlobalTimeBaseOutputCmd(FTM0, true);      //enale FTM0 GTBEOUT Please check attached video about after using GTB feature, the FTM0_CH4 and FTM3_CH1 PWM output signals. How to output two PWM output signals at one FTM module with KSDK? The two PWM output signal will provides the same clock frequency with different duty cycle. The two PWM output signal need use the same PWM mode. Please check below code to enable K65’s FTM0 module output two PWM signals. // Configure ftm params with frequency 2MHz for CLK        ftm_pwm_param_t ftmParamCLK = {             .mode                   = kFtmEdgeAlignedPWM,   //PWM mode             .edgeMode               = kFtmLowTrue,           //PWM Low-true pulses (clear Output on match-on)             .uFrequencyHZ           = 200000u,         //2MHz clock frequency             .uDutyCyclePercent      = 50,                //Duty cycle 50%             .uFirstEdgeDelayPercent = 0,                        }; // Configure ftm params with frequency 2MHz for CLK                ftm_pwm_param_t ftmParamSH =         {              .mode                   = kFtmEdgeAlignedPWM,   //PWM mode              .edgeMode               = kFtmLowTrue,   //PWM Low-true pulses (clear Output on match-on)              .uFrequencyHZ           = 200000u,        //2MHz clock frequency              .uDutyCyclePercent      = 75,     //Duty cycle 75%              .uFirstEdgeDelayPercent = 0,         };     // Initialize FTM module,     // configure for software trigger.     memset(&ftmInfo, 0, sizeof(ftmInfo));     ftmInfo.syncMethod = kFtmUseSoftwareTrig;  //Using software trigger PWM synchronization     FTM_DRV_Init(BOARD_FTM_INSTANCE, &ftmInfo);  //FTM0 initialization     FTM_DRV_SetClock(BOARD_FTM_INSTANCE, kClock_source_FTM_SystemClk, kFtmDividedBy1); //Enable FTM0 counter clock     FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamCLK, BOARD_FTM_CHANNEL); //Enable PWM output at FTM0_CH4     FTM_HAL_SetClockSource(FTM0, kClock_source_FTM_None); //Disable FTM0 counter clock     FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamSH, BOARD_FTM_CHANNEL5);   //Enable PWM output at FTM0_CH5 The tested code also be attached, please using it with KSDK V1.2 software. Wish it helps.

中文版本：     在KL25的官方Demo 源代码中只有I2C驱动的PE代码而没有I2C驱动的baremental代码，对于不习惯用PE生成代码的用户直接上手有难度，于是考虑将K60的 I2C baremental 驱动代码中移植到KL25上，以供大家参考。但在移植过程中遇到了两个比较典型的问题，所以这里分享出来，希望能帮助遇到同样问题的用户迅速定位并解决问题。 测试硬件：TWR-K60D100M开发板  K60+MMA8451（MMA8451为三轴加速传感器，与K60通过I2C总线连接。K60作为master，MMA8451作为slave）                 FRDM-KL25Z开发板       KL25+MMA8451 开发环境：IAR 6.6 1.问题描述： 配置I2Cx_F寄存器MULT位不为0时，Repeat start信号无法产生 问题提出： K60示例代码（如附件1）中I2C demo的功能是通过I2C接口读取板载的加速度传感器MMA8451的数据，并且I2C数据控制采用查询ACK标志位的方式，在TWR-K60D100M开发板上运行该Demo一切正常。使用几乎相同的I2C驱动代码，在FRDM-KL25Z开发板上执行发现：程序总是停在如下Function 1的红色字体行i2c_wait(I2C0_B)，进入这个函数内部，它实际上是停在while((p->S & I2C_S_IICIF_MASK)==0)，一直等待传输完成的中断标志IICIF置位。 Function 1. u8 hal_dev_mma8451_read_reg(u8 addr) {     u8 result;     i2c_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_WRITE);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_write_byte(I2C0_B, addr);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_repeated_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_READ);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);     result = i2c_read_byte(I2C0_B);     i2c_wait(I2C0_B);     i2c_stop(I2C0_B);     result = i2c_read_byte(I2C0_B);     pause();     return result; } Function 2. void i2c_wait(I2C_MemMapPtr p) {     while((p->S & I2C_S_IICIF_MASK)==0)  ; // wait flag     p->S |= I2C_S_IICIF_MASK;    // clear flag } 原因分析：      初步判断可能是上一步数据的传输 i2c_write_byte()没有完成，导致IICIF未能被置位。于是通过示波器去捕捉这个过程，发现在执行 i2c_repeated_start(I2C0_B)时，KL25并没有产生一个 Repeat start信号。经过一番谷哥和度娘，终于在Kinetis L的Errata中找到了答案：Repeat start cannot be generated if the I2Cx_F[MULT] field is set to a non-zero value. 这也就意味着，当 I2Cx_F[MULT]位被设置为非0值时，I2C Master不能产生一个Repeat start信号。而在应用程序的I2C初始化I2C_init()代码中， 我恰好设置I2Cx_F[MULT]=01，这正好是符合了Errata描述的错误产生的条件。 解决方案：      I2C的C1寄存器中MULT位是I2C SCL时钟的倍乘因子，用于控制I2C的波特率。为解决上面的问题，FSL官方提供了两种workaround的办法： 1）如果repeat start必须产生时，配置 I2Cx_F[MULT]为0； 2）在置位 I2Cx_F register (I2Cx_C1[RSTA]=1)的Repeat START产生位之前临时设置 I2Cx_F [MULT]，然后再在repeated start信号产生后恢复I2Cx_F [MULT]位的设置。 按照第一种方法，我修改程序中I2Cx_F[MULT]的设置从01到00，然后程序在FRDM-KL25Z 开发板上运行正常，能正常读取板载的加速度传感器MMA8451的数据。 2.问题描述： I2C单字节读取时序问题 问题提出： 在上面的Function 1中， KL25读取MMA8451的基本过程是：发送要访问的从机地址及对从机的写命令->发送要访问的从机的寄存器地址->发送Repeat Start信号到从机->发送要访问的从机地址及读命令->读取从机返回的数据，如下Figure1 MMA8451的单周期读时序图所示，其过程和上面代码的描述一致。但是有一点值得注意的是Figure 1中红色方框部分，按照Figure 1的表述，Master是在从Slave从机读取DATA[7:0]之后返回NAK信号的，用于指示本数据是Master要接收的最后一个DATA，最后发送stop signal终止数据的传送。按照这个思路得到的KL25的程序代码如下Section 2，它首先去读取从机返回的数据 i2c_read_byte(I2C0_B)，然后发送NACK信号到从机i2c_give_nack(I2C0_B)。然而从KL25实际的物理时序的角度看，这个顺序是错误的，正确的应该是如下Section 1，应该在读取从机返回的数据 i2c_read_byte(I2C0_B)之前，首先发送NACK信号到从机i2c_give_nack(I2C0_B)。 Section 1.   i2c_set_rx_mode(I2C0_B);   i2c_give_nack(I2C0_B);----line1   result = i2c_read_byte(I2C0_B);----line2   i2c_wait(I2C0_B);----line3   i2c_stop(I2C0_B);----line4   result = i2c_read_byte(I2C0_B);----line5 Section 2.   i2c_set_rx_mode(I2C0_B);   result = i2c_read_byte(I2C0_B);-   i2c_wait(I2C0_B);   i2c_give_nack(I2C0_B);-   i2c_stop(I2C0_B); 原因： 主机发送的NACK信号只有在下一个数据接收之后才会被push到总线上，KL25的RM手册中的描述为the No acknowledge signal is sent to the bus after the following receiving data byte (if FACK is cleared)。 具体分析： 按照两个时序分别做了一个测试，并用示波器捕捉了相应的波形：执行Section 1的代码得到的波形如下Figure 2所示，NACK(1)信号刚好在第9个pluse脉冲上升沿被push总线上，然后在Stop信号后总线处于idle状态（SCL和SDA均为高）。执行Section 2的代码得到的波形如下Figure 3所示，ACK(0)信号在第9个pluse脉冲上升沿被push总线上，说明后面还有数据要传输，一直处于等待MMA8451数据的再次传送中，这明显违背了读取单字节数据的原本意图。总之，KL的I2C应用中Section 1的代码操作顺序是正确的，实际的物理时序和 Figure 1的示意图时序是不一样的，这点需要特别注意。 Figure 1. MMA8451's 单周期读时序示意图 Figuire 2. Section 1 代码对应的时序 Figure 3. Section 2 代码对应的时序 为方便大家验证这些问题，我这里在附件中一并上传了K60的I2C的示例代码，KL25的示例代码，以及Kinetis L关于I2C的Errata。 —————————————————————————————————————————————————————————————————————— English Version：      Recently, I migrate the K60’s I2C demo code to the KL25, but found it can't works when the same demo code runs on FRDM-KL25Z board while it runs well on the K60 board. After a painful struggling, I finally get the cause, so here I make a record, wish it could be helpful when other users happen to meet same problem. Repeat start can't be generated when configure I2Cx_F[MULT] to non-zero      The K60’s demo( the attached 1) is to communicate with the onboard accelerometer MMA8451 by I2C, and in the demo it finish a data transmission by quering I2C’s flag bit. With almost same code, it always stops at below Function 1's red line i2c_wait(I2C0_B), also this function's defination is shown as below Function 2, it stops at while((p->S & I2C_S_IICIF_MASK)==0) to wait IICIF flag. Function 1. u8 hal_dev_mma8451_read_reg(u8 addr) {     u8 result;     i2c_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_WRITE);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_write_byte(I2C0_B, addr);    i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_repeated_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_READ);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);     result = i2c_read_byte(I2C0_B);     i2c_wait(I2C0_B);     i2c_stop(I2C0_B);     result = i2c_read_byte(I2C0_B);     pause();     return result; } Function 2. void i2c_wait(I2C_MemMapPtr p) {     while((p->S & I2C_S_IICIF_MASK)==0)  ; // wait flag     p->S |= I2C_S_IICIF_MASK;    // clear flag }      Then what's the matter? when I capture the I2C's wave form, found it didn't generate a Repeat start signal when excute i2c_repeated_start(I2C0_B);  After a struggle, In the Kinetis L's Errata do I find the answer: Repeat start cannot be generated if the I2Cx_F[MULT] field is set to a non-zero value. That means there is a bug in KL's design, if the I2Cx_F[MULT] field is set to a non-zero value, the I2C master can't generate a Repeat start signal. Coincidentally, in the I2C_init function I happen to set theI2Cx_F[MULT]=01, so it just meets the I2C's Errata.      Considering the MULT bits define the multiplier factor mul. and  used along with the SCL divider to generate the I2C baud rate. In the Errata, FSL gives two possible workarounds: 1) Configure I2Cx_F[MULT] to zero if a repeat start has to be generated. 2) Temporarily set I2Cx_F [MULT] to zero immediately before setting the Repeat START bit in the I2C C1 register (I2Cx_C1[RSTA]=1) and restore the I2Cx_F [MULT] field to the original value after the repeated start has occurred. To verify it easily, I revise the I2Cx_F[MULT] from 01 to 00. After that the same code runs well on FRDM-KL25Z board.    2. The Timing Sequence Of I2C's single byte Reading      In the above Function 1, there are a MMA8451 data read section like below after  Write Device Address->Write Register Address->Repeat Start->Write Device Address, and these steps is same as MMA8451's single byte read Timing Sequence requirment which is shown as below Figure 1. But referring to Figure 1, it looks like Section2 we should first excute below line2 to read the data, and then line1 give a nack  to suggest it's the last data, at last excute line4 to send a I2C stop signal. But unfortunately the idea is wrong, because in the phasical timing sequence the No acknowledge signal is sent to the bus after the following receiving data byte (if FACK is cleared) ,which means we need to give NACK signal before a read. And the captured wave form is like below Figure 2, you can find the NACK in the Ninth pluse, while the captured wave form is like below Figure 3 if excute Section 2 code instesd of Section 1 code, you can find the ACK in the Ninth pluse. it means the master will read another data, but the original intention is to read only one byte, so the I2C bus blocks. In a word, the section 1 code is right, the physical timing is different from the Figure 1's sketch map. Section 1.     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);----line1     result = i2c_read_byte(I2C0_B);----line2     i2c_wait(I2C0_B);----line3     i2c_stop(I2C0_B);----line4     result = i2c_read_byte(I2C0_B);----line5 Section 2.    i2c_set_rx_mode(I2C0_B);    result = i2c_read_byte(I2C0_B);-    i2c_wait(I2C0_B);    i2c_give_nack(I2C0_B);-    i2c_stop(I2C0_B); Figure 1. MMA8451's single byte read Timing sketch map Figuire 2. Section 1 code's Timing Figure 3. Section 2 code's Timing

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

This document explains a potential issue where interrupts appear to be disabled after enterring debug mode. This is as a result of the NMI being active when debug is enabled.

The DOC focuses on how to access SDRAM based on K65 SDRAM controller, it describes the hardware connection especially the address connection, the SDRAM controller initialization,the code to access SDRAM.

       FreeRTOS is a high quality, risk free, supported, free RTOS, and now it is already successful to porting more 35 architectures. As a popular RTOS, more and more embedded engineers considering it for their next project.        Next, I’m going to show you the steps of creating a MAPS-K22 FreeRTOS demo by IAR and I’ve also attached a template demo and FreeRTOS source code (Fig 1). Fig 1 FreeRTOS source code directories and files     1. Copy the FreeRTOS source code to ~\MAPSK22_SC\Libraries     2. Create FreeRTOS_Source group in the workspace, then add the source code (Fig 2) Fig 2 3. Add an application code in the main.c This is a very simple configuration. It creates two tasks, one software timer, and also uses a button interrupt. The two tasks communicate via a queue. The receiving task toggles the LED3 each time a value is received. Pressing user button K5 generates an interrupt. The interrupt service routine for which resets a software timer, then turn the LED1 on. The software timer has a five second period. The timer will expire when K5 has not been pressed again for a full five seconds. The callback function that executes when the timer expires simply turn the LED1 on again. Therefore, pressing K5 will turn the LED1 on, and the LED1 will remain on until a full five seconds pass without the button being pressed again. 4. Modify the Include Directories 5. Run the FreeRTOS demo After build the modified application code, then run it on MAPS-K22 board (Fig 3) Fig 3 IMPORTANT! Cortex-M FreeRTOS port specific configuration Configuration items specific to this demo are contained in ~\MAPSK22_SC\Libraries\RTOS\config\K22F51212\iar. The constants defined in this file can be edited to suit your application. In particular configTICK_RATE_HZ This sets the frequency of the RTOS tick interrupt. The supplied value of 1000Hz is useful for testing the RTOS kernel functionality but is faster than most applications require. Lowering this value will improve efficiency. configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY See the RTOS kernel configuration documentation for full information on these configuration constants. configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY These are equivalents to configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY, but presented in a form suitable for passing into the Freescale NVIC_SetPriority() library function. The NVIC_SetPriority() function expects priorities to be in the range of 0 to 15 - 0 being the highest priority and 15 being the lowest priority.

The following file contains example code for usage of ADC, UART, DAC, GPIO, I2C, interrupts, MCG and timers for the k53 platform. Regards.

My customer wanted to use K60 in his design but he only has the Keil IDE, so I helped to port some examples in KINETIS_SC for him as a starting point. The attachment is my porting work, which also includes a exe file to create new keil project. You may refer to "keil\build\uv4\make_new_project_keil.exe" for details. Hope that helps, B.R Kan

This file contains some codewarrior code examples migrated from the IAR examples in the sample code package available at the freescale webpage: blink_blue blink_red blink_rgb serial_test_19200 serial_test_115200 touch_toggle_leds Regards

1. Introduction MCUboot is a common used bootloader for most of Kinetis and i.mx RT devices. It can support download application via UART/USB/CAN/I2C/SPI. It enables quick and easy programming of Kinetis MCUs and i.mx RT MPU through the entire product life cycle, including application development, final product manufacturing, and beyond. K64 is a very popular device in Kinetis family. It has a M4 core, 512k and above flash, 120M main frequency and plenty of interface, such as I2C/SPI/UART/CAN/USB/ENET. But it is a bit awkward that the MCUboot demo of K64 is not include CAN. Does K64’s CAN can’t support bootloader application? No, of course not. Here we are going to port CAN function to K64 bootloader. There are two kind of CAN peripheral in Kinetis family, FlexCAN and MSCAN. FlexCAN is more complex than MSCAN. K64 has a FlexCAN. To speed up our work, we can port FlexCAN driver and related code from TWR-KV46 bootloader. Hardware: two TWR-SER board two sets of TWR-ELEV TWR-K65F150M TWR-K64F120M   Software: MCUXpresso 11.0 MCUBoot 2.0.0 package SDK_2.6.0_TWR-K64F120M 2. Software porting Step 1, copy below files to twrk64f120m_tower_bootloader project. \drivers\fsl_flexcan.c \drivers\fsl_flexcan.h        \source\bootloader\src\flexcan_peripheral_interface.c   Step 2, modify the project to enable the FlexCAN.       In bootloader_config.h, change BL_CONFIG_CAN definition to 1.        In peripherals_MK64F12.c, add #if BL_CONFIG_CAN     // CAN0     {.typeMask = kPeripheralType_CAN,      .instance = 0,      .pinmuxConfig = can_pinmux_config,      .controlInterface = &g_flexcanControlInterface,      .byteInterface = &g_flexcanByteInterface,      .packetInterface = &g_framingPacketInterface }, #endif    // BL_CONFIG_CAN       Pin mux setting. In peripherals_pinmux.h, add #define BL_ENABLE_PINMUX_CAN0 (BL_CONFIG_CAN) //! CAN pinmux configurations #define CAN0_RX_PORT_BASE PORTB #define CAN0_RX_GPIO_PIN_NUM 18             // PIN 13 in the PTA group #define CAN0_RX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 RX functionality for pin 13 #define CAN0_TX_PORT_BASE PORTB #define CAN0_TX_GPIO_PIN_NUM 19             // PIN 12 in the PTA group #define CAN0_TX_FUNC_ALT_MODE kPORT_MuxAlt2 // ALT mode for CAN0 TX functionality for pin 12       Set clock. FlexCAN clock source can be OSCERCLK or bus clock. Here we use bus clock run at 48Mhz. In flexcan_peripheral.c, add these code. const flexcan_timing_config_t bit_rate_table48m[] = {     { 23, 3, 4, 4, 4 }, /* 125 kHz */     { 11, 3, 4, 4, 4 }, /* 250 kHz */     { 5, 3, 4, 4, 4 },  /* 500 kHz */     { 3, 3, 4, 4, 4 },  /* 750 kHz */     { 2, 3, 4, 4, 4 }   /* 1   MHz */ }; change line 621 FLEXCAN_SetTimingConfig((CAN_Type *)baseAddr, &bit_rate_table48m[s_flexcanInfo.baudrate]); Step 3, compile the project.   3. Function test Software preparation To connect bootloader via CAN bus, NXP has TWR-K65 as bridge. But its source code is not in K64 SDK. It is in MCUBoot2.0.0 package. User can download the package from https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuboot-mcu-bootloader-for-nxp-microcontrollers:MCUBOOT The bridge project is called buspal which can be found in NXP_Kinetis_Bootloader_2_0_0\apps\bus_pal\MK65F18. BusPal is an embedded software tool that is available as a companion to blhost. The tool acts as a bus translator with an established connection with blhost over UART and with the target device over I2C, SPI, or CAN, and assists blhost in carrying out commands and responses from the USB target device. The BusPal is available for selected platforms. The source code for BusPal is provided with the Kinetis bootloader release, it support FRDM-KL25, TWR-KV46F150M and TWR-K65F180M and can be customized to run on other platforms. More detail of buspal is in Kinetis blhost User's Guide appendix C.   Hardware connection TWR-SER has TJA1050 as transceiver. We can connect J7 on both boards. When construct the Tower system, user should take care the power. The power tree is very flexible. Improper setting may cause TJA1050 can’t work.   The Buspal project on TWR-K65F180M use UART1 to connect with computer. The port is on TWR-SER. To make the connection simple, we can share the openSDA UART port. The openSDA UART use UART2, we can jump UART1 signal to J33 and J34 on K65 tower board.     Testing: Open a command window, type >blhost -p com4,57600 –buspal can,0,321,123 – get-property 10 This command can check if the whole system work properly. Then, you can download the code to K64 now. Please type >blhost -p com4,57600 –buspal can,0,321,123 – flash-image xxxxxx.s19 erase

Reference Solution being developed with Kinetis V (also can be done with a Kinetis K device) of a Class-D audio amplifier. 16-bit ADC sampling the audio input FlexTimer doing the PWM's for the Class-D amplifier DC/DC switched power supply with input of 12V and output of 130V to 180V (generates the power you need for making some good noise - 1kW) being controlled by the Kinetis MCU also. Capabiltiy of Audio processing/filtering using the Cortex-M4 DSP capabilities. Solution originally designed for cost-effective Automotive aftermarket sound systems. But can be adapted for implementing other audio amplifier applications also in the consumer space! Can you thing of cool applications/markets that this solution can be also quickly adapted? Soon, plan to make the reference solution design files available in the community. Stay tunned. Cheers! PK