This example shows a FRDM-KL46Z interfacing with a Bluetooth-serial board BT_BOARD V1.05, it uses FREEMASTER to graph temperature and light sensor variables. Check how to connect, configure Bluetooth, and freemaster in attached document FRDM-KL46Z-Bluetooth-Freemaster.zip contains                            srec file                            firmware                            fremaster project (.pmp) Luis

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.

Table of Contents 1       Introduction 2       DMA to emulate ADC Flexible Scan. 2.1         System overview and flow diagram for Flexscan. 3       SDK implementation. 3.1         ADC configuration. 3.2         LPMTR configuration 3.3         DMA configuration 4       ADC Flex Scan mode with DMA Appendix A: Requirements Reference   1    Introduction This document describes how to combine ADC, DMA and a timer to implement a ADC Flexible storing data with SDK 2.2 and MCUXpresso IDE. In this configuration ADC measures will be stored into an internal memory buffer with DMA, which imply, no CPU. With this configuration MCU uses less resources, only using ADC and DMA (2 channels) and a timer to trigger conversions. This way, the MCU does not need to read the ADC result register, because the memory management will be done by DMA automatically.   To implement this application we will use SDK libraries, which includes ADC and DMA libraries. The timer used to trigger ADC conversion will be the LPTMR. MCUXpresso IDE will be used as development environment, please check Appendix A to look where you can download SDK libraries and IDE. The project will be created from scratch, regardless of this, MCUXpresso IDE and SDK libraries allows us to create a project with some headers and libraries in the project, if you have problems creating a new project in MCUXpresso please check Reference 4.   In this document we will use the FRDM-K64F which is an ultra-low-cost development platform, but this implementation could be easily migrated to any kinetis family that support second-generation eDMA module (enhanced Direct Memory Access).   This document is an update of the community doc: Using DMA to Emulate ADC Flexible Scan Mode with KSDK  which uses old SDK libraries.   2     DMA to emulate ADC Flexible Scan   Flexible scan implementation needs 2 types of data movement: ADC measures (from peripheral to internal memory) and ADC mux change (from internal memory to peripheral). Second one is needed to change ADC input channel and have the flexible implementation, first one save ADC measures in our internal memory.   DMA peripheral (for this MCU) includes up to 16 channels, for this application we will only use 2 channels, one for ADC measures and one for ADC muxing channel. It is important to remark that we will use the linking feature in these channels to implement the ADC changing channel automatically, later in this document it will be explain this feature.   2.1         System overview and flow diagram for Flexscan.   As already mentioned, this implementation will use one DMA channel to transfer data from ADC measures (ADC0_RA register in this case) to a memory buffer (named here as g_ADC0_resultBuffer), so follow figure shows this movement:     As you can see, ADC0_COCO (conversion complete) will be the one that request a transfer from ADC0_RA to resultBuffer. Once this transfer has completed, we need to change ADC channel, so when DMA channel 1 transfer finishes, it will indicate us to trigger the other data movement, in this case from internal buffer g_ADC_mux (that save our adc channels) to the ADC0_SC1A register that sets the ADC channel, so the following diagram shows this.     To do this, this application used a DMA feature that link DMA channels, channel-to-channel linking. So, when one DMA channel finished, the linked DMA channel will be triggered, in this case when DMA channel 1 has completed to move data from ADC measure register to internal memory then DMA channel 0 need to be triggered to change the ADC channel, so next conversion ADC would have selected other ADC channel.   Once that the ADC channels is changed (and the HW trigger happens), the COCO flag from ADC will trigger other DMA request in channel 0 and the process will start again. This flow process can be repeated as many channels as we have and as many samples as we want, for this example code we will measure 3 channels and have 4 samples, so the result buffer size is 3 × 4 = 12 (the real buffer size is 16, to demonstrate that only 12 data field parts are written).   The ADC works in hardware trigger mode, with the LPTMR timer working as the trigger source. This mean that even though DMA channel 0 changed the ADC input channel, conversion will not start until HW trigger (LPTMR) start the conversion, this mean that the flow of the program can be as follow.       In the example code provided, when DMA channel 0 has changed 3 times the ADC channel, DMA channel 1 major loop will happen, and when the sample X is the last sample (sample 4) of the last channel in muxbuffer, then Major loop in DMA channel 0 happens and the application ends (or it could start again). This mean that the application here can be shown as:             3     SDK implementation   Implementation of this code can be dived in three parts; LPTMR, ADC and DMA configuration.   3.1         ADC configuration       ADC configuration is a normal ADC config, with 12 single ended, Asynchronous clock source and Vref as reference voltage. Hardware trigger and DMA support are enable to trigger conversions with LPTMR and to be able to trigger a DMA request when COCO interrupt happen. In ADC channel configuration, it is enable Conversion completed interrupt and it is loaded the value of g_ADC_mux to channel number, this will be the first channel that LPTMR will trigger.   3.2         LPMTR configuration       LPMTR is a common configuration with LPTMR as time counter. Please notice that prescaler could be used and select a prescaler clock. To set LPTMR period it is used the macro USEC_TO_COUNT, which just take the value in microseconds and it calculate the number of ticks to count, using the source clock. Also at the end, LTPMR is configured to be used as HW trigger for ADC conversions in the SIM register.   3.3         DMA configuration     For DMAMUX configuration it is enable Channel 0 and 1 and it is selected the source trigger, DMA for channel 0 (it will be triggered with linking feature) and ADC COCO flag for channel 1 (trigger when the ADC conversion complete).     For DMA configuration, it is needed to create 2 tcd configuration, there are set in transferConfig_chx. First one defined is for DMA channel 1 (data from ADC measure to internal memory), and the second is for DMA channel 0 (data from internal memory to ADC_SC1 register to change ADC channel). Please noticed that these definitions are in bytes to transfer, so some of them are sizeof(uint16_t). Here is also the setup to link channel 1 to channel 0.       Finally, it is added the adjustment for TCD, so when DMA major loop finished in both, it will point to the start of the source and destination. Noticed that this is added just for internal memory address, this is because for the case of a peripheral (ADC in this case), pointer to address doesn’t change.   Then DMA channel 1 and LPTMR are started.   When DMA channels were initialized, their callbacks were also defined;     This flags are just used for this implementation and as reference, they can be removed if needed. After Major loop has finished, SDK implementation disable DMA transfers automatically, so noticed that the callback_1 for DMA channel 1 has a line commented, that if uncommented, this application will act as a ADC that load measurements in an internal Ring buffer Indefinitely.   4     ADC Flex Scan mode with DMA With a basic Print implementation of ADC results we can show the functionality of this example project.     There are obtained the following results,         Appendix A: Requirements Download page for MCUXpresso IDE: MCUXpresso IDE|NXP  Download page for SDK 2.x drivers: Welcome to MCUXpresso | MCUXpresso Config Tools  Go to Build an SDK, select your device and click on Specify Additional Configuration Settings, verify that you have selected KDS as toolchain and then Go to SDK Builder. Click in Download Now, accept Term and conditions and download SDK packet. Please check: Generating a downloadable MCUXpresso SDK v.2 package    References   Using DMA to Emulate ADC Flexible Scan Mode with KSDK  MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse  https://www.nxp.com/docs/en/application-note/AN4590.pdf  Creating New Projects using installed SDK Part Support, MCUXpresso_IDE_User_Guide.pdf  

