Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

Sort by:
Explore the Features of MCU-Link Pro MCU-Link Pro is the latest ARM Cortex-M series core debugger tool from NXP. Some of its features are inherited from the past LPC-LINK2. But overall it was redesigned and introduced and many new features. These additional functions make the MCU-Link Pro a very powerful debugging tool. This article will explore these features and highlight interesting and useful ones. These functions mainly include the following aspects. SWD+SWO Measurement of current and power consumption MCU-Link pro is supported by new blhost LIBUSBSIO library for windows, Ubuntu Linux and MacOS A secondary chip LPC804 on the board   SWD+SWO MCU-Link Pro support SWD only. It doesn’t support JTAG. The main controller in the board is LPC55S69. There is level shifter circuit between the port and LPC55S69. It makes the board can debug the target board work at 1.2V to 5V. It has reference voltage trace circuit which is use to trace the target board voltage. It can trace the port automatically, needn’t any settings. The MCU-Link Pro also can supply 1.8V/3.3V to target board. The maximum current is 350mA. This is done by connecting J6 and selecting by J5. The maximum speed of SWO is 9.6Mbit/s. Same as <PC-Link, MCU-Link Pro support CMSIS-DAP and Jlink firmware. These firmware are kept updating. The latest firmware of CMSIS-DAP is 2.25. If the firmware version is old, there will be a message jump out telling customer to update it when connecting to computer. We can see that the new version gives two VCOM while the original version only have one. The new VCOM use J26-4 and J26-5.   Measurement of current and power consumption MCU-Link pro provides a very interesting real-time function of current and voltage measurement. It can capture a burst of samples of target current usage, the target supply voltage, the shield current, the analog input, the debug interface reference voltage, or target power consumption at up to 100ksps. This information is displayed in a graph and can also be exported for further analysis. The average value of the collected data can also be displayed. And based on the current and voltage data, the power consumption can also be calculated and displayed in the graph. The place where the red line is drawn in the figure below is the real-time voltage at the time point of the mouse.     What's more interesting is that the energy measurement function does not need to activate the debug to capture the data, it is offline and has a separate data channel. But it can also be linked to a session if such a debug session exists. This is very useful in debugging various low-power applications. Not only can you see the power consumption change under each step of the command, but you can also check the power change rule for a long period of time when the system is running. Since there is a separate data channel, you can even debug the program in KEIL and watch the current change in MCUXpresso. The MCU Link Pro has two current measurement configurations, each with a maximum measurable current. This is to achieve maximum measurement accuracy for a variety of different objectives. There are two automatically controlled ranges in each configuration to provide greater precision. The automatic switching from low current measurement to high current measurement is completely controlled by hardware.   Each time the MCU Link Pro is powered up, the measurement circuit calibrates itself. There is no need to disconnect/reconnect the MCU Link Pro before calibration due to transistors are used to isolate the sensing circuit from the target power supply to avoid contention and to ensure a known voltage is applied to the system during calibration. At high sample rates, the MCUXpresso IDE may not capture all data, so the sample rate may need to be adjusted using the configuration options in the energy measurement configuration settings in the tool. If the target current exceeds the maximum current in the selected range, the measurement will saturate and cut off and will therefore be inaccurate. Blhost and MCU-Link Pro The most noteworthy feature of MCU Link Pro is its USB to SPI and I2C bridge functions. This enables the computer to send I2C and SPI signals directly through USB. This powerful function is not ignored by blhost. The new version of blhost can support this function and adds a new command parameter '- L'. Specifically, '- L SPI' refers to the SPI interface and '- L I2C' refers to the I2C interface. The following figure shows the test results on frdm-k64f. It can be clearly seen in the figure that the SPI interface of MCU Link Pro can communicate with mcuboot firmware on k64 and download the encryption program to flash.     In addition to KINETIS, this function is most suitable for i.mxrt600 and I mxRT500。 These two chips have serial ISP mode. User can download the program to ram through SPI or I2C port, and then directly let it run. Many users have this usage. In the previous examples in SDK, a board of twr-kv46 or twr-k65 or frdm-kl25 was required to receive command and data from UART and translate them to SPI and I2C command. Since there is no direct interface on these boards, flying wires are required, which is very troublesome. Moreover, NXP only provides firmware for these three boards. If you want to use other chips or boards, you must also transplant firmware. It's also very troublesome. But with MCU Link Pro, it's all very easy and pleasant.   LIBUSBSIO library In order to better expand the use of bridge functions, NXP has provided libusbsio library. By calling this library, you can realize the USB to SPI \ I2C \ GPIO function in your own application. I also made the upper computer tools for writing kinetis ezport and flash according to the libusbsio library provided by NXP. I introduced this point in detail in my last article. Interested friends can read my article. It is not enough to provide libraries based on windows and Linux. NXP also provides a python library. This library is based on python3 and can be installed through the following command >pip install libusbsio Its usage is not described in detail in the libusbsio documentation. Here is a general introduction. The following is an initialization procedure of libusbsio. import logging import logging.config from libusbsio import * # enable basic console logging logging.basicConfig() # load DLL from default directory sio = LIBUSBSIO(loglevel=logging.DEBUG) # the main code # calling GetNumPorts is mandatory as it also scans for all connected USBSIO devices numports = sio.GetNumPorts() print("SIO ports = %d" % numports) if numports > 0 and sio.Open(0): print("LIB version = '%s'" % sio.GetVersion()) print("SPI ports = %d" % sio.GetNumSPIPorts()) print("Max data size = %d" % sio.GetMaxDataSize()) if(sio.GetNumSPIPorts() > 0): spi = sio.SPI_Open(1000000, portNum=0, dataSize=8, preDelay=100) if spi: data, ret = spi.Transfer(spi_ssel[0], spi_ssel[1], b"Hello World") sio.Close() else: print("No USBSIO device found") ​ Line 9 is to open an instance of libusbsio library; Line 14: get the number of usbsio ports of all USB bridges; Lines 18, 19 and 20 are the read version information, the number of SPI ports and the maximum size of SPI cache; Line 22: open an SPI interface; Line 24, start transmitting data. It can be seen from the above that the use process is relatively simple. And these commands are very similar to those of the C language library.   A secondary controller LPC804 on the board There is also an lpc804 on the MCU Link Pro board. This chip is confusing here. What is it for? Its UART, SPI and I2C ports are all connected for external use. But what's the use? One conceivable application is that the UART port is connected to the newly added vcom2, and then the SPI or I2C works in the slave mode. As a listener, it monitors the SPI or I2C bus to be debugged and displays it on the computer terminal. The LPC804 debug interface is the same as the debugging port of MCU Link Pro. Maybe the board itself is a development board, so that users can develop lpc804 programs? In addition, its UART-ISP port is connected to a UART port of LPC55S69. It seems that in the future, it can communicate with each other through the new version of CMSIS-DAP firmware. Let's look forward to new ways of playing in the future.
View full article
The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&amp;CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&amp;E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 
View full article
  CNN on FRDM_K64 1 Introduction Limited by resources, ordinary MCU is difficult to do some complex deep learning. However, although it is difficult, it can still be done. CNN, convolutional neural network, is a kind of deep learning algorithm, which can be used to solve the classification task. After the implementation of CNN, ordinary MCU can also be used as edge computing device. Next, we introduce how to run CNN on frdm-k64 to recognize handwritten numbers. The size of digital image is 28x28. 28x28 image as input for CNN will output a 1x10 matrix. There are few deep learning libraries written for MCU on the Internet. Even if there are, there will be various problems. NNoM framework is easy to transplant and apply, so we use it     2 Experiment 2.1 Required tools: frdm-k64, python 3.7, Pip, IAR, tcp232   2.2 Download the source code of deep learning framework, https://github.com/majianjia/nnom This is a pure C framework that does not rely on hardware structure. Transplantation is very convenient   2.3  we select the example ‘bubble’ to add the Inc, port and Src folders in NNoM to the project, as shown in the figure          Figure 1 Open the file ‘port.h’ . The definitation of NNOM_LOG is changed to PRINTF (__ VA_ ARGS__ ), Open the ICF file, and change the heap size to 0x5000, define symbol__ size_ heap__ = 0x5000; Malloc, which is used in this library, allocates memory from here. If it is small, it can't run the network   2.4 From the download framework, go into ‘mnist-simple/mcu’, which has trained file ‘weights.h’, and randomly generated handwritten image file, ‘image.h’. Add these two files to the project   2.5 Add headfile to ‘bubble.c’        #include "nnom_port.h" #include "nnom.h" #include "weights.h" #include "image.h"   2.6 Delete the original code, add the following code   nnom_model_t *model; const char codeLib[] = "@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\\|()1{}[]?-_+~<>i!lI;:,\"^`'.   "; /*******************************************************************************  * Code  ******************************************************************************/ void print_img(int8_t * buf) {     for(int y = 0; y < 28; y++)        {         for (int x = 0; x < 28; x++)               {             int index =  69 / 127.0 * (127 - buf[y*28+x]);                      if(index > 69) index =69;                      if(index < 0) index = 0;             PRINTF("%c",codeLib[index]);                      PRINTF("%c",codeLib[index]);         }         PRINTF("\r\n");     } }   // Do simple test using image in "image.h" with model created previously. void mnist(char num) {        uint32_t predic_label;        float prob;        int32_t index = num;        PRINTF("\nprediction start.. \r\n");               // copy data and do prediction        memcpy(nnom_input_data, (int8_t*)&img[index][0], 784);        nnom_predict(model, &predic_label, &prob);          //print original image to console        print_img((int8_t*)&img[index][0]);               PRINTF("\r\nTruth label: %d\n", label[index]);        PRINTF("\r\nPredicted label: %d\n", predic_label);        PRINTF("\r\nProbability: %d%%\n", (int)(prob*100)); }   int main(void) {     uint8_t ch;     /* Board pin, clock, debug console init */     BOARD_InitPins();     BOARD_BootClockRUN();     BOARD_InitDebugConsole();     /* Print a note to terminal */     model = nnom_model_create();        // dummy run        model_run(model);     PRINTF("\r\nwhich image to distinguish? 0-9 \r\n");     for(uint8_t i=0; i<10; i++)     {         print_img((int8_t*)&img[i][0]);     }     while(1)     {         PRINTF("\r\nwhich image to distinguish? 0-9 \r\n");         ch = GETCHAR();         if((ch >'9') || ch < '0')         {             continue;         }         PRINTF("\r\n");         mnist(ch-'0');     } }   An error will be reported when compiling ‘weights.h’, due to lack of few parameters. In layer [1], layer [4], layer [7], you need to add ‘division (1,1)’ after ‘stride (1,1)’. In this way, the compilation passes.   2.7 As a result, open the serial port software. At the beginning, the terminal will print out a variety of handwritten digital pictures, and then enter a number, The corresponded picture will be recognized.                                                    Figure 2 When we input ‘8’, the recognition is the handwriting '9'                        Figure 3   The ‘Truth label’ corresponds to IMG9_LABLE in ‘image.h’ and ‘Predicted label’ is the prediction results   3 training Through the above steps, we have realized a simple handwritten numeral recognition. Next, we will introduce ‘weights.h’. How to generate the weight model here? The image data here are all from MNIST digital set. How can we make a handwritten number for MCU to recognize?   3.1 Under ‘nnom-master\examples\mnist-simple’, there is a ‘mnist_ simple.py’. You need to run it to generate ‘weights.h’ and ‘image.h’. To run this, you need to install tensorflow, keras and so on. When you run it, you can use pip to install what is missing The network operation process is as shown in the figure                               Figure 4 Conv2d-> convolution operation, Maxpool-> pooling. The meaning of convolution operation is to extract the features of the image. Pooling is a bit like compressing data, which can reduce the running space. 28x28 input and output a 1x10 matrix, representing the possibility of 0-9   3.2 We can use the ‘Paint’ program of WIN to adjust the canvas to 28x28, write numbers on it and save it in PNG format. I wrote a ‘4’     Figure 5   Change the code as following.   nnom_model_t *model; uint8_t temp[28*28]={0}; const char codeLib[] = "@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\\|()1{}[]?-_+~<>i!lI;:,\"^`'.   "; /*******************************************************************************  * Code  ******************************************************************************/ void print_img(int8_t * buf) {     for(int y = 0; y < 28; y++)        {         for (int x = 0; x < 28; x++)               {             int index =  69 / 127.0 * (127 - buf[y*28+x]);                      if(index > 69) index =69;                      if(index < 0) index = 0;             PRINTF("%c",codeLib[index]);                      PRINTF("%c",codeLib[index]);         }         PRINTF("\r\n");     } }     void mnist_pic(uint8_t *temp) {        float prob;     uint32_t predic_label;        PRINTF("\nprediction start.. \r\n");          // copy data and do prediction        memcpy(nnom_input_data, (int8_t*)temp, 784);        nnom_predict(model, &predic_label, &prob);          //print original image to console        print_img((int8_t *)temp);        PRINTF("\r\nPredicted label: %d\n", predic_label);        PRINTF("\r\nProbability: %d%%\n", (int)(prob*100)); }   int main(void) {     /* Board pin, clock, debug console init */     BOARD_InitPins();     BOARD_BootClockRUN();     BOARD_InitDebugConsole();     /* Print a note to terminal */     model = nnom_model_create();        // dummy run        model_run(model);     while(1)     {         PRINTF("\r\n Send picture by serial\r\n");            DbgConsole_ReadLine(temp,784);         PRINTF("\r\n Got picture\r\n");           mnist_pic(temp);     } }   3.3 Then use pic2mnist.py(see the attachment), run this script with CMD and enter 'Python pic2mnist.py 1. PNG ', 1. PNG is the image to be parsed, and then ‘content.txt’ will be generated. The file contains the data of the picture. Send the data to the MCU through the serial port. Note that ‘Send as Hex’ should be checked. Similarly, the handwritten picture will be displayed first, and then the picture will be recognized.                                                           Figure 6   We can see that '4' was identified
