OpenSDA/OpenSDAv2 is a serial and debug adapter that is built into several Freescale evaluation boards. It provides a bridge between your computer (or other USB host) and the embedded target processor, which can be used for debugging, flash programming, and serial communication, all over a simple USB cable.   The OpenSDA hardware consists of a circuit featuring a Freescale Kinetis K20 microcontroller (MCU) with an integrated USB controller. On the software side, it implements a mass storage device bootloader which offers a quick and easy way to load OpenSDA applications such as flash programmers, run-control debug interfaces, serial to USB converters, and more. Details on OpenSDA can be found in the OpenSDA User Guide.     The bootloader and app firmware that lay on top of the original OpenSDA circuit was proprietary.  But recently ARM decided to open source their CMSIS-DAP interface, and now a truly open debug platform could be created. This new open-sourced firmware solution is known as OpenSDAv2.   OpenSDAv2: OpenSDAv2 uses the exact same hardware circuit as the original OpenSDA solution, and out of the box it still provides a debugger, drag-and-drop flash programmer, and virtual serial port over a single USB cable.   The difference is the firmware implementation: OpenSDA: Programmed with the proprietary P&E Micro developed bootloader. P&E Micro is the default debug interface app. OpenSDAv2: Programmed with the open-sourced CMSIS-DAP/mbed bootloader. CMSIS-DAP is the default debug interface app.       Firmware Developer Kinetis K20 Based Hardware Circuit Default Debug Interface Drag-and-drop Target MCU Flash Programming Virtual Serial Port Source Code Available OpenSDA P&E Micro x P&E Micro .srec/.s19 x   OpenSDAv2 ARM/mbed.org x CMSIS-DAP .bin x x   The bootloader and app firmware used by OpenSDAv2 is developed by the community at mbed.org, and is known as “CMSIS-DAP Interface Firmware”. If you explore that site, you will find that this firmware was also ported to run on other hardware, but the combination of this mbed.org firmware with the Kinetis K20 MCU is known as OpenSDAv2.   It is important to understand however that it is possible to run a P&E Micro debug app on the CMSIS-DAP/mbed bootloader found on OpenSDAv2. Likewise it is possible to run a CMSIS-DAP debug app on the P&E Micro bootloader found on OpenSDA. The debug application used needs to be targeted towards a specific bootloader though, as a single binary cannot be used on both the OpenSDA and OpenSDAv2 bootloaders.   OpenSDAv2.1: During development of OpenSDAv2 features and bug fixes, it was found that the reserved bootloader space was too small. Thus a new version of OpenSDAv2 had to be created, which was named OpenSDAv2.1. The difference between the OpenSDAv2.0 and v2.1 is the address where the debug application starts: for OpenSDAv2.0 it expects the application at address 0x5000, while OpenSDAv2.1 expects the application to start at address 0x8000.   The only board with OpenSDAv2.0 is the FRDM-K64F. All other OpenSDAv2 boards (such as the just released FRDM-K22F) use OpenSDAv2.1.   Unfortunately this means that new OpenSDAv2 apps are needed. From a user perspective this mostly affects the JLink app since it was shared across all boards. Make sure you download the correct app for your board based on the OpenSDAv2 version.   OpenSDAv2 Apps: mbed CMSIS-DAP for FRDM-K64F mbed CMSIS-DAP for FRDM-K22F P&E Micro  (use the Firmware Apps link) Segger JLink (look at bottom of page for OpenSDAv2.0 or OpenSDAv2.1 app)   OpenSDAv2 Bootloader: The key difference between OpenSDA and OpenSDAv2 is the bootloader. Boards with OpenSDA use a proprietary bootloader developed by P&E Micro, and it cannot be erased or reprogrammed by an external debugger due to the security restrictions in the firmware. Boards with OpenSDAv2 use the open-source bootloader developed by mbed.org, and it can be erased and reprogrammed with an external debugger.   Apps need to be specifically created to work with either the P&E bootloader (Original OpenSDA) or the CMSIS-DAP/mbed bootloader (OpenSDAv2/OpenSDAv2.1) as the bootloader memory map is different.  Thus it’s important to know which type of bootloader is on your board to determine which version of an app to load.   You can determine the bootloader version by holding the reset button while plugging in a USB cable into the OpenSDA USB port. A BOOTLOADER drive will appear for both OpenSDA and OpenSDAv2.   The OpenSDAv2.0 bootloader (may also be called the CMSIS-DAP/mbed bootloader) developed by mbed.org will have the following files inside.  Viewing the HTML source of the bootload.htm file with Notepad will tell you the build version, date, and git hash commit. For the OpenSDAv2.1 bootloader, this file will be named mbed.htm instead.     The OpenSDAv1 bootloader developed by P&E Micro will have the following inside. Clicking on SDA_INFO.HTM will take you to the P&E website.       Using CMSIS-DAP: When you connect a Freedom board that has OpenSDAv2 (such as the FRDM-K64F) to your computer with a USB cable, it will begin running the default CMSIS_DAP/mbed application which has three main features.   1. Drag and Drop MSD Flash Programming You will see a new disk drive appear labeled “MBED”.   You can then drag-and-drop binary (.bin) files onto the virtual hard disk to program the internal flash of the target MCU.   2.Virtual Serial Port OpenSDAv2 will also enumerate as a virtual serial port, which you can use a terminal program , such as TeraTerm (shown below), to connect to. You may need to install the mbed Windows serial port driver first before the serial port will enumerate on Windows properly. It should work without a driver for MacOS and Linux.   3. Debugging The CMSIS-DAP app also allows you to debug the target MCU via the CMSIS-DAP interface. Select the CMSIS-DAP interface in your IDE of choice, and inside the CMSIS-DAP options select the Single Wire Debug (SWD) option:   Kinetis Design Studio (KDS): Note: OpenOCD with CMSIS-DAP for FRDM-K22F is not supported in KDS V1.1.0. You must use either the P&E app instructions or the JLink app instructions to use KDS with the FRDM-K22F at this time. This will be fixed over the next few weeks. OpenSDAv2 uses the OpenOCD debug interface which uses the CMSIS-DAP protocol. Make sure '-f kinetis.cfg' is specified as 'Other Options':   IAR     Keil:         Resources CMSIS-DAP Interface Firmware mbed.org FRDM-K64 Page FRDM-K64 User Guide OpenSDAv2 on MCU on Eclipse blog OpenSDA User Guide KDS Debugging   Appendix A: Building the CMSIS-DAP Debug Application The open source CMSIS-DAP Interface Firmware app is the default app used on boards with OpenSDAv2. It provides: Debugging via the CMSIS-DAP interface Drag-and-drop flash programming Virtual Serial Port providing USB-to-Serial convertor   While binaries of this app are provided for supported boards, some developers would like to build the CMSIS-DAP debug application themselves.   This debug application can be built for either the OpenSDAv2/mbed bootloader, or for the original OpenSDA bootloader developed by P&E Micro. If you are not sure which bootloader your board has, refer to the bootloader section in this document.   Building the CMSIS-DAP debug application requires Keil MDK. You will also need to have the “Legacy Support for Cortex-M Devices” software pack installed for Keil.   You will also need Python 2.x installed. Due to the python script used, Python 3.x will not work.   The code is found in the MBED git repository, so it can be downloaded using a git clone command: “git clone https://github.com/mbedmicro/CMSIS-DAP.git” Note that there is a Download Zip option, but you will run into a issue when trying to compile that version, so you must download it via git instead.   The source code can be seen below:   This repository contains the files for both the bootloader and the CMSIS-DAP debug interface application. We will concentrate on the interface application at the moment.   Open up Keil MDK, and open up the project file located at \CMSIS-DAP\interface\mdk\k20dx128\k20dx128_interface.uvproj In the project configuration drop-down box, you will notice there are a lot of options. Since different chips may have slightly different flash programming algorithms, there is a target for each specific evaluation board. In this case, we will be building for the FRDM-K64F board. Scroll down until you get to that selection:   Notice there are three options for the K64: k20dx128_k64f_if: Used for debugging the CMSIS-DAP application with Keil. Code starts at address 0x0000_0000 k20dx128_k64_if_openSDA_bootloader: Creates a binary to drag-and-drop on the P&E developed bootloader (Original OpenSDA) k20dx128_k64_if_mbed_bootloader: Creates a binary to drag-and-drop onto the CMSIS-DAP/mbed developed bootloader (OpenSDAv2)   Since the FRDM-K64F comes with the OpenSDAv2 bootloader, we will use the 3 rd option. If we were building the mbed app for another Freedom board which had the original OpenSDA bootloader, we would choose the 2 nd option instead.   Now click on the compile icon. You may get some errors If you get an error similar to the one shown below, make sure you have installed the Legacy pack for ARM as previously described earlier:           compiling RTX_Config.c...             ..\..\Common\src\RTX_Config.c(184): error:  #5: cannot open source input file "RTX_lib.c": No such file or directory            and           compiling usb_config.c...             ..\..\..\shared\USBStack\INC\usb_lib.c(18): error:  #5: cannot open source input file "..\..\RL\USB\INC\usb.h": No such file or directory   If you get an error regarding a missing version_git.h file, make sure that Python 2.x and git are in your path. A Python build script fetches that file. It's called from the User tab in the project options, under "Run User Programs Before Build/Rebuild". If there is a warning about “invalid syntax” when running the Python script, make sure your using Python 2.x. Python 3.x will not work with the build script.   Now recompile again, and it should successfully compile. If you look now in \CMSIS-DAP\interface\mdk\k20dx128 you will see a new k20dx128_k64f_if_mbed.bin file   If you compiled the project for the OpenSDA bootloader, there would be a new k20dx128_k64f_if_openSDA.S19 file instead.   Loading the CMSIS-DAP Debug Application: Now take the Freedom board, press and hold the reset button as you plug in the USB cable. Then, drag-and-drop the .bin file (for OpenSDAv2) or .S19 file (for OpenSDA) into the BOOTLOADER drive that enumerated.   Perform a power cycle, and you should see a drive called “MBED” come up and you can start using the CMSIS-DAP debug interface, as well as drag-and-drop programming and virtual serial port as described earlier in this document.   Appendix B: Building the CMSIS-DAP Bootloader All Freedom boards already come with a bootloader pre-flashed onto the K20.  But for those building their own boards that would like to use CMSIS-DAP, or those who would like to tinker with the bootloader, it possible to flash it to the Kinetis K20 device. Flashing the bootloader will require an external debugger, such as the Keil ULink programmer or Segger JLink.   Also note that the OpenSDA/PE Micro Bootloader cannot be erased! Due to the proprietary nature of the P&E firmware used by the original OpenSDA, it can only be programmed at the board manufacturer and JTAG is disabled. So these instructions are applicable for boards with OpenSDAv2 only.   First, open up the bootloader project which is located at \CMSIS-DAP\bootloader\mdk\k20dx128\k20dx128_bootloader.uvproj   There is only one target available because all OpenSDAv2 boards will use the same bootloader firmware as the hardware circuitry is the same.   Click on the compile icon and it should compile successfully. If you see errors about a missing version_git.h file, note that Python 2.x must be in the path to run a pre-build script which fetches that file.   Now connect a Keil ULink to J10 and then insert a USB cable to provide power to J26. Note that if you have the 20-pin connector, you’ll want to use the first 10 pins.   Then for Keil 5 you will need to change some debug options (CMSIS-DAP is built under Keil 4.x).   Right click on the bootloader project, and go to the Debug tab and next to ULINK Pro Cortex Debugger, click on Settings:   Then under “Cortex-M Target Driver Setup”, change the “Connect” drop down box to “under Reset” and “Reset” dropdown box to “HW RESET”. Hit OK to save the settings.     Then in Keil, click on Flash->Erase.   And then on Flash->Download.   If you get an “Invalid ROM Table” error when flashing the CMSIS-DAP bootloader, make sure you made the changes to the debugger settings listed above.   After some text scrolls by, you should see:   Now power cycle while holding down the reset button, and you should see the bootloader drive come up. You’ll then need to drag and drop the mbed application built earlier onto it. And that’s all there is to it!   The binaries for the bootloader and CMSIS-DAP debug app for the FRDM-K64F board created in writing this guide are attached. Original Attachment has been moved to: k20dx128_bootloader.axf.zip Original Attachment has been moved to: k20dx128_k64f_mbed.bin.zip

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.

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

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

