One of the new features that can be found on the FRDM-K82F is the FlexIO header. It’s be specifically designed to interface with the very cost-efficient OV7670 camera, and uses 8 FlexIO lines to read data from the camera. By using the FlexIO feature, it makes it easy to connect a camera to a Kinetis MCU. A demo is included with Kinetis SDK 1.3 which streams the video data from the camera to a host computer over USB. FlexIO: The FlexIO is a highly configurable module found on select Kinetis devices which provides a wide range of functionality including: • Emulation of a variety of serial/parallel communication protocols • Flexible 16-bit timers with support for a variety of trigger, reset, enable and disable conditions • Programmable logic blocks allowing the implementation of digital logic functions on-chip and configurable interaction of internal and external modules • Programmable state machine for offloading basic system control functions from CPU All with less overhead than software bit-banging, while allowing for more flexibility than dedicated IP. Running the Demo: First you’ll need to setup the hardware. An 18 pin header needs to be installed on the *back* of the board. The camera is oriented this way to allow for use of shields on the top, even if the camera is being used. This way the functionality could be extended with WiFi or LCD shields. After the header is soldered on, plug in the camera. It will look like the following when complete: Next we need to program the K82 device with the example firmware. The software can be found in the Kinetis SDK FRDM-K82F stand-alone release, in the C:\Freescale\KSDK_1.3.0_K82\examples\frdmk82f\demo_apps\usb\device\video\flexio_ov7670 folder. Open the project, compile, and program the example specific for your compiler like done for other examples. Make sure you also compile the USB Device library as well. After programming the K82, unplug the USB cable from J5 (OpenSDA) and plug it into J11 (K82 USB). The board will enumerate as a generic USB video device called “USB VIDEO DEMO”. You can then use this device with any video capture software, like Skype or Lync.  Here's a shot of the clock in my cube: The resolution is 160*120, the video image format is RGB565. You may need to manually adjust the focus by rotating the lens on the camera. The frame rate can also be sped up by modifying line 342 in usb_descriptor.c: 5fps: 0x80,0x84,0x1E,0x00, /* Default frame interval is 5fps */ 10fps:  0x40,0x42,0x0F,0x00, 15fps:  0x2A,0x2C,0x0A,0x00, 20fps:  0x20,0xA1,0x07,0x00, The 160*120 max resolution was determined by the amount internal SRAM of the device, as there is not external RAM on the FRDM-K82F board. More Information: One of many places to buy the OV7670 camera module​ OV7670 Reference Manual​ FlexIO Overview ​ FlexIO Training presented at FTF

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

Although most of us have a basic understanding of how an ADC works and how to understand some of the basic figures that define an ADC performance, that is far from really understanding how to fully interpret and use the figures depicted in a datasheet ADC section. With all those numbers it is easy to get lost on which ones to look at when we want to know how it will react to conditions such as frequency, signal amplitude, temperature, etc; having such knowledge would allow us to better fit a specific ADC to your application and take full advantage of its features. Having this in mind I took the time to compile some information related to what the most common figures that describe an ADC performance depicted in a datasheet mean, most of the material can be found in any Analog to Digital Conversion theory book; as I mentioned before this is just a general compilation of knowledge I hope will help you better understand those specifications. It assumes those of us who use datasheets are somehow familiar with the basic working of ADCs, so I will spare the basic concepts. Now down to business, this is a extract of a typical ADC section from a microcontroller's datasheet: I am almost certain not a lot of people who use microcontrollers, and more specifically ADCs; have a clear idea of what Total Unadjusted Error, Integral Non-Linearity or Differential Non-Linearity describe in the behavior of an ADC. Even though I will try to describe in detail the most common parameters I might miss some others and there is the possibility some of the information might not be as accurate as I would like it to be, if any of you reading this brief document have specific questions regarding any parameter I describe or miss by all means comment. Common ADC electrical characteristics depicted in datasheets EQ          Quantization error      Since the analog input to an ADC can take any value, but the digital output is quantized, there may be a difference of up to ½ Less Significant Bit between the actual analog input and the exact value of the digital output. This is known as the quantization error or quantization uncertainty as shown below. In ac (sampling) applications this quantization error gives rise to quantization noise. SINAD, SNR and ENOB (Signal to Noise plus Distortion, SIgnal to Noise Ratio and Effective Number of Bits)      Signal-to-Noise-and Distortion (SINAD, or S/(N + D) is the ratio of the rms signal amplitude to the mean value of the root-sum square (rss) of all other spectral components, including harmonics, but excluding dc. SINAD is a good indication of the overall dynamic performance of an ADC      as a function of input frequency because it includes all components which make up noise (including thermal noise) and distortion. It is often plotted for various input amplitudes. SINAD is equal to THD + N if the bandwidth for the noise measurement is the same. SINAD is often converted      to effective-number-of-bits (ENOB) using the relationship for the theoretical SNR of an ideal N-bit ADC: SNR = 6.02N + 1.76 dB, the equation is solved for N, and the value of SINAD is substituted for SNR.      Effective number of bits (ENOB) is a measure of the dynamic performance of an analog to digital converter and its associated circuitry. The resolution of an ADC is specified by the number of bits used to represent the analog value, in principle giving 2 N signal levels for an N-bit signal. However, all real ADC circuits introduce noise and distortion. ENOB specifies the resolution of an ideal ADC circuit that would have the same resolution as the circuit under consideration. Often ENOB is calculated using the relationship for the theoretical SNR of an ideal N-bit ADC: SNR =      6.02N + 1.76 dB, the equation is solved for N, and the value of SINAD is substituted for SNR. SFDR      Spurious Free Dynamic Range     One of the most significant specification for an ADC used in a communications application is its spurious free dynamic range (SFDR). SFDR of an ADC is defined as the ratio of the rms signal amplitude to the rms value of the peak spurious spectral content measured over the bandwidth      of interest. SFDR is generally plotted as a function of signal amplitude and may be expressed relative to the signal amplitude (dBc) or the ADC full-scale (dBFS) as shown in Figure n. For a signal near full-scale, the peak spectral spur is generally determined by one of the first few harmonics of the fundamental. However, as the signal falls several dB below full-scale, other spurs generally occur which are not direct harmonics of the input signal. This is because of the differential nonlinearity of the ADC transfer function as discussed earlier. Therefore, SFDR      considers all sources of distortion, regardless of their origin. INL      Integral Non-Linearity     Integral nonlinearity (acronym INL) is the maximum deviation between the ideal output of an ADC and the actual output level (after offset and gain errors have been removed). The transfer function of an ADC should ideally be a line and the INL measurement depends on the ideal line selected. Two often used lines are the best fit line, which is the line that minimizes the INL result and the endpoint line which is a line that passes through the points on the transfer function corresponding to the lowest and highest input code. In all cases, the INL is the maximum distance between the ideal line selected and the actual transfer function. DNL        Differential Non-Linearity      Differnetial NonLinearity relates to the linearity of the code transitions of the converter. In the ideal case, a change of 1 LSB in digital code corresponds to a change of exactly 1 LSB of analog signal. In an ADC there should be exactly 1 LSB change of analog input to move from one           digital transition to the next. Differential linearity error is defined as the maximum amount of deviation of any quantum (or LSB change) in the entire transfer function from its ideal size of 1 LSB. Where the change in analog signal corresponding to 1 LSB digital change is more or less than 1 LSB, there is said to be a DNL error. The DNL error of a converter is normally defined as the maximum value of DNL to be found at any transition across the range of the converter. The following figure shows the non-ideal transfer functions for an ADC and shows the effects of the DNL error.      A common result of excess DNL in ADCs is missing codes resulting from DNL < –1 LSB. THD      Total Harmonic Distortion Total harmonic distortion (THD) is the ratio of the rms value of the fundamental signal to the mean value of the root-sum-square of its harmonics (generally, only the first 5 are significant). THD of an ADC is also generally specified with the input signal close to full-scale, the harmonics of the input signal can be distinguished from other distortion by their location in the frequency spectrum. The second and third harmonics are generally the only ones specified on a data sheet because they tend to be the largest. EFS     Full Scale Error Full-scale error can be defined as the difference between the actual value triggering the transition to full-scale and the ideal analog full-scale transition value. Full-scale error is equal to the offset error + gain error Offset error The transfer characteristics of both DACs and ADCs may be expressed as a straight line given by D = K + GA, where D is the digital code, A is the analog signal, and K and G are constants. In a unipolar converter, the ideal value of K is zero. The offset error is the amount by which the actual value of K differs from its ideal value. Gain error The gain error is the amount by which G differs from its ideal value, and is generally expressed as the percentage difference between the two, although it may be defined as the gain error contribution (in mV or LSB) to the total error at full-scale. TUE      Total Unadjusted Error This is the result of performing conversions without having calibrated the ADC, it is dominated by the uncalibrated gain and uncalibrated offset terms in the data sheet. Although most devices will be well within the data sheet limits, it should be noted that they are not centered around zero and full range of the incoming analog signal is not guaranteed. Therefore, an uncalibrated ADC will always show unknown levels of gain and offset error, thus reflecting the worst case of conversion error the module can provide.

