Kinetisマイクロコントローラ・ナレッジ・ベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Kinetis Microcontrollers Knowledge Base

ディスカッション

ソート順:
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 create a support ticket and associated FAQ below.   Steps to apply for the NXP USB VID/PID Program Step 1: Create a support ticket with relevant details for instance company name, PIDs, purpose. Step 2: NXP will review the request and if approved, will issue you the PIDs. Note: The moment we receive a customer's request to the time they obtain a free VID/PID, there may be a delay of a month. 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.
記事全体を表示
中文版本:     相信很多博友在调试ARM代码的时候,尤其是涉及到操作底层的时候,由于一些误操作常常会遇到Hard fault错误或者程序跑飞的情况,这些bug采用正常的方法是比较难定位的,往往需要我们逐行去排查测试,最后看的眼花缭乱,永远给人以苦逼程序员的印象,呵呵。此篇内容致力于节省广大程序员的精力,以崭新的一种方法角度或者说是手段来定位跟踪bug(仅限于支持Coresight技术的ARM处理器,本篇只讲针对M0+内核的),故冠之以“原创猛料”之称号,希望能名副其实,好了,闲话不多说,呵呵,开整……     ARM的Coresight技术估计大家有所耳闻(没听过的可以参考我之前的一篇介绍类文章http://blog.chinaaet.com/detail/29770.html),它实际上包括了ARM嵌入到其处理器内核的片上跟踪调试组件和相关的配套系统软件标准之类的,方便我们开发调试ARM产品。可能单说Coresight技术有点太泛了,把它具体化的话就不得不提到ETB(Embeded Trace Buffer)和MTB(Micro Trace Buffer)这两个经典的模块,其中ETB模块是Cortex-M3/M4内核的片上跟踪单元,而MTB模块则是Cortex-M0/M0+内核的跟踪单元。不过估计很多人没有用过,所以我就本着“吃螃蟹”的态度去尝试了一番,结果还是挺让我惊喜的,灰常好用,所以下面我就把使用方法分享给大家供大家评估,本文以MTB模块调试飞思卡尔基于Cortex-M0+内核的Kinetis L系列为例:     在介绍使用方法之前需要提一下,目前我测试的结果是J-link暂不支持MTB模块(但是支持ETB模块),所以我使用了OpenSDA平台的CMSIS-DAP固件来调用MTB模块,所以如果你手中有Kinetis L系列的Freedom板的话就直接可以跟我做了,其中CMSIS-DAP固件在本博客附件中,使用方法仍旧是类似更新OpenSDA的应用,不过换过CMSIS-DAP固件之后OpenSDA的小灯可能不亮,这个纯属正常,不要惊慌,哈哈。 测试环境:IAR6.6 + Freedom OpenSDA(CMSIS-DAP firmware) 测试目标芯片:Kinetis MKL25Z128     1)打开一个KL25的demo例程,然后右键工程Options->Debugger,选择“CMSIS-DAP”调试器,然后其他默认即可,设置完毕,点击“OK”,如下图所示:     2)点击调试按钮,进入调试界面,此时菜单栏会出现CMSIS-DAP选项,选择CMSIS-DAP->ETM Trace,调用MTB模块,弹出跟踪窗口,如下图所示。默认情况下跟踪功能是禁止的,此时点击跟踪窗口ETM Trace左上角的“电源符号”,打开跟踪功能,此时调试界面的左上角的ETM显示绿色,表示已经打开;     3)此时MTB功能已经打开,我们可以点击“全速运行”,然后再点击“暂停”,此时就可以在ETM Trace跟踪窗口看到从运行到断点停止这段时间所有的指令执行情况了,非常直观,如下图所示,此外可以选择同时查看汇编和C语言,也可以保存跟踪的结果,进而分析程序执行情况。     说到这,我们就该想到这种方式的好处了吧,如果遇到Hardfault或者程序跑飞的时候,通过设置断点或者点击暂停,然后就可以捕捉到出现hardfault或者程序跑飞的之前的程序执行情况从而帮助我们快速定位到bug的地方,非常方便实用。此外,实用CMSIS-DAP调试工具还有一个好处是,可以使用很多插件了,比如Timeline等等,灰常不错,哈哈~ English Version:     As we know, ARM Coresight, the ARM debug and trace technology, is the most complete on-chip debug and real-time trace solution for the entire System-On-Chip(SoC), making the ARM processor-based SoCs the easiest to debug and optimize. In this technology, the ETB in  Cortex-M3/M4 and MTB in Cortex-M0/M0+ are representative two units, which can effectively help us to monitor the process of software executing or focus on some hard faults by tracing the instructions.     In the article, I wanna introduce the MTB useage in our product Kineits L series, which may be helpful to some customers using KL chip. But, before that, a CMSIS-DAP firmware for OpenSDA platform is needed, which you can find in the attachment of this article. So far as I know, it seems that J-Link don't support MTB yet, but do support ETB of Cortex-M4. Testing Platform:     IAR EWARM6.6 + FRDM KL25 (OpenSDA with CMSIS-DAP fimware) Testing steps:     1) firstly, update the OpenSDA with CMSIS-DAP fimware, just like other OpenSDA applications;     2) open any KL25 demo with IAR, access project setting "Options->Debugger", and select the "CMSIS-DAP" adapter as the screenshot shown below;     3) click the debug button to access thw debug window, then click the CMSIS-DAP->ETM Trace from the menu bar,  and the ETM trace window will appear. Note that, the trace function is disabled in default, so another step is needed to click the "power port" at the top left corner to enable the trace function. The screenshot shows it below;     4) Now, the MTB is working. We can try it by click "run" and wait a while to click "pause", then the instructions from run to pause are shown in the trace window, it is really convenient. Besides, we can save, clear or zoom the trace results. Conclution:    Through the above method, some painstaking issues like hardfault or program fleet can be captured simply by setting breakpoints or mannuly pause, which can help to positioning the source of the problem. Beyong that, the CMSIS-DAP can support plugs like timeline tool. BTW, it is a pity that MTB unit in the new Kinetis E series is cut out.         Happy Tracing!
記事全体を表示
Here you can find both the code and project files for the Serial communication project, in this example the serial port (UART) is configured to establish communication between the computer using a serial terminal and the evaluation board. The default baud rate for the serial port is 9600 bauds. The code also implements an echo function, any key pressed in the computer's keyboard will be captured and displayed in the serial terminal. If your computer does not have a serial terminal you can download Tera Term from the following link: Tera Term Open Source Project The communication is established through the USB cable attached to the OpenSDA USB port. Code: #include "mbed.h" //Digital output declaration DigitalOut Blue(LED3); //Serial port (UART) configuration Serial pc(USBTX,USBRX); int main() {     Blue=1;     pc.printf("Serial code example\r\n");        while(1)     {         Blue=0;         pc.putc(pc.getc());     }    }
記事全体を表示
Hello Kinetis fans, This time I bring to you a document which explains what is and how to configure scatter/gather feature which is present in the Enhanced Direct Memory Access (eDMA). This document includes an example project for the Kinetis Design Studio (KDS) which works in the FRDM-K64F board but the configuration is the same for any MCU which includes the eDMA peripheral. If you are interested in the channel linking feature, please take a look into the document What is and how to configure the eDMA channel linking feature​. I hope you find this document useful. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors
記事全体を表示
This was a super fun project to work on and is popular around the office and on the road.  Now I have two of these for a truely amazing barrage of Nerf darts!  It's also always a lot of fun to tear things down and the Nerf gun had some cool plastic work and the shooting mechanism is more simple than what I originally guess.  But I digress, this post is about how you can build one of these yourself.  Please leave any questions or comments in the section below and I will try to answer and make refinements to this guide as we go. Say hello to my little friend. The shopping list (aka Bill of Materials or BOM) If you shop around you might be able to find better prices or substitute parts. Type Part Qty Price URL UBEC HKU5 1 $             5.33 http://www.hobbyking.com/hobbyking/store/__16663__HobbyKing_HKU5_5V_5A_UBEC.html LiPo TURNIGY 2200mAh 3S 20C 1 $             7.89 http://www.hobbyking.com/hobbyking/store/__8932__Turnigy_2200mAh_3S_20C_Lipo_Pack.html Servo S5030DX 1 $           28.63 http://www.hobbyking.com/hobbyking/store/__18862__Hobbyking_S5030DX_Digital_MG_Servo_X_Large_HV_164g_0_20s_30kg.html Servo HK15138 1 $             3.12 http://www.hobbyking.com/hobbyking/store/__16269__HK15138_Standard_Analog_Servo_38g_4_3kg_0_17s.html Relay PCB COM-11041 1 $             3.95 https://www.sparkfun.com/products/11041 Relay Components Various 1 $             3.00 https://www.sparkfun.com/wish_lists/36307 Nerf Gun Nerf Dart Tag Swarmfire Blaster 1 $           44.99 http://www.toysrus.com/product/index.jsp?productId=11267568 Controller FRDM-KL64F 1 $           12.95 http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K64F Radio Module NRF24L01 2 $             3.00 http://www.dx.com/p/2-4ghz-nrf24l01-wireless-module-black-142224#.U8VIcpRdU1I Servo Arm Double Servo Arm X-Long 1 $             3.20 http://www.hobbyking.com/hobbyking/store/__19468__CNC_Alloy_Double_Servo_Arm_X_Long_Futaba_.html Servo Arm Heavy Duty Alloy Arm 1 $             5.63 http://www.hobbyking.com/hobbyking/store/__18350__Heavy_Duty_Alloy_1in_Servo_Arm_Futaba_Red_.html Servo Linkage Alloy Pushrod with Ball-Link 65mm 1 $             2.10 http://www.hobbyking.com/hobbyking/store/__25834__Alloy_Pushrod_with_Ball_Link_65mm.html Lazy Susan Shepherd 6 in. Lazy-Susan Turntable 1 $             4.49 http://www.homedepot.com/p/Shepherd-6-in-Lazy-Susan-Turntable-9548/100180572#.UYk5UqLql8E Metal Rod 3/8 in. x 36 in. Zinc Threaded Rod 1 $             2.87 http://www.homedepot.com/p/3-8-in-x-36-in-Zinc-Threaded-Rod-17340/202183465#.UYk5pqLql8E Frame 1/2 MDF 2ftx4ft 1 $           10.45 http://www.homedepot.com/p/1-2-in-x-2-ft-x-4-ft-Medium-Density-Fiberboard-Handy-Panel-1508108/202089097?N=btn1#.UYk6CqLql8E The build Two main pieces to construct in this phase.  The base turret and the actual hacking of the Nerf gun. All your base.. The base of the turret is pretty rudimentary, lot's of room for improvement here.  I used 1/2 MDF and some carpentry skills.  Here is an instructable on how to build a MDF box.  Atop the box is a lazy susan (ball bearing ring) so that the top-plate can rotate smoothly.  We considered leaving this element out, but worried that it would put to much strain on the servo. On the subject of servos, a few tidbits of wisdom for you as you build this thing.  First, the left/right servo needs to be dead center of the lazy susan, if your off too much things will start to bind which is not good for your servo.  Second, I used large higher torque servos which cost a bit more, they might be overkill, but it certainly performs well. I did a quick dimensionally accurate rendering of the design in Sketchup. Files are here. Hacking the Nerf Now for the fun stuff. There is no shortage of screws with this Nerf Gun.  So get out your Phillips screwdriver and go to town. There are two electrical systems in the Nerf that we are going to tap into.  One is the power switch and the other is the electrical trigger. This is the electrical trigger.  The trigger goes to our relay, which is either on or off.  We did try at first to use a 7.2V R/C car battery, but the Nerf draws too much power and didn't fire.  Going up to a 11.1V LiPo fixed that right up. This is the power switch. In Nerfinator 1.0 everything was hardwired together, which prevented us from completely pulling the Nerf from the base and made repairs difficult to say the least.  Nerfinator 2.0 we put this handy connector which allowed us to completely and easily remove the Nerf from the base.  Shipping this thing around the country will take a toll on it!  On that subject, Nerf 1.0, stopped cycling to the next position for us at the Austin Mini Maker Faire.  After a through inspection of the operational mechanics inside the Nerf (really cool BTW) it was a little bitty spring that was causing the piston not to fully retract.  We replaced the spring with 1/2 a ballpoint pin spring and to our surprise it all worked again.  Cue the MacGyver theme song... Electrical Connection Diagram [PDF] Code Mbed was the programming tool of choice for this build. Receive Side (RX) - The receiver is the base side.  This one takes input from the remote and controls the servo movement. NerfGun_nRF24L01P_RX - a mercurial repository | mbed Transmit Side (TX) - The transmitter is the remote side.  This one senses the users movement (accelerometer) and sends that data to the base station. NerfGun_nRF24L01P_TX - a mercurial repository | mbed Finishing Touches In the first passes of this build we just used a bare development board as the remote control.  We found that when given the remote they would not orientate it properly.  Angus and Iain CAD'ed up this really sweet controller for us to 3D print. Custom cutouts for the FRDM board and nRF module and powering through USB. Freedom- 3D Printed Controller files on Thingiverse Development Team Deactivated user - Amplification/Motivation CJarvis - Software/Hardware iafg and angusgalloway-b45797 - Design and print of controller Community Developed Improvements Nerf Gun Web Socket Compatibility - Controlling via Web Socket
記事全体を表示
The DOC introduces the nano-edge placement  feature for KV4x family, it gives the application for the nano-edge placement feature, in other words, it's target is to increase the PWM signal resolution. It gives the example code and PWM waveform for the nano-edge placement feature.
記事全体を表示
I2C (Inter-Integrated Circuit) Module by Alejandro Lozano, Freescale TIC. i2C Protocol Explanation. Connection Diagram. How to configure the registers. Hands-On. Presentación del módulo de I2C (Inter-Integrated Circuit) por Alejandro Lozano, Freescale TIC. Explicación del Protocolo I2C. Diagrama de conexión. Explicación de cómo configurar los registros. Hands-On
記事全体を表示
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.
記事全体を表示
Latest version of the AN2295 universal bootloader includes support for IAR 7.6 IDE. - added support for Kinetis E MCUs - Kinetis K,L,M,E,W,V support
記事全体を表示
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.
記事全体を表示
Background: NXP SC18IS602B I2C bus to SPI bridge chip is using TSSOP16 package, which is 16 leads; 0.65 mm pitch; 5 mm x 4.4 mm x 1.1 mm body. Customer requires to use a smaller package to emulate the SC18IS602B function. Kinetis L series MKL03Z16VFK4R product uses QFN24 package with 4 mm x 4 mm x 0.58 mm body. Demo Overview The I2C to SPI Bridge demo provides a replacement solution demo of SC18IS602B chip. The demo is based on FRDM-KL03Z board using I2C0 module as I2C slave and SPI0 module as SPI master. Provided data buffer size is 400bytes. The demo software is based on KSDK V2.0 for FRDM-KL03Z software. I2C slave interface: Pin number                 Function              FRDM-KL03Z jumper PTB3                          I2C0_SCL           J2-10 PTB4                          I2C0_SDA           J2-9   SPI master interface: Pin number                 Function              FRDM-KL03Z jumper PTA5                           SPI0_SS             J2_3 PTA6                           SPI0_MISO         J2_5 PTA7                           SPI0_MOSI         J2_4 PTB0                           SPI0_SCK           J2_6   INT pin (indicates if I2C to SPI Bridge allows i2c master start a new i2c transfer, low is active) Pin number                 Function              FRDM-KL03Z jumper PTB11                        GPIO output         J2_2   Connect I2C master with FRDM-KL03Z I2C slave interface and connect SPI slave with FRDM-KL03Z SPI master interface; Connect FRDM-KL03Z GND to I2C master and SPI slave before add power to those boards.  Below is the hardware platform connection way: I2C to SPI Bridge Demo Function For the KL03 chip with one SPI0_PCS0 chip select pin, I2C to SPI Bridge demo only supports function ID 0x01 as SPI write command. For example: if i2c master want to write 8bytes (0x21,0x22...0x28) to SPI slave, the i2c master needs to send below data to FRDM-KL03Z board:   [START] + [I2C Slave address+/W] + [0x01](Function ID) + [0x21](data 1) + [0x22](data 2) + ... +[0x28](data 😎 + [STOP]     I2C to SPI bridge demo supports Function ID 0xF0 to configure SPI interface: There provides four SPI baud rate: 6Mbps/3Mbps/1.5Mbps/1Mbps. More detailed info, please check below picture (picture abstracted from SC18IS602B datasheet): For example: customer could configure SPI baud rate to 3Mbps with send below data to FRDM-KL03Z board:        [START] + [I2C Slave address+/W] + [0Xf0](Function ID) + [0x01](data 1) + [STOP] Hardware Platform The demo is based on FRDM-KL03Z board, using internal IRC48M clock as system and bus clock source. There doesn’t need external clock source. Toolchain supported - IAR embedded Workbench 7.60.1  (Tested) - Keil MDK 5.18a - GCC ARM Embedded 2015-4.9-q3 - Kinetis Development Studio IDE 3.2.0 Running the Demo Connect a USB cable between the host PC and the USB port on the target board. Open a serial terminal with the following settings:     - 9600 baud rate     - 8 data bits     - No parity     - One stop bit     - No flow control Download the program to the target board. I2C master start to configure SPI interface      I2C to SPI bridge board I2C address is 0x7E. I2C master write data to SPI slave    I2C master write 10bytes to SPI slave, it will send 11bytes (includes one function ID 0x01). The first data is 0xAA and the last data is 0x22.    After I2C to SPI Bridge receive the data, it will send 10bytes to SPI slave.        I2C to SPI Bridge receive 10 bytes     I2C to SPI Bridge send 10bytes to SPI slave I2C master read data from SPI slave    I2C master read 10bytes(0x10 to 0x19) from SPI slave need to write data to SPI slave at first, then read data from I2C to SPI bridge data buffer directly.    Here just shows read 10bytes from I2C to SPI bridge data buffer. Attached I2C to SPI Bridge demo software default location is: ..\SDK_2.0_FRDM-KL03Z\boards\frdmkl03z\user_apps\i2c_to_spi
記事全体を表示
Table of Contents 1       Introduction 2       DMA to emulate ADC Flexible Scan. 2.1         System overview and flow diagram for Flexscan. 3       SDK implementation. 3.1         ADC configuration. 3.2         LPMTR configuration 3.3         DMA configuration 4       ADC Flex Scan mode with DMA Appendix A: Requirements Reference   1    Introduction This document describes how to combine ADC, DMA and a timer to implement a ADC Flexible storing data with SDK 2.2 and MCUXpresso IDE. In this configuration ADC measures will be stored into an internal memory buffer with DMA, which imply, no CPU. With this configuration MCU uses less resources, only using ADC and DMA (2 channels) and a timer to trigger conversions. This way, the MCU does not need to read the ADC result register, because the memory management will be done by DMA automatically.   To implement this application we will use SDK libraries, which includes ADC and DMA libraries. The timer used to trigger ADC conversion will be the LPTMR. MCUXpresso IDE will be used as development environment, please check Appendix A to look where you can download SDK libraries and IDE. The project will be created from scratch, regardless of this, MCUXpresso IDE and SDK libraries allows us to create a project with some headers and libraries in the project, if you have problems creating a new project in MCUXpresso please check Reference 4.   In this document we will use the FRDM-K64F which is an ultra-low-cost development platform, but this implementation could be easily migrated to any kinetis family that support second-generation eDMA module (enhanced Direct Memory Access).   This document is an update of the community doc: Using DMA to Emulate ADC Flexible Scan Mode with KSDK  which uses old SDK libraries.   2     DMA to emulate ADC Flexible Scan   Flexible scan implementation needs 2 types of data movement: ADC measures (from peripheral to internal memory) and ADC mux change (from internal memory to peripheral). Second one is needed to change ADC input channel and have the flexible implementation, first one save ADC measures in our internal memory.   DMA peripheral (for this MCU) includes up to 16 channels, for this application we will only use 2 channels, one for ADC measures and one for ADC muxing channel. It is important to remark that we will use the linking feature in these channels to implement the ADC changing channel automatically, later in this document it will be explain this feature.   2.1         System overview and flow diagram for Flexscan.   As already mentioned, this implementation will use one DMA channel to transfer data from ADC measures (ADC0_RA register in this case) to a memory buffer (named here as g_ADC0_resultBuffer), so follow figure shows this movement:     As you can see, ADC0_COCO (conversion complete) will be the one that request a transfer from ADC0_RA to resultBuffer. Once this transfer has completed, we need to change ADC channel, so when DMA channel 1 transfer finishes, it will indicate us to trigger the other data movement, in this case from internal buffer g_ADC_mux (that save our adc channels) to the ADC0_SC1A register that sets the ADC channel, so the following diagram shows this.     To do this, this application used a DMA feature that link DMA channels, channel-to-channel linking. So, when one DMA channel finished, the linked DMA channel will be triggered, in this case when DMA channel 1 has completed to move data from ADC measure register to internal memory then DMA channel 0 need to be triggered to change the ADC channel, so next conversion ADC would have selected other ADC channel.   Once that the ADC channels is changed (and the HW trigger happens), the COCO flag from ADC will trigger other DMA request in channel 0 and the process will start again. This flow process can be repeated as many channels as we have and as many samples as we want, for this example code we will measure 3 channels and have 4 samples, so the result buffer size is 3 × 4 = 12 (the real buffer size is 16, to demonstrate that only 12 data field parts are written).   The ADC works in hardware trigger mode, with the LPTMR timer working as the trigger source. This mean that even though DMA channel 0 changed the ADC input channel, conversion will not start until HW trigger (LPTMR) start the conversion, this mean that the flow of the program can be as follow.       In the example code provided, when DMA channel 0 has changed 3 times the ADC channel, DMA channel 1 major loop will happen, and when the sample X is the last sample (sample 4) of the last channel in muxbuffer, then Major loop in DMA channel 0 happens and the application ends (or it could start again). This mean that the application here can be shown as:             3     SDK implementation   Implementation of this code can be dived in three parts; LPTMR, ADC and DMA configuration.   3.1         ADC configuration       ADC configuration is a normal ADC config, with 12 single ended, Asynchronous clock source and Vref as reference voltage. Hardware trigger and DMA support are enable to trigger conversions with LPTMR and to be able to trigger a DMA request when COCO interrupt happen. In ADC channel configuration, it is enable Conversion completed interrupt and it is loaded the value of g_ADC_mux to channel number, this will be the first channel that LPTMR will trigger.   3.2         LPMTR configuration       LPMTR is a common configuration with LPTMR as time counter. Please notice that prescaler could be used and select a prescaler clock. To set LPTMR period it is used the macro USEC_TO_COUNT, which just take the value in microseconds and it calculate the number of ticks to count, using the source clock. Also at the end, LTPMR is configured to be used as HW trigger for ADC conversions in the SIM register.   3.3         DMA configuration     For DMAMUX configuration it is enable Channel 0 and 1 and it is selected the source trigger, DMA for channel 0 (it will be triggered with linking feature) and ADC COCO flag for channel 1 (trigger when the ADC conversion complete).     For DMA configuration, it is needed to create 2 tcd configuration, there are set in transferConfig_chx. First one defined is for DMA channel 1 (data from ADC measure to internal memory), and the second is for DMA channel 0 (data from internal memory to ADC_SC1 register to change ADC channel). Please noticed that these definitions are in bytes to transfer, so some of them are sizeof(uint16_t). Here is also the setup to link channel 1 to channel 0.       Finally, it is added the adjustment for TCD, so when DMA major loop finished in both, it will point to the start of the source and destination. Noticed that this is added just for internal memory address, this is because for the case of a peripheral (ADC in this case), pointer to address doesn’t change.   Then DMA channel 1 and LPTMR are started.   When DMA channels were initialized, their callbacks were also defined;     This flags are just used for this implementation and as reference, they can be removed if needed. After Major loop has finished, SDK implementation disable DMA transfers automatically, so noticed that the callback_1 for DMA channel 1 has a line commented, that if uncommented, this application will act as a ADC that load measurements in an internal Ring buffer Indefinitely.   4     ADC Flex Scan mode with DMA With a basic Print implementation of ADC results we can show the functionality of this example project.     There are obtained the following results,         Appendix A: Requirements Download page for MCUXpresso IDE: MCUXpresso IDE|NXP  Download page for SDK 2.x drivers: Welcome to MCUXpresso | MCUXpresso Config Tools  Go to Build an SDK, select your device and click on Specify Additional Configuration Settings, verify that you have selected KDS as toolchain and then Go to SDK Builder. Click in Download Now, accept Term and conditions and download SDK packet. Please check: Generating a downloadable MCUXpresso SDK v.2 package    References   Using DMA to Emulate ADC Flexible Scan Mode with KSDK  MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse  https://www.nxp.com/docs/en/application-note/AN4590.pdf  Creating New Projects using installed SDK Part Support, MCUXpresso_IDE_User_Guide.pdf  
記事全体を表示
为了提高我们FAE对客户支持的效率,我们有必要将我们在客户支持过程中遇到的问题和解决方法以FAQ的形式列出来,方便大家查阅和参考。FAQ的形式比较灵活,大家可以以简单问答的形式言简意赅的描述,也可以是参考文章的链接,众人拾柴火焰高,希望大家能多收集问题并及时更新到该帖子中。 版本更新说明: Version 22: Rename "软件和例程" with "软件和文档", Add "常用的应用笔记" into "软件和文档" list; Version 20, 21: Remove "WIFI" solution, Add "SPI接口读写SD卡"; Version 19: Replace "iBeacon" with "BLE"; More version informations, please go to "Kinetis M0+ FAQ 版本更新历史" FAQ使用规范 1.FAQ Notes(Internal Use Only) 芯片选型 1.Kinetis L、E、V、W、M系列选型指南 软硬件开发环境 1.调试工具 2.量产工具 3.开源工具 4.IDE开发环境 5.开发板 硬件设计 1.电路设计注意事项 软件和文档 1.外设模块相关 2.Kinetis SDK 3.Kinetis Bootloader 4. 常用的应用笔记​ 参考设计及解决方案 1.Wireless Charging 2.Motor Control 3.BLE​ 4.M0+ 与Android手机通讯(基于AOAP协议) 5.SPI接口读写SD卡​ 常用网站资料 1.Amobbs(阿莫电子技术论坛) 2.与非网飞思卡尔技术社区 3.21IC飞思卡尔论坛 4.苏州大学教材光盘资料下载区 5.针对飞思卡尔单片机的快速上手指南 6.飞思卡尔MAPS开发板资料​ 7.FAE Technical Blogs​
記事全体を表示
客户要求:K60 100MHz芯片作为SPI主机读取片外SPI Flash存储器内容(SPI Flash器件数据准备完成会触发K60 GPIO中断),要求在130~150微秒之间读取九个不连续地址上的数据,每个地址需要读取4个字节,SPI波特率为5MHz。读取SPI Flash存储器,需要使用读取命令(1个字节)外加地址(2个字节)。换言之,每读取一次K60需要发送7个字节(1字节读取命令+2字节地址+4字节空读数据)。同时要求减少内核负担。 Customer requirement: Use K60 100MHz product as SPI master communicate with external SPI Flash device (When data ready, SPI Flash device will trigger K60 GPIO interrupt), it need to read data from 9 discontinuous address, each address read 4 bytes within 130~150us. SPI  baud rate is 5MHz. Read data from SPI Flash, it need SPI master send 1byte read command and 2bytes address. In another word, K60 need to send 7bytes(1byte read command+2bytes address+4bytes dummy read) 9times within 130us. SPI communication baud rate is 5MHz. It also require to reduce core work load. 实现方法:使用DMA模块,其中一个DMA通道1用来装载SPI传输TX数据(触发源为SPI TFFF符号,SPI FIFO可装载),另外一个DMA通道0用来接收SPI数据(触发源为SPI RFDF符号,SPI 接收FIFO非空)。通过使用DMA引擎可以自动发起SPI传输,减少内核在SPI传输过程中的干预,达到降低内核工作负荷的效果。SPI模块采用中断方式。 Reality way: Use DMA module, DMA CH0 loads data for SPI transmit, DMA CH1 stores data for SPI receive.  DMA triggered by SPI module and SPI module works in interrupt way. 测试平台:TWR-K60D100M, TWR-MEM, IAR ARM Workbench V6.60 TWR-MEM板子提供SPI Flash设备(AT26DF081A),可以通过TWR-K60D100M SPI2模块进行访问。 Test platform: TWR-K60D100M ,TWR-MEM , IAR ARM Workbench V6.60 SPI Flash AT26DF081A on TWR-MEM board, which could be accessed by TWR-K60D100M via SPI2 module. 测试场景一:读取AT26DF081A设备ID信息 Test scenario 1:  Read device ID AT26DF081A设备提供查询设备ID命令0x9F,返回4个字节设备ID信息(0x1F,0x45,0x01,0x00)。K60作为SPI主机发出查询命令,之后执行4次空写入操作用来读出设备ID信息。测试中SPI传输/接收数据帧大小设定为1个字节(8bit)。由于DSPI模块传输接收均提供4级FIFO,测试中使用两种方式进行SPI数据发送,一种方式使用DMA通道发送读取设备ID查询命令和4次空写入数据,另一种方式通过执行代码(需要内核干预)发送读取设备ID查询命令和4次空写入数据。SPI数据接收均使用DMA完成。为了便于测试使用DMA模块是否降低内核负荷,在DSPI通信同时,主程序在While循环中不停翻转GPIO引脚(PTD7)。 SPI Flash AT26DF081A provides read device ID command(0x9f), will feedback 4 bytes device ID info(0x1F,0x45,0x01,0x00)。K60 works as SPI master send read ID command, then send 4 dummy write data to read back device ID info. During test, SPI data frame size setting to 1byte(8 bit). For DSPI module TX/RX FIFO is 4 entries, so there using two ways do SPI data transfer, one is using DMA CH1 send data, the other way using software code send data. SPI RX using DMA CH0 and in main while loop it will toggle PTD7 pin to show if using DMA module will reduce core work load. 测试流程图(方法一: 使用DMA CH1发送SPI数据): Test flow chart (Way1: Using DMA CH1 do SPI TX): 测试结果(Test Result): 执行一次读ID信息操作,需要花费12.96us,其中内核处理中断的时间为(2.56+2.72)= 5.28us。 根据客户要求,依照此方法每次发送3个字节,接收4个字节,SPI通信过程中内核负荷时间比率为 (5.28/16.16) =32.7% SPI read ID operation once, it will take 12.96us, includes core deal with interrupt time 5.28us. According to this way, customer want to TX 3bytes then RX 4bytes, during SPI communication core work load rate is 32.7% 测试流程图(方法二: 使用软件代码发送SPI数据): Test flow chart (Way2: Using software code do SPI TX): 测试结果(Test Result): 执行一次读ID信息操作,需要花费11.6us,其中内核处理中断的时间为(2.48+1.40)= 3.88us。 根据客户要求,依照此方法每次发送3个字节,接收4个字节,SPI通信过程中内核负荷时间比率为 (3.88/14.80) =26.2% SPI read ID operation once, it will take 11.6us, includes core deal with interrupt time 3.88us. According to this way, customer want to TX 3bytes then RX 4bytes, during SPI communication core work load rate is 26.2% 测试场景二:读取AT26DF081A设备9处不连续地址数据 Test scenario 2: Read 9 discontinue address data from AT26DF081A AT26DF081A设备提供读阵列命令(0x0B),可以连续读取多个字节数据。根据客户要求,测试读取9处不连续地址数据,每处读取4个字节。根据AT26DF081A设备要求,读阵列命令后需要再发送3个字节地址信息外加1个字节空写入数据,之后K60将会收到数据。即如果要读取4个字节数据,K60作为SPI主机需要发送9个字节数据(1个字节读阵列命令+3个字节地址+1个字节空写入+4个字节空写入)。测试中使用两个DMA通道进行SPI数据收发,两个DMA通道交替工作,DMA通道0(SPI接收)优先级高于DMA通道1(SPI发送)。完成9处数据采集后进入SPI中断,清除EOQ标志并且修正DMA通道配置,进行新的一轮9处数据读取测试。为了便于测试使用DMA模块是否降低内核负荷,在DSPI通信同时,主程序在While循环中不停翻转GPIO引脚(PTD7)。 SPI Flash AT26DF081A provides read array command (0x0B) to sequentially read a continuous stream of data out. With customer requirement, the test will read 9 discontinue address data, each address read 4 bytes data. AT26DF081A datasheet shows read array command with 3 bytes address and 1 dummy byte, then following will be data. In order to read 4 bytes data out, K60 as SPI master need TX 9 bytes data (1byte read array command + 3bytes address + 1byte dummy data + 4bytes dummy data). During the test, it using two DMA channels do SPI TX/RX, each channel alternatively work, DMA CH0(SPI RX) with higher priority than DMA CH1(SPI TX). When finish 9 discontinue address data receive, it will clear EOQ flag and refresh DMA CH0/1 setting in SPI interrupt for next round read 9 discontinue address data test. In main while loop it will toggle PTD7 pin to show if using DMA module will reduce core work load. 测试流程图(Test flow chart): 测试结果(Test Result): 读取AT26DF081A设备9处不连续地址数据,需要花费132.32us,其中内核处理中断的时间为2.6us。 根据客户要求,依照此方法每次发送3个字节,接收4个字节,重复9次。SPI通信过程中内核负荷时间比率为 (2.6/103.52) =2.5% SPI read ID operation once, it will take  132.32us , includes core deal with interrupt time 2.6us. According to this way, customer want to TX 3bytes then RX 4bytes, 9times,during SPI communication core work load rate is 2.5% DMA模块提供动态加载DMA传输控制描述符(TCD)功能,当需要连续多次执行SPI传输时,使用这种功能可以进一步减少内核负荷。 DMA module provides dynamic scatter/gather feature, which supports automatically loading a new TCD into a DMA channel. Using this feature will reduce core work load in SPI transfer continuously. 测试结果(使用DMA动态加载功能): Test Result(Using DMA dynamic scatter/gather feature ): 读取AT26DF081A设备9处不连续地址数据,需要花费130.68us,其中内核处理中断的时间为0.76us。 根据客户要求,依照此方法每次发送3个字节,接收4个字节,重复9次。SPI通信过程中内核负荷时间比率为 (0.76/101.88) =0.75% SPI read ID operation once, it will take 130.68 us , includes core deal with interrupt time 0.76us. According to this way, customer want to TX 3bytes then RX 4bytes, 9times,during SPI communication core work load rate is 0.75% 测试结论(Test conclusion) SPI通信过程中DMA模块使用方式不同对于减轻内核负荷作用差异明显。通常SPI进行大量数据传输接收,使用DMA模块能有效减少内核负荷。鉴于客户需求,使用测试场景二的方法可以有效降低内核负荷。 How to use DMA module to reduce core work load, different way lead to different result. In general, using DMA module do amounts of SPI data transfer will reduce core work load . According customer requirement, using test scenario 2 way reduce core work load dramatically。 为什么每次读操作之间需要SPI片选无效 (Why need deassert CS signal between each read operation)? 根据AT26DF081A手册要求,读ID命令和读阵列命令都需要使片选信号无效用以结束当前的读操作,换言之如果要开始新的读操作,需要结束之前的通信(使片选信号无效)。 AT26DF081A datasheet indicates deasserting the CS pin will terminate the read operation and put the SO pin into a high-impedance state. In order to start new read command operation, it need deassert the CS pin. 计算客户要求每次读命令间隔时间为SPI实际通信时间(以5MHz波特率发送7个字节重复9次 100.8us)加上内核处理中断时间。 According customer requirement SPI each read command interval time is SPI communication time (TX 7bytes 9times with 5MHz baud rate take 100.8us) add core deal with interrupt time. 测试代码(Test source code) 测试代码基于Kientis 100MHz Rev2例程中的[spi_demo]工程,将测试代码替换<spi_demo.c>和<isr.h>文件即可。 Test source code is based on KINETIS512_V2_SC (Kientis 100MHz Rev2 Example Project) [spi_demo] project, using test code instead of orignial <spi_demo.c>&<isr.h> files.
記事全体を表示
        在我们嵌入式工程应用中,中断作为最常用的异步手段是必不可少的,而且在一个应用程序中,一个中断往往是不够用的,多个中断混合使用甚至多级中断嵌套也经常会使用到,而这样就涉及到一个中断优先级的问题。         以我们最熟悉的Cortex-M系列为例,我们知道ARM从Cortex-M系列开始引入了NVIC的概念(Nested Vectors Interrupts Controller),即嵌套向量中断控制器,以它为核心通过一张中断向量表来控制系统中断功能,NVIC可以提供以下几个功能: 1)可嵌套中断支持; 2)向量中断支持; 3)动态优先级调整支持; 4)中断可屏蔽。         抛开其他不谈,这里我们只说说中断优先级的问题。我们知道NVIC的核心工作原理即是对一张中断向量表的维护上,其中M4最多支持240+16个中断向量,M0+则最多支持32+16个中断向量,而这些中断向量默认的优先级则是向量号越小的优先级越高,即从小到大,优先级是递减的。但是我们肯定不会满足于默认的状态(人往往不满足于约束,换句俗话说就是不喜欢按套路出牌,呵呵),而NVIC则恰恰提供了这种灵活性,即支持动态优先级调整,无论是M0+还是M4除了3个中断向量之外(复位、NMI和HardFault,他们的中断优先级为负数,它们3个的优先级是最高的且不可更改),其他中断向量都是可以动态调整的。         不过需要注意的是,中断向量表的前16个为内核级中断,之后的为外部中断,而内核级中断和外部中断的优先级则是由两套不同的寄存器组来控制的,其中内核级中断由SCB_SHPRx寄存器来控制(M0+为SCB_SHPR[2:3],M4为SCB_SHPR[1:3]),外部中断则由NVIC_IPRx来控制(M0+为NVIC_IPR[0:7],M4为NVIC_IPR[0:59]),如下图所示: M0+中断优先级寄存器: M4中断优先级寄存器:         其中M4所支持的动态优先级范围为0~15(8位中只有高四位[7:4]才有效),而M0+所支持的动态优先级范围则为0~3(8位中只有高两位[7:6]才有效),而且秉承着号越小优先级越高的原则(0最高,15或3为最小),同时也间接解释了为什么复位(-3)、NMI(-2)和HardFault(-1)优先级最高的原因,很简单,人家都是负的了,谁还能比他们高,呵呵,而且这三位中复位优先级最高,NMI其次,HardFault最低(这个最低仅限于这三者)。 下面给出个ARM CMSIS库中关于M0+和M4中断优先级设置的API函数NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)实现供大家来参考: M0+: NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority) {   if(IRQn < 0) {     SCB->SHP[_SHP_IDX(IRQn)] = (SCB->SHP[_SHP_IDX(IRQn)] & ~(0xFF << _BIT_SHIFT(IRQn))) |         (((priority << (8 - __NVIC_PRIO_BITS)) & 0xFF) << _BIT_SHIFT(IRQn)); }  /* set Priority for Cortex-M  System Interrupts */   else {     NVIC->IP[_IP_IDX(IRQn)] = (NVIC->IP[_IP_IDX(IRQn)] & ~(0xFF << _BIT_SHIFT(IRQn))) |         (((priority << (8 - __NVIC_PRIO_BITS)) & 0xFF) << _BIT_SHIFT(IRQn)); }   /* set Priority for device specific Interrupts  */ } M4: void NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority) {   if(IRQn < 0) {     SCB->SHP[((uint32_t)(IRQn) & 0xF)-4] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff); } /* set Priority for Cortex-M  System Interrupts */   else {     NVIC->IP[(uint32_t)(IRQn)] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff);    }        /* set Priority for device specific Interrupts  */ }