The Real Time Clock (RTC) module is the right tool when we want to keep tracking the current time for our applications. For the Freedom Platform (KL25Z) the RTC module features include: 32-bit seconds counter with roll-over protection and 32-bit alarm 16-bit prescaler with compensation that can correct errors between 0.12 ppm and 3906 ppm. Register write protection. Lock register requires POR or software reset to enable write access. 1 Hz square wave output. This document describes how to implement the module configuration. Also, how to modify the hardware in order feed a 32 KHz frequency to RTC module (it is just a simple wire link).     Hardware. The RTC module needs a source clock of 32 KHz. This source is not wired on the board; hence we need to wire it. Do not be afraid of this, it is just a simple wire between PTC3 and PTC1 and the good news are that these pins are external.   PTC1 is configured as the RTC_CLKIN it means that this is the input of source clock.     PTC3 is configured as CLKOUT (several options of clock frequency can be selected in SIM_SOPT2[CLKOUTSEL] register). For this application we need to select the 32 Khz clock frequency.                         RTC configuration using Processor Expert. First of all we need to set the configurations above-mentioned in Component Inspector of CPU component. Enable RTC clock input and select PTC1 in Pin Name field. This selects PTC1 as RTC clock input. MCGIRCLK source as slow in Clock Source Settings > Clock Source Setting 0 > Internal reference clock > MCGIRCLK source. This selects the 32 KHz clock frequency. Set ERCLK32K Clock Source to RTC Clock Input in Clock Source Settings > Clock Source Setting 0 > External reference clock > ERCLK32K Clock Source. This sets the RTC_CLKIN as the 32 KHz input for RTC module. Select PTC3 as the CLKOUT pin and the CLKOUT pin output as MCGIRCLK in Internal peripherals > System Integration Module > CLKOUT pin control. With this procedure we have a frequency of 32 KHz on PTC3 and PTC1 configured as RTC clock-in source. The MCG mode configurations in this case is PEE mode: 96 MHz PLL clock, 48 MHz Core Clock and 24 MHz Bus clock.   For the RTC_LDD component the only important thing is to select the ERCKL32K as the Clock Source. The image below shows the RTC_LDD component configuration for this application.   After this you only need to Generate Processor Expert Code and write your application.  The code of this example application can be found in the attachments of the post. The application prints every second the current time.     RTC bare-metal configuration. For a non-PEx application we need to do the same configurations above. Enable the internal reference clock. MCGIRCLK is active.          MCG_C1 |= MCG_C1_IRCLKEN_MASK; Select the slow internal reference clock source.          MCG_C2 &= ~(MCG_C2_IRCS_MASK); Set PTC1 as RTC_CLKIN and select 32 KHz clock source for the RTC module.          PORTC_PCR1 |= (PORT_PCR_MUX(0x1));              SIM_SOPT1 |= SIM_SOPT1_OSC32KSEL(0b10); Set PTC3 as CLKOUT pin and selects the MCGIRCLK clock to output on the CLKOUT pin.     SIM_SOPT2 |= SIM_SOPT2_CLKOUTSEL(0b100);     PORTC_PCR3 |= (PORT_PCR_MUX(0x5));   And the RTC module configuration could be as follows (this is the basic configuration just with seconds interrupt): Enable software access and interrupts to the RTC module.     SIM_SCGC6 |= SIM_SCGC6_RTC_MASK; Clear all RTC registers.   RTC_CR = RTC_CR_SWR_MASK; RTC_CR &= ~RTC_CR_SWR_MASK;   if (RTC_SR & RTC_SR_TIF_MASK){      RTC_TSR = 0x00000000; } Set time compensation parameters. (These parameters can be different for each application) RTC_TCR = RTC_TCR_CIR(1) | RTC_TCR_TCR(0xFF); Enable time seconds interrupt for the module and enable its irq. enable_irq(INT_RTC_Seconds - 16); RTC_IER |= RTC_IER_TSIE_MASK; Enable time counter. RTC_SR |= RTC_SR_TCE_MASK; Write to Time Seconds Register. RTC_TSR = 0xFF;   After this configurations you can write your application, do not forget to add you Interrupt Service Routine to the vector table and implement an ISR code.   In the attachments you can find two zip files: PEx application and non-PEx application.   I hope this could be useful for you,   Adrián Sánchez Cano. Original Attachment has been moved to: FRDM-KL25Z-RTC-TEST.zip Original Attachment has been moved to: FRDM-KL25Z-PEx-RTC.zip

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

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