View full article
Making and Downloading Security Image for Kinetis Device   Introduction KINETIS devices have Flash base bootloader or ROM bootloader. They have same structure and same download tools. MCUBOOT shows supported device. The bootloader not only support plaintext image, but also encrypted image which is encrypted by AES. This can protect user’s application code from unauthorized using. Due to different internal Flash structure, security image making, key download and image download flow is a bit different to each Kinetis devices. This hands-on will introduce Flash base bootloader and ROM base bootloader security image making and downloading.   2 Security image to Flash bootloader Many NXP Kinetis device SDK have integrated bootloader. Take FRDM-K64F as example, the bootloader project is in SDK_2.8.0_FRDM-K64F\boards\frdmk64f\bootloader_examples\freedom_bootloader The bootloader support security format image by default. User can download security format image via UART and USB interface. In K64 bootloader, the key is stored in 0xb000. But the application code is start from 0xa000. That means each time the application is upgraded, key file need to be download again.   2.1 Generate key The elftosb tool can generate a key. But of course, you can take any string as key.     2.2 Image encryption Use the key to encrypt application image. Here is the bd file. options {  flags = 0x4; // 0x8 encrypted + signed, 0x4 encrypted  buildNumber = 0x1;  productVersion = "1.00.00";  componentVersion = "1.00.00";  keyCount = 1; }   sources {  inputFile = extern(0);  sbkey = extern(1); }   section (0) {  erase 0xa000..0xF6000; load inputFile > 0xa000; }       2.3 Download key and image Connect FRDM-K64F openSDA usb port. Then download key and image.     2.4 Download key with KinetisFlashTool Use keyboard to input key is really annoying. There is a GUI tool named KinetisFlashTool which can download image same as blhost.exe. To download encrypted image by this tool, we can make a sb file to download key first. Here is the bd file.   sources { } section (0) {        erase 0xb000..0xc000;        load {{E0BAA2C8231283CAF1D327CEDB82AFF9}} > 0xb000; }   Using elftosb to generate the sb file. The elftosb command line is as below \>Elftosb -V -c program_key.bd -o program_key.sb   This sb file should be download at first, then download the encrypted application image. When customer want to download security image via USB MSC or HID, this is the only way to download key. There is a limitation in those bootloader which version is lower or equal to v2.7.0. MSC function and HID function can’t be enabled together. Otherwise bootloader will fail when copy encrypted sb file to MSC disk.   2.5 About the key But it is really strange that key file should always come with encrypted file. It is reasonable to keep the key in secure status, for example, an untouched place in flash. K64 has a program once field which is located in program flash IFR. This is a standalone space different from main space. It’s address is from 0x3C0 to 0x3FF. MCU core can read or write this area by special flash command. We can put the AES key here. Again, we can use sb file to download this key. sources { } section (0) {        load ifr 0xE0BAA2C8 > 0x3c0;        load ifr 0x231283CA > 0x3c1;        load ifr 0xF1D327CE > 0x3c2;        load ifr 0xDB82AFF9 > 0x3c3; } Then we should modify sbloader_init() in sbloader.c. The source code only read key form 0xb000. We should have it read key from IFR.   Security image to ROM bootloader Some Kinetis device has ROM bootloader. They are different with flash base bootloader. This document use FRDM-K32L2A as example.   3.1 Generate AES key and download the key The key can be set as 0x112233445566778899aabbccddeeff00. Besides sb file, it can also be programmed to IFR by blhost command. \>blhost -p COM9 – flash-program-once 0x30 4 11223344 msb \>blhost -p COM9 – flash-program-once 0x31 4 55667788 msb \>blhost -p COM9 – flash-program-once 0x32 4 99aabbcc msb \>blhost -p COM9 – flash-program-once 0x33 4 ddeeff00 msb If you do not write anything to IFR, the ROM bootloader will use all-zero key. Here I use all-zero key.   3.2 Encryption algorithm The ROM bootloader hasn’t encryption algorithm. Application should include algorithm code and assign the address to bootloader, or preprogram BCA table and MMCAU code into flash. You can find MMCAU code (mmcau_cm0p.bin) and BCA(BCA_mmcau_cm0p.bin) table in MCUBoot2.0.0 package. Before you program these code into flash, new address must be written into it. For example, we put MMCAU code into 0x7f800, then we should modify the BCA table as below     And then, according this new address, modify the MMCAU_function_info structure in mmcau_cm0p.bin.   After that, download BCA to 0x3c0 and mmcau_cm0p.bin to 0x7f800.   In order to avoid using manual operation in production, above steps can be integrate in a single sb file.   3.3 Encrypt the image and download The bd file in K64 example can be reused, just need to change the image address to 0x00.   Press the reset button, after 5 second, the led will blink.   References: Kinetis Bootloader v2.0.0 Reference Manual Kinetis Elftosb User's Guide Kinetis Bootloader QuadSPI User's Guide Kinetis blhost User's Guide
View full article
  This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on the Kinetis devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: Kinetis:  FRDM-K64F Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. Kinetis platforms The Kinetis devices have a main module called Multipurpose Clock Generator (MCG) this module controls which clock source is used to derive the system clocks. A high-level description diagram is shown below: Figure 1. Multipurpose Clock Generator External clock sources can provide a frequency signal as the System oscillator module or the RTC oscillator module, also the MCG module has internal clock generators that the System integration module (SIM) manages, the SIM module provides module-specific clock gating to allow granular shutoff of modules. For more detailed information about the SIM module, refer to “Chapter 12. System Integration Module(SIM)” from the K64 Sub-Family Reference Manual.  The following clock diagram shows all the multiplexers, dividers, and clock gates that can be controlled by the MCG, however, we will focus on the external and internal clock sources and the MCG outputs. Figure 2. Oscillators,  MCG and SIM modules At ‘MCGOUTCLK’ line, the primary clocks for the system are generated, the circuitry provides fixed clock dividers for the Core clock, Bus clock, FlexBus clock, and the Flash Clock. This allows for trade-offs between performance and power dissipation. It’s important to know that the MCG has 9 states of operation shown in the following figure.    Figure 3. MCG operation states In the previous image, the arrows indicate the permitted MCG state transitions, for example, if the current MCG state is BLPI(Bypassed Low Power Internal) and the desired state is BLPE(Bypassed Low Power External) the shortest and allowed path to follow is first switch to FBI(FLL Bypassed Internal) then to FBE(FLL Bypassed External), and finally to the BLPE MCG state. These switching mode restrictions exist due to certain MCG configuration bits that must be changed to properly move from one mode to another. For example, in the K64 family, the MCG state after a power-on reset is FEI(FLL Engaged Internal) mode, the MCGOUTCLK is derived from the FLL clock that is controlled by the 32kHz Internal Reference Clock (IRC), the following table shows the output frequency values for this specific MCG state. Source Frequency MCGOUTCLK 20.97MHZ Core/System clocks 20.97MHz Bus clock 10.48MHz FlexBus clock 6.99MHz Flash clock 4.19MHz Table 1. K64 default MCG configuration after reset: FEI (FLL Engaged Internal) The following image shows the blocks used for the FEI state using Clocks Tool from MCUXpresso IDE. Figure 4. View of FEI state from Clock Tools For more detailed information, refer to “Chapter 25. Multipurpose Clock Generator (MCG)” from the K64 Sub-Family Reference Manual.  External Clock Sources     System oscillator The System Oscillator module is a crystal oscillator. The module, in conjunction with an external crystal or resonator, generates a reference clock for the MCU.  Supports 32 kHz crystals (Low Range mode) and supports 3–8 MHz, 8–32 MHz crystals and resonators (High Range mode) For more detailed information, refer to Chapter 26. Oscillator(OSC) at K64 Sub-Family Reference Manual.   RTC oscillator The RTC oscillator module, in conjunction with an external crystal, generates a reference clock source of 1Hz and 32.768KHz, supports 32 kHz crystals with very low power. For more detailed information, refer to Chapter 27. RTC Oscillator(OSC32K) at K64 Sub-Family Reference Manual.   Internal Clock Sources    IRC oscillators Internal clock driven by the Fast Internal Reference (FIR) @4MHz or the Slow Internal Reference (SIR) @32kHz.  IRC internal oscillator Internal 48 MHz oscillator that can be used as a reference to the MCG and also may clock some on-chip modules. PLL Phase-locked loop circuit that in conjunction with an external clock source can achieve higher and stable frequencies.   FLL Frequency-locked loop circuit that in conjunction with an internal/external clock source provides module-specific clock and achieves higher frequencies. Modifying MCG state from FEI to FBI state If the current system clock does not fit with our timing requirements we can modify it by changing the state of the MCG module, in this case, if the user requires a lower system clock frequency @32.7KHz(Slow IRC) or @4MHz(Fast IRC) instead @21MHz(FLL Engaged Internal ‘FEI’ default state) and a low power option of the MCG module, the FLL Bypass Internal (FBI) state is an option to reach these requirements. 1.1 Configure MCG mode The FBI state allows us to use the Fast IRC together with its frequency divider achieving frequencies between 31.25KHz to 4MHz, for this example the final core clock is @2MHz. Follow the next steps to change to the FBI state and select a 2MHz clock using the Clock-Tools tool from MCUXpresso IDE.        At the MCUXpresso QuickStart Panel select MCUXpresso Config Tools >> Open Clocks Figure 5. Open Config Tools        At the left top of the screen select the MCG mode to “FBI(FLL Bypassed Internal)” Figure 6. Selection of MCG Mode        Select the frequency divider block(FCRDIV) right-click on it and select “Edit settings of: FCRDIV” Figure 7. FCRDIV block        Modify the divider value from 1 to 2. Figure 8. FCRDIV divider value        Finally, the next image shows how the MCG state and the new yellow paths get modified. The Core and system clocks are @2MHz. Figure 9. FBI MCG state @2MHz 1.2 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. In the previous example, we configured the MCG state to FBI mode, this is translated to the following instructions in source code: “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();”  Figure 10. Source code view of FBI MCG configuration Another way to change the MCG state is by directly modifying the internal MCG registers. The blocks shown in the following image need to be modified to switch from the default FEI state to the FBI state. Figure 11. Blocks in FEI state to modify at MCG registers Note. MCG registers can only be written in supervisor mode. The ARM core runs in privileged(supervisor mode) out of reset, it is controlled by [nPRIV] bit in CONTROL core register. For more detailed information visit the Cortex-M4 ARM Documentation Reference Manual.        Internal Reference Source Multiplexor (IREFS), selects the reference source clock for the FLL.  1 is written to C1[IREFS]. The slow internal reference is selected.        PLL Select  Multiplexor(PLLS) Controls whether the PLL or FLL output is selected. 0 is written to C6[PLLS] The FLL output is selected as the MCG source, the PLL is disabled.        Clock Source Select Multiplexor(CLKS), selects the clock source for the MCGOUTCLK  line. 01 is written to C1[CLKS].  The internal reference clock is selected at the CLKS multiplexor.        Fast Clock Internal Reference Divider(FCRDIV), selects the Fast Internal Reference Clock divider, the resulting frequency can be in the range of 31.25KHz to 4MHz. 001 is written to SC[FCRDIV]. The dividing factor is 2 since the desired frequency is @2MHz and the source clock is @4MHz.        Internal Reference Clock Select (IRCS). Selects between the fast or slow internal reference clock source.  x is written to C2[IRCS]. Write 0 for Slow IRC or 1 for Fast IRC.        Finally, to enable the low power when neither the PLL nor FLL are used, a register in C2[LP] is modified. x is written to C2[LP]. Enable, or Disable the PLL & FLL in all the bypass modes.     This is translated to the following instructions in source code in “CLOCK_SetInternalRefClkConfig();” and “CLOCK_SetFbiMode();” functions:  Figure 12. Source code view of Internal MCG Registers Note. C1, C2, C6, and SC registers are part of the internal MCG control registers.  References K64 Sub-Family Reference Manual Also visit LPC's System Clocks   
View full article
      In the practical KE KEA usage, a lot of customers meet the watchdog can’t reset problems. Some customers find when they want to enable the watchdog, but can’t really enable the watchdog by set the EN bit in register WDOG_CS1; Some customers find when in debug mode, the EN bit WDOG_S1 register always be clear, but from the reference manual, this bit should be set after reset, even they check their code, and make sure they didn’t disable the watchdog;  There also have some customers find when they use the KEXX_DRIVERS_V1.2.1_DEVD code, and set the timeout value register by themselves, but the watchdog can’t reset in the timeout value. Now according to these problems, this document will analyze it and give the recommendation to avoid these problems.      From the above problem description, we can get that there actually mainly 2 reasons caused these problems: 1, software configuration; 2, debugger usage 1.  Software configuration   1) Start code disable the watchdog In the KE KEA sample code, after reset, the chip will enter in the start code at first, the start code always disable the watchdog at first, if the watchdog is disabled, the watchdog can’t be enable just by set the EN bit in register WDOG_CS1, because bit EN in register WDOG_CS1 is the write-once bit after reset. It only can be modified when the UPDATE bit is set and with 128 bus clocks after performing the unlock write sequence. Now how to find the disable code in the start code? Take KEXX_DRIVERS_V1.2.1_DEVD sample code as an example IAR: from crt0.s, will find the watchdog disable code WDOG_DisableWDOGEnableUpdate();  in the start function. The above IAR start picture is for KE, but in the KEA start file, you can’t see the start function in the KEA sample code which download from the freescale web, just find the __iar_program_start in cstartup_M_KEA128.s after the reset happens, but where is the __iar_program_start function, it can’t be searched in the whole project. Actually __iar_program_start is the default program entry function, it include the following function: You can find it will enter __low_level_init function, the watchdog disable code is just in  __low_level_init function. MDK:  From startup_MK0XZ4.s will find the watchdog disable code in the SystemInit function. Codewarrior: From __arm_start.c file, will find the watchdog disable code in __init_hardware function. 2) Codewarrior script init_kinetis.tcl disable the watchdog      To the Codewarrior, just comment the disable watchdog code in the __arm_start.c file is not enough to check the watchdog enable after reset, because in the codewarrior connect script init_kinetis.tcl, there also have the watchdog disable code.      If you want to find the state of EN bit in register WDOG_S1 after reset, you must disable all these watchdog disable code.   3) Timeout register configuration incorrect From the header file MKE02Z2.h, we can find the time out register define like this:   union {                                          /* offset: 0x4 */     __IO uint16_t TOVAL;                             /**< WDOG_TOVAL register., offset: 0x4 */     struct {                                         /* offset: 0x4 */       __IO uint8_t TOVALH;                             /**< Watchdog Timeout Value Register: High, offset: 0x4 */       __IO uint8_t TOVALL;                             /**< Watchdog Timeout Value Register: Low, offset: 0x5 */     } TOVAL8B; This structure means that customer can define the watchdog timeout value by separated unit8 TOVALH, TOVALL or just defined it with unint16 TOVAL. But actually in the IAR project usage, take an example, use 1khz as the clock source for watchdog, then want to set the timeout value as 1s, it means the timeout value should be 1000=0x03e8, so one of the customers configure it like this:    You can find, we need the TOVALL= 0XE8, TOVALH=0X03, but from the test result, the register is TOVALL= 0X03, TOVALH=0Xe8, this will cause the timeout value is much larger than 1000, that is why customer can’t reset the mcu after 1s, because the register configuration is not correct. It is caused by the IAR int16 store endian mode, the default IAR endian mode is little endian mode. So in the practical usage, it is recommended to use the separated time out value definition. 2. debugger usage When in debug mode with IDE, some customers find even they comment all the watchdog disable code, they still can’t reset the MCU by the watchdog. After check the register WDOG_S1, bit EN is 0, it means the watchdog is disabled. But from the reference manual, we get that after reset, the EN bit should be 1. What caused this? After test, we find this actually caused by the debugger, the debugger hardware which you are using. Eg, in the same project which already comment all the watchdog disable code, SEGGER JLINK will still disable the watchdog, but the PE opensda or PE multilink won’t do this, the EN bit is enabled by default, the following is the test picture, take codewarrior as an example: 1) JLINK 2) PE Opensda or PE multilink    So, if you want to test the watchdog in debug mode, and want the EN is set after reset, you can choose PE debugger tool instead of JLINK, but this JLINK feature is just influence the debug mode, after you download the code to the chip flash, and after reset, the EN bit in WDOG_S1 will still be set. Wish this document will help you get out the problem of watchdog can’t be reset.