Nested Vectored Interrupt Controller Module by Vicente Gómez Freescale TIC. NVIC Explanation Hands-on IRQ using a pin. Interruption timers. Presentación de la NVIC (Nested Vectored Interrupt Controller) por Vicente Gómez, Freescale TIC. Explicación de la NVIC. Hands-On IRQ usando un pin. Timers con interrupción

飞思卡尔拥有成套的电机控制处理器产品、强大的工具和专家支持，为大量应用提供高性价比且节能的电机控制解决方案，您可以在飞思卡尔官网电机控制主页上找到相应的电机控制参考方案。链接如下： http://www.freescale.com/zh-Hans/webapp/sps/site/homepage.jsp?code=MOTORCONTROLHOME 下文也列出BLDC和PMSM常用的控制参考方案，方便查询。 BLDC(无刷直流电机)参考设计 M0+方案 AN4776 - BLDC motor control with Hall sensor based on FRDM-KE02Z 附代码包AN4776SW AN4869 - 基于FRDM-KE04Z和Tower Board的BLDC电机正弦波控制 附代码包AN4869SW AN4796 - 基于FRDM-KE02Z和Tower Board的无传感器BLDC电机控制 附代码包AN4796SW AN4862 - 利用MKV10x实现三相BLDC无传感器控制   附代码包AN4862SW DRM144 - Three-phase BLDC sensorless motor control application AN4870 - Tuning 3-Phase BLDC motor sensorless control using MKV10  附代码包AN4870SW DRM151 - 采用Kinetis KEA128 MCU的3相无传感器BLDC电机控制参考设计 M4方案 AN4376 - 基于 kinetis 和 MQX 的带霍尔传感器的无刷直流电机控制 AN4254 - 在Freescale MQX实时操作系统下进行电机控制 DRM135 - 3-phase BLDC sensorless control with Kinetis MCU (MQX) 附代码包DRM135SW AN4597 - BLDC Sensorless Algorithm Tuning Three-Phase BLDC Sensorless Motor Control Using the MKV4x In Quadcopter Application 附代码包AN5169SW DSC方案 AN4413 - BLDC Motor Control with Hall Sensors Driven by DSC  附软件包AN4413SW AN1916 - 基于 56800/E 数字信号处理器和霍尔传感器的三相 BLDC电机控制 DRM025 - 3-Phase BLDC Motor Control with Hall Sensors Using 56F805 Designer DRM022 - 3-Phase BLDC Drive Control with Hall Sensors Reference Design AN1913 - 3-phase BLDC Motor Control with Sensorless Back-EMF ADC Zero Crossing Detection using DSP 56F80x AN1914 - 3-Phase BLDC Motor Control with Sensorless Back EMF Zero Crossing Detection Using DSP56F80x DRM108 - 采用 MC56F8006 的 BLDC 无传感器参考设计 DRM077 - PMSM and BLDC Sensorless Motor Control using the 56F8013 Device Designer DRM078 - 3-Phase BLDC Drive Using Variable DC Link Six-Step Inverter Designer DRM027 - 3-Phase Sensorless BLDC Motor Control with Back-EMF Zero Crossing Detection Using 56F805 Designer DRM098 - Direct PFC Using the MC56F8013 DRM070 - Three-Phase BLDC Motor Sensorless Control Using MC56F8013/23 Design DRM026 - 3-Phase BLDC Motor Control with Sensorless BACK-EMF ADC Zero Crossing Detection Using 56F805 AN1961 - 3-Phase BLDC Motor Control with Quadrature Encoder Using the 56F800/E PMSM(永磁同步电机)参考设计 M0+方案 AN5049 - Three-Phase PMSM Sensorless FOC Using the MKV10Z32 with Automated Motor Parameters Identification 附代码包AN5049SW AN4935 - 利用Kinetis KV10实现适用于风扇的PMSM无传感器磁场定向控制 (FOC)   附代码包AN4935SW DRM148 - 无位置PMSM矢量控制参考设计 M4方案 DRM128 - PMSM Vector Control with Quadrature Encoder on Kinetis AN4911 - 利用MKV31F实现三相PMSM无传感器FOC  附代码包AN4911SW AN5004 - Sensorless PMSM Control on MKV46F256 Using Kinetis SDK 附代码包AN5004SW AN4912 - Tuning 3-Phase PMSM Sensorless control application using MCAT Tool DRM140 - PMSM Sensorless Vector Control on Kinetis AN4489 - Using CMSIS-DSP Algorithms with MQX and Kinetis MCUs AN4381 - Configuring the FlexTimer for position and speed measurement AN3729 - Using FlexTimer in ACIM/PMSM Motor Control Applications MCLIBCORETXM4UG - Set of General Math and Motor Control Functions for Cortex M4 core PMSMCONUG - PMSM Vector Control with Encoder on Kinetis AN4680 - PMSM electrical parameters measurement DSC方案 AN4656 - PMSM FOC of Industrial Drives using the 56F84789 PMSMUG - PMSM Field-Oriented Control Using MC56F84789 DSC With Encoders DRM098 - Direct PFC Using the MC56F8013 DRM029 - 3-Phase PM Synchronous Motor Control with Quadrature Encoder Using 56F805 Designer DRM102 - PMSM Vector Control with Single-Shunt Current-Sensing Using MC56F8013/23 Design DRM018 - 3-Phase PM Synchronous Motor Torque Vector Control Using 56F805 Designer DRM036 - Sine Voltage Powered 3-Phase Permanent Magnet Synchronous Motor with Hall Sensors Designer AN5014 - Three-Phase PMSM Sensorless FOC using MC56F82748 and MC56F84789 with Automated Motor Parameter Identification  附代码包AN5014SW DRM110 - Sensorless PMSM Control for an H-axis Washing Machine Drive Designer DRM099 - Sensorless PMSM Vector Control with a Sliding Mode Observer for Compressors Using MC56F8013 DRM139 - Dual Sensorless PMSM Field-Oriented Control With Power Factor Correction on MC56F84789 DSC AN4608 - 在MC56F84789上使用PWM和ADC，驱动双PMS电机FOC AN4583 - MC56F84789 Peripherals Synchronization for Interleaved PFC Control                 若文档链接有变动或失效，请在飞思卡尔官方网站上通过文档名称(如AN4912、DRM139等)搜索相应文档。