When you go with your laptop to a public place and you don't have a wi-fi connection available you can connect your cellphone in the USB port of your computer, turn on the USB tethering feature of your smartphone and you get full acess to the internet using your carrier data plan. The USB tethering uses the the RNDIS protocol and is easy to implement on a laptop.   But how to connect a Kinetis to the internet using a cellphone?   I'm sharing the the first version of the implementation I made of the RNDIS protocol.It's based in the KSDK 1.3 + MQX + LwIP and it can be used for reference in other projects. It's only a first release and I plan some additional implementation, bugfixes and support for other Kinetis boards in the near future but it already can be useful in some projects. Initially it only supports FRDM-K22F and FRDM-K64F but it can be implemented in any MCU with USB controller and enough FLASH. It's a low-cost and simple way to connect your MCU to the internet when you don't have a Ethernet cable available or an Wi-fi connection or a 4G module available in your board.   Introduction   This project implements the RNDIS protocol on the top of the USB Host Stack and in the bottom of the LwIP (TCP/IP stack). When a cellphone is connected to a freedom board, it acts as a USB device and the Freedom board acts as a host.   * Software implementation * Cellphone connected to a FRDM-K64F providing internet connection to the board   The user can design his own software in the top of the TCP/IP stack (LwIP) like if it's connected through an ethernet cable.   Demonstration   To run the demo you will need the KDS 1.3 (www.nxp.com/kds).   To load all the projects needed to your project you have to extract the .zip file and in KDS go to File -> Import, Project of Projects -> Existing Project Sets, and browse to the *.wsd file present in the folder:   USB_RNDIS\KSDK_1.3.0\examples\[your board]\demo_apps\lwip\usb_tethering_demo\usb_tethering_demo_mqx\kds   It will import all the needed project in to your workspaces so you will be able to build all the projects and flash it into your board.   With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:     Connect your cellphone in to the USB of the MCU. After connect the phone turn on the USB tethering feature and wait some seconds:   The Freedom Board will be connected to the internet. As an example, this demo connects to an HTTP server in the internet, download to MCU some data (Lastest news from an newspaper website) and displays it through the Serial connection.   You can modify this demo for your own application, using the TCP/IP and UDP/IP provided by the LwIP.   Typical Aplications   - Low-cost temporary internet connectivity to the MCU. - Remote updat (i.e.: bootloader through USB downloading the new firmware direct from the web) - Remote control - Remote diagnostics   Known Issues and Limitations: - This first version was only full implemented for FRDM-K22F and FRDM-K64F. I can implement for other boards through requests. - It was tested on Android Phones (Samsung Galaxy, Motorola G, Motorola X). I don't have a iPhone to test yet. - Some cellphones need additional current to detect that is attached to a host.A external power is needed in this situation.For FRDM-K64F I suggest to use the J27 footprint to provide 5V and short the diode D13. - Not all the RNDIS messages was implemented yet, only the most fundamental ones. - There's a flash size limitation due the size of the TCP/IP stacks ( that requires a considerably space of flash). It can adapted in the future for stacks with smaller footprint. - Only support KDS 3.0 at this time. And it only supports MQX at this time.   Let me  know if you have any question. Hope it can be useful!   1-      With the application flashed, open a Serial terminal with 115200kbps, 8N1 for the CDC interface of OpenSDA.When the board starts, it will display:

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 🙂

    感谢Baolei之前在weekly meeting上分享的关于在Codewarrior环境下实现printf的重定向技巧，从而在CW调试环境下的Console上实现调试信息的打印功能，我将其移植到IAR环境下并进行了测试，可以实现调试信息的交互，完全可以替代串口的功能，在这里写出来分享给大家，再次感谢baolei的分享~     通过串口打印调试信息或者实现上下位机交互是我们最常使用的调试手段之一，毕竟实现起来无论是硬件成本（接出两根线Txd和Rxd，外加一个电平转换芯片）还是软件成本（下位机写好UART驱动，上位机直接超级终端或者一些第三方串口调试助手）都是相对较低的，所以这种方式还是灰常受广大“攻城师”们欢迎的。不过如果由于I/O资源紧缺串口被用做其他用处或者板子直接没有引出串口的话（是不是产生共鸣了，呵呵），那该怎么办呢？     当然，所谓时代不同了（liao）（顺口想说“男女都一样呢”，呵呵，哎，都是生在旧社会长在红旗下的孩子啊），随着嵌入式开发生态系统越来越完善，目前也是有越来越多的Poweful开发工具支持丰富的调试功能（支持打印调试信息和交互等），但是涉及到一些版权的问题价格上还是有点小贵的（对一些小企业来说还是难以接受的），所以这个时候就需要我们动动脑筋去摸索摸索其他的方法（所谓路是探索出来的），事实证明破釜沉舟下人的潜力是无限的，呵呵，这里就分享一个折衷的办法去解决大家一直苦恼的问题，即使用IAR虚拟的串口终端来实现信息的交互和打印，下面进入正题： 测试平台：IAR6.6 + FRDM KE02开发板（我目前手里有这个，其他平台都可以） 测试代码：KE驱动库（KEXX_DRIVERS_V1.0.1_DEVD\kexx_drv_lib_release_r1.0.1\build\iar\ke02\platinum） 这里稍微提一句，我测试的是KE驱动库的代码，但是实际上只要你看懂了我下面的解决方法（授之以渔而不是鱼），其他代码都是类似的。 1）打开KE02 platinum的IAR工程，进入到platinum.c文件，找到main函数如下图1，可以看到其调用了printf打印函数，而该工程是默认调用底层串口的，我们跳转到该函数的定义如图2，再继续跳转到out_char的函数定义如图3，这下就屡清楚了，我们可以很直观的看到工程默认是调用UART底层的，呵呵，下面我们就要动手改造它对printf进行重定向； 2）首先我们需要注释掉printf的实现函数，将其屏蔽掉，然后需要给printf一个重新指向的地址，下面就该我们常见的<stdio.h>这位老兄出场了（貌似当初自打我开始接触Turbo C的时候就已经用到它了，老生常谈的“Hello world”就是调用它内部的printf来实现的）。我们找到Common.h文件，将<stdio.h>添加到其中，如下图，这样凡是需要printf的文件只需要添加common.h头文件即可： 3）这里先说说stdio.h文件的作用，我们打开stdio.h文件可以看到其内部定义了标准输入输出函数，包括我们常见的scanf和printf等函数，而这些函数所调用的底层即为IAR提供的链接到其Terminal的驱动，所以……懂的，呵呵。除此之外，我们肯定不满足只输出打印（给人略显低端的感觉有木有），所以为了体现我们不是“土豪”，我觉着有必要让它交互起来，实现真正的串口功能（因为一些类似bootloader或shell之类的还是需要输入参数的进行交互的），我在main函数添加了scanf语句用来测试输入功能，如下： 4）准备工作就绪，编译链接整个工程，然后下载到KE02的板子中并进入到Debug调试环境中，点击View->Terminal I/O调出虚拟终端，然后全步运行，就可以看到Terminal下开始打印调试信息，如下图1。当然显示输出有点小case了，我们再试试输入功能，在input框中输入‘a’，然后回车，如下图2，perfect： 5）还没完，我们要玩就玩高端大气上点档次的，我们再探索探索呢，结果又发现个小惊喜，我们点击上图右下角的“Input Mode”，弹出设置框如下，很高端啊有木有： 呵呵，看完之后是不是有种跃跃欲试的兴奋呢，呵呵，just have a try and enjoy it~ 附件为我修改之后的工程代码，仅供参考~

