Kinetis微控制器知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Kinetis Microcontrollers Knowledge Base

讨论

排序依据:
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.
查看全文
The following document explains how to load an encrypted image using the MCUBoot in the K64. Download the SDK for the K64, be sure that the MCU boot feature is selected:  https://mcuxpresso.nxp.com/en/welcome   For the example, I’m going to use gpio_led_output. To prepare the example to work with the bootloader, you would need to do the following steps: In properties / C/C++ Build / MCU settings set the start of the flash to the 0xa000, this to preserve the bootloader section:   Generate the binary for the image to load.   Write BCA Create the BCA, this field is to manage the different features of the bootloader. To generated this, the KinetisFlashTool can be used, you can find it in the following link. In this options you need to add the tag, the peripheral used to communicate and a timeout to have a time frame to call again the bootloader without need to call it from your application. Click OK and save the BCA to the image.     The bootloader can be found in the SDK examples: In the bootloader_config.h, change the BL_FEATURE_ENCRYPTION_KEY_ADDRESS for outside the code you would load, in this case, I'm going to use the 0xF000: #define BL_FEATURE_ENCRYPTION_KEY_ADDRESS 0xf000 // NOTE: this address must be 4-byte aligned. After this, load the firmware to the MCU. For the next steps we will need to generate the secure file: Generate the AES 128 key using the elftosb Command: elftosb.exe -V -d -f kinetis -n 1 – K 128 -o SBKEK.key Create the SB image from the binary, Use option -k to pass the key generated before Use option -f to define the device. Device must be kinetis to be able to use a 128 AES key Use option -c to load the bd file. (see attached) Use option -o to define the output Command: elftosb.exe -V -d -f kinetis -c (bd file path) -k (key path) -o (output path).sb2 (image path)   Now we will load the image using the blhost: Erase the memory section to load the program and reset the device  Command: blhost.exe -p COMx – flash-erase-region 0xa000 0x10000 Program AES key, same as generated in the previous step. Load it to the memory section previously defined in the  BL_FEATURE_ENCRYPTION_KEY_ADDRESS and confirm that the key was loaded correctly: Command: blhost.exe -p COMx – write-memory 0xF000 “{{key generated}}” Command: blhost.exe -p COMx –read-memory 0xF000 16   Load the SB file Command: blhost.exe -p COMx – receive-sb-file (path encrypted sb file) After a reset the application should run correctly.                
查看全文
Status: Text content finished, to be updated with more diagrams/images. Foreword First of all. I have to say sorry for my English since I am not a native speaker. This is my personal experience of using AN2295 on FRDM-KL25Z. I want to share it with anyone who is suffering on it, since the existing release from FSL has not been fully tested on FRDM-KL25Z. (I can figure it out in many ways.) Components and Documents The lastest microcontrollers always have some kind of bootloader to download user code to the flash memory. FSL does offer many bootloaders for various mcu families. Among them, AN2295 bootloader is general purpose for most of these families, since it only requires an UART, either hardware or software UART. To make AN2295 work for a system, the developer must have three components: AN2295 bootloader running on target MCU, such as MKL25Z128VLK4 on FRDM-KL25Z. AN2295 bootloader PC software, such as win_hc08sprg, or my Python script, FcBootloaderProgrammer.py AN2295 aware user application, which has different start address and special treatment for interrupt vector. UPDATE Add an2295_programmer_v1.zip for Python source code, you need install PySerial module for Python 2.5. Please visit following URLs to download necessary files: http://www.freescale.com/files/microcontrollers/doc/app_note/AN2295.pdf http://cache.freescale.com/files/32bit/doc/app_note/AN4767.pdf Software for AN2295 AN4767: UART Boot Loader Design on the Kinetis E Series, a more detail application note for AN2295 on E series. Updates for AN2295 on IAR 6.5 The released AN2295 has to be updated before downloading into FRDM. When you open the AN2295_Kinetis project in IAREW, please update the following setup items in IDE. In workspace window, switch to Kinetis L Debug configuration. Right click on AN2295_Kinetis and open Options. Click on Debugger category. In Setup tab, select PE micro in driver, disable Run to options. (The release leaves it as simulator, and run to __main, which makes warning report when you downloading code to debugger) In Download tab, enable Verify download, Use flash loader, Override default .board file, with $TOOLKIT_DIR$\config\flashloader\Freescale\FlashKLxx128K.board . Disable Attach to program. In PE micro, select interface type as OpenSDA - USB In Tools|Options (IDE Options)|stack, you can leave Stack points not valid until program reaches as blank (Optional). In AN2295_LinkerFile.icf, change IntVectTable_end__ from 0x0000003f to 0x000003FF (Optional). In bootloader_cfg.h, enable AN2295_FRDM_KL25Z_cfg.h, comment out AN2295_TWR_KL25Z_cfg In AN2295_FRDM_KL25Z_cfg.h, #define BOOT_UART_BAUD_RATE 57600 Add gpio.h/gpio.c to project, in case you want use them to indicate something. We can conclude a fact that AN2295 is good enough as a bootloader as it has been tested on many MCU families. The source code is open, so you can custom it for your own specific purposes. However, you have to do it yourself. The reason why I change baudrate is I found VCP of OpenSDA will decode 0x00 send from KL25Z as 0x80. So I slow down to 57600. Updates for PC software of AN2295 Unfortunately, The released (10.0.12.0) and updated (10.0.16.0) versions of bootloader PC software don't work with my bootloader. The released PC software of AN2295 is open source as well. However I am not fan for VC++. I prefer to make my own programmer software with Python, as knows as a clue language. The programmer software is released in Windows exe format and works in command line prompt. The user don't bother to install Python/PySerial and other components. The programmer software works in a simple single shot mode, blank/erase/program actions. D:\an2295_programmer>FcBootloaderProgrammer --help ################################################## FC Booloader Programmer v0.1-alpha - An alternative to Freescale AN2295 on FRDM-KL25Z   by Allan K Liu (C)2013 Ennovation LLC ################################################## Usage: -h, --help      :       This help information -p, --port      :       Serial port setting in Windows, like COMxx, depends on your VCP installation -b, --baudrate  :       Baud rate setup from 9600/19200/38400/57600/152000 -f, --file      :       Hex file (Motorola SREC or Intel HEX) -a, --action    :       Action [blank/erase/program] -d, --debug     :       Debug [0:1]    In order to make it simpler, I prepare some DOS batch files. blank.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=blank erase.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=erase program.bat FcBootloaderProgrammer --port=COM14 --baudrate=57600 --debug=1 --action=program --file=DemoApp_4_FC_Bootloader_freedom.srec You can disable debug output optionally. Updates for Demo projects for AN2295 on IAR6.5 In order to run a user application with AN2295 bootloader, you have to rebuild it with modified linker script. You can generate a new app based upon Kinetis L Sample Codeby following steps. Run make_new_project.exe under Kinetis L Sample Code\kl25_sc_rev5\klxx-sc-baremetal\build\iar\ Offer a new project name "DemoApp_4_FC_Bootloader_freedom" according to prompt. Open it in IAR IDE. Change project linker options, enable Override default with $PROJ_DIR$\..\config files\Pflash_32KB_AN2295.icf, the modified linker file. The major changes are: define symbol __ICFEDIT_region_ROM_start__ = 0x00001000; define symbol __ICFEDIT_region_ROM_end__   = 32*1024; define exported symbol __VECTOR_TABLE      = 0x00001000; define symbol __code_start__ = 0x00001410; After building the project, we can get similiar srec file, which has start address at 0x1000. S027000044656D6F4170705F345F46435F426F6F746C6F616465725F66726565646F6D2E7372656331 S1131000F80B0020111400002929000029290000F0 S11310102929000029290000292900002929000084 ...... S1132B200A0D4B4C300000000A0D4B4C31000000E4 S1132B300A0D4B4C320000000A0D4B4C33000000D0 S10B2B400A0D4B4C34000000A7 S9032B0DC4 According to SREC file format, its filename: DemoApp_4_FC_Bootloader_freedom.srec. And it ranges from 0x1000 to 0x1B47 Finally, run "erase.bat", then "blank.bat", then "program.bat" Simple! Other Useful Tools During my development for AN2295, I used some other tools, especially PC terminal to monitor events/traffics on RS232/UART. Future Development Here are my plan. More images for step on step. Smart detection for OpenSDA VCP port. Mutli-thread GUI for bootloader tool. More labs to reduce unnecessary empty flash space on VECTOR_TABLE and flash_protection_table in user application. Support cryptographic/authentication in bootloader to support licenses.
查看全文
With the merger of NXP and Freescale, the NXP USB VID/PID program, which was previously deployed on LPC Microcontrollers, has been extended to Kinetis Microcontrollers and i.MX Application Processors. The USB VID/PID Program enables NXP customers without USB-IF membership to obtain free PIDs under the NXP VID. What is USB VID/PID Program? The NXP USB VID program will allow users to apply for the NXP VID and get up to 3 FREE PIDs. For more details, please review the application form and associated FAQ below. Steps to apply for the NXP USB VID/PID Program Step 1: Fill the application form with all relevant details including contact information. Step 2: NXP will review the application and if approved, will issue you the PIDs within 4 weeks FAQ for the USB VID/PID Program Can I use this VID for any microcontroller in the NXP portfolio? >> No. This program is intended only for the Cortex M based series of LPC Microcontrollers and Kinetis Microcontrollers, and Cortex A based series of i.MX Application Processors. What are the benefits of using the NXP VID/PID Program? >> USB-IF membership not required >> Useful for low volume production runs that do not exceed 10,000 units >> Quick time to market Can I use the NXP VID and issued PID/s for USB certification? >> You may submit a product using the NXP VID and issued PID/s for compliance testing to qualify to use the Certified USB logo in conjunction with the product, but you must provide written authorization to use the VID from NXP at the time of registration of your product for USB certification. Additionally, subject to prior approval by USB-IF, you can use the NXP VID and assigned PID/s for the purpose of verifying or enabling interoperability. What are the drawbacks of using the NXP VID/PID program? >> Production run cannot exceed 10,000 units. See NXP VID application for more details. >> Up to 3 PIDs can be issued from NXP per customer. If more than 3 PIDs are needed, you have to get your own VID from usb.org: http://www.usb.org/developers/vendor/ >> The USB integrators list is only visible to people who are members of USB-IF. NXP has full control on selecting which products will be visible on the USB integrators list. How do I get the VID if I don't use NXP’s VID? >> You can get your own VID from usb.org. Please visit http://www.usb.org/developers/vendor/ Do I also get the license to use the USB-IF’s trademarked and licensed logo if I use the NXP VID? >> No. No other privileges are provided other than those listed in the NXP legal agreement. If you wish to use USB-IF’s trademarked and licensed USB logo, please follow the below steps:                 1. The company must be a USB vendor (i.e. obtain a USB vendor ID).                 2. The company must execute the USB-IF Trademark License Agreement.                 3. The product bearing the logo must successfully pass USB-IF Compliance Testing and appear on the Integrators List under that company’s name. Can I submit my product for compliance testing using the NXP VID and assigned PIDs? >> Yes, you would be able to submit your products for USB-IF certification by using the NXP VID and assigned PID. However, if the product passes the compliance test and gets certified, it will be listed under “NXP Semiconductors” in the Integrators list. Also, you will not have access to use any of the USB-IF trademarked and licensed USB logos. How long does it take to obtain the PID from NXP? >> It can take up to 4 weeks to get the PIDs from NXP once the application is submitted. Are there any restrictions on the types of devices that can be developed using the NXP issued PIDs? >> This service requireds the USB microcontroller to be NXP products. Can I choose/request for a specific PID for my application? >> No. NXP will not be able to accommodate such requests.
查看全文
Many customers reported that their ADC function works on FRDM-KL27Z board but meet issue on their own board. We need to pay attention to the difference between the ADC reference voltages of different packages (on board MKL27Z64VLH4 is 64LQFP package). This tip introduce the ADC Reference Options on KL17/KL27 32/36pin package Part number involved: 32-pins 36-pins MKL17Z32VFM4 MKL17Z32VDA4 MKL17Z64VFM4 MKL17Z64VDA4 MKL27Z32VFM4 MKL27Z32VDA4 MKL27Z64VFM4 MKL27Z64VDA4 PTE30/VREF_OUT- connected as the primary reference option on 36-pin and below packages VDDA/VSSA - connected as the VALT reference option   ADCx_SC2[REFSEL] selects the voltage reference source used for conversions.   About the primary reference option: When on-chip 1.2V VREF is enabled, PTE30 pin must be used as VREF_OUT and has to be configured as an analog input, such as ADC0_SE23 (PORTE_PCR30[MUX] = 000). Notice: this pin needs to connect a capacitor to ground.   PTE30 can also be used as an external reference voltage input as long as PTE30 is configured as analog input and VREF module is disabled. It means you can connect external reference voltage to PTE30 pin and use it as ADC reference voltage. (For example 3.3V) KL17P64M48SF2RM     Kinetis KL17: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1) KL27P64M48SF2RM     Kinetis KL27: 48MHz Cortex-M0+ 32-64KB Flash (32-64pin) (REV 4.1)
查看全文
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 
查看全文
Introduction What is a gated timer and why would I need one? A gated timer is a timer whose clock is enabled (or "gated") by some external signal.  This allows for a low code overhead method of synchronizing a timer with an event and/or measuring an event. This functionality is not commonly included on Freescale microcontroller devices (this functionality is only included on devices that are equipped with the upgraded TPM v2 peripheral; currently K66, K65, KL13, KL23, KL33, KL43, KL03) but can be useful in some situations.  Some applications which may find a gated timer useful include asynchronous digital sampling, pulse width duty cycle measurement, and battery charging. How do I implement a gated timer with my Kinetis FTM or TPM peripheral? To implement a true gated timer with a Kinetis device (that does not have the TPM v2 peripheral), additional hardware will be required to implement the enable/disable functionality of a gated timer.  This note will focus on two different ways (low-true and high-true) to implement a gated timer.  The method used will depend on the requirements of your application. Implementing a gated timer for Kinetis devices without the TPM v2 peripheral requires the use of a comparator and a resistive network to implement a gated functionality (NOTE:  Level shifters could be used to replace the resistive network described; however, a resistive network is likely more cost effective, and thus, is presented in this discussion).  Figure 1 below is the block diagram of how to implement a gated timer functionality.  The theory behind this configuration will be explained in later sections. Theory of Operation Comparator and resistive network implementation The comparator is the key piece to implementing this functionality. For those with little experience with comparators (or need a refresher), a comparator is represented by the following figure.  Notice that there are three terminals that will be of relevance in this application: a non-inverting input (labeled with a '+' sign), an inverting input (labeled with a '-' sign), and an output. A comparator does just what the name suggests: it compares two signals and adjusts the output based on the result of the comparison.  This is represented mathematically in the figure below. Considering the above figure, output of the comparator will be a  logic high when the non-inverting input is at a higher electric potential than the inverting input.  The output will be a logic low if the non-inverting input is at a lower electric potential than the inverting input.  The output will be unpredictable if the inputs are exactly the same (oscillations may even occur since comparators are designed to drive the output to a solid high or solid low).  This mechanism allows the clock enable functionality that is required to implement a gated timer function provided that either the non-inverting or inverting input is a clock waveform and the opposite input is a stable logic high or low (depending on the desired configuration) and neither input is ever exactly equal.  Comparator Configurations There are two basic signal configurations that an application can use to enable the clock output out of the comparator: low-true signals and high-true signals.  These two signals and some details on their implementation are explained in the following two sections.  Low-true enable A low-true enable is an enable signal that will have zero electric potential (relative to the microcontroller) or a "grounded" signal in the "active" state.  This configuration is a common implementation when using a push button or momentary switch to provide the enable signal.  When using this type of signal, you will want to connect the enable signal to the non-inverting input of the comparator, and connect the clock signal to the inverting input. The high level of the enable signal should be guaranteed to always be the highest voltage of the input clock plus the maximum input offset of the comparator. To find the maximum input offset of the comparator, consult the device specific datasheet.  See the figure below to see a graphical representation of areas where the signal will be on and off. The external hardware used should ensure that the low level of the enable signal never dips below the lowest voltage of the input clock plus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. High-true enable A high-true enable is an enable signal that will have an electric potential equal to VDD of the microcontroller in the "active" state.  This configuration is commonly implemented when the enable signal is provided by an active source or another microcontroller.  When interfacing with this type of signal, you will want to connect the enable signal to the inverting input of the comparator, and connect the clock signal to the non-inverting input.  When the comparator is in the inactive state, it should be at or below the lowest voltage of the clock signal minus the maximum input offset of the comparator.  Refer to the following figure for a diagram of the "on" and "off" regions of the high true configurations. The external hardware will need to guarantee that the when the enable signal is in the active state, it does not rise above the highest voltage of the clock signal minus the maximum input offset of the comparator. The following figure displays one possible hardware configuration that is relatively inexpensive and can satisfy these requirements. Clocking Options Clocking waveform requirements will vary from application to application.  Specifying all of the possibilities is nearly impossible.  The point of this section is to inform what options are available from the Kinetis family and provide some insight as to when it might be relevant to investigate each option. The Kinetis family provides a clock output pin for most devices to allow an internal clock to be routed to a pin.  The uses for this option can vary.  In this particular scenario, it will be used to provide the source clock for the comparator clock input. Here are the most common clock output pin options across the Kinetis K series devices.  (NOTE:  If the application requires a clock frequency that the CLKOUT signal cannot provide, a separate FTM or TPM instance or another timer module can be used to generate the required clock.) In the Kinetis L series devices, the following options will be available. The clock option selected should be the slowest allowable clock for the application being designed.  This will minimize the power consumption of the application.  For applications that require high resolution, the Bus, Flash, or Flexbus clock should be selected (note that the Flexbus clock can provide an independently adjustable clock, if it is not being used in the application, as it is always running).  However, if the target application needs to be more power efficient, the LPO or MCGIRCLK should be used.  The LPO for the Kinetis devices is a fixed 1 kHz frequency and will, therefore, only be useful in applications that require millisecond resolutions.
查看全文
Ezportdl:programming Kinetis EZport by MCU-Link Pro NXP launched MCU-Link Pro at the end of 2021. This is a new debugger probe that has been significantly upgraded based on mcu-link. The focus of the upgrade is to add current measurement, analog signal monitoring, USB to SPI and I2C bridge working modes, and on-board lpc804 for peripheral simulation. Among these upgrades, USB to SPI and I2C are more interesting and practical. Combining Kinetis EZport and flashloader, MCU-Link Pro can directly download programs to the target chip, instead of bridge through another board as before. This project uses the USB to SPI function of MCU-Link Pro to download programs to kinetis K series chips through EZport. In addition to the Kinetis series, many ColdFire chips of NXP also support EZport. In addition, since EZport interface protocol is compatible with SPI NOR flash, this project can also directly burn SPI NOR flash chip. This can also be used when debugging or producing i.mxRT500 and i.mxRT600. MCU Link Pro can easily use USB to SPI and I2C interfaces because NXP provides LIBUSBSIO library. Readers can download this library and related documents from NXP's official website. Here is a brief introduction. The SUB to SIO function is only an optional additional function for lpclink2 and MCU-Link Pro devices. Its main function is to provide CMSIS-DAP debugging interface for the target microcontroller, and provide virtual serial communication using USB VCOM class. The following figure is the process framework of LIBUSBSIO. As shown in the figure, LIBUSBSIO library can support SPI, I2C and GPIO.   The core of LIBUSBSIO communication is SPI_Transfer (lpc_handle hspi, spi_xfer_t * xfer) function. This function can send and receive 1024 bytes at most at one time. In addition, LIBUSBSIO library can set baud rate, clock polarity, sampling edge, and frame length. The following figure shows the output waveform captured by the logic analyzer.   Command Description WREN Write Enable WRDI Write Disable RDSR Read Status Register READ Flash Read Data SP Flash Section Program SE Flash Sector Erase BE Flash Bulk Erase RESET Reset Chip WRFCCOB Write FCCOB Registers dl Image download fw Write/read any sequence to SPI port   This project has been tested on FRDM-K64F.    Hardware connection: MCU-Link pro            FRDM-K64F J19-2        ---       R75-1(flying a line is needed) J19-3        ---       J1-8 J19-4        ---       J11-1 J19-5        ---       J1-12    Connect ground together.   Operation steps: Before power on, R75-1 should be connected to ground, then connect openSDA USB. Thus, K64 will enter EZport status. Read memory ezportdl read [address] [number]   Write enable ezportdl wren Write flash, which can write up to 1000 byte. ezportdl sp [length] [data]   Program a binary file into flash Ezportdl dl [address] [file name] [flag]  address means start address flag=0 means erase flash before programming, flag=1 means don’t erase the flash.     Project download address: https://github.com/jophpan/ezportdl/tree/master  
查看全文
A vulnerability (CVE-2022-22819) has been identified on select NXP processors by which a malformed SB2 file header sent to the device as part of an update or recovery boot can be used to create a buffer overflow. The buffer overflow can then be used to launch various exploits. Refer to the attached bulletin for more information.   09/26/2022 - Bulletin updated to include fix datecode information. 11/01/2022 - Bulletin updated with clarification that mixed datecodes are RT600 only.    
查看全文
RNN on FRDM_K64 to denoise 1 Introduction Ordinary MCUs are limited by resources, and it is difficult to do some complex deep learning. But although it is difficult, it can still be done. Last time we used CNN for handwritten recognition. This time ,we use RNN for audio noise reduction. This audio noise reduction uses fixed-point noise reduction. MFCC and gain are used as input parameters for training. MFCC, Mel frequency cepstrum, is often used for audio feature extraction. RNN achieves the effect of noise reduction by adjusting the gain of different frequencies.        2 Experiment 2.1 Required tools: frdm-k64, python 3.7, Pip, IAR   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 Transplant fatfs file system to bubble project   Figure 2   2.5 In the bubble.c file, add the following header file        #include "nnom_port.h" #include "nnom.h" #include "weights.h" #include "denoise_weights.h" #include "mfcc.h" #include "wav.h" #include "equalizer_coeff.h"   2.6 Find main.c under ‘examples\rnn-denoise’ in the framework, ‘main_arm.c’ is used for stm32. Main.c is provided for windows running routines. This code is used to open the audio file, then run the network, and finally generate noise reduction. Use this code to facilitate experiments. The APIs for file operations in this file need to be manually changed to MCU APIs. I added a progress bar display. You can refer the attachment.   2.7 This example also uses DSP, so DSP support needs to be turned on, as shown in the figure                                                           Figure 3 2.8 Add macro                                             Figure 4   2.9 After the compilation is passed, download the program. The tested wav needs to be named ‘sample.wav’, and the mcu will reduce noise for it. Finnally mcu will generate ‘filtered_sample.wav’. Plug the SD card into the computer to listen to the noise-reduced audio. This is serial message.     Figure 5 This is the audio analyzed by the audio analysis software. The upper part is the noise reduced, and the lower part is the original sound. You can see that a lot of noise has been suppressed.                                                    Figure 6 3 training Through the above steps, we have achieved audio noise reduction, so how is this data trained? You need to install tensorflow, and keras. How to train is written in the README_CN.md file. This tensorflow needs to install the gpu version, and needs to install cuda. Please check the installation yourself. 3.1 Download the voice data https://github.com/microsoft/MS-SNSD and put it under the MS-SNSD folder 3.2 Use pip3 to install the tools in requirements.txt 3.3 Run ‘noisyspeech_synthesizer.py’ directly, this will report an error. You need to change the 15-line float to int type. 3.4 Run the script gen_dataset.py to generate mfcc and gain 3.5 Run main.py, this will generate the noise file of the sample, which can be used for testing and also generated ‘weights.h,denoise_weights.h,equalizer_coeff.h’ PS: Put the code in directory 'boards/frdmk64f/demo_app'. 'sample.zip' has the noise wave.
查看全文
Symptoms As we know: Flash must be programmed after an erase operation. Violation of this rule will cause programming fail and even hardfault(when AHB reading) on Kinetis K64 parts. Customer accidently uses SDK’s API programming same sector twice(over-programming) without an erase operation. Then when perform AHB reading of this sector(include using JFLash to read this sector), an Hardfault occurs. Diagnosis K64 flash has internal ECC on each sector. When over-programming happens, ECC will be crushed and trigger Hardfault when AHB reading of this sector. Solution Using SDK API FLASH_VerifyErase to check if this sector is erased. Call FLASH_VerifyErase every time before you want to program the flash. This problem will impact all Kinetis device which has FTFE flash module.   Thanks for Alex Yang provide the material.
查看全文
  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
