The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 

Latest version of the AN2295 universal bootloader includes support for IAR 7.6 IDE. - added support for Kinetis E MCUs - Kinetis K,L,M,E,W,V support

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

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

Introduction With the growth of the Internet of Things (IoT), more and more applications are incorporating the use of sensors while also requiring power efficiency and increased performance.  A popular interface for these sensors is the I2C protocol. The I2C bus is a great protocol that is a true multi-master protocol and allows for each bus to contain many devices.  As the performance demand of the application grows, so will the speed of the I2C bus as it will be necessary to get more data from the sensors and/or at a faster rate.  Many applications may already have a need to operate an I2C bus at 400 kHz or more.  Higher data rates means the MCU core will need to spend more time servicing the I2C transactions.  The DMA module is one good way to free up the core in order to let it tend to other aspects of the application.  This can add much needed or much desired performance to applications.  Especially applications that may be using small, power efficient, single core MCUs. It may seem like an easy, straight-forward task to add I2C reads from a sensor to an application.  However I2C is a time sensitive protocol and consequently, so is the I2C peripherals on MCUs.  It is important to understand the time requirements and how to overcome them. The recommended approach is to use DMA to transfer the received I2C data to the desired buffer in your application software.  This document is going to outline how to setup your DMA and provide an example of how to do this for a KW40 device using the Kinetis SDK version 1.3.  The KW40 is being targeted because this is a small, power efficient MCU that incorporates a radio for your wireless applications and as such, it is likely that your application could need this DMA approach.  The KSDK version 1.3 is being targeted because this version of the SDK does not currently support DMA transactions for the I2C peripheral. Understanding the Kinetis I2C peripheral module Before getting into the specifics of creating a DMA enabled I2C driver, it is important to understand some basics of the Kinetis I2C peripheral module.  This module handles a lot of the low-level timing.  However the I2C registers must be serviced in a timely manner to operate correctly.  Take the case of a master reading data from a typical I2C sensor as shown in the diagram below. In the diagram above, the red lines indicate points in the transaction where software or DMA needs to interact with the I2C peripheral to ensure the transaction happens correctly.  To begin a transaction the core must change the MST bit which puts a start bit on the bus (marked by symbol ST).  Immediately following this, the core should then also write the target slave's address (Device Address) including the read/write bit (R/W).  Once this transaction is complete, the I2C will issue an interrupt and then the core should write the register address to be read from. Upon completion of that being put on the bus, the I2C will issue another interrupt and the master should then put a repeated start (SR) on the bus as well as the slave's address again.  Now the slave will send data to the master (once the master begins the transaction by issuing a dummy read of the I2C data register).  In the standard configuration, the I2C peripheral will automatically send the NAK or AK depending on the configuration of the TXAK bit in the I2C peripheral.  Because of this automation, it is important that this bit be handled properly and is configured one frame in advance. Furthermore, to ensure that the NAK bit is sent at the appropriate time, the TXAK bit must be set when the second to last byte is received.  The timing of this configuration change is very important to ensuring that the transaction happens properly. This document will describe how to use DMA to receive the data.  The DMA will be configured before the transaction begins and will be used to receive the data from the slave.  The document will also discuss options to handle proper NAK'ing of the data to end the transaction. Writing a DMA I2C master receive function The first step in adding DMA capability to your SDK driver is to create a new receive function with an appropriate name.  For this example, the newly created receive function is named I2C_DRV_MasterReceiveDataDMA.  To create this function, the I2C_DRV_MasterReceive function (which is called for both blocking and non-blocking) was copied and then modified by removing the blocking capability of the function. Then in this function, after the dummy read of the IIC data register that triggers the reception of data, the DMA enable bit of the I2C control register is written. /*FUNCTION********************************************************************** * * Function Name : I2C_DRV_MasterReceiveDataDMA * Description   : Performs a non-blocking receive transaction on the I2C bus *                 utilizing DMA to receive the data. * *END**************************************************************************/ i2c_status_t I2C_DRV_MasterReceiveDataDMA(uint32_t instance,                                                const i2c_device_t * device,                                                const uint8_t * cmdBuff,                                                uint32_t cmdSize,                                                uint8_t * rxBuff,                                                uint32_t rxSize,                                                uint32_t timeout_ms) {     assert(instance < I2C_INSTANCE_COUNT);     assert(rxBuff);       I2C_Type * base = g_i2cBase[instance];     i2c_master_state_t * master = (i2c_master_state_t *)g_i2cStatePtr[instance];             /* Return if current instance is used */     OSA_EnterCritical(kCriticalDisableInt);         if (!master->i2cIdle)     {         OSA_ExitCritical(kCriticalDisableInt);         return kStatus_I2C_Busy;     }         master->rxBuff = rxBuff;     master->rxSize = rxSize;     master->txBuff = NULL;     master->txSize = 0;     master->status = kStatus_I2C_Success;     master->i2cIdle = false;     master->isBlocking = true;     OSA_ExitCritical(kCriticalDisableInt);             while(I2C_HAL_GetStatusFlag(base, kI2CBusBusy));     I2C_DRV_MasterSetBaudRate(instance, device);         /* Set direction to send for sending of address. */     I2C_HAL_SetDirMode(base, kI2CSend);       /* Enable i2c interrupt.*/     I2C_HAL_ClearInt(base);     I2C_HAL_SetIntCmd(base, true);       /* Generate start signal. */     I2C_HAL_SendStart(base);       /* Send out slave address. */     I2C_DRV_SendAddress(instance, device, cmdBuff, cmdSize, kI2CReceive, timeout_ms);       /* Start to receive data. */     if (master->status == kStatus_I2C_Success)     {         /* Change direction to receive. */         I2C_HAL_SetDirMode(base, kI2CReceive);                 /* Send NAK if only one byte to read. */         if (rxSize == 0x1U)         {         I2C_HAL_SendNak(base);         }         else         {         I2C_HAL_SendAck(base);         }                 /* Dummy read to trigger receive of next byte in interrupt. */         I2C_HAL_ReadByte(base);                 /* Now set the DMA bit to let the DMA take over the reception. */         I2C_C1_REG(I2C1) |= I2C_C1_DMAEN_MASK;                 /* Don't wait for the transfer to finish. Exit immediately*/     }     else if (master->status == kStatus_I2C_Timeout)     {         /* Disable interrupt. */         I2C_HAL_SetIntCmd(base, false);                 if (I2C_HAL_GetStatusFlag(base, kI2CBusBusy))         {         /* Generate stop signal. */         I2C_HAL_SendStop(base);         }                 /* Indicate I2C bus is idle. */         master->i2cIdle = true;     }         return master->status; } After writing the DMA driver, a DMA specific transfer complete function must be implemented. This is needed in order for the application software to signal to the driver structures that the transfer has been completed and the bus is now idle. In addition, the DMA enable bit needs to be cleared in order for other driver functions to be able to properly use the IIC peripheral. void I2C_DRV_CompleteTransferDMA(uint32_t instance) {     assert(instance < I2C_INSTANCE_COUNT);     I2C_Type * base = g_i2cBase[instance];     i2c_master_state_t * master = (i2c_master_state_t *)g_i2cStatePtr[instance];         I2C_C1_REG(base) &= ~(I2C_C1_DMAEN_MASK | I2C_C1_TX_MASK);     I2C_C1_REG(base) &= ~I2C_C1_MST_MASK;;        /* Indicate I2C bus is idle. */     master->i2cIdle = true; } DMA Configuration Next, the application layer needs a function to configure the DMA properly, and a DMA callback is needed to properly service the DMA interrupt that will be used as well as post a semaphore. But before diving into the specifics of that, it is important to discuss the overall strategy of using the DMA in this particular application. After every transaction, the data register must be serviced to ensure that all of the necessary data is received.  One DMA channel can easily be assigned to service this activity.  After the reception of the second to last data byte, the TXAK bit must be written with a '1' to ensure that the NAK is put on the bus at the appropriate time. This is a little trickier to do.  There are three options: A second dedicated DMA channel can be linked to write the I2C_C1 register every time the I2C_D register is serviced.  This option will require a second array to hold the appropriate values to be written to the I2C_C1 register.  The following figure illustrates this process. The second DMA channel can be linked to write the I2C_C1 register after the second to last data byte has been received.  This option would require that the primary DMA channel be set to receive two data bytes less than the total number of desired data bytes.  The primary DMA channel would also need to be re-configured to receive the last two bytes (or the application software would need to handle this).  However this could be a desirable programming path for applications that are memory constrained as it reduces the amount of memory necessary for your application. The primary DMA channel can be set to receive two data bytes less than the total number of desired data bytes and the core (application software) can handle the reception of the last two bytes.  This would be a desirable option for those looking for a simpler solution but has the drawback that in a system where the core is already handling many other tasks, there may still be issues with writing the TXAK bit on time. This example will focus on option number 1, as this is the simplest, fully automatic solution.  It could also easily be modified to fit the second option as the programmer would simply need to change the number of bytes to receive by the primary DMA and add some reconfiguration information in the interrupt to service the primary DMA channel. DMA Channel #1 The first DMA channel is configured to perform 8-bit  transfers from the I2C data register (I2C_D) to the buffer to hold the desired data.  This channel should transfer the number of desired bytes minus one.  The final byte will be received by the core.  Other DMA configuration bits that are important to set are the cycle steal bit, disable request bit, peripheral request bit (ERQ), interrupt on completion of transfer (EINT), and destination increment (DINC).  It also important to configure the link channel control to perform a link to channel LCH1 after each cycle-steal transfer and LCH1 should be configured for the channel that will transfer from memory to the I2C control register (I2C_C1).  The first DMA channel is configured as shown below. // Set Source Address (this is the UART0_D register       DMA_SAR0 = (uint32_t)&I2C_D_REG(base);             // Set BCR to know how many bytes to transfer       // Need to set to desired size minus 1 because the last will be manually       // read.        DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(destArraySize - 1);             // Clear Source size and Destination size fields.        DMA_DCR0 &= ~(DMA_DCR_SSIZE_MASK                     | DMA_DCR_DSIZE_MASK                     );       // Set DMA as follows:       //     Source size is byte size       //     Destination size is byte size       //     D_REQ cleared automatically by hardware       //     Destination address will be incremented after each transfer       //     Cycle Steal mode       //     External Requests are enabled       //     Interrupts are enabled       //     Asynchronous DMA requests are enabled.       //     Linking to channel LCH1 after each cycle steal transfer       //     Set LCH1 to DMA CH 1.        DMA_DCR0 |= (DMA_DCR_SSIZE(1)             // 1 = 8-bit transfers                    | DMA_DCR_DSIZE(1)           // 1 = 8-bit transfers                    | DMA_DCR_D_REQ_MASK                    | DMA_DCR_DINC_MASK                    | DMA_DCR_CS_MASK                    | DMA_DCR_ERQ_MASK                    | DMA_DCR_EINT_MASK                    | DMA_DCR_EADREQ_MASK                    | DMA_DCR_LINKCC(2)          // Link to LCH1 after each cycle-steal transfer                    | DMA_DCR_LCH1(1)            // Link to DMA CH1                    );       // Set destination address       DMA_DAR0 = (uint32_t)destArray; DMA Channel #2 The second DMA channel, which is the linked channel, should be configured to perform 8-bit transfers that transfer data from an array in memory (titled ack_nak_array in this example) to the I2C control register (I2C_C1).  This channel should also disables requests upon completion of the entire transfer, and enable the cycle-steal mode.  In this channel, the source should be incremented (as opposed to the destination as in the first channel). This channel is configured as shown below: // Set Source Address (this is the UART0_D register       DMA_SAR1 = (uint32_t)ack_nak_array;             // Set BCR to know how many bytes to transfer       // Need to set to desired size minus 1 because the last will be manually       // read.       DMA_DSR_BCR1 = DMA_DSR_BCR_BCR(destArraySize - 1);             // Clear Source size and Destination size fields.        DMA_DCR1 &= ~(DMA_DCR_SSIZE_MASK                     | DMA_DCR_DSIZE_MASK                     );             // Set DMA as follows:       //     Source size is byte size       //     Destination size is byte size       //     D_REQ cleared automatically by hardware       //     Destination address will be incremented after each transfer       //     Cycle Steal mode       //     External Requests are disabled       //     Asynchronous DMA requests are enabled.       DMA_DCR1 |= (DMA_DCR_SSIZE(1)             // 1 = 8-bit transfers                    | DMA_DCR_DSIZE(1)           // 1 = 8-bit transfers                    | DMA_DCR_D_REQ_MASK                    | DMA_DCR_SINC_MASK                    | DMA_DCR_CS_MASK                    | DMA_DCR_EADREQ_MASK                    );             // Set destination address       DMA_DAR1 = (uint32_t)&I2C_C1_REG(base); Once the DMA channels are initialized, the only action left is to configure the interrupts, enable the channel in the DMA MUX, and create the semaphore if it has not already been created.  This is done as shown below. //Need to enable the DMA IRQ       NVIC_EnableIRQ(DMA0_IRQn);       //////////////////////////////////////////////////////////////////////////       // MUX configuration       // Enables the DMA channel and select the DMA Channel Source        DMAMUX0_CHCFG0 = DMAMUX_CHCFG_SOURCE(BOARD_I2C_DMAMUX_CHN); //DMAMUX_CHCFG_ENBL_MASK|DMAMUX_CHCFG_SOURCE(0x31); //0xb1;       DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;             /* Create semaphore */       if(semDmaReady == NULL){         semDmaReady = OSA_EXT_SemaphoreCreate(0);       } Finally, the DMA initialization function also initializes the ack_nak_array.  This is only necessary when implementing the first DMA strategy.  The second DMA strategy would only need to write a single value at the correct time.  The array initialization for strategy #1 is shown below.  Note that the values written to the array are 0xA1 plus the appropriate value of the TXAK bit.  By writing 0xA1, it is ensured that the I2C module will be enabled in master mode with the DMA enable bit set. // Initialize Ack/Nak array       // Need to initialize the Ack/Nak buffer first       for( j=0; j < destArraySize; j++)       {           if(j >= (destArraySize - 2))           {               ack_nak_array[j] = 0xA1 | I2C_C1_TXAK_MASK;           }           else           {               ack_nak_array[j] = 0xA1 & (~I2C_C1_TXAK_MASK);           }       } DMA Interrupt Handler Now a DMA interrupt handler is required.  A minimum of overhead will be required for this example as the interrupt handler simply needs to service the DONE bit and post the semaphore created in the initialization.  The DMA interrupt handler is as follows: void DMA0_IRQHandler(void) {     // Clear pending errors or the done bit     if (((DMA_DSR_BCR0 & DMA_DSR_BCR_DONE_MASK) == DMA_DSR_BCR_DONE_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_BES_MASK) == DMA_DSR_BCR_BES_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_BED_MASK) == DMA_DSR_BCR_BED_MASK)         | ((DMA_DSR_BCR0 & DMA_DSR_BCR_CE_MASK) == DMA_DSR_BCR_CE_MASK))     {         // Clear the Done MASK and set semaphore, dmaDone         DMA_DSR_BCR0 |= DMA_DSR_BCR_DONE_MASK;         //dmaDone = 1;         OSA_SemaphorePost(semDmaReady);     } } Using your newly written driver function Once all of these items have been taken care of, it is now time for the application to use the functions. It is expected that the DMA will be initialized before calling the DMA receive function.  After the first call, the DMA can be re-initialized every time or could simply be reset with the start address of the arrays and byte counter (this is the minimum of actions that must be performed).  Then the application should ensure that the transaction happened successfully.   Upon a successful call to the I2C_DRV_MasterReceiveDataDMA function, the application should wait for the semaphore to be posted.  Once the semaphore posts, the application software should wait for the Transfer Complete flag to become set.  This ensures that the application does not try to put a STOP signal on the bus before the NAK has been physically put on the bus.  If the STOP signal is attempted out of sequence, the I2C module could be put in an erroneous state and the STOP signal may not be sent.  Next, the I2C_DRV_CompleteTransferDMA function should be called to send the STOP signal and to signal to the driver structures that the bus is idle.  At this point, the I2C transaction is now fully complete and there is still one data byte that hasn't been transferred to the receive buffer.  It is the application's responsibility to perform one last read of the Data register to receive the last data byte of the transaction. /* Now initialize the DMA */    dma_init(BOARD_I2C_INSTANCE, Buffer, ack_nak_buffer, FXOS8700CQ_READ_LEN); //Init DMAMUX       returnValue = I2C_DRV_MasterReceiveDataDMA(BOARD_I2C_INSTANCE, &slave,                                                   cmdBuff, 1, Buffer, FXOS8700CQ_READ_LEN, 1000); if (returnValue != kStatus_I2C_Success)    {        return (kStatus_I2C_Fail);    } /* Wait for the DMA transaction to complete */    OSA_SemaphoreWait(semDmaReady, OSA_WAIT_FOREVER);       /* Need to wait for the transfer to complete */ for(temp=0; temp<250; temp++)     {         if(I2C_HAL_GetStatusFlag(base, kI2CTransferComplete))         {             break;         }     }       /* Now complete the transfer; this includes sending the I2C STOP signal and       clearing the DMA enable bit */    I2C_DRV_CompleteTransferDMA(BOARD_I2C_INSTANCE);       // Once the Transfer is complete, there is still one byte sitting in the Data    // register.      Buffer[11] = I2C_D_REG(g_i2cBase[BOARD_I2C_INSTANCE]); Conclusion To summarize, as consumers demand more and more power efficient technology with more and more functionality, MCU product developers need to cram more functionality in small power efficient MCUs.  Relying on DMA for basic data transfers is one good way to improve performance of smaller power efficient MCUs with a single core. This can be particularly useful in applications where an MCU needs to pull information from and I2C sensor.  To do this, there are three methods of implementing an I2C master receive function in your SDK 1.3 based application. Use two DMA channels.  The first to transfer from the I2C Data register to the destination array.  A second dedicated DMA channel can be linked to write the I2C_C1 register every time the I2C_D register is serviced. Use two DMA channels.  The first to transfer from the I2C Data register to the destination array. The second DMA channel can be linked to write the I2C_C1 register only after the second to last data byte has been received. Use a single DMA channel can be set to receive two data bytes less than the total number of desired data bytes and the core (application software) can handle the reception of the last two bytes. The recommendation of this document is to implement the first or second option as these are fully automatic options requiring the least intervention by the core.