This is an adaptation I made for the original SMTP protocol implementation provided with the KSDK1.3, with the addition of the secure connection using WolfSSL. The example software is currently ported to the FRDM-K64F Kinetis board but it can be implemented for other boards.This demo sends a e-mail using the Gmail SMTP server ( smtp.gmail.com , port 465) through a SSL channel.   How to run the example:   1 - Download the example software attached. You will need to have KDS 3.0 and KSDK1.3 previously installed on the machine. 2 - In KDS, go to File -> Import, select the folder Project of Projects -> Existing Project Sets, then open the file mqx_smtp_ssl_demo.wsd located in the folder \SMTP_SSL_demo_KSDK_1.3.0\examples\frdmk64f\demo_apps\security\smtp_wolfssl\smtp_wolfssl_mqx\kds 3- Build all the libraries and run the example project. 4- To allow SMTP + SSL , you will need to change your Gmail account settings 5- Using a Serial terminal (115200 bps,8N1) connected to the OpenSDA CDC interface (COM port), connect it to see the shell.Type ipconfig init and ipconfig dhcp to init the Ethernet interface and get a valid IP from the router.   6- Type help to see all the commands available. 7- To send a e-mail using the secure channel, you will need a valid gmail account and use the command:        sec_email -f <sender@email.com > -t <recipient@email.com> -s <www.mail.server.com> [-u <Username>] [-p <Password>] [-j <"email subject">] [-m <"text of email message"]>   For example:        sec_email -f user@gmail.com -t recipient@email.com -s smtp.gmail.com -u user@gmail.com -p mypassword -j "email subject" -m "text of email message"   Some additional notes:   - The Certificate Authority (CA) file from Equifax, used for Gmail, is decoded in hexadecimal to a c array and it is located in the file rtcs_smtp_ssl.c , in the \middleware\tcpip\rtcs\source\apps folder:     - To connect to other servers with SSL support, you will need to obtain a valid Certificate Authority file for this server. You can do it in three steps: 1) Verify what is the certificate authority used by the server. One way to do it is using OpenSSL ( OpenSSL  ) ,  with s_client and the option -showcerts to see the server certificates and check the certificate Authority.Gmail uses Equifax as CA 2) After you know the Certificate Authority of the server, you can get the certificate file in pem file format on a e-mail client for PC (e.g. Outlook).In this case , Outlook has the Equifax certificate file.All the certificate files need to start with -----BEGIN CERTIFICATE----- and to finish with -----END CERTIFICATE----- ,as below 3) You need to convert your CA file to a c language array. You can use Bin2h to do the task.        PEM file generated by Equifax before to be converted to a c array   All the files used to build the demo are included on the file attached. The SSL connection using the WolfSSL software is made on the file rtcs_smtp_ssl.c.

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

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.

Bootloader是一种面向用户应用程序的引导代码，可以在没有烧写器的情况下烧录用户程序，也可以用于在线更新程序。飞思卡尔提供了三种实现bootloader的方式，分别为： 1.预烧写在ROM中的bootloader     这种方式是MCU中内置了专用的ROM来存放bootloader，目前支持ROM型bootloader的Kinetis系列MCU包括KL03，KL17，KL27和KL43等。其中KL03和KL17的ROM bootloader包含SPI/UART/IIC三种接收方式，KL27和KL43还增加了USB的方式。 2.预烧写在FLASH中一次性bootloader     这种类型的bootloader在芯片出厂前预写在FLASH中，因此可以像ROM型bootloader一样直接使用。但与ROM型不同的是，上电后bootloader会从FLASH搬移到RAM 中运行，再将FLASH整片擦除并烧写用户程序，因此这种bootloader是一次性的。其优点是不需要片内ROM且方便量产烧写，缺点是无法支持以后的程序更新。目前支持预烧写在FLASH中一次性bootloader的Kinetis系列MCU包括K22、K24和KV3x等。 3.开放源码的bootloader     这种方式将FLASH空间分为两个部分，一部分用于存储bootloader代码；另一部分用于存储用户应用程序代码。这种方式的bootloader方便客户定制自己的代码。     目前飞思卡尔提供开放源代码的Kboot，支持UART/SPI/IIC/USB HID 几种接口方式，其网址链接为：     www.freescale.com/kboot     除了Kboot，还有以下独立版本的bootloader，包括：     1）AN2295（开发人员的串行引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN2295.pdf         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2295SW.zip        另外FAE Yang Liang 对其进行了移植，目前已经支持FRDM-KE02,KE06,KL25,KL26,KL43,KL46, TWR-K60, KV4x, KV10.下载地址为：Kinetis/AN2295_Bootloader · GitHub     2）AN4767 （Kinetis E 系列上的UART Boot Loader 设计）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4767.pdf         基于AN2295，没有提供代码。     3）AN4775 （Kinetis E 系列上的IIC Boot Loader设计）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4775.pdf         代码下载地址为：http://cache.freescale.com/files/32bit/doc/app_note/AN4775SW.zip     4）AN4368 （USB 大容量存储设备主机引导加载程序）          文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4368.pdf          代码下载地址为：GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K60: This is usb msd Bootloader for K60 （For K60）                                        GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K64: This USB MSD bootloader for K64 （For K64）     5）AN4379  （Freescale USB大容量存储设备引导加载程序）          文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4379.pdf          代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4379SW.zip     6）AN4764   （USB Human Interface Device Boot Loader for ColdFire Plus, Kinetis K, and Kinetis L MCUs）          文档下载地址为：http://cache.freescale.com/files/32bit/doc/app_note/AN4764.pdf          代码下载见附件     7）AN4370   （用于 MCU 的 USB DFU 引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4370.pdf         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4370SW.zip       8）AN4367   （用于 MCU 的 以太网引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4367.pdf?fromsite=zh-Hans         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4367SW.zip         最新的代码请到FNET官网下载：http://fnet.sourceforge.net/    9）Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+         代码及文档下载地址为：https://community.freescale.com/docs/DOC-328168            