This document covers some of the more common questions about the new Kinetis K8x family. Any new specific issues or questions should be posted into it's own thread, and will be added to this document as appropriate. Kinetis K80 Basics What is the K8x family? It is a new Kinetis family of Cortex-M4F devices, running up to 150MHz, that include 256K of Flash and 256K of SRAM. It features FS USB, SDRAM, QuadSPI, SPI, I2C, LPUART, and much much more. How does the Kinetis K8x family differ from other Kinetis K families? The K8x family offers the same advantages and compatibility as other Kinetis K families, but also offers several new features not found on other Kinetis K families: QuadSPI Support Dual Voltage Domains (independent VDDIO domain down to 1.8V for QuadSPI or other interfaces) EMVSIM (Euro, MasterCard, Visa Serial Interface Module) FlexIO Additionally the K81 and K82 families offer the following new security modules: LTC (Low Power Trusted Cryptography) Encryption / Decryption algorithms in hardware (as opposed to using mmCAU s/w libs) OTFAD (On The Fly AES Decryption) Zero latency decryption when executing encrypted code from QuadSPI Secure RAM 2KB of Secure Session RAM Because of the addition of a second voltage domain and QuadSPI, there is no hardware pin compatibility with previous Kinetis derivatives. However there is significant module and enablement re-use, so if you’re familiar with other Kinetis devices, it will be easy to get started with the K80. Where can I find reference manuals, datasheets, and errata? These can be found on the K8x documentation pages. Detailed information on the K81 is under NDA, so please contact your NXP sales representative for those documents. What’s the difference between the different K8x devices? K80 is the base version, which includes QuadSPI controller, SDRAM controller, FS USB, and much more. K81 adds DryIce Tamper Detect and the LTC/OTFAD modules K82 adds just the LTC/OTFAD modules K80 and K82 families have the same pin out for their respective packages. The pinout for K81 is slightly different but can still be compatible. What boards are available to evaluate the K80 family? FRDM-K82F: A Freedom board with a 100LQFP K82 device. Also includes dual QuadSPI, touch pad, Arduino compatible footprint, and FlexIO header compatible with OV7670 camera. TWR-K80F150M: A Tower board with 121XFBGA K80 device. Includes dual QuadSPI, SDRAM, EVMSIM, SDCard holder, touch pads, and more. TWR-POS-K81: A Point of Sale reference design board in tower form factor. This board is only available via your NXP sales representative. The K8x MCU Family Hardware Tools selection guide has more details on board differences. What packages are available? The 100 LQFP and 121 XFBGA packages are lead packages available today. The 144 LQFP package and the WLCSP are part of the Package Your Way (PYW) program, and you should contact your NXP sales representative if interested in those packages. What is the difference between K8x and KL8x families? The KL8x family shares many of the same features as the K8x family. The biggest differences are that the KL8x family uses the Cortex-M0+ core (instead of Cortex-M4F), has a lower max clock speed, and has less internal Flash and RAM. It also reduces the instances of peripherals available, but still includes QuadSPI, FlexIO, LTC, and BootROM peripherals like on the K80. See the KL8x Fact Sheet for more details. KL8x devices will be available in the first quarter of 2016. Software/Tools Where can I find instructions and details on the hardware used to evaluate the K8x family? FRDM-K82F: http://nxp.com/frdm-k82f/startnow​ TWR-K80F150M: http://nxp.com/twr-k80f150m/startnow ​ Which version of Kinetis SDK supports the K8x family? Kinetis Software Development Kit (KSDK) support is split depending on the evaluation platform. For TWR-K80F150M, support can be found in the Kinetis SDK 1.3 Mainline Release. For FRDM-K82F, support can be found in the Kinetis SDK FRDM-K82F Stand-alone release. Note that the FRDM-K82 standalone release is truly standalone, and does not require the mainline release to be installed. How do I run the FRDM-K82F OV7670 camera demo? See this Community post: https://community.freescale.com/docs/DOC-329438 How can I use the micro SD card reader on the TWR-K80F150M? Because the SD card signals are shared with the QuadSPI signals, the SD card slot is not connected by default. See section 3.14 of the TWR-K80F150M User Guide for details on how to connect it, with the understanding that QuadSPI will not be available on the board while using SDHC. How do I use the SDRAM on the TWR-K80F150M? See section 3.9 of the TWR-K80F150M User Guide. Due to the layout of the board, the OpenSDA UART feature cannot be used while running the SDRAM as jumpers J6 and J8 need to be removed. QuadSPI What is QuadSPI Flash? Why should I use it? QuadSPI is a name for a popular type of serial NOR flash memory that is SPI compatible, but also allows for multiple data lines (up to 4 per device, or 8 if done in parallel) with bi-directional data for increased memory bandwidth. The QuadSPI controller on the K8x also allows for Execute-In-Place (XIP) mode so that code can be executed out of this external memory. QuadSPI memory can be used for either extra memory storage or for extra code space, or a combination of both. After initialization, it appears as a readable area of memory starting at 0x6800_0000 (as well as at the alias regions). How can I program the QuadSPI? There is an example application in Kinetis SDK that shows how to program the QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\driver_examples\qspi For programming an entire application, the ROM bootloader can be used. Details are in the K80 Bootloader Tools Package. The Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. There is also an example Kinetis SDK application that runs out of QuadSPI at C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi_alias What performance tips are there if doing QuadSPI XIP? A few key performance factors: Ensure both the data and instruction cache is enabled Use as many data lines as possible (4, or 8 if available in dual/octal modes) Use DDR mode Any critical code should be placed in Flash/RAM for fastest performance If using XIP, code should be executed out of the QuadSPI aliased address space which starts at 0x0400_0000. A more detailed app note is under development. How do I debug code located in QuadSPI? You must make use of the aliased QuadSPI address space at 0x0400_0000. There is an example of this in the hello_world_qspi_alias example in Kinetis SDK. Due to the architecture of the M4 core on Kinetis, breakpoints cannot be set in the 6800_0000 address space, which is why the alias address space is provided. What app notes are available for the QuadSPI? Because the QuadSPI module found on the K8x family has also been used on other NXP devices, there are some app notes available that can be useful for QuadSPI development. Note that some of the implementation details and features as described in the app notes will be different for K8x, so please use the K8x reference manual for full details. AN4186​ AN4512​ AN4777​ ROM Bootloader Where can I find more information on the bootloader that comes built into the silicon of the K8x family? Download the K80 Bootloader Tools package. If interested in QuadSPI, the Kinetis Bootloader QuadSPI User's Guide that comes as part of that package describes all the steps needed to get up and running with QuadSPI. The other information found on the Kinetis Bootloader website is also useful as this is what the ROM Bootloader is based off of. What interfaces does the ROM Bootloader support? The ROM Bootloader on the K8x family can interface via LPUART, I2C, SPI, or USB HID (via BLHost) to erase and program both the internal flash and/or QuadSPI flash. This is the same bootloader found on other Kinetis devices, but also includes some more advanced features to support QuadSPI. How can I enter bootloader mode? By default, when using a Kinetis SDK project, the bootloader is disabled and the code immediately jumps to the address in Flash pointed at location 0x4. By asserting the NMI pin at reset though, the part can be forced to enter bootloader mode. This is useful for programming the QuadSPI or interfacing with the bootloader in other ways. This feature is controlled via the FOPT[BOOTPIN_OPT] bit, which the Kinetis SDK code sets to '0' to enable the NMI pin to enter bootloader mode. The NMI button on each board is: FRDM-K82F: SW2 TWR-K80F150M: SW2 The FOPT register (at 0x40C) can be modified to always go into Bootloader mode if desired. Details are in boot chapter of the K80 reference manual. Where is the bootloader configuration data found in Kinetis SDK? The Bootloader Configuration Area (BCA), which begins at address 0x3C0, is defined in C:\Freescale\KSDK_1.3.0\platform\devices\MK80F25615\startup\system_MK80F25615.c starting on line 133. You must also add the define BOOTLOADER_CONFIG in the project settings to let the linker files know to program this BCA area. The FOPT configuration register (at 0x40D) is defined in C:\Freescale\KSDK_1.3.0_K82\platform\devices\MK82F25615\startup\<compiler>\startup_MK80F25615.s and by default is set to 0x3D which disables the bootloader, but does enable the option to enter bootloader via the NMI pin at reset (see previous question) How can I use the UART port on the FRDM-K82F with the BootROM? The OpenSDA/UART lines on the FRDM-K82F use LPUART4, which is not used by the BootROM. If you would like to use the serial UART lines to interact with the BootROM, you can blue wire a connection from either J24 or J1, and connect to R32 (RX) and R36 (TX). This was due to muxing trade-offs. The OpenSDA/UART lines on the TWR-K80F150M are connected to UART1 and thus no modification is necessary for that board. Also keep in mind that you can use the USB interface with the BLHost tool on both boards with no modification. The examples in Kinetis SDK setup the QuadSPI Configuration Block (QCB) data using a qspi_config.bin file. How can I generate my own custom QCB file? There is a C file that come as part of Kinetis SDK (C:\Freescale\KSDK_1.3.0\examples\twrk80f150m\demo_apps\hello_world_qspi\qspi_config_block_generator.c) or in the KBoot zip file, that can be compiled with various toolchains on a host computer, that will then produce a .bin file. You could import this file, and then after compilation, run it, and it will write out the new .bin to your hard drive. There is a tool under development that simplifies this process by reading in that example .bin file and then you can modify the fields in the app, and then it will write out the modified .bin file. Can I jump directly to QuadSPI for Execute in Place (XiP) after booting? Yes. However note that you must still put the Bootloader Configuration Area (BCA) into internal flash. And you also may want to put the QuadSPI Configuration Block (QCB) in flash as well since it needs to be read before the QuadSPI is setup. Thus even if all your code is in QuadSPI address space, the internal flash must also be written at least once to put in the configuration data. Once you have that set though, then you can develop code by only programming the QuadSPI address space. Troubleshooting I’m having debugger connection issues when using an external debugger, like a Segger JLink. Why? It’s likely that the OpenSDA circuit is interfering, and thus needs to be isolated via jumpers on the board. For TWR-K80F150M: Pull J16 and J17 For FRDM-K82F: Pull J6 and J7 Also make sure you are using the correct debug header for the K8x device on the board: For TWR-K80F150M: J11 For FRDM-K82F: J19 Where is the CMSIS-DAP/OpenOCD debug configuration for the K8x family in Kinetis Design Studio? KDS 3.0 does not support programming the K8x family via the CMSIS-DAP interface. You will need to change the OpenSDA app on the board to either J-Link or P&E as described in the K8x Getting Started guides (Part 3). I can't get OpenSDA on the FRDM-K82F into bootloader mode. Make sure jumper J23 is on pins 1-2 to connect the reset signal to the OpenSDA circuit. On some early versions of the board this was incorrectly installed on pins 2-3 instead. When using IAR with the default CMSIS-DAP debug interface, I sometimes get the error: “Fatal error: CPU did not power up” This is an issue in some older versions of IAR. Upgrade to at least version 7.40.5 which fixes this. When using KDS with the JLink interface with the FRDM-K82F board, I get an error. If you see the error "The selected device 'MK82FN256XXX15' is unknown to this version of the J-Link software." it's because the J-Link driver that comes with KDS 3.0.0 does not know about the K82 family. You can either select a MK80FN256XXX15 device (which is compatible with the K82 on the board) or update the JLink software by downloading and installing the latest JLink Software and documentation pack. At the end of the installation process it will ask to update the DLLs used by the IDEs installed on your computer, so make sure to check the KDS checkbox on that screen. I’m using the P&E OpenSDA App and debugging is not working. I get either "Error reading data from OpenSDA hardware. E17925" or “The system tried to join a drive to a directory on a joined drive” in KDS If using IAR, make sure you have the latest version (7.40.7 or later) If using KDS, you need to update the P&E plugin in KDS. Go to Help->Check for Updates, and select the P&E debug update. Make sure not to select the other debugger updates as it will break it in KDS 3.0.0 (see this thread)