This years annual hacker security conference known as DEFCON used a couple of NXP devices for this years electronic badge. This document is to explain how to program the device and add extra components. The badge was developed by Grand Idea Studio, with engineering help from NXP, and this presentation has details about the development of the badge. I'm the NXP systems engineer that was helping people get started with reprogramming their badge at Defcon, and wanted to create something that gives all the details on how to do that yourself.  Full schematics and firmware source code can be found at: http://www.grandideastudio.com/defcon-27-badge/   The badge has these two NXP devices:  KL27  - MKL27Z64VDA4 - 48Mhz ARM Cortex M0+ microcontroller w/ 64KB flash (Datasheet and Reference Manual) NXH2261UK- Near Field Magnetic Induction (NFMI) chip for the wireless communication. Has a range on the badge of about 6 inches (15cm), but the technology can work a bit further. It's often found in high end headphones because BLE waves are disrupted by your head but these waves aren't. Also less power consumption. Using the serial port: There's a serial interface which prints out helpful information and there's some "secrets" available if you have a completely leveled up badge. It'll also be really helpful if you're writing new code to hack your badge for printf debugging. Note that you cannot program the board by default over the serial port. This particular chip doesn't support that, though some of our other chips do. It of course would be possible to write a serial bootloader for it, but that's definitely not beginner level. You'll need two pieces of hardware: 1) Header Pins 3) Serial-to-USB converter Header Pin: You can solder on a header to the PCB footprint. Because of the quartz, the leads would need to be flat on the PCB. A Harwin M20-8770442 will fit the footprint and is what was provided at the soldering village and what you see in the photos below. You could also try creating your own header.  Serial to USB Converter: Since almost no computer today comes with a serial port, a serial to USB converter dongle is needed. It'll have four pins: GND, Power, TX, and RX. The DEFCON badge runs at 1.8V, but the chip itself is rated up to 3.6V, so a 3.3V dongle can be used *as long as you do not connect the power pin on the serial header*. You only need to connect GND, RX, and TX. In a production design you would not want an IO voltage above VCC, but for hacking purposes it'll work, and I've used it all week without an issue on multiple boards.  There's a lot of options. Here's a 1.8V one if you want to be extra cautious or a 3.3V one that already comes with connectors for $8. Anything that transmits at 1.8V or 3.3V will work so you may already have one, but again, just don't connect the power pin.    Software: You'll need to install a serial terminal program like TeraTerm or Putty.  1) Plug the 3.3V or 1.8V USB converter dongle into your computer and it should enumerate as a COM port.  2) Connect the GND line on the dongle to GND on the header 3) Connect the TX pin on the dongle to the RX pin on the header 4) Connect the RX pin on the dongle to the TX pin on the header (it is not RX to RX, I spent 2 whole days tearing my hair out over that during my robotics project in college) 5) DO NOT CONNECT THE POWER PIN  5) Should look like the following when finished 6) In your serial terminal program, connect to the COM port your dongle enumerated as 7) Find the serial port settings menu (in TeraTerm it's in Setup->Serial Port from the menu bar) , and set the baud rate to 115200. The other settings should not need to be changed (8 data bits, no parity, 1 stop bit).  😎 In the terminal, press enter. You should get a > prompt 9) In the terminal, press the '?' key on your keyboard, and hit enter, you'll see the menu.         10) Note that the key you press won't show up in the terminal, but just press Enter and then the command will be run 11) Hit Ctrl+x to exit interactive mode and turn back on the radio.  12) While not in interactive mode, the terminal will display the transmit packet of any badge you bring close to it.  Reprogramming Your Badge: Hardware:  There's two pieces of hardware needed: 1) Programmer/debugger 2) Programming cable Program Debugger: Most any ARM Cortex M debug programmer can be used, as the KL27 chip has a ARM M0+ core. I'd recommend the LPC-Link2 as it's only $20 and can be bought directly from NXP or from most distributors (like Mouser or DIgikey). Search for "OM13054". But you could also use a J-Link, PEMicro, or others if you already have an ARM programmer. Cable: The DEFCON badge has the footprint for a Tag Connect TC2050-IDC-NL-050-ALL. Because this cable is meant for manufacture programming and not day-to-day debugging, if you plan on stepping through code, you'll also want to pop off the the quartz front and get some retainer clips to keep the programmer connected to the board. If you just simply want to reprogram the board, you can just snip off the 3 long guide clips, and press the cable against the PCB while holding your hand steady for the ~5 seconds it takes to flash it each time.  Alternatively if you already have a JTAG/SWD cable and have soldering skills, you can use some fine gauge wire and hack up your own converter to your board like /u/videlen did with some true hacker soldering. However as /u/int23h pointed out, because it's using Single Wire Debug (SWD) you only need to really solder 2 of the pins, SWDIO and SWDCLK. However nRESET is also recommended as it'll let you take control of the device if it's in sleep mode (which it is most of the time). Power (which is needed so the programmer knows what voltage to send the signals at) and GND you can get from the serial header. Software There's three pieces of software you'll need:  1) Compiler 2) MCUXpresso SDK for the KL27  3) Badge source code Compiler: Recommended Option: Latest version of MCUXpresso IDE - available for Windows, Mac, and Linux Second Option: Download older version of MCUXpresso IDE for Windows from the DEFCON media server  Third Option: If you use the latest SDK, you can easily use ARM-GCC, IAR, or Keil tool chains as well.  MCUXpresso SDK: Recommend Option: Download latest SDK version for KL27 - includes setup for MCUXpresso IDE, ARM-GCC, IAR, and Keil compilers Other option: Download the older 2.4.2 SDK version on the DEFCON server which only has MCUXpresso IDE compiler support.  Badge Source: Recommended Option: Download zip off Joe Grand Website: http://www.grandideastudio.com/wp-content/uploads/dc27_bdg_source.zip  Other option: Download from DEFCON media server. However the .project and .cproject files do not show up by default, so you must make sure to explicitly download them as well and put them in the main firmware folder (at the same level as the .mex file). These are the exact same files as in the zip.  wget -r -np -R "index.html*" https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/ wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.cproject wget  https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20badge/Firmware/.project  Getting Started with MCUXpresso IDE:      1) Open up MCUXpresso IDE. When it asks for a workspace directory to use, select (or make) a new empty directory that is in a different location than where you          downloaded the firmware source.       2) Drag and drop the SDK .zip file from your file system into the MCUXpresso IDE "Installed SDKs" window. This is how the compiler learns about the KL27 device and the flash algorithms.  3) Drag and drop the badge firmware folder from a file explorer window into the MCUXpresso IDE "Project Explorer" window 4) In the Quickstart panel hit Build 5) In the Console tab, you should see the message that it compiled successfully 7) In the Quickstart panel hit Debug.  If you're not using a LPC Link2 for programming, you'll need to hold Shift when clicking this the first time so it'll rescan for your debugger.  If using the latest MCUXpresso IDE, you'll see a dialog box that the launch configuration needs to be updated. Click on "Yes".    7) A dialog box will come up confirming your debug probe. 😎 Connect the programming cable to the board and press to make a good connection. Make sure the alignment pins match up with the alignment holes on the PCB, and that pin 1 (the red stripe) matches the photo below. You may hear the badge beep, as it's being reset. 9) Then hit OK in the dialog box to start programming. Make sure to keep the probe held there until the programming is finished - about 5 seconds. 10) You should see it program successfully and hear the board beep as it reboots.  Programming Troubleshooting/Tips: If you're not using a LPC Link2, hold down the Shift key when you hit the Debug button, and it'll re-search for new probes. Also make sure your debug settings and probe is using SWD mode and not JTAG mode.  If you have the programming cable not lined up with the pads, you'll see this error. Re-align your probe and try again. Also you must have power from the battery as the MCU needs to be turned on while programming. You can hit the GUI flash programmer at the top for a quicker download experience since it won't load the debug view. Useful if just flashing the device without wanting to step through code.  Finally, some of the game state variables are stored in the non-volitale internal flash, and may not automatically get erased when reprogramming the firmware as the programmer doesn't realize that area of flash memory is being used and thus to save time, doesn't bother to erase it. You can force a complete erase of the flash to wipe all the game variables by setting the mass erase option. Double click on the dc27_badge LinkServer Debug.launch file which contains the debug settings, and go to GUI Flash Tool->Program and set Program (mass erase first).  Getting Started with ARM-GCC: To make this easier, you'll need to download the latest SDK from the NXP website first.  Follow the instructions in Section 6 of the MCUXpresso SDK User Guide for how to setup the environment and test it out on Hello World. You can then use that project for copying the badge source code into. I'm sure someone can put together a Makefile for the badge specifically. See this series of blog posts on how to use the SDK (compiling/debugging) with arm-gcc in Linux. My badge isn't working: First thing to try is power cycling the badge by gently prying the battery out (with a butter knife or something) and putting it back in. A couple of things might happen: If nothing at all happens, you battery might be dead. Try replacing the battery.  If nothing at all happens still, the battery holder might be loose. Use a multimeter ot measure the voltage between GND and VCC on the serial header, it should read 1.8V. If it does not, check the battery holder. If you hear beeps, all 6 LEDs light up, and then 4 LEDs (2 on each side) flash in sync a few times, it means there was an issue communicating with the NFMI device. This could be due to a loose solder joint on one of the chips or the I2C pull up resistors (SCL and SDA on the pinout image). You could also do a reflow if you have the equipment, but it may not be fixable. Also could see if see any I2C communication on those SCL/SDA pins. If you hear a normal startup beep, the lights flash, and then it goes back to the startup beep, and so on, forever, something is causing the MCU to keep resetting. Could be a short or ESD damage. Check soldering. Connecting your board to a serial terminal and see how far it gets in the boot process to help narrow down the cause.  Sometimes the flags don't get saved properly. A power cycle usually works, and could also try reflashing the badge.  If your badge isn't responding to other badges with the NFMI, it could be one of two things: Your copper antenna is loose/broken/missing. This happened a lot. Solder it back on. If missing, it's a Sunlord MTNF6040FS3R7JTFY01 but it's not available online anywhere at the moment. Datasheet is here. See this post for more details on possible alternatives. If you were previously in interactive mode, you have to explicitly exit it with Ctrl+X to receive packets again.  Further hacking: For basic hacking of the code, try changing your game flags to trick it to giving you a fully unlocked badge. From there, you could try to make your own chameleon badge like others have done (https://github.com/japd06/defcon27_badge and https://github.com/nkaminski/DC27-badge-CFW and https://github.com/NickEngmann/Jackp0t among others if you want ideas). Or make your own songs with the piezo. Or some ASCII art on the terminal. For more advanced hacking on the badge, PTE22 and PTE23, the TX and RX pins on the serial header, could be programmed to be ADC input pins instead. Or timer inputs or outputs for PWM or input capture.  And with some good soldering, you could even add an additional I2C device by soldering to the resistor points. t.   Finally if you want a more flexible platform for exploring embedded development, you can pick up a FRDM-KL27Z dev kit for $20 which has the same chip as the badge. You can buy it direct or all major distributors online. The programmer and serial interface are built into the board so you only need to use a USB cable to do all the programming. The KL27 SDK also includes dozens of example programs that show how to use all the features of the chip and there's some getting started videos (mostly what I covered already in this post though). While it does not have a NFMI chip on it, it does have USB support, as well as an Arduino hardware footprint on it so it can be easily expanded with extra boards. You can find the example programs by going to "Import SDK examples" from the Quickstart panel window.  If you have any more questions about the badge, post a response! 