記事全体を表示
[EEPROM emulation driver for KEA128 and KEA8] software used for Kinetis EA family product (without integrated EEPROM memory), which using the sector-erasable Flash memory be used to emulate the EEPROM through EEPROM emulation software.  The software could downloaded from here: This document will interpret EEPROM emulation driver demo for KEA128 product and shows how the EEPROM emulation driver works and related API function introduction. 1> EEPROM emulation driver feature The EEPROM emulation driver for SGF/FTM flash family implements the fix-length data record scheme. Several sectors shall be involved in emulation with a round robin scheduling scheme. The EEPROM functionalities to be emulated include initializing, de-initializing, reading, writing records. The EEPROM emulation driver is more complicated than general Flash program data application with following features: User configurable emulated EEPROM size. Larger life for the flash memory used for EEPROM emulation. Unique feature of Cache Table which makes data retrieval fast. Support fix length record scheme only. Support synchronous model which can be run from both RAM and FLASH. When running from FLASH, user needs to relocate flash launch command routine to RAM to avoid Read While Write error. If any operation fails during EEPROM emulation, the driver will try to repeat that operation until successfully for several times (which is defined by user). If that operation still fails, the driver will make the related sector to DEAD to eliminate it from round robin sequence and continue other tasks without stopping driver. Concurrency support via callback. Release in C source code format. Ready-to-use demos illustrating the usage of the driver with different compilers. 2> Demo interpretation The demo routine located at default installation path: ..\\KEA EEPROM Emulation Driver\KEA_SGF180\Demos\build\TRK_KEAZ128\iar\Normal_demo folder. For the demo runs in Flash memory, avoiding Read While Write error happened, Eed_FlashLauchnCommand and g_EECallBack must be relocated to or placed in RAM when the main routine start. Then it will disable the cache and initialize Flash clock(KEA128 ICS module default clock mode is FEI, the default system/core clock is 21MHz, the Flash clock divider value set to 20 to make Flash clock to be 1MHz).   After flash clock initialized, it will initialize EEPROM configuration start address. The status of each sector with five value, which means Blanked, Alternative, Active, Dead and Invalid. The EE_ALLOTED_SECTORS macro will calculate the total number of sectors, which includes Active sectors and Alternative sectors. #define EE_ALLOTED_SECTORS              (EE_ACTIVE_SECTORS + EE_READY_SECTORS) The EE_ACTIVE_SECTORS value is 1 and EE_READY_SECTORS value is 2, so the EE_ALLOTED_SECTORS value is 3. Then there with three allotted sector, and allocated at below address:      eepromConfig.startSecAddr[0] = 0x1A00;      eepromConfig.startSecAddr[1] = 0x1C00;      eepromConfig.startSecAddr[2] = 0x1E00; After initialize start address for EEPROM configuration, following to call Eed_DeinitEeprom() function to erase all sectors used for emulation. Then it will initialize EEPROM emulation, includes to remove dead sector from EEPROM system and determine maximum valid index in array of start sector address after that; also includes initialize all sectors by erasing the “possible-error-sector”; and initialize and update cache table if enabled. It call Eed_InitAllSectors() function to initialize all sectors and allocate the current active sector to base sector. The Eed_ShiftIdxToBase() function will be called to shift the current index to base index of 0. After that, the EEPROM configuration startSecAddr array will change to :      eepromConfig.startSecAddr[0] = 0x1E00;      eepromConfig.startSecAddr[1] = 0x1A00;      eepromConfig.startSecAddr[2] = 0x1C00; The active sector start address at 0x1E00. Then it will program erase cycle value to each sector start address, the erase cycle value will occupy 4 bytes with sector start address offset 0: Then make the base sector to be active and program the active indicator at sector start address offset 8. Here the base sector start address is 0x1E00, the active indicator will be programmed at 0x1E08 with active indicator value 0x55555555: Then it will call Eed_SearchBlankSpace () function to find blank space of EEPROM system, in this demo, the blank space start address at 0x1e0c. If enable the Flash cache, the cache will be cleared and updated during EEPROM emulation initialize phase. The demo will write eight group data to EEPROM system, each group with 16 bytes data, total data number is 128 bytes. The data located at Flash start address is 0x1e0c. After each group data programming, it will following with the data ID info and program the status. With all data was written, the all 128 bytes data was programed at 0x1e00 start EEPROM sector. When the write data exceed the active EEPROM sector, the swapping will occur. The swapped EEPROM sector will record previous data and current write data. If there exist sector erase action, it will also update the erase cycle value. The data is full and the new data written will make swap happens: After swap happens: At the end of demo, it will read EEPROM data back and make sure all valid record ID are written to EEPROM emulation.
記事全体を表示
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  
記事全体を表示
在电机控制,Audio等很多应用中,我们经常会用到一些常见的正余弦,矩阵变换,FFT等一些DSP函数,提到DSP库,通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准,包括针对内核操作的CMSIS-CORE API,针对DSP应用的CMSIS-DSP Library,针对RTOS的CMSIS-RTOS API,与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中,又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能,CMSIS-DSP部分提供了超过60多种功能的DSP算法库,尤其是随着Cortex-M4中集成了FPU硬件单元,CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持,然而在CodeWarrior中没有直接支持CMSIS,需要用户移植到自己的CW工程中,所以就需要使用者了解CMSIS的结构,手动添加库文件和头文件,并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元,有些不支持,在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中,FPU浮点运算单元也是一个可选的部件,只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能,如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元,整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片,编译器也设置了相应的 FPU 功能开启/关闭的选项,在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能,在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能,而芯片未开启 FPU 单元,程序运行到浮点语句时就会出现异常。相反,如果编译器未使能 FPU 功能,芯片即使开启了 FPU单元,程序还是会按照未使能 FPU 的代码进行处理。在本例程中,为对比分析是否采用FPU的编译指令差别以及在板的执行效率,选用Kinetis K70FN1M为实验对象。 硬件平台:TWR-K70F120M核心板      软件环境:CodeWarrior v10.5        CMSIS版本 :V3.2 一. 准备工作: 下载CMSIS的库,当前最新的版本为V3.2,解压后名称为CMSIS-SP-00300-r3p2-00rel1,其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中,真正用到的文件包括CMSIS\Include中CM4相关的头文件,CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点),以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元,移植CMSIS的DSP库到CW的步骤;      Step 1:    新建一个Baremental的工程,选择器件器件MK70FN1M0(支持硬件FPU);     Step 2:    选择Floating Point浮点运算实现的类型,即指定编译器将C代码编译成汇编代码时使用的规则; 在Floating Point四个选项含义如下: Software选项:表示不使用FPU硬件,而是使用GCC的整数算术运算来模拟浮点运算; Handware(-mfloat –abi=hard) 选项:表示使用FPU硬件来进行浮点运算,函数的参数直接传递到FPU的寄存器(s0-d0)中; Handware(-mfloat –abi=softfp)选项:表示使用FPU硬件来进行浮点运算,但是函数的参数传递到整数寄存器(r0-r3)中,然后再传递到FPU中; Handware(-mfloat –abi=softfp –fshort -double)选项:其配置项同上,只不过使能了fshort  double功能,并且此处的double数据的宽度等同于float; 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章,在本例程中使用的是软浮点,所以选择Software项。需要注意的是:此配置选项仅出现支持FPU硬件单元的芯片工程中,如MK60FN1M0, MK60FX512等,否则默认没有此选项,默认为软件浮点。 Step 3:    点击“Next”进入下图,选择使用Processor Expert,点击“Finish“完成工程的建立; Step 4:    进入当前工程的文件夹,新建文件夹CMSIS,从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外,拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中; Step 5:    回到CodeWarrior主界面选择新建的工程文件,F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件,包括M0+/M3/M4的一些头文件;在Lib文件中是已经编译好的库文件,ARM文件夹是使用在KEIL IDE中的库文件,G++文件夹是使用在IAR中的库文件,而由于当前CW工程使用的GCC的编译器,所以GCC文件夹才是CW需要的,因此,为缩减工程大小可以删除ARM和G++文件夹;     Step 6:    打开工程属性框,选择Target Processor的Float ABI为No FPU; Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4; Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件,路径为:工程目录\CMSIS\Include; Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU,所以选择libarm_cortexM4l_math.a,此处需要特别注意,否则编译会报错; Step 10: 在ProcessorExpert.c文件中添加代码; #include <math.h> #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug,在  sinOutput = arm_sin_f32(radians);处设置断点,可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常,其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V,仅在 FPU 功能被使能时使用),完成一个正弦计算; 至此,完成了不使用K70的FPU浮点运算单元,移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元,移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元,移植CMSIS的DSP库到Codewarrior的方法有两种:一种是按照上面软浮点的方式Step By Step的建立工程,步骤和上面二的步骤基本一致,主要的两个区别在于:(1). Step 2要选择Handware(-mfloat –abi=hard) 选项,(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便,本教程采用第二种方案,完成在Codewarrior中调用CMSIS的DSP库,通过K70的FPU浮点运算单元执行浮点运算,即硬浮点。 Step 1:    打开工程属性对话框,选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard); Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义:_VFPV4; Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则,把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"; Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU,所以选择libarm_cortexM4lf_math.a,此处需要特别注意,否则编译会报错; Step 5:    完成以上配置后,编译工程并下载调试(此处建议编译之前先Clean一下整个工程),同样,在  sinOutput = arm_sin_f32(radians);处设置断点,可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常,其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V,仅在 FPU功能被使能时使用),并且在Register观察窗口中也多了个FPU寄存器列表,感兴趣的读者可以对比一下和前面实验汇编出代码的差异,此处不再赘述; 至此,分别完成了使用和不适用K70的FPU浮点运算单元情况下, CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数,在项目中直接调用即可。下一步, Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是,前文中讲到使用FPU单元需要两步设置:(1). 在编译器中开启相应的 FPU 功能选项;(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤,然而第二个步骤呢?仔细查看_arm_atart.c文件,可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程,如下图,是一个条件编译函数,这也就解释了为什么在上面Step 2中定义了_VFPV4,其本质也就是使能芯片的FPU单元,其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif
記事全体を表示
The 5V Kinetis E series MCUs are designed to maintain high robustness for complex electrical noise environments and high-reliability applications. Kinetis EA series MCUs using the same architecture with automotive level operation temperature range, are various used for auto body electrical application. There was a reality customer requirement to let KEA core running the application (light a LED) within 20ms from power up. It need to know the whole startup processing for KE/KEA product. Please check below picture to get more info about boot sequence: During the power up phase, after VDD rising to VPOR voltage threshold, there with about 15us delay before internal IRC start oscillating. T2 interval is FLL acquisition time to make FLL generating clock. The Reset_b pin is released and then the system is released from reset. After that, the NVM starts internal initialization. Flash Controller is released from reset and begins initialization operations while the core is still halted before the flash initialization completes. When the flash Initialization completes (16 μs) , the core sets up the stack, program counter (PC), and link register (LR). The processor reads the start SP (SP_main) from vector-table offset 0. The core reads the start PC from vector-table offset 4. LR is set to 0xFFFF_FFFF. The CPU begin to execute the first instruction. Overview the whole power up processing, FLL acquisition time is the longest time interval almost 1ms, then following power up time about 0.1ms (using 17KV/sec VDD ramp-up slew rate). There seems a lot of time left to run the chip initialization code and application code. Customer requirement (power up to light a led within 20ms) should be matched without any problem. While, during customer test, there seems it need to take more than 30ms to find the LED be lighten after power up. In order to check the issue, we get the customer test code and find there with below clock initialization code: void Clk_Init() {                 ICS_C1|=ICS_C1_IRCLKEN_MASK; /* Enable the internal reference clock*/                 ICS_C3= 0x90;                                    /* Reference clock frequency = 31.25 KHz*/                       while(!(ICS_S & ICS_S_LOCK_MASK));  /* Wait for FLL lock, now running at 40 MHz (1280 * 31.25Khz) */                                               ICS_C2|=ICS_C2_BDIV(1)  ;                    /*BDIV=2, Bus clock = 20 MHz*/                 ICS_S |= ICS_S_LOCK_MASK ;              /* Clear Loss of lock sticky bit */      } We do a test to check the Clk_init() function execution time and find it will take almost 25ms. We toggle a GPIO pin and almost 25ms for checking ICS status register [LOCK] be asserted. KE/KEA product using ICS module as clock source, which default mode is FEI. In general, during the chip initialization, using ICS status register [LOCK] bit to check if the FLL cock is stable or not. From KE/KEA product datasheet, the Max. FLL acquisition time is 2ms. Why the ICS_S[LOCK] bit be asserted need take more than 25ms? After double check with ICS IP owner, we get below info: The FLL_S[LOCK] bit act as “LOCK detection”, the LOCK bit will be set if FLL clock frequency stays within the tolerance 6% for 20ms~30ms. After acquisition time (max. 2ms) FLL achieved clock accuracy as same as LOCK bit be asserted. After ICS configuration modified, customer can call a 2ms delay routine to make sure FLL acquisition clock successfully before executing the application code. 
記事全体を表示