View full article
Dear all :      I would like to share an IoT application note to you. The note will help us to setup a FRDM-K64F to connect to Microsoft Azure and get alarm message from Azure. Detail please refer to attachment. Demonstration : IoT client (FRDM-K64F) report data to Cloud (Microsoft Azure) IoT client receive data from Cloud Could computing IoT client data and take action Tools : FRDM-K64F ( http://www.freescale.com/FRDM-K64F ) Device Explorer ( http://aka.ms/iot-hub-how-to-use-device-explorer ) Visual Studio 2015 SSH client ( PuTTY  or Tera Term ) mbed  ( http://www.mbed.com ) Microsoft Azure ( https://azure.microsoft.com )
View full article
Here you will find both the code and project files for the ADC project. This project configures the ADC to perform single conversions, by default this is performed using a 16 bit configuration. The code uses ADC0, channel 12, once the conversion is finished it is displayed at the serial terminal. Code: #include "mbed.h" AnalogIn AnIn(A0); DigitalOut led(LED1); Serial pc(USBTX,USBRX); float x; int main() {     pc.printf(" ADC demo code\r\n");     while (1)     {     x=AnIn.read();     pc.printf("ADC0_Ch12=(%d)\r\n", x);     wait(.2);     } }
View full article
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
View full article
Here you will find the code and project files corresponding to the I2C-Accelerometer project. The accelerometer/magnetometer is connected to the I2C port, although bot the accelerometer and magnetometer are contained within a single package, they must be initialized individually. In this example the measurements from both devices (X,Y and Z axis) is performed and displayed at the serial terminal. In order to compile the project, the following library must be imported: FXOS8700Q.h Code: #include "mbed.h" #include "FXOS8700Q.h" //I2C lines for FXOS8700Q accelerometer/magnetometer FXOS8700Q_acc acc( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); FXOS8700Q_mag mag( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); //Temrinal enable Serial pc(USBTX, USBRX); MotionSensorDataUnits mag_data; MotionSensorDataUnits acc_data; int main() {     float faX, faY, faZ;     float fmX, fmY, fmZ;     acc.enable();     printf("\r\n\nFXOS8700Q Who Am I= %X\r\n", acc.whoAmI());     while (true)     {         acc.getAxis(acc_data);         mag.getAxis(mag_data);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", acc_data.x, acc_data.y, acc_data.z);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", mag_data.x, mag_data.y, mag_data.z);         acc.getX(&faX);         acc.getY(&faY);         acc.getZ(&faZ);         mag.getX(&fmX);         mag.getY(&fmY);         mag.getZ(&fmZ);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", faX, faY, faZ);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", fmX, fmY, fmZ);                 wait(1.0);     } }
View full article
Encrypted QuadSPI image Implementation       The Kinetis family of MCU includes the system security and flash protection features that can be used to protect code and data from unauthorized access or modification. This application note discusses the usage of encrypted boot with the KBOOT and experiment with the FRDM-K82 board. FRDM-K82 board
View full article
Hello all.   I would like to share an example project for FRDM-KL25Z board on which C90TFS Flash Driver was included to implement emulated EEPROM (Kinetis KL25 doesn’t have Flex Memory). It is based on the “NormalDemo” example project. A string of bytes is stored on the last page of the flash memory (address 0x1FC00-0x1FFFF), and then, it is overwritten with a different string.   The ZIP file also includes the “Standard Software Driver for C90TFS/FTFx Flash User’s Manual” document. For more information, please refer to Freescale website and search for “C90TFS” flash driver. Hope this will be useful for you. Best regards! /Carlos
View full article
   CodeWarrior v10.6 and KDS are integrated development tools which are based on Eclipse, these two IDEs provide easy way to build project when using the GUI, but some engineers still want to build their projects from command line to do automated builds. This document provides examples on how to do it! Build project in CodeWarrior from command line: For a CW v10.6 created project, CW provides the “Make” tool and can also generate the needed “MakeFile” to build this project out of eclipse GUI. The below are the steps: Create and new project “k22_makefile” in CW v10.6, you will see there are two build configurations: RAM & FLASH Launch “cmd prompt” in Windows and go to “eclipse” folder of CW installation Now, you can generate the makefile for configuration FLASH by executing the below command ecd.exe –generateMakefiles –project “C:\workspace_cmd\k22_makefile” –config FLASH Now, checking the “FLASH” subfolder in project location, you will see “makefile” is generated. 4.To use “make” tool convenient, we can define an environment variable pointing to {CW}\gnu\bin where “make” is located. See command as below: 5. Go to the configuration folder “FLASH” where the project’s makefiles are located and run the follow commands to build the project. %MCU_BIN%\make.exe PS: to get more information of make and ecd, please just run the below command: Ecd.exe –help Make.exe –help Build project in KDS from command line: Compare with CodeWarrior, it is much easier to build an application in command mode. KDS provides a command “eclipse.exe” with which you can build a project with only two steps. In this example, I have created an application with name “cmd_ke02”, and the workspace path is “C:\wks_kdscmd”. To build the application in cmd, please first launch command mode in Windows system and then go to {KDS}\eclipse. Then, you need import the application into current workspace in the below command: eclipsec.exe -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data "C:\wks_kdscmd" -import "C:\wks_kdscmd\cmd_ke02" then, build the project with the below command: eclipsec.exe -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data "C:\wks_kdscmd" -build "cmd_ke02" For more details of building project from command line in KDS, please refer: http://mcuoneclipse.com/2014/09/12/building-projects-with-eclipse-from-the-command-line/
View full article
The FRDM-KL25Z is an ultra-low-cost development platform enabled by Kinetis L Series KL1 and KL2 MCUs families built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL25Z is supported by a range of Freescale and third-party development software. Features MKL25Z128VLK4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP Capacitive touch “slider,” MMA8451Q accelerometer, tri-color LED Easy access to MCU I/O Sophisticated OpenSDA debug interface Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps P&E Multilink interface provides run-control debugging and compatibility with IDE tools Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit Take a look at these application notes: USB DFU boot loader for MCUs Developer’s Serial Bootloader. Low Cost Universal Motor Drive Using Kinetis L family . Writing your First MQXLite Application Learn more...
View full article
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!
View full article
  Hello Freedom community users Few weeks before, I produced for the Element14 community a full video review of the FRDM-KL46Z including all the steps to program and debug your first project example. Video has a length of less than 13 min so your evaluation of the Kinetis KL46 should be really quick and easy http://www.element14.com/community/community/designcenter/kinetis_kl2_freedom_board/blog/2014/06/17/frdm-kl46z-full-review-and-getting-started-in-video Enjoy Greg
View full article
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:
View full article
Here you can find both the code and project files for the Serial communication project, in this example the serial port (UART) is configured to establish communication between the computer using a serial terminal and the evaluation board. The default baud rate for the serial port is 9600 bauds. The code also implements an echo function, any key pressed in the computer's keyboard will be captured and displayed in the serial terminal. If your computer does not have a serial terminal you can download Tera Term from the following link: Tera Term Open Source Project The communication is established through the USB cable attached to the OpenSDA USB port. Code: #include "mbed.h" //Digital output declaration DigitalOut Blue(LED3); //Serial port (UART) configuration Serial pc(USBTX,USBRX); int main() {     Blue=1;     pc.printf("Serial code example\r\n");        while(1)     {         Blue=0;         pc.putc(pc.getc());     }    }
View full article
Here you can find the code and project files for the GPIO example, in this example the 3 colors of the RGB led are turned on sequentially when the SW2 push button is pressed, the led pin definition is shared throughout all the freedom platforms. The wait function can be defined in seconds, miliseconds or microseconds. Code: #include "mbed.h" //Delay declared in seconds /*GPIO declaration*/ DigitalOut Red(LED1);         DigitalOut Green(LED2); DigitalOut Blue(LED3); DigitalIn sw2(SW2); int main() {     /*Leds OFF*/     Red=1;     Green=1;     Blue=1;         while(1)     {         if(sw2==0)         {             Red = 0;             wait(.2);             Red = 1;             wait(1);                                Green=0;             wait(.2);             Green=1;             wait(1);                         Blue=0;             wait(.2);             Blue=1;             wait(1);         }     } }
View full article
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
View full article