Test environment: FRDM-K64F Rev.D IAR ARM Workbench IDE V8.30.1 MCUXpresso SDK for FRDM-K64F v2.4.2(2018-08-02) Test project is [ftm_output_compare] located with default path: ..\FRDM-K64F\boards\frdmk64f\driver_examples\ftm\output_compare Test reason to verify the CnV register is updated on the next FTM counter change. Three test signals: FTM0_CH0 pin as output compare pin will generate square signal with 1.33KHz . FTM0_CH1 pin generate 24KHz Edge-Aligned PWM signal(High-true pulses (clear Output on match)) with 50% duty cycle as FTM counter monitor. When FTM counter change, the FTM0_CH1 will toggle to output high voltage. Test using a delay() function to emulate modify FTM0_CH0 output compare mode and CnV value periodically. There is a GPIO pin will toggle after each delay() function to detect/verify the CnV value actual load point. FlexTimer module setting: The FTM0 refer clock is 60MHz For the FTM0_CH1 pin generate 24KHz PWM signal, the FTM0 MOD value is fixed to 0x9C3 (60MHz/24KHz = 2500).   Below is the overall signals: Test Process Record: During FTM0 module initialization, set the FTM0_CH0 pin output compare value to 0xA00 (more than MOD register value (0x9C3)) with below code: Set the CnV value more than MOD register is to avoid the output compare be set during at start. After that,  enable FTM0 counter and toggle GPIO pin to set a mark: After delay, toggle GPIO pin and update CnV register to 0x270 (the match point is half of the PWM high voltage). The actual signal is : After the first CH0 output compare set match, before set CH0 pin clear on match. It need to keep the CH0 pin with same output compare mode and set CnV back to 0xA00 (more than MOD) again with below code: Then we set CH0 with clear on match mode and update CnV value to 0x752 (middle of CH1 PWM low voltage): The actual signal is: With the similar code, before next CH0 set on match, it need to keep the CH0 pin with same match compare mode setting and CnV change back to 0xA00 (more than MOD). The actual signal is below: Note: During the output compare signal compare mode set/clear change phase, it need to keep previous output compare mode setting, please don't using kFTM_NoOutputSignal setting at code. Otherwise, the output compare signal will exist decay: Test Result: From FTM0 register value, the FTM0_SYNCONF[SWRSTCNT] bit is clear, which means select Legacy PWM synchronization method. The legacy PWM synchronization method will update Output Compare mode CnV register value at the next FTM counter change. The actual signal also verify it. Below is FTM0 all registers value: For the more detailed info, please check the original thread at here. Please check attachment about test code.

