1.jicheng0622-AET-电子技术应用 2.wuyage-AET-电子技术应用 3.fanxi123-AET-电子技术应用

As general introduction on thread https://community.freescale.com/docs/DOC-328302 , I did a smart LED application with GoKit and FRDM-KL02. In this design, FRDM-KL02 will communicate with GoKit by WIFI, and control LED flash. Code Structure Code Basic Introduction In this project structure, you need to do following items on code. ü Add your functions, such as UART, LED, motor driver code. ü Add function running functions in protocol.c ü Add functions order in main loop. You can find my main.c and protocol.c as attachment. In this document, I would like to detail introduce function MessageHandle()， void MessageHandle(void) {                 pro_headPart    tmp_headPart; //Common command package                 memset(&tmp_headPart, 0, sizeof(pro_headPart));                 if(get_one_package)                 {                                                                              get_one_package = 0;                                 memcpy(&tmp_headPart, uart_buf, sizeof(pro_headPart));                                                                 //CRC error, send back error command                                 if(CheckSum(uart_buf, uart_Count) != uart_buf[uart_Count-1])                                 {                                                 SendErrorCmd(ERROR_CHECKSUM, tmp_headPart.sn);                                                 return ;                                 }                                 So, you can see that only get_one_package=1, we can receive frame completely.                                 switch(tmp_headPart.cmd)                                 {                                                              case       CMD_GET_MCU_INFO:                                                                 CmdGetMcuInfo(tmp_headPart.sn);                                                                                                                                     break;                                                                   case CMD_SEND_HEARTBEAT:                                                                 SendCommonCmd(CMD_SEND_HEARTBEAT_ACK, tmp_headPart.sn);                                                                                 break;                                                 case CMD_REBOOT_MCU:                                                                 SendCommonCmd(CMD_REBOOT_MCU_ACK, tmp_headPart.sn);                                                 case       CMD_SEND_MCU_P0:                                                                 CmdSendMcuP0(uart_buf);                                                                 break;                                                 case       CMD_REPORT_MODULE_STATUS:                                                                 CmdReportModuleStatus(uart_buf);                                                                 break;                                                 default:                                                                 SendErrorCmd(ERROR_CMD, tmp_headPart.sn);                                                                 break;                                 }                              } } After that, you can do operations mentioned in thread https://community.freescale.com/docs/DOC-328302. You can see smart LED device and been found.

There is a popular WIFI platform called “GoKit” in China. This testing kit can be use to do some customized application. Not only WIFI communication, kit also support other functions. You can find interfaces listed as below. GoKit Interfaces: I try to use FRDM-KL02 to communicate with this kit to do a WIFI communication application. Board connection as below. This platform has two running mode. One is AirLink mode, and another is normal running mode. AirLink mode is used to WIFI communication or pair. Go to AirLink mode steps: Power on FRDM-KL02 Long press key1 to reset WIFI module. Wait until RED led on. Short press Key2 to go into configuration mode, wait until RED led flash on WIFI module. Open demo APP, select “adding device”, input SSID password. Waiting for configuration finish. Command Format HOF: 2bytes, value 0xFFFF Length: 2bytes Cmd:1byte SN:1byte Flags:2bytes DATA: Xbytes Checksum:1byte WIFI acquire device information MCU inform WIFI into configure mode MCU reset WIFI WIFI inform MCU status WIFI ask for reset Illegal command For detail code, I will post another thread for your reference.

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 🙂

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