Kinetis L series MCUs combine the exceptional energy-efficiency and ease-of-use of the new ARM® Cortex™-M0+ processor with the performance, peripheral sets, enablement and scalability of the Kinetis 32-bit MCU portfolio. The Kinetis L series frees power-critical designs from 8- and 16-bit MCU limitations by combining excellent dynamic and stop currents with superior processing performance, a broad selection of on-chip flash memory densities and extensive analog, connectivity and HMI peripheral options. Kinetis L series MCUs are also hardware and software compatible with the ARM Cortex-M4-based Kinetis K series, providing a scalable migration path to more performance, memory and feature integration. The Kinetis L Series MCUs are Energy-Efficient Product Solutions by Freescale. For more information visit Freescale.com\Lseries

Hello Kinetis World, I just wanted to take this opportunity to share the press release for our newly announced WLCSP device.         http://finance.yahoo.com/news/thin-blade-grass-freescale-newest-120000684.html The Ultra Thin CSP, MK22FN512CBP12R, is equivalent to the standard height CSP, MK22FN512CBP12R.  Therefore, from Therefore, from a software enablement perspective, the MK22FN512CAP12 device can be selected as shown in the attached Processor Expert screenshot.  We're looking forward to seeing what amazing things you can accomplish using Kinetis technology!      