在电机控制，Audio等很多应用中，我们经常会用到一些常见的正余弦，矩阵变换，FFT等一些DSP函数，提到DSP库，通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准，包括针对内核操作的CMSIS-CORE API，针对DSP应用的CMSIS-DSP Library，针对RTOS的CMSIS-RTOS API，与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中，又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能，CMSIS-DSP部分提供了超过60多种功能的DSP算法库，尤其是随着Cortex-M4中集成了FPU硬件单元，CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持，然而在CodeWarrior中没有直接支持CMSIS，需要用户移植到自己的CW工程中，所以就需要使用者了解CMSIS的结构，手动添加库文件和头文件，并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元，有些不支持，在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中，FPU浮点运算单元也是一个可选的部件，只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能，如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元，整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片，编译器也设置了相应的 FPU 功能开启/关闭的选项，在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能，在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能，而芯片未开启 FPU 单元，程序运行到浮点语句时就会出现异常。相反，如果编译器未使能 FPU 功能，芯片即使开启了 FPU单元，程序还是会按照未使能 FPU 的代码进行处理。在本例程中，为对比分析是否采用FPU的编译指令差别以及在板的执行效率，选用Kinetis K70FN1M为实验对象。 硬件平台：TWR-K70F120M核心板      软件环境：CodeWarrior v10.5        CMSIS版本 ：V3.2 一. 准备工作： 下载CMSIS的库，当前最新的版本为V3.2，解压后名称为CMSIS-SP-00300-r3p2-00rel1，其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中，真正用到的文件包括CMSIS\Include中CM4相关的头文件，CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点)，以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤；      Step 1:    新建一个Baremental的工程，选择器件器件MK70FN1M0（支持硬件FPU）；     Step 2:    选择Floating Point浮点运算实现的类型，即指定编译器将C代码编译成汇编代码时使用的规则； 在Floating Point四个选项含义如下： Software选项：表示不使用FPU硬件，而是使用GCC的整数算术运算来模拟浮点运算； Handware(-mfloat –abi=hard) 选项：表示使用FPU硬件来进行浮点运算，函数的参数直接传递到FPU的寄存器(s0-d0)中； Handware(-mfloat –abi=softfp)选项：表示使用FPU硬件来进行浮点运算，但是函数的参数传递到整数寄存器(r0-r3）中，然后再传递到FPU中； Handware(-mfloat –abi=softfp –fshort -double)选项：其配置项同上，只不过使能了fshort  double功能，并且此处的double数据的宽度等同于float； 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章，在本例程中使用的是软浮点，所以选择Software项。需要注意的是：此配置选项仅出现支持FPU硬件单元的芯片工程中，如MK60FN1M0, MK60FX512等，否则默认没有此选项，默认为软件浮点。 Step 3:    点击“Next”进入下图，选择使用Processor Expert，点击“Finish“完成工程的建立； Step 4:    进入当前工程的文件夹，新建文件夹CMSIS，从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外，拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中； Step 5:    回到CodeWarrior主界面选择新建的工程文件，F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件，包括M0+/M3/M4的一些头文件；在Lib文件中是已经编译好的库文件，ARM文件夹是使用在KEIL IDE中的库文件，G++文件夹是使用在IAR中的库文件，而由于当前CW工程使用的GCC的编译器，所以GCC文件夹才是CW需要的，因此，为缩减工程大小可以删除ARM和G++文件夹；     Step 6:    打开工程属性框，选择Target Processor的Float ABI为No FPU； Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4； Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件，路径为：工程目录\CMSIS\Include； Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU，所以选择libarm_cortexM4l_math.a，此处需要特别注意，否则编译会报错； Step 10: 在ProcessorExpert.c文件中添加代码； #include <math.h> #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V，仅在 FPU 功能被使能时使用)，完成一个正弦计算； 至此，完成了不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元，移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元，移植CMSIS的DSP库到Codewarrior的方法有两种：一种是按照上面软浮点的方式Step By Step的建立工程，步骤和上面二的步骤基本一致，主要的两个区别在于：(1). Step 2要选择Handware(-mfloat –abi=hard) 选项，(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便，本教程采用第二种方案，完成在Codewarrior中调用CMSIS的DSP库，通过K70的FPU浮点运算单元执行浮点运算，即硬浮点。 Step 1:    打开工程属性对话框，选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard)； Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义：_VFPV4； Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则，把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"； Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU，所以选择libarm_cortexM4lf_math.a，此处需要特别注意，否则编译会报错； Step 5:    完成以上配置后，编译工程并下载调试（此处建议编译之前先Clean一下整个工程），同样，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V，仅在 FPU功能被使能时使用)，并且在Register观察窗口中也多了个FPU寄存器列表，感兴趣的读者可以对比一下和前面实验汇编出代码的差异，此处不再赘述； 至此，分别完成了使用和不适用K70的FPU浮点运算单元情况下， CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数，在项目中直接调用即可。下一步， Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是，前文中讲到使用FPU单元需要两步设置：(1). 在编译器中开启相应的 FPU 功能选项；(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤，然而第二个步骤呢？仔细查看_arm_atart.c文件，可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程，如下图，是一个条件编译函数，这也就解释了为什么在上面Step 2中定义了_VFPV4，其本质也就是使能芯片的FPU单元，其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif

When using ADCs it is not enough to just configure the module, add a clock signal, apply the Nyquist criteria and hope for the best, because normally that is just not enough. Even if we use the best software configuration, sampling rate, conversion time, etc; we might end up with noisy conversions, and worst of all a low ENOB figure which sums up in a lousy, low resolution ADC application. To complement the software end you need to follow some basic hardware design rules, some of them might seem logical, other might even weird or excessive however they are the key to a successful conversion, I took the time to compile a short list of effective design best practices trying to cover the basics of ADC design. If you think I missed something feel free to comment and ask for more information. Ground Isolation Because ground is the power return for all digital circuits and analog circuits, one of the most basic design philosophies is to isolate digital and analog grounds. If the grounds are not isolated, the return from the analog circuitry will flow through the analog ground impedance and the digital ground current will flow through the analog ground, usually the digital ground current is typically much greater than the analog ground current.  As the frequency of digital circuits increases, the noise generated on the ground increases dramatically. CMOS logic families are of the saturating type; this means the logic transitions cause large transient currents on the power supply and ground. CMOS outputs connect the power to ground through a low impedance channel during the logic transitions. Digital logic waveforms are rectangular waves which imply many higher frequency harmonic components are induced by high speed transmission lines and clock signals.                              Figure 1: Typical mixed signal circuit grounding                              Figure 2: Isolated mixed signal circuit grounding Inductive decoupling Another potential problem is the coupling of signal from one circuit to another via mutual inductance and it does not matter if you think the signals are too weak to have a real effect, the amount of coupling will depend on the strength of the interference, the mutual inductance, the area enclosed by the signal loop (which is basically an antenna), and the frequency. It will also depend primarily on the physical proximity of the loops, as well as the permeability of the material. This inductive coupling is also known as crosstalk in data lines.                               Figure 3: Coupling induced noise It may seem logical to use a single trace as the return path for the two sources (dotted lines). However, this would cause the return currents for both signals to flow through the same impedance, in addition; it will maximize the area of the interference loops and increase the mutual inductance by moving the loops close together. This will increase the mutual noise inductance and the coupling between the circuits. Routing the traces in the manner shown below minimizes the area enclosed by the loops and separates the return paths, thus separating the circuits and, in turn, minimizing the mutual noise inductance.                               Figure 4: Inductance decoupling layout Power supply decoupling The idea after power decoupling is to create a low noise environment for the analog circuitry to operate. In any given circuit the power supply pin is really in series with the output, therefore, any high frequency energy on the power line will couple to the output directly, which makes it necessary to keep this high frequency energy from entering the analog circuitry. This is done by using a small capacitor to short the high frequency signals away from the chip to the circuit’s ground line. A disadvantage of high frequency decoupling is it makes a circuit more prone to low frequency noise however it is easily solved by adding a larger capacitor. Optimal power supply decoupling A large electrolytic capacitor (10 μF – 100 μF) no more than 2 in. away from the chip. A small capacitor (0.01 μF – 0.1 μF) as close to the power pins of the chip as possible. A small ferrite bead in series with the supply pin (Optional).                               Figure 5: Power supply decoupling layout Treat signal lines as transmission lines Although signal coupling can be minimized it cannot be avoided, the best approach to effectively counteract its effects on signal lines is to channel it into a conductor of our choice, in this case the circuit’s ground is the best choice to channel the effects of inductive coupling; we can accomplish this by routing ground lines along signal lines as close as manufacturing capabilities allow. An very effective way to accomplish this is routing signals in triplets, these works for both digital and analog signals.The advantages of doing so are an improved immunity not only to inductive coupling but also immunity to external noise. Optimal routing: Routing in “triplets” (S-G-S) provide good signal coupling with relatively low impact on routing density Ground trace needs to be connected to the ground pins on the source and destination devices for the signal traces Spacing should be as close as manufacturing will allow                               Figure 6: Transmission line routing Signal acquisition circuit To improve noise immunity an external RC acquisition circuit can be added to the ADC input, it consists of a resistor in series with the ADC input and a capacitor going from the input to the circuit’s ground as the figure below shows:                                                             Figure 7: ADC with an external acquisition circuit The external RC circuit values depend on the internal characteristics and configuration of the ADC you use, such as the availability of an internal gain amplifier or the ADC’s architecture; the equation and circuit shown here represents a simplified form of ADC used in Freescale devices. The equivalent sampling resistance RSH is represented by total serial resistance connected between sampling capacitance and analog input pin (sampling switch, multiplexor switches etc.). The sampling capacitance CSH is represented by total parallel capacitance. For example in a case of Freescale SAR ADC equivalent sampling capacitance contains bank of capacitances. The equation shown how to calculate the value of the input resistor based on the values of both the input and sample and hold circuit. It must be noted the mentioned figures could have an alternate designation in any given datasheet; the ones mentioned here are specific to Kinetis devices: TAQ=      Acquisition time (.5/ADC clock) CIN=       Input capacitance (33pF min) CSH=      Sample & Hold circuit capacitance ( CDAIN in datasheet) VIN=       Input voltage level VCSH0= Initial voltage across S&H circuit (0V) VSFR=    Full scale voltage (VDDA) N=           bit resolution Note:  Special care must be taken when performing the calculation since a deviation from the correct values will result in a significant conversion error due to signal distortion.

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

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

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

Hey there Kinetis lovers!  We in the Systems Engineering team for Kinetis Microcontrollers see all kinds of situations that customers get into, and none can be particularly troubling like how the reset pin is handled.  The purpose of this document is to provide a list of Frequency Asked Questions (FAQ) that we get here in the Kinetis Systems Engineering department.  This is intended to be a living list and as such, may in no way be complete.  However we hope that you will find the below questions and answers useful.   Q:  Do I need to connect the reset signal to be able to debug a Kinetis device?   This is a commonly asked question. Strictly speaking, you do not need to connect the device reset line of a Kinetis device to the debug connector to be able to debug. The debug port MDM-AP register allows the processor to be held in reset by means of setting the System Reset Request bit using just the SWD_CLK and SWD_DIO lines.   However, before deciding to omit the reset line from your debug connector you should give some careful thought to how this may impact the ability to program and debug the device in certain scenarios. Does the debugger/flash programmer or external debug pod require the reset pin? It may be that the specific tool you are using only supports resetting the device by means of the reset line and does not offer the ability to reset the device by means of the MDM-AP. Have you changed the default function of the debug signals? You may need to use the SWD_CLK and/or the SWD_DIO signals for some other function in your application. This is especially true in low pin count packages. Once the function is changed (by means of the PORTx_PCRy registers) you will no longer have access to the MDM-AP via those signals. If you do not have access to the reset signal then you have no way of preventing the core from executing the code that will disable the SWD function of the pins. So you will not be able to re-program the device. In order to prevent this type of situation you need to either: Setup your code to change the function of the SWD pins several seconds after reset is released so that the debugger can halt the core before this happens. Put some kind of “backdoor” mechanism in your code that does not re-program the SWD function, or re-enables the SWD function, on these pins. For example, a specific character sequence sent via a UART or SPI interface.   Some Kinetis devices allow the reset function of the reset pin to be disabled. In this case you can only use the SWD signals as a means of resetting the device via the MDM-AP. If you change the SWD pin function in addition to disabling the reset pin then you must provide a backdoor means of re-enabling the SWD function if you want to be able to reprogram the device.

Recently I did a porting based on AN4370SW for a customer to support TWR-K20D72M, and with some modification in source code, header file and link file as well, it works well as expected. The following simple describes what I have done: 1.Copy the project file folder for K20D50M "AN4370SW\Source\Device\app\dfu_bootloader\iar_ew\kinetis_k20" and rename is as "kinetis_k20d70m" 2.Change the target settings as well as the flash loader. 3. Replace the header file for K20D50M and include it in derivative.h. The header file for K20D72M can be found from KINETIS_72MHz_SRC(http://cache.freescale.com/files/32bit/software/KINETIS_72MHz_SRC.zip?fpsp=1&WT_TYPE=Lab%20and%20Test%20Software&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&sr=9) 4.Modify the interrupt table in cstartup_M.s, which is more likely a K60's vertor table. 5.Search the code related with the macro "MCU_MK20D5", and add similar code snippet for K20D72M , You may easily find them by search the keyword "MCU_MK20D7". That code parts include initialization for MCG, and PIT0 and USB interrupt enablements, some definition in bootloader.h . 6. Copy the link file from K20D50M, and modify the PFLASH size,SRAM size and DFLASH size as shown below: Perform MassErase before programming . and then you may press the SW1 on TWR-K20D72M to select which mode to enter after download the application firmware: pressing SW1 to enter bootloader mode and releasing it to enter application mode. 7. Build image for this DFU bootloader. Actually the bareboard projects in KINETIS_72MHz_SRC can be used for that purpose, and only link file needs some modification to put the image starting from 0xA000, since exception table redirection has already been done in these projects. after that, user needs change some settings in the CW projects to use the new link file: and generate S19 file as the output as well as the map file: after compiling , you will have a xxx.afx.s19 file, but that is not the final format, we still need to transform it to bin format, and it can be done by a small tool in "C:\Program Files\Freescale\CW MCU v10.3\MCU\prog" There are some settings for this tool to transform the S19 file, by clicking Burner->Burner Dialog, you will see some option views, please set them as below: Referring to the above figure, maybe you would wonder how to set up the Origin and Length field, actually Origin is the value where the image starts from just as the link file specified , and Length is calculated by the results from the map file. Please refer to the following figure for details. 0x3550 = 0x1c90 + 0x18c0. I also attached the burner's configuration file and image link file as well as the image for reference. Please copy the link file in "KINETIS_72MHz_SRC\build\cw\linker_files". Please kindly refer to the attachment for more details. Hope that helps, B.R Kan

Here you will find both the code and project files for the ADC project. This project configures the ADC to perform single conversions, by default this is performed using a 16 bit configuration. The code uses ADC0, channel 12, once the conversion is finished it is displayed at the serial terminal. Code: #include "mbed.h" AnalogIn AnIn(A0); DigitalOut led(LED1); Serial pc(USBTX,USBRX); float x; int main() {     pc.printf(" ADC demo code\r\n");     while (1)     {     x=AnIn.read();     pc.printf("ADC0_Ch12=(%d)\r\n", x);     wait(.2);     } }

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

Welcome to the FRDM-K64 mbed workshop, in this page you will find all the code examples we will review on this session. The program covers the following modules: GPIO Serial communication Interrupts PWM ADC I2C (Accelerometer) USB Ethernet Depending on how fast we advance during the session some of the modules might be skipped; however here you can find both the source code and binary files ready to be flashed into the FRDM-K64 development board. FRDM-K64Z120M The FRDM-K64 is fully compatible with the Arduino rapid prototyping system, the following image depicts the board's pinout, the green labels can be used directly into your mbed proyects, they have already been defined in the headers and libraries in order to make development easier. Sign up at mbed.org In order to create the projects covered on this session it is necessary to create an mbed user account, open the website and create a user account, if you have already signed up please log in. Mbed debugging application To enable the FRDM-K64 development board using the binary files generated by mbed it is necessary to update the board's firmware, follow the steps mentioned below in order to enable the board to be programmed: Press the board's reset button While pressing the reset button connect the board to your computer using the USB cable, it must be connected to the J26 USB connector. Once the unit has enumerated as "Bootloader", copy the 20140530_k20dx128_k64f_if_mbed.bin file into the unit Disconnect and reconnect the USB cable, the board must enumerate as "MBED" Serial communication driver To implement serial communication you need to install the serial driver in your computer, download the driver, once your board has enumerated as MBED execute the driver and wait for it to be finished, this might take a couple of minutes. Serial terminal In order to communicate with the board via serial port it is necessary to use a serial terminal, by default WIndows 7 and 8 do not have this application, XP does. If your OS does not feature a serial terminal, you can download the one at the bottom (Teraterm). ! Your board is now ready to be programmed using mbed!

最近搞了一个基于TWR-K20D50M的的USB MSD device bootloader, 可以打开文件夹CW中的K20D5下的.project来查看。 在原始的MSD的基础上移植了FAT过来。 其他IAR和Kinetis的其他chip没有测试，如果需要使用，一个是新增相关头文件，二是在bootloader.h中修改相应的MCU_K20D50M定义下的flash及ram配置

Here you can find the code and project files for the GPIO example, in this example the 3 colors of the RGB led are turned on sequentially when the SW2 push button is pressed, the led pin definition is shared throughout all the freedom platforms. The wait function can be defined in seconds, miliseconds or microseconds. Code: #include "mbed.h" //Delay declared in seconds /*GPIO declaration*/ DigitalOut Red(LED1);         DigitalOut Green(LED2); DigitalOut Blue(LED3); DigitalIn sw2(SW2); int main() {     /*Leds OFF*/     Red=1;     Green=1;     Blue=1;         while(1)     {         if(sw2==0)         {             Red = 0;             wait(.2);             Red = 1;             wait(1);                                Green=0;             wait(.2);             Green=1;             wait(1);                         Blue=0;             wait(.2);             Blue=1;             wait(1);         }     } }

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

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

Since the mbed Ethernet library and interface for FRDM-K64 have not yet been fully tested, instead of using mbed we will use one of the latest demo codes from MQX specifically developed for the FRDM-K64 platform. Before starting please make sure you have the following files and software installed in your computer: CodeWarrior 10.6 (professional or evaluation edition) MQX 4.1 for FRDM-K64 (it is not necessary to install full MQX 4.1) JLink_OpenSDA_V2.bin (this is the debugger application) * If you don't have a valid license, you can find a temporary license below, it will only be valid until 7/30/2014 and it will only be available online until 7/05/2014. Building the project The first step to use an MQX project is to compile the target/IDE libraries for the specific platform: 1. Open CodeWarrior and drag the file from the following path C:\Freescale\Freescale_MQX_4_1_FRDMK64F\build\frdmk64f\cw10gcc onto your project area: This will load all the necessary libraries to build the project, once they are loaded build them it is necessary to modify a couple of paths on the BSP: 2. Right click on the BSP project and then click on properties 3. Once the properties are displayed, expand the C/C++ Build option, click on settings, on the right pane expand the ARM Ltd Windows GCC Assembler and select the directories folder, this will display all the libraries paths the compiler is using 4. Double click on the "C\Freescale\CW MCU v10.6\MCU\ProcessorExpert\lib\Kinetis\pdd_100331\inc" path to modify it, once the editor window is open, change the path from "pdd_100331" to "pdd" 5. Repeat steps 2 and 3 for the ARM Ltd Windows GCC Compiler 6. Now you can build the libraries, build them one at a time by right clicking on the library and selecting build project, build them in the following order, it is imperative you do it in that order. BSP PSP MFS RTCS SHELL USBD USBH 7. Once all the libraries are built, import the web hvac demo, do it by dragging the .project file to your project area; the project is located in the following directory:                     C:\Freescale\Freescale_MQX_4_1_FRDMK64F\demo\web_hvac\build\cw10gcc\web_hvac_frdmk64f 8. Once the project is loaded, build it by right clicking on the project folder and select Build project Debugging the project To debug the project it is necessary to update the FRDM-K64 debugging application: Press the reset button on the board and connect the USB cable Once the board enumerates as "BOOTLOADER" copy the JLink_OpenSDA_vs.bin file to the unit Disconnect and reconnect the board On CodeWarrior (having previously compiled the libraries and project) click on debug configurations 5. Select the connection and click on debug 6. Open HVAC.h and change the IP Address to 192.168.1.202 Now the demo code has been downloaded to the platform you will need the following to access all the demo features: Router Ethernet Cable Serial Terminal The code enables a shell access through the serial terminal, it also provides web server access with a series of options to simulate an Heating Air Conditioning Ventilation System, the system was implemented using MQX and a series of tasks, for more details on how the task are created, the information regarding how to modify the code please check the attached document: Freescale MQX RTOS Example guide.