Porting FatFs file system to KL26 SPI SD card code 1 Abstract      Without the SDHC module, Kinetis KL series need to use the SPI interface to communicate with the SD card. Normally, when customer use the SD card, they are not only want to write and read the SD card, but also prefer to create files(eg, text file, csv file,etc.) in the SD card to record some important data. Use the file to record the data, then the data can be read easily by the PC. MCU need to use the file system to operate the files, the file system should realize the function of file creating, file deleting, file reading and writing, etc. FatFs is a generic FAT/exFAT file system module for small embedded systems. This document mainly describe how to port a FatFs file system to the KL26 SPI SD card code, SD card SPI interface hardware circuit and the SD card basic operation code. 2 FatFs file system introduction 2.1 FatFs feature Windows compatible FAT/exFAT file system. Platform independent. Easy to port. Very small footprint for program code and work area. Various configuration options to support for: Multiple volumes (physical drives and partitions). Multiple ANSI/OEM code pages including DBCS. Long file name in ANSI/OEM or Unicode. exFAT file system. RTOS envilonment. Fixed or variable sector size. Read-only, optional API, I/O buffer and etc... 2.2 FatFs file system organizations   From the above pictures, we can see that in a project with Fatfs module, there mainly 4 parts: application, Fatfs, Disk I/O layer and the Media(SD card). (1) Application, user just need to call the FatFs API function to realize the file creation, read, write and delete. (2) FatFs module, this module contains 6 important files which customer need to use, it is: diskio.c, diskio.h, ff.c, ff.h, ffconf.h, integer.h.  diskio.c and diskio.h is used to call the SD card operation function from the Disk I/O layer, user need to modify this file to match the disk I/O layer, or write the disk I/O layer match this file. ff.c,ff.h is the FatFs file system layer, it defines the API function, user don’t need to modify it. ffconf.h is the system configuration file. integer.h is the data type define file, user don’t need to modify these two files. (3) Disk I/O layer, there has mmc.c and spi.c, actually, the detail name can be defined by the user, it is not fixed. Mmc.c is used to realize the SD card function, eg, SD initialization, SD block writing and reading.  Spi.c is the MCU SPI interface file, it realize the SPI communication function, because the Kinetis series don’t have the SDHC interface, then it use the SPI interface to communicate with the SD card. (4) Media, it can be SD,MMC, USB, NAND flash, here we use the SD card. More details, please refer to FatFs Module application note. 2.3 Common API function f_mount - Register/Unregister a work area of a volume f_open - Open/Create a file f_close - Close an open file f_read - Read data f_write - Write data f_lseek - Move read/write pointer, Expand size f_truncate - Truncate size f_sync - Flush cached data More functions, please go to this link: http://elm-chan.org/fsw/ff/00index_e.html 3 SPI SD operation 3.1 Hardware       This document use the YL_KL26 as the testing board, customer also can add an external SD card circuit to the FRDM-KL26 board. The board is using the TF card, SD SPI interface circuit is:   The pin assignment in the YL-KL26 board is defined as follows: KL26 pin SPI name PTC4 SPI_CS0 PTC5 SPI_SCK PTC6 SPI_MOSI PTC7 SPI_MISO 3.2 Softwave      The test code project is based on the MDK5.1x. 3.3 SD I/O Layer 3.3.1 SD card initialization The communication speed for SD card initialization can’t exceed 400kb/s, if the speed is higher than 400kbps, user need to add the delay in the initialization code, otherwise the initialization will be failure. After the initialization is successful, user can increase the SD card communication speed. Initialization process: (1)  Initialize the SPI interface which connect to the SD card, down to low speed. (2)  Power on delay 72clks, wait for the SD card ready (3)  Go idle state, CMD0, this command will trigger the SD card to use the SPI interface. (4)  Get SD card information, CMD8, get the SD card version. (5) Active the SD card,  with CMD55+CMD41 (6) Read OCR data,CMD59. (7) Set SD card block size to 512Byte. CMD16 (8) Read CSD, get other information, CMD9 (9) Change to high speed and disable the CS uint8 MMCInit(void) {                 uint8 i = 0,k = 0,tmp = 0;                 uint16 cnt=0;                 uint8  buff[512];                                 SSP0LowSpeed();                                      // low speed                 MMCDelayUs(5000);                                                                                   for (i=0; i<0x0F; i++)                               {                    Send_Byte(0xFF);          // send 72 clocks                 }                 // Send Command CMD0 to SD/SD Card  enter idle                 do                 {                     tmp = MMCWriteCmd(CMD0,0x00,0x95);   // CMD0                      k++;                 }while ((tmp != 1) && (k < 200));                                   if(k == 0)                 {                   MMCCS(1);           //cs pullup, disconnect                   Send_Byte(0xFF);                   printf("\n SD reset fail");                   return 1;//                 }                                              //get SD card version                  tmp = MMCWriteCmd( CMD8,0x1AA,0x87 );                  printf( "SD_CMD8  return  %d........\n\n", tmp );  if(tmp == 1)// 2.0 card {          cnt=0xffff;                    do    {     MMCWriteCmd( CMD55, 0, 0xff );     tmp = MMCWriteCmd( CMD41,0x40000000, 0xff);//CMD41      cnt--;    } while ((tmp) && (cnt));                  //Get OCR information                  tmp = MMCWriteCmd(CMD58, 0, 0 );    if ( tmp != 0x00 )    {                   MMCCS(1);           //cs pullup, SD card disconnect                                 printf( "\nSD_CMD58 return  %d....\n", tmp );                   return 1;//    }      for ( i = 0; i < 4; i++ )    {     buff[ i ] = Get_Byte();    }    MMCCS(1);    printf( "OCR return: %x %x %x %x....\n\n", buff[0],buff[1],buff[2],buff[3] );      if ( buff[0] & 0x40 )    {                                  SD_Type = SD_TYPE_V2HC;      printf( "card is V2.0 SDHC.....\n\n" );    }    else {                                  SD_Type = SD_TYPE_V2;      printf( "card is V2.0.....\n\n" );    }              while(MMCWriteCmd(CMD16,512,0xff)!=0);                  MMCWriteCmd(CMD9,0,0xff);   }                 SSP0HighSpeed();                    //back to high speed                 MMCCS(1);                             return 0;                        } 3.3.2 Read one SD card block The block size is 512Byte, the read process is: Send CMD17 and wait the response Receive the start token 0XFE Receive the 512Byte data Receive 2 bytes CRC Disable the CS pin   uint8 MMCReadSingleBolck(uint32 addr,uint8 *buf) {                 uint16 i;                 uint8 sta;                 if(SD_Type!=SD_TYPE_V2HC)                 {                       addr= addr<<9;                 }                 sta = MMCWriteCmd(CMD17,addr,0x01);                 while(sta !=0)                 {                   sta = MMCWriteCmd(CMD17,addr,0x01);                 }                   while (Get_Byte() != 0xFE){;}                   if(sta == 0)                 {                   for (i=0; i<512; i++)                        {                     buf[i] = Send_Byte(0xFF);                   }                            }                 Send_Byte(0xFF);                                                                  Send_Byte(0xFF);                 MMCCS(1);                 return 0; } 3.3.3 Read multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {          uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                     addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE){;}                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 3.3.4 Write one SD card block The procedure is: Send CMD24 and wait the response Receive the start token 0XFE Send the 512Byte data Send 2 bytes CRC Disable the CS pin   uint8 MMCWriteSingleBlock(uint32 addr,const uint8 *buf) {                 uint16 i,retry ;                 uint8  temp;                                 if(SD_Type!=SD_TYPE_V2HC)                 {                      addr=addr<<9 ;                 }                                              if (MMCWriteCmd(CMD24,addr,0x01) != 0x00)                         {                     return 1;                                                  }                 MMCCS(0);                 //wait SD card ready                 Send_Byte(0xFF);                          Send_Byte(0xFF);                 Send_Byte(0xFF);                 Send_Byte(0xFE);                               for (i=0; i<512; i++)                                 {                     Send_Byte(buf[i]);                 }                 //Dummy CRC                 Send_Byte(0xFF);                                                                              Send_Byte(0xFF);                 temp = Send_Byte(0xFF);                                                        temp &= 0x1F;                        if (temp != 0x05)                 {                     MMCCS(1);                     return 1;                                                                                                  }                                                 while (Send_Byte(0xFF) == 0x00)                 {                      retry++;                      if(retry>0xfffe)                     {                       MMCCS(1);                        return 1 ;                      }                 }                 MMCCS(1);                 Send_Byte(0xFF);                 return 0; } 3.3.5 Write multiple SD card block uint8 MMCReadMultipleBolck(uint32 addr,uint8 *buf,uint8 count) {     uint16 i;                 if(SD_Type!=SD_TYPE_V2HC)                 {                                   addr= addr<<9;                 }                                                 if (MMCWriteCmd(CMD18,addr,0xFF) != 0x00)                    {                     return 1;                                          }                                 MMCCS(0);                 do                 {                     while (Send_Byte(0xFF) != 0xFE)                     {                         ;                                                                                    }                                     for (i=0; i<512; i++)                                         {                         *buf++ = Send_Byte(0xFF);                     }                                     Send_Byte(0xFF);                                                                                         Send_Byte(0xFF);                                 }while (--count);                                 MMCCS(1);                 MMCWriteCmd(CMD12,0x00,0xFF);                   Send_Byte(0xFF);//delay                 return 0; } 4 FatFs file system porting 4.1 FatFs source code download Go to FatFs official website download the source code, the link is: http://elm-chan.org/fsw/ff/00index_e.html The latest version is FatFs R0.12.    Unzip it, like the following picture, just need 6 files, user can copy it to the project SPI driver folder, and create a new folder named as fatfs. 4.2 Modify diskio.c file We need to modify these functions: disk_initialize：Disk initialize disk_status     ：Get the Disk status disk_read       ：Read Disk block disk_write      ：Write Disk block disk_ioctl       ：control device character get_fattime    ：Get current time 4.2.1 disk_initialize function DSTATUS disk_initialize (                 BYTE pdrv                                                 ) {                 DSTATUS stat;                    stat=MMCInit();  //SD card initialization                  if(stat == STA_NODISK)                    {                         return STA_NODISK;                     }                 else if(stat != 0)                   {                         return STA_NOINIT;                   }               else                {                      return 0;                         } } 4.2.2 disk_status  function DSTATUS disk_status (                 BYTE pdrv                 /* Physical drive nmuber to identify the drive */ ) {        if(pdrv)     {         return STA_NOINIT;      }                 return RES_OK; } 4.2.3 disk_read function DRESULT disk_read (                 BYTE pdrv,                                /* Physical drive nmuber to identify the drive */                 BYTE *buff,                               /* Data buffer to store read data */                 DWORD sector,        /* Sector address in LBA */                 UINT count                               /* Number of sectors to read */ ) {     DRESULT res;     if (pdrv || !count)     {            return RES_PARERR;      }                           if (count == 1)                  {                                 res = MMCReadSingleBolck(sector,buff);                 }                 else                           {                                 res = MMCReadMultipleBolck(sector,buff,count);                 }     if(res == 0x00)     {         return RES_OK;     }     else     {         return RES_ERROR;     } } 4.2.4 disk_write function DRESULT disk_write (                 BYTE pdrv,                                                /* Physical drive nmuber to identify the drive */                 const BYTE *buff,      /* Data to be written */                 DWORD sector,                        /* Sector address in LBA */                 UINT count                                               /* Number of sectors to write */ ) {                 DRESULT res;                   if (pdrv || !count)     {            return RES_PARERR;      }     if(count == 1)     {         res = MMCWriteSingleBlock(sector, buff);     }     else     {         res = MMCWriteMultipleBlock(sector, buff, count);     }     if(res == 0)     {         return RES_OK;     }     else     {         return RES_ERROR;     } }   4.2.5 disk_ioctl function DRESULT disk_ioctl (                 BYTE pdrv,                                /* Physical drive nmuber (0..) */                 BYTE cmd,                /* Control code */                 void *buff                /* Buffer to send/receive control data */ ) {                 DRESULT res;                 BYTE n, csd[16];                 DWORD csize;                  if (pdrv)                  {                         return RES_PARERR;                  }                 res = RES_ERROR;                 switch (cmd)                 {                     case CTRL_SYNC       : res = RES_OK; break;                     case GET_SECTOR_COUNT: /* Get number of sectors on the disk (WORD) */                                                                 if((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd))                                                                 {                                                                 if((csd[0] >> 6) == 1) /* SDC ver 2.00 */                                                                 {                                                                 csize = csd[9] + ((WORD)csd[8] << 😎 + 1;                                                                 *(DWORD*)buff = (DWORD)csize << 10;                                                                 }                                                                 else /* MMC or SDC ver 1.XX */                                                                 {                                                                 n = (csd[5] & 15) + ((csd[10] & 128) >> 7) + ((csd[9] & 3) << 1) + 2;                                                                 csize = (csd[8] >> 6) + ((WORD)csd[7] << 2) + ((WORD)(csd[6] & 3) << 10) + 1;                                                                 *(DWORD*)buff = (DWORD)csize << (n - 9);                                                                 }                                                                 res = RES_OK;                                                                 }                                                                 break;                     case GET_SECTOR_SIZE : /* Get sectors on the disk (WORD) */                                                                    *(WORD*)buff = 512;                                                                    res = RES_OK;                                                                    break;                     case GET_BLOCK_SIZE  :                                                             if ((MMCWriteCmd(0x49,0x00,0x95) == 0) && MMCCSD_CID(0x49, csd)) /* Read CSD */                                                        {                              *(DWORD*)buff = (((csd[10] & 63) << 1) + ((WORD)(csd[11] & 128) >> 7) + 1) << ((csd[13] >> 6) - 1);                                                                        res = RES_OK;                                                        }                                            break;                       default              : res = RES_PARERR; break;                 }                   return res; } 4.2.6 Get_fattime function   This function is used to get the current time, and write it in the file attribute when create, modify the files. It should associate with the RTC, this project didn’t add this function, so just write the code like this: DWORD get_fattime (void) { return 0; } 4.2.7 include SD.h file Comment usb, ATA include files, and add the user SD.h file, this is the SD card IO layer header file. #include "diskio.h"                   /* FatFs lower layer API */ //#include "usbdisk.h"              /* Example: Header file of existing USB MSD control module */ //#include "atadrive.h"            /* Example: Header file of existing ATA harddisk control module */ //#include "sdcard.h"                               /* Example: Header file of existing MMC/SDC contorl module */ #include "SD.h" /* Definitions of physical drive number for each drive */ //#define ATA                           0              /* Example: Map ATA harddisk to physical drive 0 */ //#define MMC                        1              /* Example: Map MMC/SD card to physical drive 1 */ //#define USB                          2              /* Example: Map USB MSD to physical drive 2 */ 4.3 Modify main function This project function is to create two files: Test.csv and Test.txt.  Write four items in these files: Test1, Test2, Test3, Test4. int main (void) {                 uint16 i,j;                 FATFS fs;                               FRESULT fr;                 FIL          fil;                                                            UINT bw;                 char file_name1[12]="Test.csv";                 char file_name2[12]="Test.txt";                 System_init();                 spiInit(SPI0_BASE_PTR , Master);                 fr= f_mount(&fs,file_name1,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                 fr = f_open(&fil, file_name1, FA_WRITE | FA_OPEN_ALWAYS);//create csv file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the excel file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                  fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }                 fr= f_mount(&fs,file_name2,0);                 if(fr)                 {                                 printf("\nError mounting file system\r\n");                                 for(;;){}                 }                              fr = f_open(&fil, file_name2, FA_WRITE | FA_OPEN_ALWAYS);//create txt file                 if(fr)                 {                                 printf("\nError opening text file\r\n");                                 for(;;){}                 }                 fr = f_write(&fil, "Test1 ,Test2 ,Test3 ,Test4 \r\n", 29, &bw); //write data to the txt file                 if(fr)                 {                                 printf("\nError write text file\r\n");                                 for(;;){}                 }                 fr = f_close(&fil);                 if(fr)                 {                                 printf("\nError close text file\r\n");                                 for(;;){}                 }            while(1)                 {                          for(i=0;i<10;i++) for(j=0;j<65535;j++);                         printf("\ntest_sd\n");//                 } } Add FatFs header files in the main.h. #include "spi.h" #include "SD.h" #include "diskio.h" #include "ff.h" 5 Test result     After download the code to the KL26 board, then insert a 8G microSD card which already format with the Fat32, press the reset button on the board, user can find the following printf log from the com port: It means the SD card is identified.      Now, take out the SD card and insert it to the PC, user will find there has two files: Test.csv and Test.txt. Open these files, data Test1, Test2, Test3, Test4 can be find in it,  it means the FatFs file system is porting successfully.

