Kinetis Microcontrollers Knowledge Base

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

Kinetis Microcontrollers Knowledge Base

Discussions

Sort by:
Since the mbed Ethernet library and interface for FRDM-K64 have not yet been fully tested, instead of using mbed we will use one of the latest demo codes from MQX specifically developed for the FRDM-K64 platform. Before starting please make sure you have the following files and software installed in your computer: CodeWarrior 10.6 (professional or evaluation edition) MQX 4.1 for FRDM-K64 (it is not necessary to install full MQX 4.1) JLink_OpenSDA_V2.bin (this is the debugger application) * If you don't have a valid license, you can find a temporary license below, it will only be valid until 7/30/2014 and it will only be available online until 7/05/2014. Building the project The first step to use an MQX project is to compile the target/IDE libraries for the specific platform: 1. Open CodeWarrior and drag the file from the following path C:\Freescale\Freescale_MQX_4_1_FRDMK64F\build\frdmk64f\cw10gcc onto your project area: This will load all the necessary libraries to build the project, once they are loaded build them it is necessary to modify a couple of paths on the BSP: 2. Right click on the BSP project and then click on properties 3. Once the properties are displayed, expand the C/C++ Build option, click on settings, on the right pane expand the ARM Ltd Windows GCC Assembler and select the directories folder, this will display all the libraries paths the compiler is using 4. Double click on the "C\Freescale\CW MCU v10.6\MCU\ProcessorExpert\lib\Kinetis\pdd_100331\inc" path to modify it, once the editor window is open, change the path from "pdd_100331" to "pdd" 5. Repeat steps 2 and 3 for the ARM Ltd Windows GCC Compiler 6. Now you can build the libraries, build them one at a time by right clicking on the library and selecting build project, build them in the following order, it is imperative you do it in that order. BSP PSP MFS RTCS SHELL USBD USBH 7. Once all the libraries are built, import the web hvac demo, do it by dragging the .project file to your project area; the project is located in the following directory:                     C:\Freescale\Freescale_MQX_4_1_FRDMK64F\demo\web_hvac\build\cw10gcc\web_hvac_frdmk64f 8. Once the project is loaded, build it by right clicking on the project folder and select Build project Debugging the project To debug the project it is necessary to update the FRDM-K64 debugging application: Press the reset button on the board and connect the USB cable Once the board enumerates as "BOOTLOADER" copy the JLink_OpenSDA_vs.bin file to the unit Disconnect and reconnect the board On CodeWarrior (having previously compiled the libraries and project) click on debug configurations 5. Select the connection and click on debug 6. Open HVAC.h and change the IP Address to 192.168.1.202 Now the demo code has been downloaded to the platform you will need the following to access all the demo features: Router Ethernet Cable Serial Terminal The code enables a shell access through the serial terminal, it also provides web server access with a series of options to simulate an Heating Air Conditioning Ventilation System, the system was implemented using MQX and a series of tasks, for more details on how the task are created, the information regarding how to modify the code please check the attached document: Freescale MQX RTOS Example guide.
View full article
This document shows the implementation of the infrared on the UART0 using the FRDM-KE02Z platform. The FRDM-KE02Z platform is a developing platform for rapid prototyping. The board has a MKE02Z64VQH2 MCU a Kinetis E series MCU which is the first 5-Volt MCU built on the ARM Cortex-M0+ core. You can check the evaluation board in the Freescale’s webpage (FRDM-KE02Z: Kinetis E Series Freedom Development Platform) The Freedom Board has a lot of great features and one of this is an IrDA transmitter and receiver on it. Check this out! One of the features of the MCU is that the UART0 module can implement Infrared functions just following some tricks (MCU-magic tricks). According to the Reference Manual (Document Number: MKE02Z64M20SF0RM) this tricks are:      UART0_TX modulation: UART0_TX output can be modulated by FTM0 channel 0 PWM output      UART0_RX Tag: UART0_RX input can be tagged to FTM0 channel 1 or filtered by ACMP0 module For this example we are going to use the ACMP0 module to implement the UART0_RX functionality. Note1: The Core is configured to run at the maximum frequency: 20 Mhz Note2: Refer to the reference manual document for more information about the registers. Configuring the FTM0. The next lines show the configuration of the FTM0; the module is configured with a Frequency of 38 KHz which is the ideal frequency for an infrared led. The FTM0_CH0 is in Edge_Aligned PWM mode (EPWM).           #define IR_FREQUENCY       38000 //hz      #define FTM0_CLOCK                BUS_CLK_HZ      #define FTM0_MOD_VALUE            FTM0_CLOCK/IR_FREQUENCY      #define FTM0_C0V_VALUE            FTM0_MOD_VALUE/2      void FTM0CH0_Init( void )      {        SIM_SCGC |= SIM_SCGC_FTM0_MASK;             // Init FTM0 to PWM output,frequency is 38khz        FTM0_MOD= FTM0_MOD_VALUE;        FTM0_C0SC = 0x28;        FTM0_C0V = FTM0_C0V_VALUE;        FTM0_SC = 0x08; // bus clock divide by 2      } With this we accomplish the UART0_TX modulation through a PWM on the FTM0_CH0. Configuring the ACMP0. The configuration of the ACMP0 is using a DAC and allowing the ACMP0 can be driven by an analog input.      void ACMP_Init ( void )      {        SIM_SCGC |= SIM_SCGC_ACMP0_MASK;        ACMP0_C1 |= ACMP_C1_DACEN_MASK |                   ACMP_C1_DACREF_MASK|                   ACMP_C1_DACVAL(21);    // enable DAC        ACMP0_C0 |= ACMP_C0_ACPSEL(0x03)|                            ACMP_C0_ACNSEL(0x01);        ACMP0_C2 |= ACMP_C2_ACIPE(0x02);  // enable ACMP1 connect to PIN        ACMP0_CS |= ACMP_CS_ACE_MASK;     // enable ACMP                } With this we have now implemented the UART0_RX.     IrDA initialization. Now the important thing is to initialize the UART0 to work together with these tricks and implement the irDA functions. Basically we initialize the UART0 like when we use normal serial communication (this is not the topic of this post, refer to the project to see the UART_init function) and we write to the most important registers:         SIM_SOPT |= SIM_SOPT_RXDFE_MASK; UART0_RX input signal is filtered by ACMP, then injected to UART0.      SIM_SOPT |= SIM_SOPT_TXDME_MASK; UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout. The configuration is as follows:      void IrDA_Init( void )      { // initialize UART0, 2400 baudrate        UART_init(UART0_BASE_PTR,BUS_CLK_HZ/1000,2400);                  // clear RDRF flag        UART0_S1 |= UART_S1_RDRF_MASK;                  // initialize FTM0CH1 as 38k PWM output        FTM0CH0_Init();                      // enable ACMP        ACMP_Init(); SIM_SOPT |= SIM_SOPT_RXDFE_MASK;  //UART0_RX input signal is filtered by ACMP, then injected to UART0.        UART0_S2 &= ~UART_S2_RXINV_MASK;  //inverse data input SIM_SOPT |= SIM_SOPT_TXDME_MASK;  //UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout.      } With the irDA initialization we got the infrared features on the UART0. Philosophy of the Example In the attachments of this post you can find the example which shows the use of these functions in a basic application; the project was compiled in CodeWarrior 10.6 and the philosophy is: I hope that the information presented on this document could be useful for you. Thank you! Best Regards!
View full article
You can put the code directory in the SDK_2.6.0_FRDM-K64F\boards\frdmk64f to use. 1、Introduction As is known to all, we use debugger to download the program or debug the device. FRDMK64 have the opsenSDA interface on the board, so wo do not need other’s debugger. But if we want to design a board without debugger but can download the program, we can use the bootloader. The bootloader is a small program designed to update the program with the interface such as UART,I2C,SPI and so on. This document will describe a simple bootloader based on the FRDMK64F.The board uses SD card to update the application. User can put the binary file into the card. When the card insert to the board ,the board will update the application automatically. The bootloader code and application code are all provided so that you can test it on your own board.   2、Bootloader’s implementation   The schematic for SD card is shown below. The board uses SDHC module to communicate with SD card.                                                  Figure 1.Schematic for SD card   We use the 2.6.0 version of FRDM-K64F’s SDK.You can download the SDK in our website. The link is “mcuxpresso.nxp.com”. The bootloader uses SDHC and fafts file system. So we should add files to support it.                   Figure 2.The support file   In main code, the program will wait until the card has inserted. Then it will find the file named “a000.bin” in sd card to update the application. If the file do not exist, the board will directly execute the application. If there is no application, the program will end. The following code shows how the program wait for inserting sd card. It will also check if the address has the application’s address.                      Figure 3.The code -- wait for inserting card   The following code shows how the program opens the binary file. If sd card doesn’t have the file, the program will go to the application. Figure 4.Open the binary file   If the program opens the file normally, the update will begin. It will erase 200k’s space from 0xa000. You can adjust it according to your project. Now I will explain update’s method in detail. Our data is written to the buffer called “rBUff”. The buffer size is 4K. Before write data to it, it is cleared.  Please note that when we erase or program the flash, we should disable all interrupts and when the operations finish we should enable the interrupts.  The file size will decide which way to write the data to flash.  1、If the size < 4k ,we just read the file’s data to buffer and judge if its size aligned with 8 byte. If not , we increase the size of “readSize” to read more data in our data buffer called “rBuffer”. The more data we read is just 0.    2、If the size > 4K, we use “remainSize” to record how much data is left. We read 4k each time until its size is smaller than 4k and then repeat step 1. When finish the operation at a  time, we should clear the buffer and increase the sector numer to prepare the next transmission. Figure 5.Write flash operation code   The way to clear the space is shown in the figure. It will initialize the flash and erase the given size from the given address.  “SectorNum” is used to show which sector to erase. Figure 6.Erase operation code   The following figure shows how to write the data to flash.              Figure 7.Program operation code    Before we go to the application, we should modify the configuration we did in the bootloader.     Close the systick, clear its value.     Set the VTOR to default value.     Our bootloader runs in PEE mode. So we should change it to FEI mode.     Disable the all pins. You should disable the global interrupt when run these codes. And don’t forget to enable the global interrupt. Figure 8.Deinitalization code   Then we can go to the application. Figure 9.Go to Application   3、Memory relocation The FRDMK64 has the 1M flash, from 0x00000000 to 0x00100000.As shown in figure 10,we use the 0xa000 as the application’s start address.            Figure 10.The memory map   Now, I will show you how to modify the link file for user application in different IDE. In IAR                                    Figure 11.IAR’s ICF In MDK Figure 12.MDK’s SCF   In MCUXpresso Figure 13.MCUXpresso’s flash configuration 4、Run the demo 1) Download the bootloader first. 2) Prepare a user application program. We use the “led blinky” as an example. 3) Modify the Link file. 4) Generate the binary file with your IDE, please name it as “a000.bin”. 5) Put it into the sd card like figure 5. Figure 14.SD card’s content        6) Insert the card. And power on. Wait for a moment, the application will execute automatically. 5、Reference 1) Kinetis MCU的bootloader解决方案 2) KEA128_can_bootloader
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 SPI bus has the capability of addressing multiple slave devices by a single master. The Kinetis L series of devices feature either an 8-bit or 16-bit capable SPI module; however, there is only one dedicated CS/SS signal per instance of the module. Of course this signal is muxed to a few pin locations on the device. Unfortunately, there are not that many pins with the CS/SS muxing and they are most likely they are not near to each other physically. A solution to this issue is to use GPIO as CS/SS lines. This way you can take advantage of the SPI bus protocol and the Kinetis L series IOPORT interface (also known as FGPIO on Kinetis L). The Cortex-M0+ allows accesses to the IOPORT to occur in parallel with any instruction fetches; therefore, these accesses will complete in a single cycle. Core vs. SPI I'm sure many who have tried to use GPIO as CS/SS have written code similar to this pseudo code, I know I have: while(1) {      set_cs_low;      send_byte;      set_cs_high; } Logically this makes sense, but on an oscilloscope you will see the GPIO CS/SS line toggling at irregular intervals and out of sync with the SPI transfers. This is due to the nature of the 'send_byte' function or instruction. Simply transmitting a data packet will not prevent the core from waiting for the transmission to complete. The core will move on from writing data to the SPI data register, and execute the next instruction. If you have a core operating at 48 MHz and you are performing, at most depending on instance, 24 MHz SPI transfers the core will always move onto the next instruction before the data has left the module. The code must either implement a delay or wait for the transmission to complete. Incorporating an accurate delay can be tricky and can be interrupted by any interrupts occurring during the delay process. A more robust solution is to wait for the transmission to complete. However, there appears to be no Transmit Complete Flag (TCF) in the L-Series SPI module. The Solution Fortunately, there is a way to wait for transmit complete. Software must wait for the SPI read buffer full flag (SPRF) to be set in the SPI status register (SPIx_S) after writing data to the SPI data register (SPIx_D) . When the SPRF bit is set, software must read the SPIx_D. This procedure will ensure that the core does not move onto GPIO toggling, or other instructions, until the data has left the SPI module. The following function demonstrates how to write the above procedure in C using SPI0 and PTD0 as the CS/SS line: uint8_t SPI_send(uint8_t spiWrite) {     uint8_t spiRead;                        //Variable for storing SPI data     FGPIOD_PCOR |= (1 << 0);                //Toggle CS/SS line low     while(!(SPI0_S & SPI_S_SPTEF_MASK))     {         __asm("NOP");     }                                       //Wait for SPI transmit empty flag to set     SPI0_D = spiWrite;                            //Write data to SPI     while(!(SPI0_S & SPI_S_SPRF_MASK))     {         __asm("NOP");     }                                       //Wait for receive flag to set     spiRead = SPI0_D;                       //Read the SPI data register     FGPIOD_PSOR |= (1 << 0);                //Toggle CS/SS line high     return spiRead; } Please note that the GPIO CS/SS toggling need not be in the function. It should work just as well if the GPIO CS/SS toggles occur before and after the function is call, just remove the FGPIO instructions from the function and place them outside. I hope this document proves useful to those of you designing multiple slave SPI buses around Kinetis L series parts.
View full article
Hello Kinetis friends! The launch of new Kinetis devices and development tools called "Kinetis K2" brought some new K22_120 MHz devices to the K22 family portfolio. :smileyinfo: Please notice the name "Kinetis K2" only refers to the Kinetis generation, but it is not related to part number (e.g. K63/K64 are part of K2 generation). Previously existing Kinetis portfolio already had some K22_120 MHz devices, so this  caused confusion regarding the documentation, header files, features, development boards and others, because the part numbers are very similar. I created the next reference table outlining the existing K22_120 MHz parts with their corresponding files and boards. The last column is an overview of the features or peripherals that are either missing or added in each device. :smileyalert: IMPORTANT NOTES:           - I gathered and put together this information as reference, but it is not official. For the most accurate information please visit our webpage www.nxp.com.           - Header files MK22F12.h and MK22FA12.h apply for legacy K22_120 devices. However TWR-K21F120M(A) board has a K21_120 part, so use MK21F12.h or MK21FA12.h instead.      Colleague Carlos Chavez released an Engineering Bulletin (EB811) with good information related to this document:      http://cache.nxp.com/files/microcontrollers/doc/eng_bulletin/EB811.pdf Regards! Jorge Gonzalez
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
The Freescale Freedom development platform is a low-cost evaluation and development platform featuring Freescale's newest ARM® Cortex™-M0+ based Kinetis KL25Z MCUs NEW! Quick Start Guide Features: KL25Z128VLK4--Cortex-M0+ MCU with:   - 128KB flash, 16KB SRAM - Up to 48MHz operation  - USB full-speed controller OpenSDA--sophisticated USB debug interface Tri-color LED Capacitive touch "slider" Freescale MMA8451Q accelerometer Flexible power supply options   - Power from either on-board USB connector - Coin cell battery holder (optional population option)  - 5V-9V Vin from optional IO header - 5V provided to optional IO header - 3.3V to or from optional IO header Reset button Expansion IO form factor accepts peripherals designed for Arduino™-compatible hardware
View full article
Overview          KBOOT v2.0 had been released in the Q2 of the 2016 and it has a lot of new features versus the previous version. For instance, the USB peripheral can work as Mass Storage Class device mode now, not just only supports the HID interface. And in following, USB MSD Bootloader implementation will be illustrated. Preparation FRDM-K64F board Fig1 FRDM-K64F KBOOT v2.0 downloading: KBOOT v2.0 IDE: IAR v7.50 Application demo: KSDK v2.0   Flash-resident bootloader           The K64_120 doesn’t contain the ROM-based bootloader, so the flash-resident bootloader need to be programmed in the K64 and the flash-resident bootloader can be used to download and program an initial application image into a blank area on the flash, and to later update the application.         I. Open the the bootloader project, for instance, using the IAR and select the freedom_bootloader demo         The Fig 2 illustrates the bootloader project for K64 which resides in ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloade r_2_0_0\targets\MK64F12. Fig 2      II. After compiles the demo, then clicks the  button to program the demo to the K64 Linker file modification       According to the freedom_bootloader demo, the vector table relocation address of the application demo has been adapted to the 0xa000 (Table 1), however the default start address of the application is 0x0000_0000. So it’s necessary to modify the linker file to fit the freedom_bootloader and the Table 2 illustrates what the modifications are.                                                     Table 1 // The bootloader will check this address for the application vector table upon startup. #if !defined(BL_APP_VECTOR_TABLE_ADDRESS) #define BL_APP_VECTOR_TABLE_ADDRESS 0xa000 #endif                                                   Table 2 define symbol __ram_vector_table_size__ = isdefinedsymbol(__ram_vector_table__) ? 0x00000400 : 0; define symbol __ram_vector_table_offset__ = isdefinedsymbol(__ram_vector_table__) ? 0x000003FF : 0; //define symbol m_interrupts_start       = 0x00000000; //define symbol m_interrupts_end         = 0x000003FF; define symbol m_interrupts_start       = 0x0000a000; define symbol m_interrupts_end         = 0x0000a3FF; //define symbol m_flash_config_start     = 0x00000400; //define symbol m_flash_config_end       = 0x0000040F; define symbol m_flash_config_start     = 0x0000a400; define symbol m_flash_config_end       = 0x0000a40F; //define symbol m_text_start             = 0x00000410; define symbol m_text_start             = 0x0000a410; define symbol m_text_end               = 0x000FFFFF; define symbol m_interrupts_ram_start   = 0x1FFF0000; define symbol m_interrupts_ram_end     = 0x1FFF0000 + __ram_vector_table_offset__; define symbol m_data_start             = m_interrupts_ram_start + __ram_vector_table_size__; define symbol m_data_end               = 0x1FFFFFFF; define symbol m_data_2_start           = 0x20000000; define symbol m_data_2_end             = 0x2002FFFF; /* Sizes */ if (isdefinedsymbol(__stack_size__)) {   define symbol __size_cstack__        = __stack_size__; } else {   define symbol __size_cstack__        = 0x0400; } if (isdefinedsymbol(__heap_size__)) {   define symbol __size_heap__          = __heap_size__; } else {   define symbol __size_heap__          = 0x0400; } define exported symbol __VECTOR_TABLE  = m_interrupts_start; define exported symbol __VECTOR_RAM    = isdefinedsymbol(__ram_vector_table__) ? m_interrupts_ram_start : m_interrupts_start; define exported symbol __RAM_VECTOR_TABLE_SIZE = __ram_vector_table_size__; define memory mem with size = 4G; define region m_flash_config_region = mem:[from m_flash_config_start to m_flash_config_end]; define region TEXT_region = mem:[from m_interrupts_start to m_interrupts_end]                           | mem:[from m_text_start to m_text_end]; define region DATA_region = mem:[from m_data_start to m_data_end]                           | mem:[from m_data_2_start to m_data_2_end-__size_cstack__]; define region CSTACK_region = mem:[from m_data_2_end-__size_cstack__+1 to m_data_2_end]; define region m_interrupts_ram_region = mem:[from m_interrupts_ram_start to m_interrupts_ram_end]; define block CSTACK    with alignment = 8, size = __size_cstack__   { }; define block HEAP      with alignment = 8, size = __size_heap__     { }; define block RW        { readwrite }; define block ZI        { zi }; initialize by copy { readwrite, section .textrw }; do not initialize  { section .noinit }; place at address mem: m_interrupts_start    { readonly section .intvec }; place in m_flash_config_region              { section FlashConfig }; place in TEXT_region                        { readonly }; place in DATA_region                        { block RW }; place in DATA_region                        { block ZI }; place in DATA_region                        { last block HEAP }; place in CSTACK_region                      { block CSTACK }; place in m_interrupts_ram_region            { section m_interrupts_ram }; SB file generation     I. Brief introduction of SB file         The Kinetis bootloader supports loading of the SB files. The SB file is a Freescale-defined boot file format designed to ease the boot process. The file is generated using the Freescale elftosb tool. The format supports loading of elf or srec files in a controlled manner, using boot commands such as load, jump, fill, erase, and so on. The boot commands are prescribed in the input command file (boot descriptor .bd) to the elftosb tool. The format also supports encryption of the boot image using AES-128 input key.          And right now, the USB MSD bootloader only support SB file drag and drop.    II. Generate the BIN file         After open the hello_world demo in the IAR, using project options dialog select the "Output Converter" and change the output format to "binary" for outputting .BIN format image (Fig 3). Next, build the application demo, then the .BIN file will be generated after the building completes. Fig 3      III. Create BD file There is a template BD file which resides in the ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\src. Next, adapt the BD file by referring to the Kinetis Elftosb User's Guide, the following table shows the BD file content.                                                    Table 3 sources {         # BIN File path         myBINFile = "hello_world.bin"; } section (0) {         #1. Erase the internal flash         erase 0x0000a000..0x0010000;         #2. Load BIN File to internal flash         load myBINFile > 0xa000;         #3. Reset target.         reset; }      IV.  SB file generation          After creating the BD file shown in the following figure, copy the "hello_world.bin", elftosb.exe, and the BD file into the same directory. Then, open the window with command prompt and invoke elftosb such as “elftosb –V –c FRDM-K64F.bd –o image.sb”. The elftosb processes the FRDM-K64F.bd file and generates an image.sb file. Elftosb also outputs the commands list as shown in Fig 4. Fig 4     V. Application code updating       Plug a USB cable from the PC to the USB connector J26 to power the board , then keep holding the button SW2 down until press and release the Reset button SW1, it can force the K64_120 enter the BOOTLOADER mode. Next, plug another USB cable from the PC to the USB connector J22 (Fig 5), the FSL Loader will come out after completes the enumeration and it will appear as a removable storage driver (Fig 6).  Copy & paste or drag & drop the image.sb to the FSL Loader drive to update the application code, and the Fig 7 illustrates the result of application code runs. Fig 5 Fig 6 Fig 7
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
For Remote Control means, that is needed two computers - Server Computer and User Computer, which will be in connection. There are two types of connection, which can be used - HTTP or DCOM. There are two different ways how to set up the remote control in Windows. I made the tutorial, which describes both types of Remote Control. Ok - so, let´s start! HTTP Settings On the Server Computer side: 1. Plug the board to the Server Computer 2. Go to Remote Communication Server 3. Set HTTP connection and choose the right COM Port according the plugged board If the plugged board is on e.g. COM23, it is possible to edit number of Port in Device Manager On the User PC side: 1. Open FreeMASTER,  go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (HTTP) and type the IP address of the server, do not forget join to IP address :8080 3. And start communication by STOP button to successful connection DCOM Settings On the Server Computer side: 1. Plug board to the Server Computer 2. Launch DCOM in FreeMASTER Remote Server Choose COM according plugged board or edit COM according to step 2 - Server Computer in HTTP Connection (up). 3. Setting permissions for the user, User PC. Right click on Computer -> Manage. In Computer Management click to Distributed COM Users. In Distributed COM Users Properties add the user, User Computer. After that, set the permissions in Component Services. In cmd type dcomcnfg.exe In Component Services go to Computers -> My Computer -> DCOM Config -> MCB FreeMASTER Remote Server Application Right click on MCB FreeMASTER Remote Server Application and go to Properties. In Security Tab is possible to add the permissions. There are 3 types of permissions. First permission - Launch and Activation Permissions. There are 4 permission options. Local Launch and Remote Launch means, that user, User Computer can launch e.g. FM Remote Server Application. But for success communication is needed allowing Local Activation and Remote Activation. Second permission - Access Permissions. Click to Edit and Allow Local Access and Remote Access for the user. Do not forget that if there is a change of permissions, specifically allowing, it is necessary for User to log out and log in. On the User Computer side: 1. Open Freemaster, go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (DCOM) and for filling Connect string is possible to use Configure. Definitely, type the IP address of the server and ;Port Name. 3. And start communication by STOP button in FreeMASTER to successful connection And now.. you can do anything 🙂
View full article
Hello, I've created a application of USB FLASH Drive acessing the 1MB internal FLASH of K64 using the Freescale's bareboard USB Stack 5.0 software + FRDM-K64F to be used by anyone as reference. It seems to be stable, I already wrote some files on that and checked the integrity of the volume. It can be very useful for datalogger application where the equipment can store data on the MCU FLASH using a internal filesystem, and read it through PC as it was a regular USB stick. It also very much cheaper than using a external SD Card, as it only needs the MCU + a external crystal and a USB connector.The only limitation so far is that it cannot exceed the number of the erase/write cycles of the device (of course!). Please see the file attached with the USB Stack and the example on the folder "{Installation Path}\Freescale_BM_USB_Stack_v5.0\Src\example\device\msd\bm\iar\dev_msd_disk_frdmk64f". The project was wrote using IAR. Also I have attached the srec file if you don't want to build the project by yourself. Any issues, doubts or suggestions, please let me know. Denis
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
Here you can find the code and project files for the Interrupt example, in this example 2 KBI interrupts are enabled, one assigned to SW2 and another to SW3, during the main routine the blue led is turned on, when the interrupt routines are triggered the blue led is turned off and the red or green led blink once, the interrupt was configured to detect falling edges only. Code: #include "mbed.h" DigitalOut Red(LED1); DigitalOut Blue(LED3); InterruptIn Interrupt(SW2); void blink() {     wait(.4);     Red=1;     Blue=0;     wait(.4);     Blue=1;     wait(.4); } int main() {     Interrupt.fall(&blink);     Blue=1;     while (1)     {         Red=!Red;         wait(.4);     } }
View full article
In this document we are going to see how to use the attached code which implements the configuration of the FRDM-KL25 board as a USB HOST interfacing with a Numeric Keyboard and a 16x2 LCD. The project is compiled in the CodeWarrior IDE using Processor Expert and the Components to support the USB module of the USB Stack 4.1.1. How to add the Processor Expert USB components. The instructions to install the USB components to use them with Processor Expert are in the documentation of the USB Stack 4.1.1; here you can see the steps as well: Download the USB Stack 4.1.1 from the Freescale’s Website (USB Stack 4.1.1) Run the .exe file and install it in the default location. Open CodeWarrior and select Import Components in the Processor Expert button in menu bar. An Open windows will pop up, there you need to go to the path: <install folder>\Freescale USB Stack v4.1.1\ProcessorExpert\Components. To have the complete components and support for the USB module add each PEupd file repeating this step. Close CodeWarrior and open it again to ensure correct installation of the components. Check that the new components are available in the Components Library. About this Project. This project is based in the example code for Processor Expert in the USB Stack 4.1.1 USB_HID_MOUSE_HOST_MKL25Z128_PEx which implements the use of the FRDM-BOARD KL25 and a HID Mouse Device to interface with. In this project the HID Device is a Numeric Keyboard and the HOST Device (FRDM-KL25) is handling the data and printing them in a 16x2 LCD used in 8 bits mode (The LCDHTA component used here was created by Erich Styger; find the component an all the information about it here: http://mcuoneclipse.com/2012/12/22/hd44780-2x16-character-display-for-kinetis-and-freedom-board/ and say Thank you Erich: “Thank you Erich”). Here you can find a video of the implementation of this application: HID HOST WITH FRDM-KL25 The hardware components are: FRMD-KL25 Rev.E Adafruit Prototype Shield v.5 LCD JHD-162A Numeric USB Keyboard (Product Name: Numpad i110, Model No. GK-100010) USB _host Inside the project you can see there is a folder called USB_Host an it contains two important folders with source files: App_keyboard: Contains the specific function for the Keyboard configuration: in use, attached detached, callbacks and more; contain how to handle the data coming from the device. The function process_kdb_buffer is where the data is transmitted to the LCD and use it for the application. Classes: contain the necessary function to handle a hid as the device. Handle all the functions necessary for the USB protocol. Note: The usb_classes.c and usb_classes.h files are generated by processor expert. I attach these two files as well to have a reference how these files must look like. This is because sometimes during the code generation process Processor Expert erases part of the code. I hope this project is useful for you. Best Regards, Adrian.
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
This hint will demonstrate how to verify ADC conversion rate (with oscilloscope) during testing phase.   Refer to the phenomenon descripted in"Figure 1. Voltage drops at ADC input during sampling process" of AN4373. If too large values is selected for the external RC components, serious voltage disturbances (voltage drops/peaks) at the ADC input (see Figure 1) can be observed. The disturbance at the ADC input in this case results from the basic principle of operation of the sample and hold (S/H) circuit inherent in a SAR ADC. Although we should avoid this happening, but it can be used to measure the ADC conversion rate with oscilloscope during testing phase.   According to the 'Table 30. 16-bit ADC operating conditions' of K64P144M120SF5, we can know that the max ADC conversion rate is 818.330 ksps. Here I create an example by using KDS3.2 with Processor Expert(See the attach file). After select same configuration according to that table, I got almost the same ADC conversion rate. The conversion time meet equation given in Reference Manual too. Now let's measure the ADC conversion rate on FRDM-K64F board with oscilloscope. After connected an external 1.5KΩ resistance, the value of external RC components is big enough to be observed. Below is the waveform observed with oscilloscope, the frequency between voltage drops at ADC input during sampling is about 818 ksps. This test result is consistent with the theoretical calculated value.
View full article
Here you will find both the code and project files for the USB Mouse project. In this project the USB module is configured as a device, the X and Y coordinates to move the cursor are obtained from the accelerometer measurements. Once the code is loaded it is necessary to disconnect the USB cable from the J26 USB connector and plug it to the K64 USB connector. Once the device enumerates you can use it as an air mouse. The left and right click buttons have not been enabled. To compile the project you must import the following libraries: USBMouse.h FXOS8700Q.h Code: #include "mbed.h" #include "USBMouse.h" #include "FXOS8700Q.h" //I2C lines for FXOS8700Q accelerometer/magnetometer FXOS8700Q_acc acc( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); USBMouse mouse; int main() {     acc.enable();     float faX, faY, faZ;     int16_t x = 0;     int16_t y = 0;       while (1)     {         //acc.getAxis(acc_data);         acc.getX(&faX);         acc.getY(&faY);         x = 10*faX;         y = 10*faY;               mouse.move(x, y);         wait(0.001);     } }
View full article
Today the universal motor is still widely used in home appliances such as vacuum cleaners, washers, hand tools, and food processors. The operational mode, which is used in this application, is closed loop and regulated speed. This mode requires a speed sensor on the motor shaft. Such a sensor is usually an incremental sensor or a tachometer generator. The kind of motor and its drive have a high impact on many home appliance features like cost, size, noise, and efficiency. Electronic control is usually necessary when variables speed or energy savings are required. MCUs offer the advantages of low cost and attractive design. They can operate with only a few external components and reduce the energy consumption as well as the cost. This circuit was designed as a simple schematic using key features of a Kinetis L MCU. For demonstration purposes, the Freescale low cost Freedom KL25z development platform was used. This application note describes the design of a low-cost phase angle motor control drive system based on Freescales’s Kinetis L series microcontroller (MCU) and the MAC4DC snubberless triac. The low-cost single-phase power board is dedicated for universal brushed motors operating from 1000 RPMs to 15,000 RPMs. This application note explains both HW and SW design with an ARM Kinetis L series MCU. Such a low-cost MCU is powerful enough to do the whole job necessary for driving a closed loop phase angle system as well as many others algorithms.        -Freedom development platform with universal motor drive board extension The phase angle control technique is used to adjust the voltage applied to the motor. A phase shift of the gate’s pulses allows the effective voltage, seen by the motor, to be varied. All required functions are performed by just one integrated circuit and a small number of external components. This allows a compact printed circuit board (PCB) design and a cost-effective solution. Learn more about the Kinetis L series Freedom Board Get the full application note in the link bellow:
View full article
Test environment: FRDM-K64F Rev.D IAR ARM Workbench IDE V8.30.1 MCUXpresso SDK for FRDM-K64F v2.4.2(2018-08-02) Test project is [ftm_output_compare] located with default path: ..\FRDM-K64F\boards\frdmk64f\driver_examples\ftm\output_compare Test reason to verify the CnV register is updated on the next FTM counter change. Three test signals: FTM0_CH0 pin as output compare pin will generate square signal with 1.33KHz . FTM0_CH1 pin generate 24KHz Edge-Aligned PWM signal(High-true pulses (clear Output on match)) with 50% duty cycle as FTM counter monitor. When FTM counter change, the FTM0_CH1 will toggle to output high voltage. Test using a delay() function to emulate modify FTM0_CH0 output compare mode and CnV value periodically. There is a GPIO pin will toggle after each delay() function to detect/verify the CnV value actual load point. FlexTimer module setting: The FTM0 refer clock is 60MHz For the FTM0_CH1 pin generate 24KHz PWM signal, the FTM0 MOD value is fixed to 0x9C3 (60MHz/24KHz = 2500).   Below is the overall signals: Test Process Record: During FTM0 module initialization, set the FTM0_CH0 pin output compare value to 0xA00 (more than MOD register value (0x9C3)) with below code: Set the CnV value more than MOD register is to avoid the output compare be set during at start. After that,  enable FTM0 counter and toggle GPIO pin to set a mark: After delay, toggle GPIO pin and update CnV register to 0x270 (the match point is half of the PWM high voltage). The actual signal is : After the first CH0 output compare set match, before set CH0 pin clear on match. It need to keep the CH0 pin with same output compare mode and set CnV back to 0xA00 (more than MOD) again with below code: Then we set CH0 with clear on match mode and update CnV value to 0x752 (middle of CH1 PWM low voltage): The actual signal is: With the similar code, before next CH0 set on match, it need to keep the CH0 pin with same match compare mode setting and CnV change back to 0xA00 (more than MOD). The actual signal is below: Note: During the output compare signal compare mode set/clear change phase, it need to keep previous output compare mode setting, please don't using kFTM_NoOutputSignal setting at code. Otherwise, the output compare signal will exist decay: Test Result: From FTM0 register value, the FTM0_SYNCONF[SWRSTCNT] bit is clear, which means select Legacy PWM synchronization method. The legacy PWM synchronization method will update Output Compare mode CnV register value at the next FTM counter change. The actual signal also verify it. Below is FTM0 all registers value: For the more detailed info, please check the original thread at here. Please check attachment about test code.
View full article