Hi All, NXP provides a software drivers library for Kinetis M devices, the KM bare-metal drivers. It includes support for peripherals and FreeRTOS. Follow the instructions to download and install the software package. Go to the KM3x section in the NXP webpage. Click on the documentation tab In the Application Notes section look for the API reference manual for Kinetis M bare-metal drivers and software examples, download: HTML > Reference Manual and documentation ZIP > Software package Unzip the KMSWDRVAPIRM_SW.zip file into a computer location. Inside the folder you will find several .exe files, select the appropriate file for your application and follow the installation instructions. By default a folder named KMxxxSWDRV_Rx_x_x is created. You can see the folder structure like this build: Build examples project files for the selected IDE. refman: Source files of the HTML Reference Manual src: Source files for drivers: common – common files for projects: device headers, startup routines, etc. drivers – peripheral drivers source code. freemaster – Freemaster source files for communication functions with Freemaster software. freertos – FreeRTOS files, kernel and RTOS support. projects – example projects demonstrating peripherals and modes. toolchain – toolchain support. template – Base projects for supported IDEs and make_project.exe file to create new project for different supported IDEs. If you need support for a different IDE or KM device you just need to extract the appropriate .exe file from the SW package. Hope information helps! Happy Downloading and installing! Regards, Adrian Cano NXP FAE