查看全文
Introduction: User can modify the value of internal reference clock (IRC) by using the Trimming capability of programmers. There are two registers (ICS_C3 & ICS_C4) which contains the trim and fine trim value of the clock respectively. By default, devices comes with a factory programmed trim value which is automatically passed into these registers during reset initialization when not in debug mode. These registers needs to be passed with appropriate value to get the required clock value. This is where programmers come into picture, they generally have this capability to find the accurate trim and fine trim values corresponding to required clock. Now the catch here is that the customized trim value calculated by programmers is stored at reserved flash location (eg-0x000003ff and 0x000003fe for Ke02) and have to be copied to trim registers( ICS_C3 &C4) manually by user during code initialization. Using this process to trim the clock will give accurate desired clock without any deviation between samples. Process:  There is an option in programmers( like I am using PEmicro Multilink universal ) for enabling and setting the trimming feature in the configuration settings as below:         After enabling this option, the programmer will find the best trim value and store at internal memory location:   0x03ff for trim internal reference value 0x03fe for fine trim internal reference value   Below snapshot from console shows this process:       Next step is to copy these value from above locations and pass it to ICS_C3 and ICS_C4 manually in our application code. You can use below code lines:       ICS->C3 = *((uint8_t*) 0x03FF); // trim internal reference clock     ICS->C4 |= ICS_C4_SCFTRIM(*((uint8_t*) 0x03FE)); // fine trim internal reference clock   What the above logic does is – it copies the trimmed value from the factory programmer into your ICS register – not dependent on a constant value but dynamically update the register as per the tuning happening by the programmer. Similar option is there in production programmers also to take care of the trimming process. Note: Above steps are with reference to KE series, for other series user has to check the device reference manual for specific address and register. Also attaching a code with the above mentioned things added into it for ease of understanding. Thanks Madhur
查看全文
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
查看全文
     