The FlexIO module was first introduced in the Freescale Kinetis KL43 family. It is capable of emulating various serial communication protocols including: UART, SPI and I2C. The FlexIO module is very flexible and you can configure it according to your communication needs. The main components of the FlexIO module are the shifters, timers, and pins. Data is loaded onto a shifter and a timer is assigned to generate the shifter clock and use a pin to output the data from the shifter. The KL43 FlexIO module has 4 32-bit shifters, 4 16-bit timers and 8 bidirectional I/O pins. Each shifter and timer has its own configuration registers. The most important registers that configure the whole FlexIO behavior are the SHIFTCFG, SHIFTCTL, TIMCFG, TIMCTL and TIMCMP registers. There are other registers that contain status flags, interrupt enabling bits and the buffers for the shifters. Shifters have a timer assigned to them to generate the shift clock and it can be configured to shift data in or out. When the shifter is configured to transmit mode, the data from the SHIFTBUF register will be loaded to the shifter and the shifter status flag will be set meaning that the shifter is ready to start the transmission. In receive mode, the shifter status flag is set when SHIFTBUF has been loaded with the data from the shifter, and the status flag is cleared when the SHITBUF register is read. The timers are highly configurable, they can use external or internal triggers to generate certain conditions to reset, enable and disable the timer. The triggers can be a timer output, shifter status flag, pin input or an external trigger input. They can be configured to enable in response to a trigger, pin or shifter condition. Each shifter or timer can be configured to use any FlexIO pin with either polarity. The pins can be used as an input or output. A pin configured as an input for a timer can be used to receive a clock and use it as the shifter clock that is assigned to this timer. Once everything is configured you need to read/write the shifter buffers and the shifter and timer status flags to start a transmission or to read the contents of the shifter buffer when receiving data. The following diagram gives a high-level overview of the configuration of FlexIO timers and shifters. Figure 1. FlexIO block diagram In the following example configuration, the FlexIO module will be configured as a transmitter. It will use one shifter, two timers, and three pins. The pins will be used for the outputs of the shifter and the two timers. One timer will be used as the shifter clock and the other timer will be used as a chip select to show when a transmission is being made. The FlexIO will be configured to have a baud rate of FlexIO clock/4 and will do an 8-bit transmission. Figure 2. Example transmission Timer 0 Timer Configuration 0 Register (FLEXIO_TIMCFG0) = 0x00002200 TIMOUT = 0    Timer output is logic one when enabled and is not affected by timer reset. TIMDEC = 0    Decrement counter on FlexIO clock, Shift clock equals Timer output. TIMRST = 0    Timer never reset. TIMDIS = 2    Timer disabled on Timer compare. TIMENA = 2    Timer enabled on Trigger high. TSTOP  = 0    Stop bit is disabled. TSTART = 0    Start bit disabled. Timer Control 0 Register (FLEXIO_TIMCTL0) = 0x01C30101 TRGSEL = 1    Trigger select. Shifter 0 status flag. TRGPOL = 1    Trigger active low. TRGSRC = 1    Internal trigger selected. PINCFG = 3    Timer pin output. PINSEL = 1    Timer pin 1 select. PINPOL = 0    Pin is active high. TIMOD  = 1    Dual 8-bit counters baud/bit mode. Timer Compare 0 Register (FLEXIO_TIMCMP0) = 0x00000F01 TIMCMP = 0x00000F01        Configure 8-bit transfer with a baud rate of FlexIO clock/4. Set TIMCMP[15:8] = (number of bits x 2) - 1. Set TIMCMP[7:0] = (baud rate divider / 2) - 1. In our case we want an 8-bit transfer so TIMCMP[15:8] = 0xF and a baud rate divider of 4 so TIMCMP[7:0] = 0x1. Timer 1 Timer Configuration 1 Register (FLEXIO_TIMCFG1) = 0x00001100 TIMOUT = 0    Timer output is logic one when enabled and is not affected by timer reset. TIMDEC = 0    Decrement counter on FlexIO clock, Shift clock equals Timer output. TIMRST = 0    Timer never reset. TIMDIS = 1    Timer disabled on Timer N-1 disable. TIMENA = 1    Timer enabled on Timer N-1 enable. TSTOP  = 0    Stop bit is disabled. TSTART = 0    Start bit disabled. Timer Control 1 Register (FLEXIO_TIMCTL1) = 0x00030283 TRGSEL = 0    Trigger select. Doesn’t matter because we won’t use a trigger. TRGPOL = 0    Trigger active high. TRGSRC = 0    External trigger selected. PINCFG = 3    Timer pin output. PINSEL = 2    Timer pin 2 select. PINPOL = 1    Pin is active low. TIMOD  = 3    Single 16-bit counter mode. Timer Compare 1 Register (FLEXIO_TIMCMP1) = 0x0000FFFF TIMCMP = 0x0000FFFF Never compare. Shifter 0 Shifter Control 0 Register (FLEXIO_SHIFTCTL0) TIMSEL = 0    Timer 0 select. TIMPOL = 0    Shift on posedge of Shift clock. PINCFG = 3    Shifter pin output. PINSEL = 0    Shifter pin 0 select. PINPOL = 0    Pin is active high. SMOD   = 2    Transmit mode. Load SHIFTBUF contents into the Shifter on expiration of the Timer. Shifter Configuration 0 Register (FLEXIO_SHIFTCFG0) INSRC  = 0    The input source of the shifter is from a pin. In our cause this doesn’t matter because our shifter is set as transmit mode. SSTOP  = 0    Stop bit disabled. SSTART = 0    Start bit disabled. Once all the FlexIO components are configured you have to enable the FlexIO instance by setting the FLEXEN bit in the FLEX_CTRL register. Initially, the shifter status flag is set and is cleared each time the SHIFTBUF register is written. This flag is set each time the SHIFTBUF data has been transferred to the Shifter (SHIFTBUF is empty).  The shifter status flag 0 is configured to be the trigger of the timer 0, so as soon as the status flag is cleared, the timer 0 will be enabled because TIMENA = 2 (Timer enabled on Trigger high)and TRGPOL = 1 (Trigger active low). The shifter will begin to shift out the data on the positive edge of the clock (TIMPOL = 0) until the timer is disabled. The timer will disable when the timer counter reaches 0 (TIMDIS = 2). The timer 1 is configured to be active (low) when the timer 0 is enabled. This is because TIMDIS = 1 and TIMENA = 1. The compare register is configured to 16-bit counter and set to 0xFFFF. With this value the timer will never compare and always be active when the timer is enabled. To send data, you have to make sure that the previous transaction was completed and you can check this by reading the TIMSTAT flag. This flag sets each time the timer counter reaches 0. Once the TIMSTAT flag is set, you clear it and write your new data to the SHITBUF register to start the transaction. The KSDK 1.2.0 has drivers and a HAL to facilitate the configuration of the FlexIO module. Some of the important functions are: FLEXIO_DRV_Init(uint32_t instance, const flexio_user_config_t *userConfigPtr); Use this function to initialize the FlexIO module before using it. In this configuration you can change the settings in the FLEXIO_CTRL register such as: Doze Enable, Debug Enable, Fast Access and software reset. FLEXIO_HAL_ConfigureTimer(FLEXIO_Type * base, uint32_t timerIdx, const flexio_timer_config_t *timerConfigPtr); Use this function to configure a timer in the FlexIO. This function uses a configuration structure that can change the TIMCFG, TIMCTL and TIMCPM registers. FLEXIO_HAL_ConfigureShifter(FLEXIO_Type * base, uint32_t shifterIdx, const flexio_shifter_config_t *shifterConfigPtr); Use this function to configure a shifter in the FlexIO. This function uses a configuration structure that can change the SHIFTCFG and SHIFTCTL registers. FLEXIO_HAL_SetShifterBuffer(FLEXIO_Type * base, uint32_t shifterIdx, uint32_t value); Use this function to start a transmission. When writing to the SHIFTBUF register, the Shifter Status Flag is cleared. FLEXIO_DRV_Start(uint32_t instance); Use this function to enable the FlexIO module by setting the FLEXEN bit in the FLEX_CTRL register. FLEXIO_HAL_GetTimerStatusFlags(FLEXIO_Type * base); This function returns the contents of the TIMSTAT register. You can use this function to check when a transmission is finished. FLEXIO_HAL_ClearTimerStatusFlags(FLEXIO_Type * base, uint32_t mask); This function clears a specific Timer Status Flag. You can use this function to clear a flag after you read that the flag was set. To change the frequency of the transmission you have to change the value of the TIMCMP register. In dual 8-bit counters baud/bit mode, the lower 8-bits configures the baud rate divider equal to (CMP[7:0] + 1) * 2 and the upper 8-bits configure the number of bits in each word equal to (CMP[15:8] + 1) / 2. In our example the baud rate divider is set to 4, this means CMP[7:0] has the value 1. The number of bits transmitted is set to 8, this means CMP[15:8] has the value 0xF. Let’s change the baud rate divider to 32. To obtain the CMP[7:0] value, we will have to solve the simple equation: 32 = (CMP[7:0]+1)*2 CMP[7:0] = 15=0xF Now let’s change the number of bits to 16. The CMP[15:8] value is defined by: 16 = ((CMP[15:8]+1))/2 CMP[15:8] = 31=0x1F The value for the TIMCMP for the timer 0 has to be 0x00001F0F to get a baud rate divider of 32 and a word length of 16 bits. The waveform will look as follows. Figure 3. 16-bit transmission By default the shifter in the FlexIO transmits the LSB first. To change the transmission order, you have to write to the SHIFTBUFBIS (Bit swapped) register instead of the SHIFTBUF register. There are also other buffer registers: SHIFTBUFBYS and SHIFTBUFBBS. The first register swaps the bytes and the second register swaps the bytes and bits at the same time. When using one of these registers you have to be careful to consider that the length of the SHIFTBUF registers is of 32 bits, so if you choose to use the SHIFTBUFBIS for a transmission and your transmission length is not of 32 bits, you have to start writing your data starting from the most significant bit. The following image shows a MSB transmission. The value 0x6AED0000 was written to the SHIFTBUFBIS register. Figure 4. MSB 16-bit transmission The FlexIO module supports automatic start and stop bit handling. All you have to do is change the SHIFTCFG and the TIMCFG configuration bits. In the SHIFTCFG register set SSTOP to 11 if you want the stop bit to have the value 1, and set the SSTART to 10 if you want the stop bit to have the value 0. In the TIMCFG register set the TSART to 1 and the TSOP to 10. The transmission will look as the following image. Data transmitted 0x0F. Figure 5. Transmission with start and stop bit Changing the phase of the clock is very easy, you just have to set the TIMPOL bit to 1 in the SHIFTCTL register. Figure 6. Shift on negedge of Shift clock The conditions to disable and enable the timers can be configured by changing the TIMENA and TIMDIS values in the TIMCFG register. In our example the timer is enabled by the trigger high. The trigger can be set to be an external pin, a shifter status flag, or a timer output. In our case the trigger was set to the shifter status flag, but you can change this configuration to your communication needs. The timer can also be enabled when the previous timer is enabled, on a certain pin edge, or with a combination of pins and triggers. The timer in the example above disables on the timer compare. This means that when the timer counter reaches zero, the timer will disable automatically. The timer counter is loaded with the timer compare value every time it reaches zero or when it is first enabled.  The timer can also be disabled by other conditions such as: when the previous timer is disabled, on a trigger falling edge, on a pin edge, or on a combination of these. Each pin can be configured to be active high or low. When a pin polarity is changed it only affects the output of the pin, for example, if a timer is set to be the shifter clock and you change the pin polarity, the shifter clock will not change its polarity, only the output to the pin from the timer will change. The configuration for the polarity of the pins is located in the TIMCTL and SHIFTCTL. When the PINPOL value is changed to 1, the pin is active low. In the following image the polarity of the timer pin and the shifter pin was changed to 1, so they are active low. Figure 7. Timer and Shifter active low The FlexIO module can generate an interrupt from 3 sources: Shifter error, Shifter status flag and Timer status flag. To enable the interrupts you need to set the bits in the SHIFTSIEN,SHIFTEIEN and TIMIEN. If you are using KSDK you can enable the interrupt in NVIC by setting true .useInt in the FlexIO user config that the function FLEXIO_DRV_Init utilizes. The default handler for the interruption is named UART2_FLEXIO_IRQHandler. The following example configuration will configure the FlexIO module as a receiver. This configuration works with the first example configuration shown. Both tower boards (TWR-KL43Z48M) have to be connected as shown further below in the Table 1 Hardware connnections. The FlexIO module will use one Shifter, one timer, and three pins. The pins will be used for the input of the shifter, the input clock for the timer and the trigger for the timer. The timer will use pin 1 as an input and its output will be the same as the input clock. The trigger for the timer will be the transmitter chip select pin and it will be used to enable or disable the timer. The FlexIO will be configured to do an 8-bit transmission. Shifter 0 Shifter Control 0 Register (FLEXIO_SHIFTCTL0) = 0x00800001 TIMSEL = 0    Timer 0 select. TIMPOL = 1    Shift on negedge of Shift clock. PINCFG = 0    Shifter pin output disabled. PINSEL = 0    Shifter pin 0 select. PINPOL = 0    Pin is active high. SMOD   = 1    Receive mode. Captures the current Shifter content into the SHIFTBUF on expiration of the Timer. Shifter Configuration 0 Register (FLEXIO_SHIFTCFG0) = 0x00000000 INSRC  = 0    The input source of the shifter is from a pin. In our cause this doesn’t matter because our shifter is set as transmit mode. SSTOP  = 0    Stop bit disabled. SSTART = 0    Start bit disabled. Timer 0 Timer Configuration 0 Register (FLEXIO_TIMCFG0) = 0x01206602 TIMOUT = 1    Timer output is logic zero when enabled and is not affected by timer reset. TIMDEC = 2    Decrement counter on Pin input (both edges), Shift clock equals Pin input. TIMRST = 0    Timer never reset. TIMDIS = 6    Timer disabled on Trigger rising edge. TIMENA = 6    Timer enabled on Trigger falling edge. TSTOP  = 0    Stop bit is disabled. TSTART = 1    Start bit enabled. Timer Control 0 Register (FLEXIO_TIMCTL0) = 0x04C00103 TRGSEL = 4    Trigger select. Pin 2 input. TRGPOL = 1    Trigger active low. TRGSRC = 1    Internal trigger selected. PINCFG = 0    Timer pin output disabled. PINSEL = 1    Timer pin 1 select. PINPOL = 0    Pin is active high. TIMOD  = 3    Single 16-bit counter mode. Timer Compare 0 Register (FLEXIO_TIMCMP0) = 0x0000000F TIMCMP = 0x0000000F Configure 8-bit transfer. Set TIMCMP = (number of bits x 2) - 1. The shifter status flag is set every time the SHIFTBUF register has been loaded with data from the shifter. This occurs every time that the transmitter sends 8 bits of data. You can read the shifter status flag by polling or by enabling an interrupt based on your needs. This flag clears automatically when you read the SHITBUF register. During the transmission, the first thing that happens is that timer from the receiver will be enabled because the chip select signal from the transmitter is configured as a trigger. Once the timer is enabled, the timer will begin to decrement on the pin input, this means that the shifter clock of the receiver will be equal to the pin input. The transmitter shifter is configured to shift data out on the positive edge of the clock and the receiver shifter is configured to shift data in on the negative edge of the clock. After 8 bits have been transmitted, the compare register from the receiver will reach 0 and this generates an event to store the data from the shifter to the SHITBUF register and the Shifter Status Flag will be set. Finally the timer will be disabled by the chip select signal and keep waiting for another transaction. The hardware connections are shown in the following table. Signal name TWR-KL43Z48M transmitter TWR-KL43Z48M receiver Pin name Board Location Pin name Board Location Serial Data PTD0/FXIO0_D0 B46 PTD0/FXIO0_D0 B46 Clock PTD1/FXIO0_D1 B48 PTD1/FXIO0_D1 B48 Chip Select PTD2/FXIO0_D2 B45 PTD2/FXIO0_D2 B45 GND GND B2 GND B2 Table 1. Hardware connections Figure 8. Hardware connections The example projects for the FlexIO transmitter and receiver are developed in KDS 3.0.0 with KSDK 1.2.0. The application lets the user communicate with the transmitter via a serial terminal and the transmitter sends each character to the receiver via FlexIO and the receiver displays the received character on another serial terminal. To be able to compile the project, first you need to compile the library located in C:\Freescale\KSDK_1.2.0\lib\ksdk_platform_lib\kds\KL43Z4. Once the two TWR-KL43Z48M are connected as described above, import both projects into KDS, compile the platform library, and both projects. Open two serial terminals configured to 115200 bauds and run each project on a different tower. On the transmitter terminal you can write anything and it will be displayed and transmitted to the receiver tower via FlexIO and will be shown on the other terminal. Figure 9. FlexIO example application. Transmitter (left terminal). Receiver (Right terminal). The FlexIO module is also capable of generating a PWM signal by configuring one of its timers to the Dual 8-bit counters PWM mode. This mode is configured by writing 01 to TIMOD in the TIMCTL register. In this mode, the lower 8-bits of the counter and compare register are used to configure the high period of the timer output and the upper 8-bits are used to configure the low period of the timer output. The shifter bit count is configured using another timer or external signal. To calculate the frequency of the PWM signal you have to add the lower 8-bits of the counter and the upper 8-bits and divide it by the FlexIO clock*2 (Only if the timer is configured to decrement on the FlexIO clock.) The frequency of the PWM signal is given by: f = (FlexIO clock)/(TIMCMP[15:8]+TIMCPM[7:0]+2) To calculate the TIMCMP values to get a certain frequency you can solve the equation for TIMCMP TIMCMP[15:8]+TIMCPM[7:0] = (FlexIO clock)/f-2 For example, let’s say we want a 200kHz PWM signal, by using the formula above and using the FlexIO clock of 48MHz, we get that the sum of the TIMCMP values must be 238. If we want a 50% duty cycle we need to write the value 238/2 to the lower and upper 8 bits of the TIMCMP register. The waveform generated by these settings is shown in the figure below. Figure 10. 200kHz 50% duty cycle PWM signal To change the duty cycle you need to change the values of TIMCPM[15:8] and TIMCPM[7:0] but without changing the sum of both values, otherwise the frequency will also be altered. For example, if we need a 20% duty cycle we multiply 0.20*238 and 0.8*238. We round up the results and get TIMCPM[7:0] = 48 and TIMCPM[15:8] = 190. The waveform generated will look as shown in the figure below. Figure 11. 200kHz 20% duty cycle PWM signal

