Kinetis微控制器知识库

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

Kinetis Microcontrollers Knowledge Base

讨论

排序依据:
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
查看全文
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.                
查看全文
     
查看全文
     
查看全文
  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   
查看全文
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
查看全文
Reference Solution being developed with Kinetis V (also can be done with a Kinetis K device) of a Class-D audio amplifier. 16-bit ADC sampling the audio input FlexTimer doing the PWM's for the Class-D amplifier DC/DC switched power supply with input of 12V and output of 130V to 180V (generates the power you need for making some good noise - 1kW) being controlled by the Kinetis MCU also. Capabiltiy of Audio processing/filtering using the Cortex-M4 DSP capabilities. Solution originally designed for cost-effective Automotive aftermarket sound systems. But can be adapted for implementing other audio amplifier applications also in the consumer space! Can you thing of cool applications/markets that this solution can be also quickly adapted? Soon, plan to make the reference solution design files available in the community. Stay tunned. Cheers! PK
查看全文
Hi All, all presentations were included in this archive file.
查看全文
1. Kinetis L系列外部IO中断分配问题(Tips about extern IO interrupt distribution of Kinetis L serious) 2. KL26通过UART的DMA方式发送数据包(Send data package through UART with DMA mode on KL26) 3. Freescale ARM Cortex-M系列软复位的使用方法 4.分享飞思卡尔KL25使用UART通信唤醒低功耗模式代码 5. 飞思卡尔KL系列低功耗特性和唤醒时间测试 6. BME学习心得(BME Study Notes) 7. 分享一个基于Kinetis KL25/KL26 USB读写U盘的例程 8. 如何实现Kinetis ADC自校准 9. Kinetis系列Flash烧写数据时写命令需要放到RAM中运行 10. Kinetis内部ADC转换速率探讨 11. KE02底层驱动库内部时钟Trim造成的UART通信不准的问题 12. Kinetis之教你将K60主频超到200MHz以上 13. 在Kinetis参考手册中快速找到芯片的Flash和SRAM地址空间分配 14. KL26 SD卡读写程序 15. KL03不能正常进入低功耗模式的原因及解决办法 16. 对Flash擦写数据时使用ESFC位以避免写冲突造成擦写失败(Using ESFC bit - Flash programming routines in Cotex M0+ kinetis MCU) 17. M0+单周期快速GPIO的使用方法 18. Kinetis 16-bit ADC+DMA+定时器实现AutoScan自动通道扫描采样 19. Kinetis将Flash保护打开造成程序下载失败的解决办法 20. 移植ARM CMSIS USB Stack的CDC类到飞思卡尔Kinetis KL25 21. I2C总线被挂起的原因和解决办法 22. 使用Kinetis系列中UART的IDLE Line功能识别帧结束 23. Kinetis K系列SPI接口设计注意事项 24. I2C从机地址左移一位的原因 25. Kinetis 使用eDMA完成串口接收功能 26. 移植ARM CMSIS USB Stack 的CDC类到飞思卡尔Kinetis KL26[Keil]​ 27. KE 驱动库中UART中断问题​ 28. KE驱动库中KE06 CAN Demo的遇到几个问题和说明​ 29. 深入剖析Kinetis系列内部IO结构​ 30. ARM Cortex-M4和Cortex-M0+中断优先级及嵌套抢占问题​
查看全文
Freescale's Jeff Bock highlights the awesome features of the Kinetis 32-bit microcontrollers based on the ARM Cortex-M4 core
查看全文
      In the practical KE KEA usage, a lot of customers meet the watchdog can’t reset problems. Some customers find when they want to enable the watchdog, but can’t really enable the watchdog by set the EN bit in register WDOG_CS1; Some customers find when in debug mode, the EN bit WDOG_S1 register always be clear, but from the reference manual, this bit should be set after reset, even they check their code, and make sure they didn’t disable the watchdog;  There also have some customers find when they use the KEXX_DRIVERS_V1.2.1_DEVD code, and set the timeout value register by themselves, but the watchdog can’t reset in the timeout value. Now according to these problems, this document will analyze it and give the recommendation to avoid these problems.      From the above problem description, we can get that there actually mainly 2 reasons caused these problems: 1, software configuration; 2, debugger usage 1.  Software configuration   1) Start code disable the watchdog In the KE KEA sample code, after reset, the chip will enter in the start code at first, the start code always disable the watchdog at first, if the watchdog is disabled, the watchdog can’t be enable just by set the EN bit in register WDOG_CS1, because bit EN in register WDOG_CS1 is the write-once bit after reset. It only can be modified when the UPDATE bit is set and with 128 bus clocks after performing the unlock write sequence. Now how to find the disable code in the start code? Take KEXX_DRIVERS_V1.2.1_DEVD sample code as an example IAR: from crt0.s, will find the watchdog disable code WDOG_DisableWDOGEnableUpdate();  in the start function. The above IAR start picture is for KE, but in the KEA start file, you can’t see the start function in the KEA sample code which download from the freescale web, just find the __iar_program_start in cstartup_M_KEA128.s after the reset happens, but where is the __iar_program_start function, it can’t be searched in the whole project. Actually __iar_program_start is the default program entry function, it include the following function: You can find it will enter __low_level_init function, the watchdog disable code is just in  __low_level_init function. MDK:  From startup_MK0XZ4.s will find the watchdog disable code in the SystemInit function. Codewarrior: From __arm_start.c file, will find the watchdog disable code in __init_hardware function. 2) Codewarrior script init_kinetis.tcl disable the watchdog      To the Codewarrior, just comment the disable watchdog code in the __arm_start.c file is not enough to check the watchdog enable after reset, because in the codewarrior connect script init_kinetis.tcl, there also have the watchdog disable code.      If you want to find the state of EN bit in register WDOG_S1 after reset, you must disable all these watchdog disable code.   3) Timeout register configuration incorrect From the header file MKE02Z2.h, we can find the time out register define like this:   union {                                          /* offset: 0x4 */     __IO uint16_t TOVAL;                             /**< WDOG_TOVAL register., offset: 0x4 */     struct {                                         /* offset: 0x4 */       __IO uint8_t TOVALH;                             /**< Watchdog Timeout Value Register: High, offset: 0x4 */       __IO uint8_t TOVALL;                             /**< Watchdog Timeout Value Register: Low, offset: 0x5 */     } TOVAL8B; This structure means that customer can define the watchdog timeout value by separated unit8 TOVALH, TOVALL or just defined it with unint16 TOVAL. But actually in the IAR project usage, take an example, use 1khz as the clock source for watchdog, then want to set the timeout value as 1s, it means the timeout value should be 1000=0x03e8, so one of the customers configure it like this:    You can find, we need the TOVALL= 0XE8, TOVALH=0X03, but from the test result, the register is TOVALL= 0X03, TOVALH=0Xe8, this will cause the timeout value is much larger than 1000, that is why customer can’t reset the mcu after 1s, because the register configuration is not correct. It is caused by the IAR int16 store endian mode, the default IAR endian mode is little endian mode. So in the practical usage, it is recommended to use the separated time out value definition. 2. debugger usage When in debug mode with IDE, some customers find even they comment all the watchdog disable code, they still can’t reset the MCU by the watchdog. After check the register WDOG_S1, bit EN is 0, it means the watchdog is disabled. But from the reference manual, we get that after reset, the EN bit should be 1. What caused this? After test, we find this actually caused by the debugger, the debugger hardware which you are using. Eg, in the same project which already comment all the watchdog disable code, SEGGER JLINK will still disable the watchdog, but the PE opensda or PE multilink won’t do this, the EN bit is enabled by default, the following is the test picture, take codewarrior as an example: 1) JLINK 2) PE Opensda or PE multilink    So, if you want to test the watchdog in debug mode, and want the EN is set after reset, you can choose PE debugger tool instead of JLINK, but this JLINK feature is just influence the debug mode, after you download the code to the chip flash, and after reset, the EN bit in WDOG_S1 will still be set. Wish this document will help you get out the problem of watchdog can’t be reset.