I need to connect multi phy device with a single cpu. I want realize a follow hardware (see picture MultiPhys.jpg ). My dubt is if this schematic is correct. I need to send frame either PHY1 or PHY2. My application is like a gateway, it sends messages to network in selective way ( and it receives from every PHYs device ). Is it possible connect many PHY device with one RMII bus? what is the correct way to connect many PHY device on RMII bus? Anyone knowns documents that describe multi Phy configurations ?

Fat File System for SD card using SPI for Kinetis-K60, K22 and K20

Hi All, This Kinetis Design Tips and Tricks document is used for those needing to have a checklist or troubleshooting document for their Kinetis hardware designs.  This will be a living document that is updated as needed. Enjoy all! Please give any and all feedback on this forum. Mike Steffen

Hi team ,      I would like to share an experiment that about the Fast IO - zero wait state access of KL series . Detail please refer to attached file . Best regards, David

From K61/K64/K66 reference manual/ datasheet, it is mentioned that the SDHC clock can be set up to 50MHz. But from the SDHC timing spec, SDHC output timing violate SD specification if SDHC clock is 50MHz, because output delay (SD6 tOD) is max 6.5ns.  SD specification require setup time at SD card 6ns, then output delay should less than 4 ns if SDHC clock is 50MHz. In other word, according to the SD card specification, input set-up time is minimum 6ns, then maximum of SD6 should be 4ns in order to support 50 MHz clock frequency. So we recommend customer to drop the SDHC clock frequency to 40MHz, then the 6.5ns output valid time will allow them to meet the 6ns setup requirement for the card.