ROM Bootloader KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports. When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash. The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader. For example:       When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;       When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application). There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT]  = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0. blhost utility application The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder. About how to use blhost application, please check KBLHOSTUG document for more detailed info. Call Rom Bootloader from customer application In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example. Set a signal for application code to call the ROM bootloader, such as press a button. In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader. //Initalize PTEC3 as GPIO button PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL); GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3); The bootloader entry point for customer application to call the ROM bootloader.  //prototype of the entry point definition void run_bootloader(void * arg); //Variables uint32_t runBootloaderAddress; void (*runBootloader)(void * arg);   // Read the function address from the ROM API tree. runBootloaderAddress = **(uint32_t **)(0x1c00001c); runBootloader = (void (*)(void * arg))runBootloaderAddress; in <main.c> routine to call the ROM bootloader:   while (1)   {     if ((GPIOC_PDIR & (1 << 3)) == 0)     {       // Start the bootloader. runBootloader(NULL);     }   } Press SW3 button of FRDM-KL43Z board will call ROM bootloader.  Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0. In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43. When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product. More detailed info, please check attached demo code. BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.

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.

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.

Hi everyone,      I have got customer queries on unavailability of complementary mode PWM on KL25Z . So, I thought let me experiment something and post it onto the community.      The timer module on KL25 is TPM, not FTM!. There are 3 TPMs, TPM0 with 6 channels, TPM1 and TPM2 with 2 channels each. To generate a PWM signal, PWM component can be used. But the PWM bean doesnot provide option to generate complementary PWM. So, we need to configure different channels to get the complementary PWM. Again, there is a limitation for this. PWM component doesn't allow to generate initial polarity high. It says "the inherited component doesnot support this feature". But in run time can set or clear value on the PWM output pin using the SetValue() and ClrValue(). But again the inherited component"TimerUnit_LDD" doesn't support generating SetValue() and ClrValue().      So, I came to a conclusion 'not to use PWM component' and started using Init_TPM. Using this component, 2 channels are configured to have opposite polarity during initialization. They are configured to have the same period. Deadtime is also inserted by configuring different duty cycle on each channel. But methods are not available since the component only provides the initialization function which is good enough to start . Dynamically if dutycycle needs to be changed, methods have to be written explicitly     Project and oscilloscope captures are attached for reference. Hi Note that this is also supported in the uTasker project - see http://www.utasker.com/docs/uTasker/uTaskerHWTimers.PDF See specifically the final page - this is compatible for K and KL processors. Regards Mark http://www.utasker.com/kinetis.html This document was generated from the following discussion: Complementary PWM on FRDM-KL25Z using processor expert

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

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 🙂

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

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

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.