查看全文
This is a copy of the currently posted KL26 reference manual to be used to enter community comments.  Please feel free to add inline comments in this reference manual. You can point out where more information is needed or where existing information is incorrect.  You can also enter information in your comment that expands on existing information in the document, based on your experience with the device.  If you are pointing out that more information is needed in a paragraph or a section, please be very specific, not “needs more information”.  Your comments in this manual may help other members and will drive improvements in this and future documentation. Note: The doc viewer does not support going directly to a specified page.  Instead of manually paging through one page at a time, you can do a search on a string on a page such as "types of resets", or you can go to chapter links listed in the inline comments.  To do this, page down to the comments below the doc view, select "Inline Comments", sort the comments by "page", and then select the chapter you want to view.
查看全文
The DOC focuses on how to access SDRAM based on K65 SDRAM controller, it describes the hardware connection especially the address connection, the SDRAM controller initialization,the code to access SDRAM.
查看全文
Hi: Kinetis's ADC have no multi channels sequence sampling function, compared with LPC's ADC. But we could use DMA for such case, attached are two demos: 1.multi_channels_edma_ADC_DMA_SW_TRIG Description: use SW trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; 2.multi_channels_edma_ADC_DMA_LPIT_HW_TRIG Description: use LPIT timely trigger DMA transfer for 6 ADC channels, DMA ch0 is for ADC channels transfer, DMA ch1 is for ADC sample result transfer in DMA ch1 ISR, report ADC sample are done; but LPIT could trigger continuously without SW engage.
查看全文
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
查看全文
DFU_PC_demo_source_code.zip
查看全文