Please note that the document shown above is an approximation of the original document.

Hi community!! The following example uses a PIT to start an adc conversion, once the conversion has finished it issues a DMA request and the DMA controller stores the converted value in a buffer. The examples were implemented in both CodeWarrior 10.6 and KDS 1.1 for every board. The recommended test circuit is the following: Please feel free to modify the files, I hope this examples will be useful for you and will help you by decreasing your development time. Best Regards Manuel Rodríguez Technical Information Center Intern

Hi All Kinetis Lovers, Microcontroller programming is a passion for all we are following this Community, but sometimes, trying to understand the peripherals of a Microcontroller is not an easy task, especially if we are in our first approach to a new module or device. In this post you will find a document that explains in detail the DMA module for Kinetis devices and also some examples for CodeWarrior and Kinetis Design Studio using DMA and other peripherals. The Documentation found here is: Using DMA module in Kinetis devices (complete): Document that includes DMA module explanation: everything you need to know when using DMA and the necessary information to understand the code included (K20_DMA for CW or K20D72_DMA for KDS). Using DMA module in Kinetis devices (example): Document that includes the necessary information to understand the code included (K20_DMA for CW or K20D72_DMA for KDS). Attached are two folders named: DMA examples for CW: include the DMA example projects for CW DMA examples for KDS: include the DMA example projects for KDS. Each folder includes 5 examples that are: Please feel free to modify the examples; I hope this will be useful for you. Many thanks and credits to manuelrodriguez for his valuable help developing and editing this project. :smileyinfo:For the SPI examples it is necessary to make a bridge between MOSI and MISO pins (master loop mode is used for the example). For this the TWR Elevators were used.     In the attachments you can find some extra information when using SPI and DMA. Best Regards, Adrian Sanchez Cano Technical Support Engineer

    作者 Shaozhong Liang     YAFFS（Yet Another Flash File System）文件系统是专门针对NAND闪存设计的嵌入式文件系统。在YAFFS中，文件是以固定大小的数据块进行存储的，块的大小可以是512字节、1024字节或者2048字节。这种实现依赖于它能够将一个数据块头和每个数据块关联起来。每个文件（包括目录）都有一个数据块头与之相对应，数据块头中保存了ECC(Error Correction Code)和文件系统的组织信息，用于错误检测和坏块处理。     YAFFS在文件进行改写时总是先写入新的数据块，然后删除旧的数据块，这样即使意外掉电，丢失的也只是这一次修改数据的最小写入单位，从而实现了掉电保护，保证了数据完整性。 YAFFS是为NAND FLASH设计的，它作了以下的假设或定义。     NAND Flash是基于块(block）的，每一个Block大小相同，由整数个chunk组成。每一个Block可单独擦除。一页(page，或chunk）为Flash的分配单元。所有的访问（读或者写）都是基于页（或chunk）的。     当对NAND Flash编程时，只有二进制中的0被编程，而1则“不关心”。比如，一个字节包含的二进制数为1010，那么当编程1001，会导致这两个数的位与操作。结果为1000.这和NOR FLASH不同。     YAFFS 分别用块号和 chunk id 标示块和 chunk 。它将空块（填满0xFF）当作空闲块或者已擦除块。这样，格式化一个YAFFS分区等价于擦除所有未损坏的块。 因此YAFFS最少需要一些函数能够擦除块，读一个页，写一个页。 1. 直接接口(Direct Interface)的相关文件     仅需要提取少量文件。使用yaffs的直接接口，你不需要所有的文件。你实际需要的文件列在下面，其余文件不需要编译。 direct/yaffsfs.c yaffs_guts.c direct/yaffscfg.c yaffs_nand.c yaffs_tagsvalidity.c yaffs_checkptrw.c yaffs_qsort.c yaffs_tagscompat.c yaffs_ecc.c yaffs_packedtags2.c 2. YAFFS  存储设备     YAFFS对文件系统上的所有内容（比如正常文件，目录，链接，设备文件等等）都统一当作文件来处理，每个文件都有一个页面专门存放文件头，文件头保存了文件的模式、所有者id、组id、长度、文件名、Parent Object ID等信息。因为需要在一页内放下这些内容，所以对文件名的长度，符号链接对象的路径名等长度都有限制。前面说到对于NAND FLASH上的每一页数据，都有额外的空间用来存储附加信息，通常NAND驱动只使用了这些空间的一部分，YAFFS正是利用了这部分空间中剩余的部分来存储文件系统相关的内容。以512+16B为一个PAGE的NAND FLASH芯片为例,Yaffs文件系统数据的存储布局如下所示： 0 to 511 数据区域 512 to 515 YAFFS TAG 516 Data status byte 517 Block status byte 坏块标志位 518 to 519 YAFFS TAG 520 to 522 后256字节数据的ECC校验结果 523 to 524 YAFFS TAG 525 to 527 前256字节数据的ECC校验结果     可以看到在这里YAFFS一共使用了8个BYTE用来存放文件系统相关的信息（yaffs_Tags）。这8个Byte的具体使用情况按顺序如下： Bits Content 20 ChunkID，该page在一个文件内的索引号，所以文件大小被限制在2^20 PAGE 即512Mb 2 2 bits serial number 10 ByteCount 该page内的有效字节数 18 ObjectID 对象ID号，用来唯一标示一个文件 12 Ecc, Yaffs_Tags本身的ECC校验和 2 Unused     其中Serial Number在文件系统创建时都为0，以后每次写具有同一ObjectID和ChunkID的page的时候都加一，因为YAFFS在更新一个PAGE的时候总是在一个新的物理Page上写入数据，再将原先的物理Page删除，所以该serial number可以在断电等特殊情况下，当新的page已经写入但老的page还没有被删除的时候用来识别正确的Page，保证数据的正确性。 ObjectID号为18bit，所以文件的总数限制在256K即26万个左右。     由于文件系统的基本组织信息保存在页面的备份空间中，因此，在文件系统加载时只需要扫描各个页面的备份空间，即可建立起整个文件系统的结构，而不需要像JFFS1/2 那样扫描整个介质，从而大大加快了文件系统的加载速度。     一个YAFFS设备是一个逻辑设备，它代表了一个物理设备的部分或整体。你可以认为它是一个Nand上的一个“分区”。比如，该分区可能覆盖整个NAND，也许只是一半，而另外一半就是另一个Yaffs_Device.它也可以用于你使用一个非flash设备（比如RAM）来测试的情况下。 一个Yaffs_Device记录了起始和结束块。通过改变它的起始和结束块，你就可以在同一个物理设备上使用不止一个的Yaffs_Device。 这里将需要你自己建立的Yaffs_Device结构的数据域列出，其他数据域由Yaffs自动创建。 int nDataBytesPerChunk     如其名，这是每一个chunk的字节数，还记得吧，在yaffs术语中，一个页就是一个chunk，因而它也是一页的字节数。它是数据字节数，即不包含OOB的数据。比如一页时2048字节+64字节的OOB，那么数值nDataBytesPerChunk为2048。 int nChunksPerBlock     物理Nand设备中每页包含的chunk（就是Nand上的页）的数目，最少是2。 int spareBytesPerChunk     空闲域（spare area）大小，比如：每个chunk（页）的OOB字节数。 int startBlock     该逻辑Yaffs_Device设备第一个块的块号（而字节地址），注意，yaffs需要第一个块是空闲的，因此你不可以设置该变量为0，如果设置为0，Yaffs会给它加1，并且会在结束块号上也加1，在你设置设备从块0开始，到最后一个块结束，这意味着yaffs试图写一个不存在的块，从而出现错误。 int endBlock     该逻辑Yaffs_Device设备的最后一个块号。如果startBlock为0，那么yaffs会使用endBlock+1，至少使startBlock+nReservedBlocks+2 int nReservedBlocks     这是YAFFS必须保留，用于垃圾回收和块错误恢复的可擦除块的数目。至少是2，但是5更好。如果你使用一个不会损坏的介质，比如RAM或者RAM盘，或者主机文件系统模拟，那么可以是2。 int nShortOpCaches     配置当前设备YAFFS Cache项的数目。0值表示不使用cache。对于大多数系统，推荐使用10到20之间的一个数值。不能大于YAFFS_MAX_SHORT_OP_CACHES定义的数值。 int useNANDECC     这是一个标志，用于指示是由yaffs执行ECC计算，还是由NAND驱动程序来执行ECC计算。（译者注：此数值取0，则使用yaffs来执行ECC计算，软件ECC计算。如果想要使用硬件ECC校验时，应该设置为1，并且在NAND驱动程序中加入硬件ECC校验的代码。） void *genericDevice     这是一个指针，它应该指向任何数据，底层NAND驱动程序需要知道以从物理设备读、写。 int isYaffs2     我们使用的是否YAFFS2版本？ int inbandTags     是否为OOB区，如果不是，那么它为真，仅用于yaffs2 u32 totalBytesPerChunk     这个名字可能有点误导人，它应该等于nDataBytesPerChunk ，而非其名字暗示的nDataBytesPerChunk + spareBytesPerChunk。如果inbandTags为真，那么yaffs设置nDataBytesPerChunk，因此有足够的空闲空间存储数据，yaffs会在空闲域中正常存储。 write/readChunkWithTagsFromNAND, markNANDBlockBad queryNANDBlock 这些都是函数指针，你需要提供这些函数来给YAFFS，读写nand flash。 3.NAND Flash 访问函数 int (*writeChunkWithTagsToNAND) (struct yaffs_DeviceStruct * dev, int chunkInNAND, const u8 * data, const yaffs_ExtendedTags * tags);   dev: 要写入的yaffs_Device逻辑设备. chunkInNAND: 将chunk写入的页 Data: 指向需要写入的数据的指针 tags: 未压缩（打包）的OOB数据 Return: YAFFS_OK / YAFFS_FAIL 该函数将页（chunk）写入nand中，向nand中写入数据。数据和标签（tags）永远不应为 NULL. chunkInNand 是将要写入的页的页号，而不是需要转换的地址。 int (*readChunkWithTagsFromNAND) (struct yaffs_DeviceStruct * dev, int chunkInNAND, u8 * data, yaffs_ExtendedTags * tags);  dev: 要写入的yaffs_Device逻辑设备. chunkInNAND: 将chunk读入的页 Data: 指向需要读入的数据的缓冲区指针 tags: 指向未压缩（打包）的OOB数据的缓冲区指针 Return: YAFFS_OK / YAFFS_FAIL 该函数执行上一个函数的相反的功能，首先，读取数据和OOB字节，接着将这些输入放在一个由参数data指向的缓冲区中 int (*markNANDBlockBad) (struct yaffs_DeviceStruct * dev, int blockNo);   dev: 要写入的yaffs_Device逻辑设备. blockNo: 要标记的块. Return: YAFFS_OK / YAFFS_FAIL int (*queryNANDBlock) (struct yaffs_DeviceStruct * dev, int blockNo, yaffs_BlockState * state, u32 *sequenceNumber);   dev: 要写入的Yaffs_Device逻辑设备. blockNo: 要标记的块. state: Upon returning this should be set to the relevant state of this particular block. Sequance number: 该块的顺序号（The Sequence number），为0表示此块未使用 Return: YAFFS_OK / YAFFS_FAIL     它应检查一个块是否是有效的。如果在OOB中设置了坏块标记，那么*state应该被赋值为YAFFS_BLOCK_STATE_DEAD，*sequenceNumber赋值为0，然后返回YAFFS_FAIL。     如果该块没坏，那么应解压缩标签。标签解压缩后，若发现chunk已使用(查看tags.chunkUsed),则*sequenceNumber应赋值为tags.sequenceNumber，*state赋值为YAFFS_BLOCK_STATE_NEEDS_SCANNING，否则该块未使用，则*sequenceNumber赋值为0，*state赋值为YAFFS_BLOCK_STATE_EMPTY 4. YAFFS的缓存机制     由于NandFlash是有一定的读写次数的，所以在对一个文件进行操作的时候往往是先通过缓冲进行，对最后一次性写入NandFlash，这有效的减少了用户对NandFlash的频繁操作，延长了NandFlash的寿命。下面大致说一下YAFFS的缓存机制： 4.1.首先在yaffs_mount的时候会对yaffs_dev这个结构体进行注册，和缓冲部分相关的有： dev->nShortOpCaches//这个变量决定了有多少个缓冲，因为缓冲会大量的占用堆栈的空间，所以在yaffs不建议缓冲的数量很大，即使你填一个很大的数，系统也不会超过YAFFS_MAX_SHORT_OP_CACHES的总数。 yaffs_ChunkCache *srCache;//缓冲区的首地址，dev->srCache = YMALLOC( dev->nShortOpCaches * sizeof(yaffs_ChunkCache));下面介绍一下缓冲区这个结构体的组成： typedef struct { struct yaffs_ObjectStruct *object;//一个缓冲区对应一个文件 int chunkId; int lastUse; //通过lastUse来 int dirty; //标志了这一个缓冲区是否被使用 int nBytes; __u8 data[YAFFS_BYTES_PER_CHUNK];//数据区 } yaffs_ChunkCache; 4.2.什么时候用到缓冲区？        用到缓冲区最多的地方显而易见是对已经创建的文件进行写操作。而且是需要写的大小和512不一致的时候，这是因为如果是刚好512的话，系统会直接写入NandFlash中。对于小于512的系统首先会调用yaffs_FindChunkCache(in,chunk)这个函数来判断in这个object是否在缓冲区中存在。如果存在会调用已有缓冲区进行操作。当然如果是第一次对一个object进行操作，肯定在缓冲区中是不存在对应它的空间的，因此系统会调用yaffs_GrabChunkCache函数为此次操作分配一个缓冲区。 5. 应用层接口     YAFFS为连接的应用程序提供了一组函数。大部分跟标准C库函数,如open/close一致，只是增加了yaffs_前缀，如 yaffs_open. 这些函数定义在direct/yaffsfs.h中。     初始化yaffs来完成读写，你必须在每个你要使用的yaffs设备上调用yaffs_mount。比如yaffs_mount(”/boot”)。这可以在系统启动的时候执行，如果存在一个操作系统，那么程序需要考虑这点。在你完成使用的时候，你也需要调用yaffs_umount函数，这样yaffs就会将它需要状态写入磁盘。 如果读写文件的应用层接口已经存在，你可以根据相关的操作系统调用来封装相关的函数调用。 1 yaffs_mount( ) 功能说明：加载指定器件。 输入参数：path    要加载的器件。 输出参数：无。 返回值： 表明加载的状态。 调用的函数：yaffsfs_FindDevice( )、yaffs_GutsInitialise( )。 2 yaffs_open( ) 功能说明：按照指定方式打开文件。 输入参数：path    文件的绝对路径；           Oflag   打开的方式；           Mode    文件许可模式。 输出参数：无。 返回值：句柄。 调用的函数：yaffsfs_GetHandle( )、yaffsfs_FindDirectory( )、yaffs_MknodFile( )、yaffsfs_PutHandle( )、yaffs_ResizeFile( )、yaffsfs_FindObject( )。 3 yaffs_write( ) 功能说明：根据打开文件的句柄，从指定数组处读指定字节写入文件中。 输入参数：fd      要写入的文件的句柄；           Buf     要写入的数据的首地址；           Nbyte   要写入的字节数。 输出参数：无。 返回值： 写入了的字节数。 调用的函数：yaffs_WriteDataToFile( )、yaffsfs_GetHandlePointer( )、yaffsfs_GetHandleObject( ) 4 yaffs_read( ) 功能说明：根据打开文件的句柄，从文件中读出指定字节数据存入指定地址。 输入参数：fd       要读出的文件的句柄；           Buf      读出文件后要存入的数据的首地址；           Nbyte    要读出的字节数。 输出参数：无。 返回值： 读出了的字节数。 调用的函数：yaffs_ReadDataFromFile( )、yaffsfs_GetHandlePointer( ) 5 yaffs_close( ) 功能说明：关闭已经打开的文件句柄，yaffs 有缓冲机制，当调用yaffs_close()关闭文件之后能够保证将内容写入nandflash。 输入参数：fd    需要关闭的文件的句柄； 输出参数：无。 返回值：无。 6. YAFFS在MQX的应用案例     YAFFS提供了直接调用模式，可以方便移植到 none-OS或者light-weighted OS中。附件是将YAFFS移植到Freescale MQX实时操作系统的源代码和工程，可以在II型集中器的Demo Board上运行。     初步的测试表明YAFFS工作正常，能够完成创建目录，创建/删除文件，读/写文件操作等。 YAFFS非常适合none-OS或者是light-weighted OS，使用YAFFS需要关注的是RAM的消耗，适合小量文件(<20)。 如果不想使用MQX默认的MFS(FAT32文件系统)，YAFFS可以作为一个文件系统的备选方案。

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

       上篇详细的介绍了加密锁定Kinetis的一种方法，本篇再接再厉，给大家再介绍一种加密方法（哎，这点家底都晒出来了）。当然实际上原理还是不变的，即还是通过修改0x400~0x40F地址段的内容来实现加密锁定，万变不离其宗，所谓殊途同归罢了，下面好戏登台：        既然实现security最终都是改写寄存器加载段flash地址的内容，那实际上修改flash内容的方式还是灵活多变的，方案一中提到的在中断向量表的最后添加flash配置信息只是其中一种，那还有哪些呢？还是不摆谱了，小心被拍砖，哈哈。不错，那就是通过在指定地址定义常量的方法，当然定义常量大家都会用到（有些应用譬如LCD显示的字模或者一些固定的查找表为节省RAM空间我们一般会选择定义const常量的方法将它们存放到flash空间中），但是指定地址的存放方式用的会少些（一般都是让编译器自动分配的），如果我们非要指定地址呢（哎，强迫症又开始了，呵呵），即将flash配置信息作为常量强制指定存放到0x400起始的地址，那岂不是跟方案一有了异曲同工之妙了，好吧，这样的话那就该“@”这位老兄上场了（咳咳，可不是给单片机发email啊，呵呵），相信很多人到此处就都明白了。下面我仍然以IAR环境下锁定K60为例，简单介绍下方案二的使用步骤： 1. 打开待加密工程中的main.c文件，在其中的main函数之前以添加如下图所示常量定义，即将FlashConfig数据组数据存放到“.flashConfig”段中，其中FlashConfig[11]即为0x40C地址： 2. 至于这个.flashConfig段属性是需要在与该工程匹配的IAR连接文件（.icf文件）中人为添加定义的，如下图所示，需要添加三个部分，然后保存： 3. 前两步完成之后，其实需要添加的部分就已经完成了，但是还有特别重要的两点需要注意，这里我加红注释一下，如下： （1）采用方案二的情况，需要确保vectors.c中中断向量表最后的16个字节没有被添加，即不能有4个CONIFG_x配置信息的，否则会出现编译错误，因为这就涉及到两者冲突的问题，也就是说在采用方案一的话就不能采用方案二，同理，采用方案二的话也不能采用方案一，总之两者不能同存； （2）还需要考虑编译器优化的问题，因为我们在.flashConfig段定义了常量，但是在代码程序里却没有使用它，这种情况下编译器会直接把这段常量优化掉，所以我们做的工作算是白做了，即使我们在IAR的优化等级中设置成low或者none都不行，因为人家编译器认死理儿，反正你也没有使用它，我就是怕它pass掉，这下子伤心了，呵呵。还好IAR给我们留了条后路，在options->Linker->Input选项卡中提供了Keep symbol功能，如下图，将FlashConfig添加进去即可强制编译不优化它，这样目的就达到了，呵呵，看来还是天无绝人之路啊有木有。 3. 编译通过，下载调试，程序下载之后同样会出现进入不到调试窗口的现象，这个是正常现象，因为这个时候芯片就已经被security了，这样就可以放心量产了，呵呵~       希望这两篇系列文章能对大家有所帮助，enjoy it~

The Kinetis K70 MCU family includes 512KB-1MB of flash memory, a single precision floating point unit, Graphic LCD Controller, IEEE 1588 Ethernet, full- and high-speed USB 2.0 On-The-Go with device charge detect, hardware encryption, tamper detection capabilities and a NAND flash controller. 256-pin devices include a DRAM controller for system expansion. The Kinetis K70 family is available in 196 and 256 pin MAPBGA packages. For more information visit www.freescale.com/kinetis

           This is a demo of NFC device to read and write the contactless card. Kinets K60 tower board and NXP PN512 board are used for this test enviroment. These connected pins from K60 tower board to PN512 RF board are listed as below:   SPI1:     SPI1_SIN : PTE1/SDHC0_D0     SPI1_SCK : PTE2/SDHC0_DCLK     SPI1_SOUT : PTE3/SDHC0_CMD     SPI1_PCS0 : PTE4/SDHC0_D3     Reset:     PTB9   External interrupt:     PTA26         Because the SPI1 port is used as the host interface of pn512, it is necessary to enable the SPI1 driver in the user configuration file of MQX.           To open the project file in the /build folder with CW10.5.    And the PSP and BSP libraries had to be built before test image is built, as they are needed in this test project.   The following diagram shows the serial numbers and block data of reading from the test card of Mifare one.

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

Hello Kinetis fans, This time I bring to you a document which explains what is and how to configure scatter/gather feature which is present in the Enhanced Direct Memory Access (eDMA). This document includes an example project for the Kinetis Design Studio (KDS) which works in the FRDM-K64F board but the configuration is the same for any MCU which includes the eDMA peripheral. If you are interested in the channel linking feature, please take a look into the document What is and how to configure the eDMA channel linking feature​. I hope you find this document useful. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

for M68HC08, HCS08, ColdFire and Kinetis MCUs by: Pavel Lajsner, Pavel Krenek, Petr Gargulak Freescale Czech System Center Roznov p.R., Czech Republic The developer's serial bootloader offers to user easiest possible way how to update existing firmware on most of Freescale microcontrollers in-circuit. In-circuit programming is not intended to replace any of debuging and developing tool but it serves only as simple option of embedded system reprograming via serial asynchronous port or USB. The developer’s serial bootloader supported microcotrollers includes 8-bit families HC08, HCS08 and 32-bit families ColdFire, Kinetis. New Kinetis families include support for K series and L series. This application note is for embedded-software developers interested in alternative reprogramming tools. Because of its ability to modify MCU memory in-circuit, the serial bootloader is a utility that may be useful in developing applications. The developer’s serial bootloader is a complementary utility for either demo purposes or applications originally developed using MMDS and requiring minor modifications to be done in-circuit. The serial bootloader offers a zero-cost solution to applications already equipped with a serial interface and SCI pins available on a connector. This document also describes other programming techniques: FLASH reprogramming using ROM routines Simple software SCI Software for USB (HC08JW, HCS08JM and MCF51JM MCUs) Use of the internal clock generator PLL clock programming EEPROM programming (AS/AZ HC08 families) CRC protection of serial protocol option NOTE: QUICK LINKS The Master applications user guides: Section 10, Master applications user guides. The description of Kinetis version of protocol including the changes in user application: Section 7, FC Protocol, Version 5, Kinetis. The quick start guide how to modify the user Kinetis application to be ready for AN2295 bootloader: Section 7.8, Quick guide: How to prepare the user Kinetis application for AN2295 bootloader. Full application note and  software attached.

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

Introduction Even with the prevalence of universal asynchronous receiver/transmitter (UART) peripherals on microcontrollers (MCUs), bit banged UART algorithms are still used.  The reasons for this vary from application to application.  Sometimes it is simply because more UARTs are needed than the selected device provides.  Maybe application or layout restrictions require certain pins to be used for the UART functions but the device does not route UART pins to the required package pins.  Maybe the application requires a non-standard or proprietary UART scheme. Whatever the reason, there are applications where a bit banged UART is used and is typically a pure software implementation (a timer is used and the MCU core controls a GPIO pin directly).  A better alternative may be to use Flextimer (FTM) or Timer/PWM Module (TPM) to take advantage of the features of these peripherals and possibly offload the CPU.  This document will explain and provide a sample application of how to emulate a UART using the FTM or TPM peripheral.  A Kinetis SDK example (for the TWR-K22F120M and FRDM-K22F platforms) and a baremetal legacy code example (for the FRDM-KL26Z) are provided here. UART protocol Before creating an application to emulate a UART, the UART protocol and encoding must be understood. The UART protocol is an asynchronous protocol that typically includes a start bit, payload (of 7-10 data bits), and a stop bit but does allow for many variations on the number of stop bits and what/how to transfer the data.  For this document and application example, the focus will be UART transmission that follows 1 start bit, 8 data bits, 1 stop bit, no parity, and no flow control.  The data will be transmitted least significant bit (LSB) first.  The following image is a block diagram of this transmission. However, this doesn't specify what the transmission looks like electrically. The figure below shows a screenshot of an oscilloscope capture of a UART transmission.  The data transmitted is 0x55 or a "U" in the ASCII representation. Notice that the transmission line is initially a logic high, and then transitions low to signal the start of the transmission.  The transmission line must stay low for one bit width for the receiver to detect it.  Then there are 8 data bits, followed by 1 stop bit.  In the case shown above, the data bits are 0x55 or 0b0101_0101.  Remember that the transmissions are sent LSB first, so the screenshot shows 1-0-1-0-1-0-1-0.  The last transition high marks the beginning of the stop bit and the line remains in that state until the start of the next transmission.  The receiver, being asynchronous, does not require any type of identifying transition to mark the end of the stop bit. FTM/TPM configuration The first question many may ask when beginning a project like this is "How do I configure the FTM/TPM when emulating a UART".  The answer to this depends on the aspect of this problem you are trying to solve.  Transmitting and receiving characters require two different configurations.  Transmission requires a configuration that manipulates the output pin at specific points in time.  Receiving characters requires a configuration that samples the receive pin and measures the time between pin transitions.  The FTM and TPM have the modes listed in the following table: The FTM and TPM have four different modes that manipulate an output:  Output compare (no pulse), Output compare (with pulse), Edge-aligned PWM, and Center-aligned PWM.  Neither PWM mode is ideal for the requirements of the application.  This is because the PWM modes are designed to produce a continuous waveform and are always going to return to the initialized state once during the cycle of the waveform.  However, the UART protocol may have continuous 1's or 0's in the data without pin transitions between them. The output compare mode (high-true or low-true pulse modes) is designed to only manipulate the pin once, and only produces pulses that are one FTM/TPM clock cycle in duration.  So this is obviously not desirable for the application.  The output compare mode (Set/Clear/Toggle on match) is promising.  This mode manipulates the output pin every cycle.  There are three different options:  clear output on match, set output on match, and toggle output on match.  Neither "clear output on match" nor "set output on match" are ideal as either would require configuration changes during the transmission of a character.  The "toggle output on match", however, can be used and is the selected configuration mode for this sample application. To receive characters, there is only one mode that is intuitive:  "the input capture mode".  This mode records the timer count value on an edge transition of the selected input pin.  Similar to the output compare mode chosen for the transmit functionality, the input capture mode has three sub-modes:  capture on rising edge, capture of falling edge, and capture on either edge.  It is clear from the descriptions that capture on either edge should be selected. Transmit encoding The selection of the FTM/TPM mode is moderately intuitive, but using this mode to emulate a UART transmission is not.  There are two issues that make this a little tricky. 1) The output pin is initialized low. However, the UART protocol needs the pin to begin in a logical high state. 2) The pin transitions on every cycle provided the channel value is less than the value of the MOD register. Due to continuous strings of 1's or 0's, it is necessary to have periods where the pin does not transition. Both of these points have workarounds. Output pin initialization For the first issue, the channel interrupt is first enabled and the channel value register is loaded with a value much less than the value in the MOD register.  Then in the channel interrupt service routine, the pin is sampled to ensure that it is in the logic high state and the channel interrupt is disabled (and will not be re-enabled throughout the life of the application).  The code for this interrupt service routine is as follows. Output pin control For the second issue, a method of not transitioning the pin value while allowing the timer to continue counting normally is necessary.  The Output Compare mode uses the channel value register to determine when the pin transition occurs.  If a value greater than MOD is written to the channel value register, the channel value will never match the count register and thus, a pin transition will never occur.  So, when a series of continuous 1's or 0's need to be transmitted, a value greater than the value in the MOD register can be written to the channel value register to keep the output pin in its current state. However, when a value greater than MOD is written to the channel value register, no channel match will occur (which means channel interrupts will not occur).  So the timer overflow interrupt must be used to continue writing values.  This requires the updates to be output pin to be planned ahead of time and makes the transmission algorithm a little tricky.  The following diagram displays when which values should be written to the channel value register at which points in time to generate the appropriate pulses. Writing a function to translate a number into the appropriate series of MOD/2 and MOD+1 values can be a little tricky. To do this, we must first notice that MOD/2 needs to be written when changes on the transmission pin are need and MOD+1 needs to be written when pin transmissions are not desired.   So, what logical function can we use to determine when a change has happened?  XOR is the correct answer.  So what two values need to be XOR'd together?  One value is obviously the value that we want to send.  But what is the second value?  It turns out that the second value is a shifted version of the value that we want to send.  Specifically, the second value is the desired value to send shifted to the left by one.  (You can think of it as sort of a "future" value of the desired value).  The following pictures show how to determine the queue to use for the transmission. Receive decoding The receive functionality has an advantage over the transmit functions in that it is possible to use DMA for the reception of characters.  This is because the receive function takes advantage of the input capture functionality of the FTM / TPM and therefore can use the channel match interrupt.  The example application provided with this document implements a DMA method and a non-DMA method for reception. First, the non-DMA method will be discussed. Before discussing the specifics of gathering the input pulse widths, some details of the receive pin need to be discussed. Detecting the start bit The receive pin needs to be able to determine when the start of the packet transmission begins.  To do this, the receive pin is configured as an FTM / TPM pin. At the same time, the GPIO interrupt functionality is configured on the same pin for a falling edge interrupt.  The GPIO interrupt capabilities are enabled in any digital mode, so the GPIO interrupt will still be able to be routed to the Nested Vector Interrupt Controller (NVIC).  The pin interrupt is used to start the FTM / TPM clock when a new character reception begins. In the GPIO interrupt for this pin, the FTM / TPM counter register is reset and the clock to the FTM / TPM is turned on.  The code for the GPIO interrupt service routine is shown below.  Receiving characters without DMA Now, when receiving characters and not using DMA, the first thing to understand is that the Interrupt Service Routine (ISR) will be used and it will mainly be used to record the captured count values.  The interrupt service routine also tracks the current receive character length and resets the counter register.  This is so that the values in the receive queue reflect the time since the last pin transition.  The interrupt function for the non-DMA application is shown below. Notice that the first two actions in the ISR are resetting the count register, and clearing the channel event interrupt flag.  Then the channel value is stored in the receive pulse width array (this is simply an array that holds the receive pulse widths of the current character being received).  Next, recvQueueLength, the variable which holds the current length of the character being received, is updated to reflect the latest character length.  The next step is to determine if the full character has been received.  This is determined by comparing recvQueueLength to the RECV_QUEUE_THRESH, which is the threshold as determined by multiplying the number of expected bits by the expected bit width plus another bit width (for the start bit).  If the recvQueueLength is greater than the RECV_QUEUE_THRESH, then a semaphore is set, recvdChar, to indicate that a full character has been received.  The FTM / TPM clock is turned off, and the pin interrupt functionality of the receive pin is enabled.  The final step in the interrupt routine is to increment the receive queue index, recvQueueIndex.  This variable points to the current entry in the receive queue array. Using DMA to receive characters When using DMA, the receive FTM / TPM interrupt is much different. The interrupt routine simply needs to clear the channel interrupt flag, stop the FTM / TPM timer, disable the DMA channel, and set the received character semaphore.  The character is then decoded outside of the interrupt routine.  The interrupt function when using DMA is shown below: Decoding the received pulse widths Once the array of pulse widths has been populated, the received character needs to be translated into a single number.  This varies slightly when using DMA and when not using DMA. However, the basic principle is the same.  The number of bits in a single entry is determined by dividing by the expected bit width and this is translated into a temporary array that contains 1's and 0's, and then that is used to shift in the appropriate number of 1's and 0's into the returned char variable.  A temporary array is needed because the values are shifted into the UART LSB first, so the bit must be physically flipped from the first entry to the last.  There is no logical operation that will do this automatically. The algorithm to perform this translation is shown below.  In this algorithm, note that recvPulseWidth is the array that contains the raw count value of the pulse width.  The array tempRxChar holds the decoded character in reverse order and rxChar is a char variable that holds the received character. Conclusion This document provides an overview of the UART protocol and describes a method for creating a software UART using the timing features of the FTM or TPM peripheral.  This method allows for accurate timing and while not relying entirely on the CPU and the latency associated with the interrupt and the GPIO pins.  The receive function is open to further optimization by using DMA, which can provide further unloading of the CPU.

For Remote Control means, that is needed two computers - Server Computer and User Computer, which will be in connection. There are two types of connection, which can be used - HTTP or DCOM. There are two different ways how to set up the remote control in Windows. I made the tutorial, which describes both types of Remote Control. Ok - so, let´s start! HTTP Settings On the Server Computer side: 1. Plug the board to the Server Computer 2. Go to Remote Communication Server 3. Set HTTP connection and choose the right COM Port according the plugged board If the plugged board is on e.g. COM23, it is possible to edit number of Port in Device Manager On the User PC side: 1. Open FreeMASTER,  go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (HTTP) and type the IP address of the server, do not forget join to IP address :8080 3. And start communication by STOP button to successful connection DCOM Settings On the Server Computer side: 1. Plug board to the Server Computer 2. Launch DCOM in FreeMASTER Remote Server Choose COM according plugged board or edit COM according to step 2 - Server Computer in HTTP Connection (up). 3. Setting permissions for the user, User PC. Right click on Computer -> Manage. In Computer Management click to Distributed COM Users. In Distributed COM Users Properties add the user, User Computer. After that, set the permissions in Component Services. In cmd type dcomcnfg.exe In Component Services go to Computers -> My Computer -> DCOM Config -> MCB FreeMASTER Remote Server Application Right click on MCB FreeMASTER Remote Server Application and go to Properties. In Security Tab is possible to add the permissions. There are 3 types of permissions. First permission - Launch and Activation Permissions. There are 4 permission options. Local Launch and Remote Launch means, that user, User Computer can launch e.g. FM Remote Server Application. But for success communication is needed allowing Local Activation and Remote Activation. Second permission - Access Permissions. Click to Edit and Allow Local Access and Remote Access for the user. Do not forget that if there is a change of permissions, specifically allowing, it is necessary for User to log out and log in. On the User Computer side: 1. Open Freemaster, go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (DCOM) and for filling Connect string is possible to use Configure. Definitely, type the IP address of the server and ;Port Name. 3. And start communication by STOP button in FreeMASTER to successful connection And now.. you can do anything 🙂

The attached zip file contains software that accompanies the document UART Emulation Using the FTM or TPM.  It contains two sample applications:  one that uses the TPM, and one that uses the FTM. The TPM example targets the FRDM-KL26Z development board and is written in baremetal code.  The FTM example targets the TWR-K22F120M and FRDM-K22F and is written using the Kinetis SDK 1.0 release.  Installation instructions are contained within the zip package. Unzip the package to an empty folder and then copy the appropriate folders to the the appropriate locations on your PC per the instructions located in the zip file.