The following file contains codewarrior code that was migrated from the IAR example code in the sample code package at the freescale webpage. It contains the following examples: adc_demo freedom_greem_led freedom_red_led lcd_rtc_lowpower PIT_basic sLCD_freedom uart_low_power_wu_dut Regards

1. How Calibration works There are three main sub-blocks important in understanding how the Kinetis SAR module works.  There is a capacitive DAC, a comparator, and the SAR engine that controls the module. Of those blocks, the DAC is most susceptible to variations that can cause linearity problems in the SAR. The DAC is architected with three sets of binary weighted capacitors arrayed in banks, as in Figure 1. The capacitors that represent the most significant bits of the SAR (B15:B11) are connected directly to the inputs of the comparator. The next bank of five capacitors (B10:B6) is connected to the top plate of the MSB array through an intentionally oversized scaling capacitor. The final six capacitors that makeup the least significant bits of the SAR (B5:B0) are correspondingly connected to the top plate of the middle bank of capacitors through another scaling capacitor. Figure 1. Arrangement of DAC capacitors Only the MSB capacitor bank is calibrated. Because the first scaling capacitor is intentionally oversized, each of the non-calibrated MSB capacitors will have an effective capacitance too small to yield accurate results. However, because they are always too small, we can measure the amount oferror that each of those capacitors would cause individually, and add that back in to the result. Calibration starts with the smallest of the LSB capacitors, B11. The SAR samples Vrefl on all of the capacitors that are lower-than or equal-to the capacitor under test (CUT), while connecting all of the smaller capacitors to Vrefh. The top plate of all of the MSB capacitors is held at VDDA while this happens. After the sampling phase is complete, the top plates of the MSB capacitors are allowed to float, and the bottom plates of the MSBs not under test are connected to Vrefl. This allows charge to redistribute from the CUT to the smaller capacitors. Finally, an 11 bit SAR algorithm (corresponding with the 11 capacitors that are smaller than the MSB array) is performed which produces a result that indicates the amount of error that the CUT has compared to an ideally sized capacitor. This process is repeated for each of the five MSBs on both the plus side and minus side DACs and the five error values that are reported correspond to the five MSBs accordingly. All of these error values are about the same magnitude, with a unit of 16-bit LSBs. See Figure 2 for an example. Figure 2. Example of calibration on bit 11 The DAC MSB error is cumulative. That is, if bit 11 of the DAC is set, then the error is simply the error of that bit. However if bit 12 of the DAC is set, the total error is equivalent tothe error reported on bit 12, plus the error reported on bit 11. For each MSB the error is calculated as below, where Ex is the error found during the calibration for its corresponding MSB bit: When bit 11 of the DAC is set: CLx0 = E0. When bit 12 of the DAC is set: CLx1 = E0+E1. When bit 13 of the DAC is set: CLx2 = E2 + E1 + 2E0. When bit 14 of the DAC is set: CLx3 = E3 + E2 + 2E1 + 4E0. When bit 15 of the DAC is set: CLx4 = E4 + 2E3 + 4E2 + 8E1 + 16E0 Figure 3. Effect of calibration error on ADC response These are the values that are then placed in each of the CLxx calibration results registers. Figure 3 shows how the errors would accumulate if all of the CLxx registers were set to zero. The offset and gain registers are calculated based on these values as well. Because of this, the gain and offset registers calibrate only for errors internal to the SAR itself. Self calibration does not compensate for board or system level gain or offset issues. 2. Recommended Calibration Procedure From the above description it is evident that the calibration procedure is in effect several consecutive analog to digital conversions. These are susceptible to all of the same sources of error of any ADC conversion. Because what is primarily being measured is the error in the size of the MSB capacitors; the recommendation is to configure the SAR in such a way as to make for the most accurate conversions possible in the environment that the SAR is being calibrated in. Noise is the primary cause of run-to-run variation in this process,so steps should be taken to reduce the impact of noise during the calibration process. Such as: All digital IO should be silent and unnecessary modules should be disabled. The Vrefh should be as stable and high a voltage as possible, since higher Vrefh means larger ADC code widths. An isolated Vrefh pin would be ideal. Lacking that, using an isolated VDDA as the reference would be preferable to using VREFO. The clock used should be as noise free as possible, and less than or equal to 6 MHz. For this purpose the order of desirable clock sources for calibration would be OSC > PLL > FLL > ASYNC The hardware averaging should be set to the maximum 32 samples. The Low Power Conversion bit should be set to 0. The calibration should be done at room temperature. The High Speed Conversion and Sample Time Adder will not have much effect in most situations, and the Diff and Mode bits are completely ignored by the calibration routine. The calibration values should be taken for each instance of the SAR on a chip in the above conditions. They should be stored in nonvolatile memory and then written into their appropriate registers whenever the ADC register values are cleared. In some instances, the system noise present will still cause the calibration routine to exhibit greater than desired run-to-run variation. One rule of thumb would be to repeat calibration several times and look at the CLx0 registers. If the value reported in that register varies by more than three, the following procedure can be implemented. Run the calibration routine several times. Twenty to forty times. Place the value of each of the calibration registers into a corresponding array. Perform a bubble sort on each array and find the median value for each of the calibration registers. Use  these median values as described for typical calibration results.

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

Hello Freedom community users Bheema has posted on the Element14 community a very clear tutorial (accessible following the link below) to create from scratch a basic project example featuring the SLCD of the FRDM-KL46Z with Processor Expert. Freescale Freedom development platform: [FRDM-K... | element14 Those steps should be very useful to create your own project featuring SLCD display and better understand the constraints of this peripheral. Happy SLCD Displaying Greg

Hello Freedom users I have created another full board review this time for the FRDM-KL05Z always including clear instructions to program and debug your first project. I'm still working on the video version (looking for a better accent :smileyconfused:), but the commands illustrated by screen captures should be easy to follow. Freescale Freedom development platform: [FRDM-K... | element14 Enjoy Greg