The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools Getting Started with MCUXpresso and FRDM-K64F Generating a downloadable MCUXpresso SDK v.2 package Quick Start Guide – Using MCUXpresso SDK with PINs&CLOCKs Config Tools Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+ PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70 USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults How to create chain of pbuf's to be sent? Send data using UDP. Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading USB VID/PID numbers for small manufacturers and such like Open SDA and FreeMaster OpenSDAv2 Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER! The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0 GDB Debugging with Kinetis Design Studio KDS Debug Configurations (OpenOCD, P&E, Segger) How to use printf() to print string to Console and UART in KDS2.0 Kinetis Design Studio - enabling C++ in KSDK projects Using MK20DX256xxx7 with KDS and KSDK Kinetis SDK Kinetis SDK FAQ Introducing Kinetis SDK v2 How to: install KSDK 2.0 Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt
Hey there Kinetis lovers! We in the Systems Engineering team for Kinetis Microcontrollers see all kinds of situations that customers get into, and none can be particularly troubling like how the reset pin is handled. The purpose of this document is to provide a list of Frequency Asked Questions (FAQ) that we get here in the Kinetis Systems Engineering department. This is intended to be a living list and as such, may in no way be complete. However we hope that you will find the below questions and answers useful. Q: Do I need to connect the reset signal to be able to debug a Kinetis device? This is a commonly asked question. Strictly speaking, you do not need to connect the device reset line of a Kinetis device to the debug connector to be able to debug. The debug port MDM-AP register allows the processor to be held in reset by means of setting the System Reset Request bit using just the SWD_CLK and SWD_DIO lines. However, before deciding to omit the reset line from your debug connector you should give some careful thought to how this may impact the ability to program and debug the device in certain scenarios. Does the debugger/flash programmer or external debug pod require the reset pin? It may be that the specific tool you are using only supports resetting the device by means of the reset line and does not offer the ability to reset the device by means of the MDM-AP. Have you changed the default function of the debug signals? You may need to use the SWD_CLK and/or the SWD_DIO signals for some other function in your application. This is especially true in low pin count packages. Once the function is changed (by means of the PORTx_PCRy registers) you will no longer have access to the MDM-AP via those signals. If you do not have access to the reset signal then you have no way of preventing the core from executing the code that will disable the SWD function of the pins. So you will not be able to re-program the device. In order to prevent this type of situation you need to either: Setup your code to change the function of the SWD pins several seconds after reset is released so that the debugger can halt the core before this happens. Put some kind of “backdoor” mechanism in your code that does not re-program the SWD function, or re-enables the SWD function, on these pins. For example, a specific character sequence sent via a UART or SPI interface. Some Kinetis devices allow the reset function of the reset pin to be disabled. In this case you can only use the SWD signals as a means of resetting the device via the MDM-AP. If you change the SWD pin function in addition to disabling the reset pin then you must provide a backdoor means of re-enabling the SWD function if you want to be able to reprogram the device.
With the merger of NXP and Freescale, the NXP USB VID/PID program, which was previously deployed on LPC Microcontrollers, has been extended to Kinetis Microcontrollers and i.MX Application Processors. The USB VID/PID Program enables NXP customers without USB-IF membership to obtain free PIDs under the NXP VID. What is USB VID/PID Program? The NXP USB VID program will allow users to apply for the NXP VID and get up to 3 FREE PIDs. For more details, please review the application form and associated FAQ below. Steps to apply for the NXP USB VID/PID Program Step 1: Fill the application form with all relevant details including contact information. Step 2: NXP will review the application and if approved, will issue you the PIDs within 4 weeks FAQ for the USB VID/PID Program Can I use this VID for any microcontroller in the NXP portfolio? >> No. This program is intended only for the Cortex M based series of LPC Microcontrollers and Kinetis Microcontrollers, and Cortex A based series of i.MX Application Processors. What are the benefits of using the NXP VID/PID Program? >> USB-IF membership not required >> Useful for low volume production runs that do not exceed 10,000 units >> Quick time to market Can I use the NXP VID and issued PID/s for USB certification? >> You may submit a product using the NXP VID and issued PID/s for compliance testing to qualify to use the Certified USB logo in conjunction with the product, but you must provide written authorization to use the VID from NXP at the time of registration of your product for USB certification. Additionally, subject to prior approval by USB-IF, you can use the NXP VID and assigned PID/s for the purpose of verifying or enabling interoperability. What are the drawbacks of using the NXP VID/PID program? >> Production run cannot exceed 10,000 units. See NXP VID application for more details. >> Up to 3 PIDs can be issued from NXP per customer. If more than 3 PIDs are needed, you have to get your own VID from usb.org: http://www.usb.org/developers/vendor/ >> The USB integrators list is only visible to people who are members of USB-IF. NXP has full control on selecting which products will be visible on the USB integrators list. How do I get the VID if I don't use NXP’s VID? >> You can get your own VID from usb.org. Please visit http://www.usb.org/developers/vendor/ Do I also get the license to use the USB-IF’s trademarked and licensed logo if I use the NXP VID? >> No. No other privileges are provided other than those listed in the NXP legal agreement. If you wish to use USB-IF’s trademarked and licensed USB logo, please follow the below steps: 1. The company must be a USB vendor (i.e. obtain a USB vendor ID). 2. The company must execute the USB-IF Trademark License Agreement. 3. The product bearing the logo must successfully pass USB-IF Compliance Testing and appear on the Integrators List under that company’s name. Can I submit my product for compliance testing using the NXP VID and assigned PIDs? >> Yes, you would be able to submit your products for USB-IF certification by using the NXP VID and assigned PID. However, if the product passes the compliance test and gets certified, it will be listed under “NXP Semiconductors” in the Integrators list. Also, you will not have access to use any of the USB-IF trademarked and licensed USB logos. How long does it take to obtain the PID from NXP? >> It can take up to 4 weeks to get the PIDs from NXP once the application is submitted. Are there any restrictions on the types of devices that can be developed using the NXP issued PIDs? >> This service requireds the USB microcontroller to be NXP products. Can I choose/request for a specific PID for my application? >> No. NXP will not be able to accommodate such requests.
It has been reported that OpenSDA v2/2.1 bootloader could be corrupted when the board is plugged into a Windows 10 machine. An updated OpenSDA bootloader that fixes this issue is available at www.NXP.com/openSDA. There is also a blog article by Arm addressing this issue. To reprogram the bootloader on affected boards, you will require an external debugger, such as Segger JLink or Keil ULink programmer attached to the JTAG port connected to the K20 OpenSDA MCU. For your convenience, the binaries of the OpenSDA v2.2 bootloader is attached at the bottom of this post. If using a Segger JLink, download the latest JLink Software and Documentation pack and use the following JLink.exe commands to connect to the K20 OpenSDA MCU: Connect MK20DX128xxx5 S 4000 And then use the following commands to reflash the bootloader: erase loadbin <your Bootloader Binary> 0x00000000 Here is another post on how to recover bricked OpenSDA boards and to prevent it getting re-bricked. To check more information regarding OpenSDA on your boards, please go to www.nxp.com/opensda.
Revise History: Version 23: NXP kinetis bootloader GUI upgrade from v1.0 to v1.1: added 04 extended linear address record and 02 sector address record processing for hex format. This article describes how to do in-system reprogramming of Kinetis devices using standard communication media such as SCI. Most of the codes are written in C so that make it easy to migrate to other MCUs. The solution has been already adopted by customers. The pdf document is based on FRDM-KL26 demo board and Codewarrior 10.6. The bootloader and user application source codes are provided. GUI and video show are also provided. Now the bootloader source code is ported to KDS3.0, Keil5.15 and IAR7.40 which are also enclosed in the SW package. Customer can make their own bootloader applications based on them. The application can be used to upgrade single target board and multi boards connected through networks such as RS485. The bootloader application checks the availability of the nodes between the input address range, and upgrades firmware nodes one by one automatically. Key features of the bootloader: Able to update (or just verify) either single or multiple devices in a network. Application code and bootloader code are in separated projects, convenient for mass production and firmware upgrading. Bootloader code size is small, only around 2K, which reduces the requirement of on chip memory resources. Source code available, easy for reading and migrating. GUI supports S19,HEX and BIN format burning images. For more information, please see attached document and code. The attached demo code is for KL26 which is Cortex - M0+ core. For Cortex-M4 core demo, refer this url: https://community.freescale.com/docs/DOC-328365 User can also download the document and source code from Github: https://github.com/jenniezhjun/Kinetis-Bootloader.git Thanks for the great support from Chaohui Guo and his team. NOTE: The bootloader and GUI code are all open source, users can revise them based on your own requirement. Enjoy Bootloader programming 🙂
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 grou nding 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: Figur e 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.
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 🙂
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.
Introduction What is a gated timer and why would I need one? A gated timer is a timer whose clock is enabled (or "gated") by some external signal. This allows for a low code overhead method of synchronizing a timer with an event and/or measuring an event. This functionality is not commonly included on Freescale microcontroller devices (this functionality is only included on d evices that are equipped with the upgraded TPM v2 peripheral; currently K66, K65, KL13, KL23, KL33, KL43, KL03) but can be useful in some situations. Some applications which may find a gated timer useful include asynchronous digital sampling, pulse width duty cycle measurement, and battery charging. How do I implement a gated timer with my Kinetis FTM or TPM peripheral? To implement a true gated timer with a Kinetis device (that does not have the TPM v2 peripheral), additional hardware will be required to implement the enable/disable functionality of a gated timer. This note will focus on two different ways (low-true and high-true) to implement a gated timer. The method used will depend on the requirements of your application. Implementing a gated timer for Kinetis devices without the TPM v2 peripheral requires the use of a comparator and a resistive network to implement a gated functionality (NOTE: Level shifters could be used to replace the resistive network described; however, a resistive network is likely more cost effective, and thus, is presented in this discussion). Figure 1 below is the block diagram of how to implement a gated timer functionality. The theory behind this configuration will be explained in later sections. Theory of Operation Comparator and resistive network implementation The comparator is the key piece to implementing this functionality. For those with little experience with comparators (or need a refresher), a comparator is represented by the following figure. Notice that there are three terminals that will be of relevance in this application: a non-inverting input (labeled with a '+' sign), an inverting input (labeled with a '-' sign), and an output. A comparator does just what the name suggests: it compares two signals and adjusts the output based on the result of the comparison. This is represented mathematically in the figure below. Considering the above figure, output of the comparator will be a logic high when the non-inverting input is at a higher electric potential than the inverting input. The output will be a logic low if the non-inverting input is at a lower electric potential than the inverting input. The output will be unpredictable if the inputs are exactly the same (oscillations may even occur since comparators are designed to drive the output to a solid high or solid low). This mechanism allows the clock enable functionality that is required to implement a gated timer function provided that either the non-inverting or inverting input is a clock waveform and the opposite input is a stable logic high or low (depending on the desired configuration) and neither input is ever exactly equal. Comparator Configurations There are two basic signal configurations that an application can use to enable the clock output out of the comparator: low-true signals and high-true signals. These two signals and some details on their implementation are explained in the following two sections. Low-true enable A low-true enable is an enable signal that will have zero electric potential (relative to the microcontroller) or a "grounded" signal in the "active" state. This configuration is a common implementation when using a push button or momentary switch to provide the enable signal. When using this type of signal, you will want to connect the enable signal to the non-inverting input of the comparator, and connect the clock signal to the inverting input. The high level of the enable signal should be guaranteed to always be the highest voltage of the input clock plus the maximum input offset of the comparator. To find the maximum input offset of the comparator, consult the device specific datasheet. See the figure below to see a graphical representation of areas where the signal will be on and off. The external hardware used should ensure that the low level of the enable signal never dips below the lowest voltage of the input clock plus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. High-true enable A high-true enable is an enable signal that will have an electric potential equal to VDD of the microcontroller in the "active" state. This configuration is commonly implemented when the enable signal is provided by an active source or another microcontroller. When interfacing with this type of signal, you will want to connect the enable signal to the inverting input of the comparator, and connect the clock signal to the non-inverting input. When the comparator is in the inactive state, it should be at or below the lowest voltage of the clock signal minus the maximum input offset of the comparator. Refer to the following figure for a diagram of the "on" and "off" regions of the high true configurations. The external hardware will need to guarantee that the when the enable signal is in the active state, it does not rise above the highest voltage of the clock signal minus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. Clocking Options Clocking waveform requirements will vary from application to application. Specifying all of the possibilities is nearly impossible. The point of this section is to inform what options are available from the Kinetis family and provide some insight as to when it might be relevant to investigate each option. The Kinetis family provides a clock output pin for most devices to allow an internal clock to be routed to a pin. The uses for this option can vary. In this particular scenario, it will be used to provide the source clock for the comparator clock input. Here are the most common clock output pin options across the Kinetis K series devices. (NOTE: If the application requires a clock frequency that the CLKOUT signal cannot provide, a separate FTM or TPM instance or another timer module can be used to generate the required clock.) In the Kinetis L series devices, the following options will be available. The clock option selected should be the slowest allowable clock for the application being designed. This will minimize the power consumption of the application. For applications that require high resolution, the Bus, Flash, or Flexbus clock should be selected (note that the Flexbus clock can provide an independently adjustable clock, if it is not being used in the application, as it is always running). However, if the target application needs to be more power efficient, the LPO or MCGIRCLK should be used. The LPO for the Kinetis devices is a fixed 1 kHz frequency and will, therefore, only be useful in applications that require millisecond resolutions.