Actually the latest FSL USB stack has become part of KSDK , so it is recommended customer design USB application based on KSDK, while there are some old parts like K70, K60F and KL25 are still not supported in KSDK yet, so USB stack ver 4.1.1 is somewhat of help for those who still develop application based on those parts. USB stack ver 4.1.1 supports K70 instead of K60F, but since they are both Kinetis 120MHz parts, so the porting is very easy, here I provide a porting guide for this part. The porting is based on K70 USB examples, either Host or Device. 1. Replace the device header file. Use MK60F12.h instead, which may be extracted from KINETIS_120MHz_SC(Kinetis 120MHz bare metal sample code) , and put this header file in the folder of "C:\Freescale\Freescale USB Stack v4.1.1\Source\Host\source\bsp\P3" for Host or "C:\Freescale\Freescale USB Stack v4.1.1\Source\Device\app\common\kinetis" for device, and modify derivative.h as  below: 2. Macro definition changes in MK60F12.h, MCU_MK60F12 is defined instead of MCU_MK70F12, so in this step we will have to change some code snippet related with MCU_MK70F12. Firstly search MCU_MK70F12 in the project, for example ， in the Host demo USB_MSD project based on IAR, you may do that as below: and you may find some macro like "#ifdef MCU_MK70F12" or "#ifndef MCU_MK70F12", and change them as below: #ifdef MCU_MK70F12 ----> #if (defined MCU_MK60F12) || (defined MCU_MK70F12) #ifndef MCU_MK70F12 ----> #if (!defined MCU_MK60F12) && (!defined MCU_MK70F12) 3. IO driver modification. Since TWR-K70F120 has almost the same hardware as TWR-K60F120, there is no need to change the driver code after replacing the header file, except the serial port driver, referring to USB_MSD demo, the serial driver is in sci_kinetis.c, TWR-K70F120M uses PTE16 and PTE17(UART2) as the console, while TWR-K60F120M use PTE8 and PTE9(UART5) instead, so you have to change the driver as below to make printf work properly. void sci2_init(){ #if (defined MCU_MK60F12) || (defined MCU_MK70F12)     register uint_16 sbr, brfa;     uint_8 temp; #ifdef MCU_MK70F12     /* Enable the UART2_TXD function on PTD3 */     PORTE_PCR16 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the UART2_RXD function on PTD2 */     PORTE_PCR17 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the clock  */     SIM_SCGC4 |= SIM_SCGC4_UART2_MASK;     /* Make sure that the transmitter and receiver are disabled while we      * change settings.      */     UART_C2_REG(UART2_BASE_PTR) &= ~(UART_C2_TE_MASK | UART_C2_RE_MASK);     /* Configure the UART for 8-bit mode, no parity */     UART_C1_REG(UART2_BASE_PTR) = 0;    /* We need all default settings, so entire register is cleared */     /* Calculate baud settings */     sbr = (uint_16)((SYSCLK*1000)/(UART_BAUDRATE * 16));     /* Save off the current value of the UARTx_BDH except for the SBR field */     temp = UART_BDH_REG(UART2_BASE_PTR) & ~(UART_BDH_SBR(0x1F));     UART_BDH_REG(UART2_BASE_PTR) = temp |  UART_BDH_SBR(((sbr & 0x1F00) >> 8));     UART_BDL_REG(UART2_BASE_PTR) = (uint_8)(sbr & UART_BDL_SBR_MASK);     /* Determine if a fractional divider is needed to get closer to the baud rate */     brfa = (((SYSCLK*32000)/(UART_BAUDRATE * 16)) - (sbr * 32));     /* Save off the current value of the UARTx_C4 register except for the BRFA field */     temp = UART_C4_REG(UART2_BASE_PTR) & ~(UART_C4_BRFA(0x1F));     UART_C4_REG(UART2_BASE_PTR) = temp |  UART_C4_BRFA(brfa);       /* Enable receiver and transmitter */     UART_C2_REG(UART2_BASE_PTR) |= (UART_C2_TE_MASK    | UART_C2_RE_MASK); #else   //MCU_MK60F12         /* Enable the UART2_TXD function on PTE8 */     PORTE_PCR8 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin     /* Enable the UART2_RXD function on PTE9 */     PORTE_PCR9 = PORT_PCR_MUX(0x3); // UART is alt3 function for this pin                /* Enable the clock  */     SIM_SCGC1 |= SIM_SCGC1_UART5_MASK;     /* Make sure that the transmitter and receiver are disabled while we      * change settings.      */     UART_C2_REG(UART5_BASE_PTR) &= ~(UART_C2_TE_MASK | UART_C2_RE_MASK);     /* Configure the UART for 8-bit mode, no parity */     UART_C1_REG(UART5_BASE_PTR) = 0;    /* We need all default settings, so entire register is cleared */     /* Calculate baud settings */     sbr = (uint_16)((SYSCLK*1000)/(UART_BAUDRATE * 16));     /* Save off the current value of the UARTx_BDH except for the SBR field */     temp = UART_BDH_REG(UART5_BASE_PTR) & ~(UART_BDH_SBR(0x1F));     UART_BDH_REG(UART5_BASE_PTR) = temp |  UART_BDH_SBR(((sbr & 0x1F00) >> 8));     UART_BDL_REG(UART5_BASE_PTR) = (uint_8)(sbr & UART_BDL_SBR_MASK);     /* Determine if a fractional divider is needed to get closer to the baud rate */     brfa = (((SYSCLK*32000)/(UART_BAUDRATE * 16)) - (sbr * 32));     /* Save off the current value of the UARTx_C4 register except for the BRFA field */     temp = UART_C4_REG(UART5_BASE_PTR) & ~(UART_C4_BRFA(0x1F));     UART_C4_REG(UART5_BASE_PTR) = temp |  UART_C4_BRFA(brfa);        /* Enable receiver and transmitter */     UART_C2_REG(UART5_BASE_PTR) |= (UART_C2_TE_MASK    | UART_C2_RE_MASK); #endif        #endif } #ifdef __CC_ARM int sendchar (int ch) #else void TERMIO_PutChar (char ch) #endif { #if (!defined MCU_MK60F12) && (!defined MCU_MK70F12)     #if (defined MCU_MK20D5) || (defined MCU_MK20D7) || (defined MCU_MK40D7)         /* Wait until space is available in the FIFO */         while(!(UART1_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART1_D = (uint_8)ch;       #elif(defined MCU_MK21D5)         while(!(UART2_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART2_D = (uint_8)ch;       #elif(defined MCU_MKL25Z4) || (defined MCU_MKL46Z4)         /* Wait until space is available in the FIFO */         while(!(UART0_S1 & UART_S1_TDRE_MASK)){};        /* Send the character */        UART0_D = (uint_8)ch;       #else         /* Wait until space is available in the FIFO */         while(!(UART3_S1 & UART_S1_TDRE_MASK)){};                /* Send the character */         UART3_D = (uint_8)ch;     #endif   #else #ifdef MCU_MK70F12     /* Wait until space is available in the FIFO */     while(!(UART2_S1 & UART_S1_TDRE_MASK)){};     /* Send the character */     UART2_D = (uint_8)ch; #else      /* Wait until space is available in the FIFO */     while(!(UART5_S1 & UART_S1_TDRE_MASK)){};     /* Send the character */     UART5_D = (uint_8)ch; #endif #endif } 4. Set the correct device type in IDE settings. For IAR, change the device family in view of project options. Now, you can start to run the USB demos on TWR-K60F120M, please note the above steps is ok for USB device stack, but USB Host stack has some code issue , as mentioned in [USB stack ver 4.1.1] a code issue in msd_mfs_generic host demo , so please fix the issue before going further. Hope that helps, Best Regards, Kan

   在培训和论坛提问中，发现用户提出的很多问题都集中在如何有效的检索到“适合的开发工具和开发资源”上。在此帖中，简单的介绍一下在飞思卡尔官方网站上查找到实用的开发资源的一些简单步骤，希望对大家有帮助。     通常学习和应用一款芯片是从选择一个评估/开发板开始的，然后安装相应的开发环境和硬件驱动、最后结合芯片Datasheet、Reference Manul、参考设计和官方例程编写程序代码完成项目开发。和其它行业一样，如今对于芯片厂商也流行提供一整套的解决方案，有现成的方案设计提供给客户，减少客户的时间成本，提高开发效率。可是在哪里能找到例程代码、参考设计、如何动手呢，对于很大部分不熟悉飞思卡尔官网的人来说，找到自己需要的资源就很困难，这里以FSL Kinetis系列芯片为例简单给大家介绍一下在飞思卡尔官网资源检索的通常步骤。     首先，进入飞思卡尔的官网www.freescale.com， 通常大家更习惯于中文，所以点击右上角“中文”选择显示中文，如图1，以后再次进入网站时，它都会自动默认中文显示。然后选择“产品”->微控制器”可以看到里面包括飞思卡尔MCU相关的产品，早期8位/16位MCU、主要用于电机控制的DSC、Vybrid多核控制器，ColdFire架构MCU以及ARM Cortex架构的Kinetis，这里选择Kinetis ARM Cortex MCU，如图2。 图1 图2        可以看到Kinetis K系列、L系列、M系列、W系列的一些MCU，这里选择KL2，如图3，打开之后如图4可以看到很多调试仿真器、评估开发板、相关软件工具等，这里是一个资源合集。在“文档”栏目中能找到KL2X芯片的Datasheet、参考手册、应用笔记、用户指南等等；在“软件和工具”栏目中能找到KL2X系列MCU可以使用的仿真调试器、评估开发板、软件开发工具、中间件驱动程序等； 图3  图4          如前文所讲，需要先找一个硬件开发平台，于是展开“评估/开发板与系统”，可以看到很多飞思卡尔公司提供的开发板，包括FRDM-KL05Z（KL0系列MCU，不知为何放在这里）、FRDM-KL25Z（FRDM板）、TWR-KL2548M（塔形板）几个版本，这里我们选择使用最为广泛的的FRDM-KL25Z，点击进去，如图5，就能看到对应于KL25Z的Demo板相关信息和资源，在“文档”栏目里有KL25Z相关的应用说明、用户手册等等；在”下载”栏目里能找到FRDM-KL25Z开发板的电路原理图、例程代码（含Codewarrior、IAR、Keil三个版本）、开发环境搭建用到的软件以及告诉你如何安装驱动的QSG文件；在“购买/规格”栏目里能看到开发板购买的价格和途径，值得一提的是这款板不仅包括KL25Z芯片的最小系统，还板载了一个OpenSDA下载/调试器（既可以调试板载芯片，也可以引出调试其它器件），而价格只有12.95$，不到一百块人民币，可谓是超值。 图5      至此，开发的软件环境、需要准备的硬件板、原理图、驱动软件、例程源代码、DataSheet、User's Manual都知道在哪里获得了相应资源了，后续需要自己搭建环境，安装驱动，根据项目需要参照测试例程、Datasheet和User's Manual进行编程开发了。 至于其他系列的芯片Datasheet、User's Manual、例程代码、开发环境等等资源也可以按照这个步骤进行检索。另外，飞思卡尔网站对一些重要的资源还提供了快捷链接，如KL25Z开发板：www.freescale.com/FRDM-KL25Z，K60的100M开发板：http://www.freescale.com/TWR-K60D100M ，MQX操作系统：www.freescale.com/MQX，技术支持：http://www.freescale.com/support 等等。     另外，大家还可以在官网上看到一些其他的技术信息，有问题也欢迎飞思卡尔官方社区community.freescale.com和EEFOCUS飞思卡尔社区 www.freescaleic.org/bbs/ 讨论和分享自己的问题和经验。

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 was created in collaboration with Dragos Musoiu Trying to debug a hard fault on MKW24D512, ARM Cortex M4 based microcontroller, we did not find too much documentation on working with IMPRECISE hard faults.  We started our investigation from the post of Erich Styger Debugging Hard Faults on ARM Cortex-M. Based on this, we used Erich’s code to find the hard fault source, but it was impossible to find the instruction that caused the hard fault, because the executed instructions around the saved PC looked to be correct.  After, we checked the Hard Fault Status Register, from the System Control Block of the ARM Cortex M4 processor, we found the FORCED bit set. The ARM Cortex M4 documentation mentions that this bit indicates a forced hard fault, generated by escalation of a fault with configurable priority that cannot be handled, either because of priority or because it is disabled. When this bit is set to 1, the HardFault handler must read the other fault status registers to find the cause of the fault. We checked the other fault registers and we found, in the Configurable Fault Status Register (Bus Fault Status Register) from the System Control Block of the ARM Cortex M4 processor, the IMPRECISERR bit set. According to the ARM Cortex M4 documentation, if this bit is set a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. So that explained why we did not find the instruction that caused the hard fault using Erich’s indications. Also, this is an asynchronous fault. Therefore, if it is detected when the priority of the current process is higher than the BusFault priority, the BusFault becomes pending and becomes active only when the processor returns from all higher priority processes. The Cortex M4 processors have a write buffer feature that when a write is carried out to a bufferable memory region, the processor can proceed to the next instruction before the transfer is completed. This is great for performance, but can cause some complexity in debugging imprecise bus faults. Studying better the documentation, we found in the ARM Cortex M4 Auxiliary Control Register the DISDEFWBUF bit that when set to 1, disables write buffer use during default memory map accesses. This causes all BusFaults to be precise BusFaults but decreases performance because any store to memory must complete before the processor can execute the next instruction. In this way the processor will not continue executing the next instruction until the write operation is completed, and so enabling this bit and using Erich’s code the saved PC pointed to the instruction which caused the hard fault. In other case, if the Bus Fault is triggered by an instruction executed in an interrupt handler, with higher priority than the BusFault handler, setting the DISDEFWBUF can be useful in the debugging process because the BFAR register value remains valid in case of precise error.

This is a Processor Expert project created by CodeWarrior for MCUs v10.6 which implements the charge-discharge time of a RC circuit for measuring capacitance. The charge-discharge sequence is performed by TPM0 operating in PWM mode, while the time is measured by TPM1 operating in Input Capture mode. A 100K ohm series resistor is being used, and the result is expressed on nF. It is also using the LCDHTA component from Erich Styger for showing the measurements on a 16x2 LCD, connected to the FRDM-KL05Z through a proto shield. The project is attached, and the pictures shows the measurements of three different capacitors: 10nF, 47nF and 1uF.