Status: Text content finished, to be updated with more diagrams/images. Foreword First of all. I have to say sorry for my English since I am not a native speaker. This is my personal experience of using AN2295 on FRDM-KL25Z. I want to share it with anyone who is suffering on it, since the existing release from FSL has not been fully tested on FRDM-KL25Z. (I can figure it out in many ways.) Components and Documents The lastest microcontrollers always have some kind of bootloader to download user code to the flash memory. FSL does offer many bootloaders for various mcu families. Among them, AN2295 bootloader is general purpose for most of these families, since it only requires an UART, either hardware or software UART. To make AN2295 work for a system, the developer must have three components: AN2295 bootloader running on target MCU, such as MKL25Z128VLK4 on FRDM-KL25Z. AN2295 bootloader PC software, such as win_hc08sprg, or my Python script, FcBootloaderProgrammer.py AN2295 aware user application, which has different start address and special treatment for interrupt vector. UPDATE Add an2295_programmer_v1.zip for Python source code, you need install PySerial module for Python 2.5. Please visit following URLs to download necessary files: http://www.freescale.com/files/microcontrollers/doc/app_note/AN2295.pdf http://cache.freescale.com/files/32bit/doc/app_note/AN4767.pdf Software for AN2295 AN4767: UART Boot Loader Design on the Kinetis E Series, a more detail application note for AN2295 on E series. Updates for AN2295 on IAR 6.5 The released AN2295 has to be updated before downloading into FRDM. When you open the AN2295_Kinetis project in IAREW, please update the following setup items in IDE. In workspace window, switch to Kinetis L Debug configuration. Right click on AN2295_Kinetis and open Options. Click on Debugger category. In Setup tab, select PE micro in driver, disable Run to options. (The release leaves it as simulator, and run to __main, which makes warning report when you downloading code to debugger) In Download tab, enable Verify download, Use flash loader, Override default .board file, with $TOOLKIT_DIR$\config\flashloader\Freescale\FlashKLxx128K.board . Disable Attach to program. In PE micro, select interface type as OpenSDA - USB In Tools|Options (IDE Options)|stack, you can leave Stack points not valid until program reaches as blank (Optional). In AN2295_LinkerFile.icf, change IntVectTable_end__ from 0x0000003f to 0x000003FF (Optional). In bootloader_cfg.h, enable AN2295_FRDM_KL25Z_cfg.h, comment out AN2295_TWR_KL25Z_cfg In AN2295_FRDM_KL25Z_cfg.h, #define BOOT_UART_BAUD_RATE 57600 Add gpio.h/gpio.c to project, in case you want use them to indicate something. We can conclude a fact that AN2295 is good enough as a bootloader as it has been tested on many MCU families. The source code is open, so you can custom it for your own specific purposes. However, you have to do it yourself. The reason why I change baudrate is I found VCP of OpenSDA will decode 0x00 send from KL25Z as 0x80. So I slow down to 57600. Updates for PC software of AN2295 Unfortunately, The released (10.0.12.0) and updated (10.0.16.0) versions of bootloader PC software don't work with my bootloader. The released PC software of AN2295 is open source as well. However I am not fan for VC++. I prefer to make my own programmer software with Python, as knows as a clue language. The programmer software is released in Windows exe format and works in command line prompt. The user don't bother to install Python/PySerial and other components. The programmer software works in a simple single shot mode, blank/erase/program actions. D:\an2295_programmer>FcBootloaderProgrammer --help ################################################## FC Booloader Programmer v0.1-alpha - An alternative to Freescale AN2295 on FRDM-KL25Z   by Allan K Liu (C)2013 Ennovation LLC ################################################## Usage: -h, --help      :       This help information -p, --port      :       Serial port setting in Windows, like COMxx, depends on your VCP installation -b, --baudrate  :       Baud rate setup from 9600/19200/38400/57600/152000 -f, --file      :       Hex file (Motorola SREC or Intel HEX) -a, --action    :       Action [blank/erase/program] -d, --debug     :       Debug [0:1]    In order to make it simpler, I prepare some DOS batch files. blank.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=blank erase.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=erase program.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=program --file=DemoApp_4_FC_Bootloader_freedom.srec You can disable debug output optionally. Updates for Demo projects for AN2295 on IAR6.5 In order to run a user application with AN2295 bootloader, you have to rebuild it with modified linker script. You can generate a new app based upon Kinetis L Sample Codeby following steps. Run make_new_project.exe under Kinetis L Sample Code\kl25_sc_rev5\klxx-sc-baremetal\build\iar\ Offer a new project name "DemoApp_4_FC_Bootloader_freedom" according to prompt. Open it in IAR IDE. Change project linker options, enable Override default with $PROJ_DIR$\..\config files\Pflash_32KB_AN2295.icf, the modified linker file. The major changes are: define symbol __ICFEDIT_region_ROM_start__ = 0x00001000; define symbol __ICFEDIT_region_ROM_end__   = 32*1024; define exported symbol __VECTOR_TABLE      = 0x00001000; define symbol __code_start__ = 0x00001410; After building the project, we can get similiar srec file, which has start address at 0x1000. S027000044656D6F4170705F345F46435F426F6F746C6F616465725F66726565646F6D2E7372656331 S1131000F80B0020111400002929000029290000F0 S11310102929000029290000292900002929000084 ...... S1132B200A0D4B4C300000000A0D4B4C31000000E4 S1132B300A0D4B4C320000000A0D4B4C33000000D0 S10B2B400A0D4B4C34000000A7 S9032B0DC4 According to SREC file format, its filename: DemoApp_4_FC_Bootloader_freedom.srec. And it ranges from 0x1000 to 0x1B47 Finally, run "erase.bat", then "blank.bat", then "program.bat" Simple! Other Useful Tools During my development for AN2295, I used some other tools, especially PC terminal to monitor events/traffics on RS232/UART. Future Development Here are my plan. More images for step on step. Smart detection for OpenSDA VCP port. Mutli-thread GUI for bootloader tool. More labs to reduce unnecessary empty flash space on VECTOR_TABLE and flash_protection_table in user application. Support cryptographic/authentication in bootloader to support licenses.