查看全文
     
查看全文
  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   
查看全文
Using five channels from FTM2 module of the KE02 microcontroller included on the FRDM-KE02Z board for controlling a robotic arm powered by five servomotors. Each servomotor is controlled by a couple of buttons of a matrix keyboard, which is connected to eigth GPIOs. Interrupts are not used in this example. The code was generated and compiled on CodeWarrior for Microcontrollers v10.5.
查看全文
This application demonstrates the use of the FRDM-KL25 as a HID HOST. 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 .
查看全文
Hey All, Check out the unboxing video for UAV Drone designed using Kinetis V series MCUs to be showcased in Freescale Technology Forum 2015 at booth 249. The Kinetis V series 32-bit MCUs are based on ARM Cortex M cores and specially designed to enable motor control and power conversion applications. Please visit Kinetis V Series Webpage for more information. This drone is powered by Kinetis KV5x MCU (First Kinetis MCU with the latest ARM Cortex M7 Core). The Kinetis KV5x is used in Electronic Speed Control (ESC) unit and a single Kinetis KV5x MCU chip is used to control 4 Brushless DC motors which typically is controlled by four 8 bit MCUs. Along with controlling four motors, the KV5x MCU has enough performance and peripheral headroom so that it can be used as a flight controller and communication interface with connectivity features such as CAN and Ethernet. Kinetis KV5x is ideal solution for industrial IOT with the applications such high performance motor control and power conversion and real time control. Please visit Kinetis KV5x Series Webpage for more information. There is another drone in the Analog section at Freescale Technology Forum based on Kinetis KV4x MCU (based on ARM Cortex M4 core) and Freescale GD3000 3-Phase Brushless DC Gate driver. The Kinetis KV4x MCU is used to control 4 Brushless DC motors and is the cost optimized version of Kinetis KV5x MCUs. Please check out the Kinetis based drone demo as well as other cool demos at Freescale Technology Forum. PS: I apologize for the quality of the video. Working on the better video and editing skills.  Thanks, Mohit Kedia
查看全文