Foreword This document is a supplement and revision of AN4379 Freescale USB Mass Storage Device Bootloader written by dereksnell in 2011. The original version was programmed with CW for Flexis JM/ColdFire MCF522XX/Kinetis K60. It has not been updated for 2 years. In 2013, I selected FSL MKL25Z as my prefer platform for USB host/OTG application, because it has on chip OTG module, instead of regular device module in its competitors have. I can develop some USB host applications. IAR is selected among commercial compilers for KL2X and other MCU development, since IAR can offer 32KB limited edition for ARM. In order to make AN4379 work on my FRDM-KL25Z, it involves porting efforts between compilers (from CW to IAR EW) and hardware platforms (from K60 to KL25). Reused Sources I gave up the original release since I found FSL USB stack has been improved in many ways between v4.0.3/v4.1.1 and Derek's base. The MSD application from USB stack are reused as baseline. I also merge flash and serial port driver from AN2295 Serial bootloader, as well as some helper functions for debug purpose. The printf( ) sometimes is more helpful than debugger, since it can reveal information during full speed run time. However, don't print out too many characters, since it occupies many resources. Don't print message everywhere, use it only when necessary and remove them in your final release. Bootloader Project & Sources A working bootloader project should include following files and paths. X:\Freescale USB Stack v4.0.3\Source\Device\app\msd_bootloader X:\Freescale USB Stack v4.0.3\Source\Device\app\common X:\Freescale USB Stack v4.0.3\Source\Device\source\driver\kinetis X:\Freescale USB Stack v4.0.3\Source\Device\source\class\usb_msc*.* X:\Freescale USB Stack v4.0.3\Source\Device\source\common Since I have not touched any code in Device\source folder and it is part of USB stack. You can unzip them into a separate folder and merge them into your existing USB stack tree. Be careful, since I have changed some code in common folder. It is up to you to merge them with compare tool. And MSD bootloader and MSD user application indeed have differences in main( ). Open the attached project msd_bootloader_v10beta_20131029.zip in IAR EW, rebuild it and download into debugger. Then you can connect its user USB port to PC, the OS will prompts MSC device connecting and BOOTLOADER driver is shown later on. You can drag and drop , copy and paste or enter in command prompt to copy any user application S-record file into BOOTLOADER driver. If your application code is designed for MSD bootloader, it will run after reset. For what is designed for MSD bootloader, please check the following chapter. First Thing First The bootloader must have conditional jump to user application. The condition could be push button or timeout counter. As a result, the GPIO and timer must be initialized as first step. According to Cortex-M's nature, MCG should be initialized as well in some cases. However, I find multiple calls to MCG initialization routines may cause system hangs on it. The detail logic has not been recovered so far. But I would like to recommend to initial GPIO and LPTMR only, without touching too much on MCG pll_init( ). Default Operation The bootloader will check if PTA2 has been grounded after reset. It will drops to bootloader anyway if it is connected to ground. Otherwise, it will check 0x8000~0x8004 for SP/PC checking. If there is a valid user application, it will transfer control to user application. If not, bootloader will enumerate an MSD driver called BOOTLOADER. There is a file called READY.TXT inside the driver. Custom Bootloader The bootloader can be used directly, or you can custom it. That's why I still keep the revised bootloader as open source. You can rename the driver label, download and run, more firmware format like intel hex, use another ISP push button, resize the driver, add CDC for debug purpose, add driver inf file for custom driver installation, add bi-directional communication over file system, add more features. However, you must understand FAT16 and make modification by yourself. You have to help yourself. Demo User Application Project Another attachment FRDM_KL25ZDemo_freedom.srec is demo project from Kinetis L family release and its S19 file, linked with modified ICF link file. The starting address of an user application is heavily device dependent, which basically related to its 32bit flash protection registers. Since MKL25Z128VLK4 has 128KB flash memory, the minimal protected flash block is 128K/32=4KB. The existing MSD bootloader release is 22KB (0x597F). So 0x6000 could be the start address of an application. Considering potential integrated features and data storage in future releases, 0x8000 is recommended as application start address. General Purpose ICF files During my development with AN2295(Serial) / AN4370(DFU) / AN4379(MSC device) bootloaders, I prepared more linker file. The only differences are the starting addresses, aka relocated vector address, ranges from 0x4000 / 0x8000 / 0xA000. The attachment Pflash_128KB_0x8000.icf explains itself from its name You can easily find necessary modifications for your ICF files in AN2295/AN4370/AN4379 documets. We can put three versions of ICF file in your linker script folder for easy development. Unnecessary Flash Protection Bytes By inspecting the S-Record file, I found the flash protection bytes are still reserved in user applications. Furthermore, the area between 0x80C0 and 0x83FF is kept as 0xFF, blank bytes. The flash protection bytes from 0x8410 to 0x841F are unnecessary since these flash protection bytes are useless in a relocated flash address besides 0x410~0x41F. We can remove the definitions and free some flash memories for user code and EEPROM emulation. In order to free these bytes, we must search source file and icf file who might hold them. This topic has not been covered here. Debug Skills You can debug both bootloader as well as user application with FRDM-KL25Z. Amazing ! It is easy for debug bootloader, since it is a regular application. How to debug a relocated user application? You can download the firmware by bootloader. After bootloader transfers control to the user application, you have to debug it in disassembly Window. Or you can download the user firmware as a regular application in debugger. The debugger will stop at main( ) of user application. If you want to debug the code before running main. Simply add more breakpoint, press reset. The debugger will tell you if you want to stop running to main. Click "stop", you will be forwarded to the address of user PC points to. By using these skills, I found my bootloader pll_init( ) has some side-effects on user application's pll_init( ). The debugger is very helpful in debugging both bootloader and relocated user firmware. Compare to IAR's debugger, Eclipse's debug Window is a mess. It has not reset button at all. That is why I usually use IAR for development and port to GCC later on. More Features FSL bootloaders only offers a basic framework. The users will need more features in future development. I am preparing following features when I am available. License file Including SNR and installation, activation, authentication as well as user API. By this license program, the firmware developers can monetize their IPR investment. User files Support emulated file with on-chip flash memories, Including drivers, html and other files. It is a handy feature since the users can access the related driver easily. And these files can be read-only and virus-proof. This files can also be used as keys for access control and other security applications. ROM API Since bootloader can be used as part of user application, we can integrate some important ROM API, like authentication, serial communication, and any other algorithms. It is simple to implement, define a dedicated code section, and use KEEP directive avoid optimization by the compilers. Limitations I have changed some code during this release. Like bootloader_task.c .FlashConfig should be updated to protect 32KB or 24KB. The current figure 0xFFFFFFFE only protects one block, aka 4KB.  And it is heavily device dependent. (Please correct me if I am wrong) So maybe there are still a lot of bugs. Feel free to leave your comment. I only tested it with S-record file, you are free to test it with CW binary and raw binary files. Even the S-record file, I have not tested those files with memory gaps in the file. Maybe you should padding the gaps with 0xFF before download.

Hello Kinetis community. Attached there is a guide on how to modify an existing KDS project to be loaded using the KBOOT Flash Resident bootloader. Basically it explains 2 procedures: 1- Manipulating linker file to move application and vectors. 2- Adding data for the Bootloader Configuration Area (BCA). I am also including 3 adapted KDS v3.0.0 example projects ready to be used with KBOOT Flash Resident bootloader in a FRDM-K22F: - Baremetal project. - KSDK project. - KSDK project with Processor Expert support. The application simply toggles the red, green and blue LEDs sequentially. I hope you find the document and projects useful! Regards! Jorge Gonzalez

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

Summary:   This tool is based upon the Audio BiQuad Cookbook Here:   http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt   Very useful for configuring the FRDM-JAM and the MonkeyJam software!     Requirements:   You need a machine with the .net 4.0 Framework (or greater) Installed (Windows 7 or Greater).    If you have issues go here:   Download Microsoft .NET Framework 4 (Standalone Installer) from Official Microsoft Download Center   Instructions:   Just unzip and run the .exe   Please report any problems in the comments section Original Attachment has been moved to: BiQuadFilterView---1.0.0.zip