Kinetis微控制器知识库

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

Kinetis Microcontrollers Knowledge Base

讨论

排序依据:
I’m using the NXP FRDM-K64F board in several projects.One issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues. The EzPort is a special serial interface present on some Kinetis, ColdFire+ and ColdFire V2 devices. The issue is that if the EzPort chip select (EZP_CS) is LOW during reset of the microcontroller, it enters the special EzPort mode. The problem is that a pull-up on the EZP_CS line might not pulled up fast enough due capacitance on the line. The commance is if something is not used, disable it! So the solution is to disable the EzPort functionality. That setting is part of the FOPT (flash option register).
查看全文
Introduction This document provides guidance to program or store code in FlexNVM memory available in KW36 MCU to use it as P-Flash memory. This article uses as the starting point, an example imported from the connectivity software stack. Software Requirements 1. FRDM-KW36 SDK 2.2.0.   2. MCUXpresso IDE. Hardware Requirements 1. FRDM-KW36 board. Programming KW36 FlexNVM Example The objective is to explain how to place a linker input section, variable or function into the FlexNVM memory. Before starting, the developer must know that the GNU linker cannot automatically place code or data across two separate memory regions, so the developer must analyze and manually choose what sections will be placed at which memory (P-Flash or FlexNVM) to get the most efficient way to use the total memory size. This example will use the "bare-metal" version of the heart rate sensor project (included in the SDK), however, the same steps apply for the "freertos" version. 1. Select "Import SDK example(s)..." option in the "Quickstart Panel" window. Next, choose the FRDM-KW36 board. Click the "Next" button. 2. Expand "wireless_examples/bluetooth/hrs" folders and select bm project with the checkbox beside. Click the "Finish" button. 3. Replace the "MKW36Z512xxx4_connectivity.ld" file by "MKW36_connectivity_dflash_use.ld" (attached to this document) into the source folder in the workspace. 4. Open the "Project/Properties" window and select "C/C++Build/Settings". Next, go to the "MCU Linker/Managed Linker Script" perspective and edit the linker script name to "MKW36_connectivity_dflash_use.ld". Click "Apply and Close" button.   Placing input sections in FlexNVM memory It is possible to program specific input sections in the FlexNVM memory following the next steps: 1. Open the "MKW36_connectivity_dflash_use.ld" linker file. 2. Search for output sections. In this example, we will edit the "text" section to save it in the FlexNVM array. Replace the "m_text" memory by "FLEX_NVM" memory as in the following picture.  3. Debug the project using the CMSIS-DAP debugger. 4. Open the memory perspective. Add a new memory monitor with the "green plus icon" in the 0x1000_0000 address. Verify the expected results.      Placing variables and functions in FlexNVM memory Also, it is possible to place a specific function or variable in the Flex NVM using attributes as follows: 1. Open the "MKW36_connectivity_dflash_use.ld" linker file. 2. Search for output sections. In this example, we will create a new section placed at Flex NVM address range. The name of this output section is "text_Flash2". Edit the linker file as shown below.   3. Create your functions and variables using the following section attribute (in this example we will open and place the text below in the "fsl_os_abstraction_bm.c" file under framework/OSAbstraction/Source folder in the workspace): __attribute__ ((section(".d_flash_array"))) const uint32_t const_data_table[10] = {0,1,2,3,4,5,6,7,8,9}; __attribute__ ((section(".text.$FLEX_NVM"))) void delay (void) {        volatile uint32_t i = 0;        for (i = 0; i < 800000; i++)        {               __asm("NOP");        }        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Use your own variables and functions in the code (this step is only for testing purpose, this is important to prevent any optimizations performed by the compiler). In this example, we will use the delay function and the const array in the main function located at "fsl_os_abstraction_bm.c" file. uint32_t Use_Array; uint32_t index;     for (index = 0; index < 10; index++) {        delay();        Use_Array = const_data_table[10]; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 5. Debug the project using the CMSIS-DAP debugger. 6. Open the memory perspective. Add a new memory monitor with the "green plus icon" in the 0x1000_0000 address. Verify the expected results.
查看全文
En México, el 5.1% de la población vive con algún tipo de discapacidad, de los cuales 23% poseen discapacidades del tipo motriz en extremidades inferiores y superiores (INEGI, 2011). Los métodos que actualmente se utilizan en el proceso de rehabilitación no poseen características integrales en las que el usuario pueda aprovechar la terapia para ejecutar diferentes acciones. El objetivo de este proyecto es el de diseñar y construir una herramienta que permita al usuario no solo hacer ejercicios de rehabilitación, sino que también le ayude a realizar tareas cognitivas o a interactuar con algún medio electrónico (i. e. navegar por internet, realizar trabajos a través de una computadora con Rehab Glove como mouse y/o teclado). Rehab Glove es una herramienta en forma de guante que posee sensores de flexión en las articulaciones de los dedos y de fuerza en las yemas, ubicados estratégicamente con el fin de obtener diferentes valores arrojados mientras el usuario realiza ejercicios de rehabilitación como cerrar el puño o tocar las yemas de los dedos con el pulgar. Estos valores serán convertidos en instrucciones diversas que van desde mover un  carro a control remoto, pasando por el control de videojuegos educativos, hasta llegar a tareas más complejas como escribir o controlar el cursor de una computadora sin la necesidad de un mouse o un teclado. La terapia comenzará con el usuario portando RehabGlove frente al elemento que desea controlar, pidiéndole que realice movimientos específicos con la mano para que pueda lograr el objetivo final. Se espera que el nivel de complejidad vaya aumentando en cuanto al tipo de movimientos, rapidez, precisión y fuerza aplicada en cada acción. Con el uso de RehabGlove se espera que las terapias de rehabilitación posean niveles de cognición mayores y que tengan un avance progresivo aumentando el nivel de complejidad en cada ejercicio.   Video de prototipo<<<<< Rehab Glove Kinetis - YouTube Original Attachment has been moved to: Codigo-Fuente-Rehab-Glove.txt.zip
查看全文
Agenda Mastering Kinetis-M Microcontrollers Schedule Module Description Duration Presenter 8:00 Registration 0:30 8:30 Introduction & Welcome 0:15 MM 8:45 MKM34Z256 core and peripherals architecture 1:00 Cano 9:45 DSP fractional, Filter, and FFT-based libraries for general signal processing and metering applications 1:00 LV 10:45 Break 0:15 11:00 Power meter & PLC reference design overview (1ph, 2ph (MKM34Z128), 3ph, 3ph shunt based + sensor node) 1:00 RK 12:00 Introduction to TWR-MKM34Z75, bare-metal drivers, SDK 2.0, FreeRTOS and FreeMaster 1:00 Cano+ID 13:00 Launch in the office 1:00 14:00 Workshop - TWR LCD example (preprogrammed, debugging, SW re-flashing) 0:45 Cano 14:45 Workshop - Using serial bootloader example (learn the way of bootloder integration into application) 0:45 PK 15:30 Workshop - LPTMR and GPIO example (LPTIM & GPIO API, programming interrupt, debugging) 0:45 MM 16:15 Break 0:15 16:30 Workshop - FreeRTOS preemptive multitasking example (basics of FreeRTOS programming) 0:30 MM 17:00 Workshop - High-precision waveform measurement example (SD ADC & FreeMaster programming) 0:45 MM 17:45 Workshop - 64-bit math coprocessor example (mastering DSP instruction set the MMAU) 0:45 MM 18:30 Q&A 0:30 19:00 Dinner @ Brasserie restaurant 2:00 21:00
查看全文
Recently I did a porting based on AN4370SW for a customer to support TWR-K20D72M, and with some modification in source code, header file and link file as well, it works well as expected. The following simple describes what I have done: 1.Copy the project file folder for K20D50M "AN4370SW\Source\Device\app\dfu_bootloader\iar_ew\kinetis_k20" and rename is as "kinetis_k20d70m" 2.Change the target settings as well as the flash loader. 3. Replace the header file for K20D50M and include it in derivative.h. The header file for K20D72M can be found from KINETIS_72MHz_SRC(http://cache.freescale.com/files/32bit/software/KINETIS_72MHz_SRC.zip?fpsp=1&WT_TYPE=Lab%20and%20Test%20Software&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&sr=9) 4.Modify the interrupt table in cstartup_M.s, which is more likely a K60's vertor table. 5.Search the code related with the macro "MCU_MK20D5", and add similar code snippet for K20D72M , You may easily find them by search the keyword "MCU_MK20D7". That code parts include initialization for MCG, and PIT0 and USB interrupt enablements, some definition in bootloader.h . 6. Copy the link file from K20D50M, and modify the PFLASH size,SRAM size and DFLASH size as shown below: Perform MassErase before programming . and then you may press the SW1 on TWR-K20D72M to select which mode to enter after download the application firmware: pressing SW1 to enter bootloader mode and releasing it to enter application mode. 7. Build image for this DFU bootloader. Actually the bareboard projects in KINETIS_72MHz_SRC can be used for that purpose, and only link file needs some modification to put the image starting from 0xA000, since exception table redirection has already been done in these projects. after that, user needs change some settings in the CW projects to use the new link file: and generate S19 file as the output as well as the map file: after compiling , you will have a xxx.afx.s19 file, but that is not the final format, we still need to transform it to bin format, and it can be done by a small tool in "C:\Program Files\Freescale\CW MCU v10.3\MCU\prog" There are some settings for this tool to transform the S19 file, by clicking Burner->Burner Dialog, you will see some option views, please set them as below: Referring to the above figure, maybe you would wonder how to set up the Origin and Length field, actually Origin is the value where the image starts from just as the link file specified , and Length is calculated by the results from the map file. Please refer to the following figure for details. 0x3550 = 0x1c90 + 0x18c0. I also attached the burner's configuration file and image link file as well as the image for reference. Please copy the link file in "KINETIS_72MHz_SRC\build\cw\linker_files". Please kindly refer to the attachment for more details. Hope that helps, B.R Kan
查看全文
The installation file containing MKM34Z256 training examples programmed using Kinetis-M bare metal drivers and compiled using IAR EWARM 7.40.1. These examples explain programming steps for GPIO, Low Power Timer, Sigma Delta ADC, Memory Math Arithmetic Unit, and LCD on-chip peripherals. In addition, you will learn how to create simple FreeRTOS and 1-phase power meter applications. All examples including their handouts will be installed on your PC in c:\Freescale\KM34Z75_EXAMPLES subfolder. For more information about each example, please refer to its handout.
查看全文
1. Overview BLE beacon is a common use of low power Bluetooth and it broadcasts advertisement at some interval. Freescale BLE beacon demo use Freescale Kinetis KL16 low power MCU and EMC EM9301 Bluetooth controller to implement a beacon reference design. Freescale BLE beacon features low power consumption of an average cost of 50uA with 600ms interval. Freescale Kinetis KL16 coordinates with EM9301 through SPI interface. View attachment to learn more
查看全文
Archive file of the Kinetis-M bare-metal drivers and software examples REV 4.1.5 - this version is not yet available @ nxp.com. Release notes 4.1.5 (Apr.22,2016): Added configuration structures for watchdog timer operating in debug mode. Included IAR EWARM 7.60.1 project templates. Modified LLWU Pin Falling Edge Wakeup example. Please refer to How to download and install KM Bare-metal divers
查看全文
Dear all :      I would like to share an IoT application note to you. The note will help us to setup a FRDM-K64F to connect to Microsoft Azure and get alarm message from Azure. Detail please refer to attachment. Demonstration : IoT client (FRDM-K64F) report data to Cloud (Microsoft Azure) IoT client receive data from Cloud Could computing IoT client data and take action Tools : FRDM-K64F ( http://www.freescale.com/FRDM-K64F ) Device Explorer ( http://aka.ms/iot-hub-how-to-use-device-explorer ) Visual Studio 2015 SSH client ( PuTTY  or Tera Term ) mbed  ( http://www.mbed.com ) Microsoft Azure ( https://azure.microsoft.com )
查看全文
Here you will find both the code and project files for the ADC project. This project configures the ADC to perform single conversions, by default this is performed using a 16 bit configuration. The code uses ADC0, channel 12, once the conversion is finished it is displayed at the serial terminal. Code: #include "mbed.h" AnalogIn AnIn(A0); DigitalOut led(LED1); Serial pc(USBTX,USBRX); float x; int main() {     pc.printf(" ADC demo code\r\n");     while (1)     {     x=AnIn.read();     pc.printf("ADC0_Ch12=(%d)\r\n", x);     wait(.2);     } }
查看全文
The ARM Cortex-M4 Kinetis K50 MCU integrates an analog measurement engine consisting of integrated operational and transimpedance amplifiers and high-resolution ADC and DAC modules that make it ideal for portable healthcare and medical applications. For more information visit www.freescale.com/kinetis
查看全文
Introduction The K32L3A60VPJ1AT MCU is a next generation Kinetis dual core device.  This device brings processing and multi-tasking capabilities that legacy Kinetis devices did not support.  In addition, the K32L3A60VPJ1AT offers improved power consumption and security features.   Some important aspects of these security features lie in a nonvolatile information register (IFR) memory region and how this region is programmed.  The IFR memory region is a memory space with restricted access separate from the main array and is comprised of an erasable IFR region and a non-erasable IFR region.  The non-erasable IFR region contains the program once identifier and the version identifier.  The erasable IFR region holds the flash security, flash options, mass erase enable, and other such features that governs how the device behaves.  In legacy Kinetis devices, certain fields of the main flash array (flash addresses 0x400 - 0x40F) configured the IFR at boot time.  In the K32L3A60VPJ1AT however, the IFR memory region is no longer controlled in this manner.  This presents challenges when trying to configure these settings.  The purpose of this document is to explain how these settings can be changed and provide some options of how to make these changes.   IFR Field Programming Process The first step in configuring the IFR fields is understanding how the these fields are programmed via the hardware. IFR fields are programmed using a special flash command called the Program Index Command. Once programmed, the flash configuration values cannot be reprogrammed without first erasing these fields.  The only way to erase these values is via a mass erase.  This provides security in that the IFR values cannot be changed without erasing the user code as well.  In addition, changes to the user code image cannot affect the bootloader operation, ensuring that a secure boot function can be executed.  The procedure for writing the erasable IFR values is described here:   Write FCCOB0 with the Program Index command (0x43). Write FCCOB1 with the Index to be programmed. The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 and FCCOB3 with 0x00 as they are not used with this command.  Write FCCOB4 - FCCOBB with the desired value.  (Note that not all of the indexes use all of the FCCOB fields.  Be sure to consult the Erasable IFR Map table for which FCCOB fields are used for the index you are programming). NOTE:  For 2 byte IFR fields that map to 2 bit wide register bit fields (i.e., SEC0, FSLACC, MEEN, and KEYEN fields which map to the FSEC register bit fields), the lower FCCOB register maps to the LSB of the bit field and the upper FCCOB register maps to the MSB of the bit field.  For example, to write 0b'10 to the FSEC field, FCCOB6 should be written to 0xFF and FCCOB7 should be written to 0x00 before executing the Flash command.  Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. (Note that this command MUST be a byte write.) Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the typical Program Index command completion time of 110us.)   After the IFR has been programmed, the IFR should be read back to verify that it completed correctly.  The process for this is as follows:   Write FCCOB0 with the Read Index command (0x41). Write FCCOB1 with the Index to be read.  The possible Indexes are listed in Erasable IFR Map table (table 16.4.1.2 in the K32L3A6 reference manual). Write FCCOB2 - FCCOBB with 0. The results will be stored in FCCOB4 - FCCOBB so, these should be cleared to ensure correct results are received. Write 0x70 to the Flash status register (FSTAT) to clear any errors that might have been present from the last flash command. Note that this command MUST be a byte write. Write 0x80 to the Flash status register (FSTAT) to initiate the programmed flash command. Poll the FSTAT register until the CCIF bit field (bit field 7) is one ('1').  (Note that it may not be possible in your scripting language to do this, or it may just be easier to simply wait for the flash command to finish executing. In these cases, wait significantly longer than the maximum Read Index command completion time of 35us.)   When using the Program Index Command, you must know which index you want to modify to create the correct flash commands.  The index list can be found in the IFR descriptions section of the Flash chapter in the K32L3A60VPJ1AT reference manual.     There are several different options for programming the FOPT fields. These options are: Using the Kinetis Flash Tool  Using blhost Debugger script Subroutine in user software   Option #1: Kinetis Flash Tool Using the Kinetis Flash Tool is likely the most convenient method to change the IFR values.  The Kinetis Flash Tool uses either the UART or USB protocol to interface with the K32L3A6 bootloader and write the IFR fields desired. One of the biggest advantages for the Kinetis Flash Tool is that it provides a graphical interface for users to easily program the IFR fields. The following figure is a picture of the Kinetis Flash Tool and highlights the important input controls and tabs to be used when programming the IFR fields:     This field is the Port set box.  It selects the interface (UART or USB) to be used when communicating to the bootloader.  This box also allows for configuration of the interface.  Consult the K32L3A6 reference manual for default configurations.   This is the Flash Utilities tab.  Select this tab to see the controls shown in this image.  This is the Index input field.  The Index of the IFR to program should be entered here.  This is the Hex digits field.  This value will be programmed at the IFR Index indicated in the Index field. The value here should be in hex format WITHOUT the preceding "0x".  Note that this will write to the FCCOBs in descending order.  For example, to write 0b'10 to the KEYEN field, FFFFFF00 should be written to the Hex digits field. Refer to the programming process outlined in the IFR Field Programming Process in this document for more information.    This is the Byte Count field.  This tells the utility how many bytes to program and must be the byte count of that IFR field.  Consult the Erasable IFR Map table in the reference manual for the value of the specific IFR index to be programmed.   This is the Program button.  After all of the fields have been filled out, click this button to program the desired IFR location.    Option #2: BLHOST The MCUBoot package also includes a command line executable to interface with the bootloader.  This tool, blhost, can be used to program the IFR fields as well.  The "flash-program-once" command should be used to program the desired IFR location.  The syntax of this command is as follows:   flash-program-once <index> <byteCount> <data>   So for example, if you want to program the FOPT IFR field (record index 0x84) with 0xFFFFF3FF, the correct syntax using this command would be   flash-program-once 0x84 4 FFFFF3FF   After programming, the "flash-read-once" command can be used to read back and verify the programmed IFR field(s).  Below is an example using the previous IFR locations   flash-read-once 0x84 4   Below is a full example of erasing the device, programming the FOPT IFR, and reading the FOPT IFR back from the command line using blhost.     When Programming two byte fields, blhost orders the bytes in descending FCCOBx order (just like the Kinetis Flash Tool).  The blhost utility also requires the input to be 4 or 8 byte aligned, but the flash-program-once command only uses the last 2 bytes.  The upper 4 bytes can be padded with 0's or F's. For example, to write the KEYEN field such that the KEYEN bit field is 0b'10, the command would be as follows: flash-program-once 0x83 4 FFFFFF00 Below is a full example of using the blhost command line to erase the device, program the KEYEN IFR, read the KEYEN IFR back, and evaluate the FSEC bit field using the Attach to Running Target function in a debugger.     After executing a pin reset and attaching to the running target:     Option #3: Debugger Script A simple debugger script is another convenient way to write the IFR values.  Debugger scripts are executed in the background of the debug session initiation process (therefore are hidden operations from the user) and typically can be edited easily using any text editor.  However, it can be cumbersome to change the value because this generally must done manually with each programming by the user. With that in mind, it is a good idea to have different connect scripts for different configurations   The first step in using a debugger script is writing a debugger script.  The capabilities and syntax of a debugger script are dependent on your toolchain. For the purposes of this document, we will focus on MCUXpresso IDE.  MCUXpresso IDE uses the PokeXX and PeekXX (where XX is 8, 16, or 32 depending on whether you want to byte access, half-word or word access to the desired register) commands, which are debugger agnostic. So the same commands that work on a device will continue to work whether you are debugging with a JLink or CMSIS-DAP, or whatever other debugger you are using. Below is an example of a MCUXpresso connect script which writes the FOPT register and then reads it back for printing to the debug log.    5140 REM ====================Program FOPT=================================== 5150 Poke32 this 0x40023004 0x43840000 5160 REM Stuff FCCOB registers with desired FOPT value 5170 Poke32 this 0x40023008 v% 5171 s% = Peek32 this 0x40023008 5172 Print "New Val ";~s% 5180 Poke32 this 0x4002300c 0x00000000 5180 Poke8 this 0x40023000 0x70 5190 Poke8 this 0x40023000 0x80 5200 wait 1000 6000 REM ================== Read FOPT ===================================== 6001 REM Now read the FOPT back 6010 Poke32 this 0x40023004 0x41840000 6020 Poke32 this 0x40023008 0x00000000 6030 Poke32 this 0x4002300c 0x00000000 6040 Poke8 this 0x40023000 0x70 6050 Poke8 this 0x40023000 0x80 6060 wait 1000 6070 s% = Peek32 this 0x40023008 6080 Print "New FOPT Val ";~s%   Note in the above script that v% is the desired FOPT value and it has been defined in sections of the script not shown (at line 164).    162 REM This is the value to be written to the FOPT 164 v% = 0xfffff3ff   After the script is written, MCUXpresso must be told to use the connect script.  This is done in the Debug Configurations window.  Assuming a debug configuration has already been created, click on the arrow next to the green bug icon and select Debug Configurations.       In the resulting dialog box, select the debug configuration you want to use, and select the Linkserver Debug tab.  In the Connect Script field, point MCUXpresso to the location of your connect script.       That's all that needs to be done in the IDE. The selected debug configuration should now be using the script which was written.     Some debuggers will allow standalone command line running of a script, such as a JLink debugger.  As the JLink is one of the more popular external debuggers that we encounter, an example of programming using this script has been provided below.     // Now Program the FOPT w4 0x40023004, 0x43840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0xfffff3ff // Write 0xFFFF_1FFF to boot the M4 from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Now Read the FOPT back w4 0x40023004, 0x41840000 // The 43 selects the Program Index command. The 84 selects the FOPT IFR field. // Stuff the FCCOB registers (4-7) with the FOPT value we want to write. // ** (Boot Settings) ** w4 0x40023008, 0x00000000 // Write 0xFFFF_F1FF to boot the M0+ from internal Flash. Asserting the NMI pin will force booting from the ROM. // Write FCCOB registers 8-B with dummy values. w4 0x4002300c, 0x00000000 // Write the FSTAT register to clear any errors that could have been present. w1 0x40023000, 0x70 // Launch the flash command. w1 0x40023000, 0x80 // Wait for the flash command to finish. Sleep 1 // Read the memory back to verify the FOPT settings that should be present after reset. mem32 40023000,4     Option #4: Subroutine in User Software Occasionally the requirements of your system will prevent implementation of any of the above methods to program the IFR values.  In these cases, you may need to implement your own subroutine to program the IFR.  The procedure to do this is essentially the same as in the debugger script methods, just written in code instead of an external script.  The flash drivers provided in the SDK aid in this process.  One key to remember is that you likely will need to erase the entire flash.  So this subroutine and flash drivers should be placed in RAM memory.  The SDK flash drivers also operate a little differently from the Kinetis flash tool and blhost.  The FCCOB registers will be loaded in ascending order.  For example, to write 0b'10 to the SEC0 bit field in the FSEC register, the command would be: result = FLASH_ProgramOnce(&s_flashDriver, 0x80, ifr2write, 0x2); where ifr2write is an array defined as uint8_t ifr2write[2] = {0x00, 0xFF}; The above will result in 0x00 being loaded to FCCOB6 and 0xFF being loaded to FCCOB7 and SEC0 will then be 0b'10 on the reset after the command is successfully executed.   Conclusion In summary, the IFR registers are nonvolatile information registers that govern certain behaviors of the K32L3A MCU.  The IFR is dividing into an erasable IFR space and non-erasable IFR space, both of which are not a part of the main flash array.  Programming these values requires the use of special flash commands and requires that these values haven't been previously written since the last mass erase.  There are, in general, four different methods of programming the FOPT register settings.  The four methods are:   Kinetis Flash Tool BLhost command line interface Debugger script  User software subroutine   Each method has its advantages, therefore, you should pick the one that meets your needs and is most convenient. However with any of the methods chosen, the IFR values must not have been programmed before writing erasable IFR fields. It is best to perform a mass erase (which can be done using any of the methods presented in this document) before attempting to program any IFR fields.     
查看全文
Encrypted QuadSPI image Implementation       The Kinetis family of MCU includes the system security and flash protection features that can be used to protect code and data from unauthorized access or modification. This application note discusses the usage of encrypted boot with the KBOOT and experiment with the FRDM-K82 board. FRDM-K82 board
查看全文
作者 Shaozhong Liang         MQX4.0支持长文件名(Long FileName),但不支持中文长文件名。在MQX创建长文件名的文件时,只是简单地将文件名对应的字符串由转换为UNICODE编码。         如果使用的是拉丁字母,其编码将会被补全为2个字节,前面一个字节为0x00,例如字符“A”的编码是0x0041,是0x00接上字符对应的ASCII码。这个编码方式在英文字符串上编解码不成问题。         但是中文的表示方式是以GB2312编码方式,用2个字节来表示一个中文字。         例如中文字“啊”,对应的GB2312码为0xB0A1,MQX会将这2个字节拆分为0xB0和0xA1,然后分别进行UNICODE编码,这时候“啊”的编码将是0x00B0,0x00A1,变成4个字节的UNICODE编码。         最终将导致错误乱码,“啊”因此会被译码显示成  °  和  ¡         而实际上“啊”在UNICODE编码为0x554A,为了MQX能够支持中文长文件名,此时我们需要对GB2312和UNICODE进行转换。         我们需要对MFS源代码进行修改。现在修改后的代码只支持创建文件,暂时不支持修改已经存在的中文长文件名文件。         将附件中的文件替换原有的文件,重新编译MFS库和应用程序即可。         按照这种方法修改后,对中文字对应的GB2312编码范围进行UNICODE的转换,处理后文件名将支持中文,同时也可以实现中英文文件名的混用。 mfs\source\generic\mfs_entry.c 修改了函数MFS_create_directory_entry mfs\source\generic\mfs_lfn.c 增加了长文件名保存函数MFS_lfn_save 增加了oem字符集到unicode字符集的转换函数MFS_oem2unicode,用户层的代码直接使用中文文件名,有转换函数转换为对应的UNICODE编码。 由于GB2312全集占用空间太大,用户可以将gb2unicode.c的字符集表oem2unicode_table中数据进行精简。 mfs\source\include\mfs_prv.h 增加了上述函数声明。 Original Attachment has been moved to: lfn_mfs.rar
查看全文
The following file contains codewarrior code that was migrated from the IAR example code in the sample code package at the freescale webpage. It contains the following examples: adc_demo freedom_greem_led freedom_red_led lcd_rtc_lowpower PIT_basic sLCD_freedom uart_low_power_wu_dut Regards
查看全文
主板原理图。
查看全文
Hi team :      I would like to share an experience to you . Any comments would be welcome .      The RTC 32.7668KHz clock can only be sourced from an external crystal that is challenged of some space restricted case . The internal reference clock will be required to support RTC at this moment . Of cause , the IRC accuracy maybe not compete with external crystal , but in this case space is the major concern . However , Kinetis RTC not support clock sourced from IRC . We make a workaround to enable RTC reference to IRC . The detail please refer to attachment . The sample code is build with KDS V3.0 for FRDM-K64F . Best regards, David
查看全文
update of the FreeMASTER component
查看全文
    以DMA方式通过UART发送数据应该是工程应用中很常用的一种方式了,尤其是在需要频繁发送数据或者数据包长度较大的场合,如果使用传统的UART查询或者中断方式发送和接收数据,对CPU资源的占用将是极大的浪费,带操作系统的应用还好些,如果是纯粹的前后台程序有时不能容忍的,所以DMA方式是很恰当的选择。而本篇以Kinetis L系列为例介绍一下以DMA方式通过UART端口发送长数据包,当然不同于K系列复杂强大的eDMA功能,L系列的DMA模块配置起来还是比较简单的。 测试平台:IAR6.7 + KL26 FRDM 测试代码:FRDM-KL26Z_SC\FRDM-KL26Z_SC_Rev_1.0\klxx-sc-baremetal\build\iar\uart0_dma        其实KL26的官方sample code中是自带uart0_dma例程的,但是实现的功能只是将UART口接收到的每一个字节的数据通过DMA方式再发送出去(即环形缓冲),这样用来作为一个功能演示的demo是可以,但是往往我们需要的是将某缓冲区的数据以DMA方式发送出去或者将接收到的数据以DMA方式写到某缓冲区这样的功能,为此我们就需要在原有的例程上进行修改从而达到我们的应用目的,这里给出几点需要修改的地方,并做了相关注释(整个工程见最后附件): 1)定义待发送缓冲区: /* array to be sended */ uint8 testdata[]={"\nFreescale Kinetis KL26\n"}; 2)设置DMA源地址: #define DMA0_DESTINATION  0x4006A007    /* the memory adress of UART0_D register */ #define DMA0_SOURCE_ADDR  (uint32)testdata    /* define the source data array address */ 3) 在DMA0_init()函数中修改发送数据包的长度: DMA_SAR0 = DMA0_SOURCE_ADDR;    //Set source address to UART0_D REG DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));    //Set BCR to know how many bytes to transfer DMA_DCR0 &= ~(DMA_DCR_SSIZE_MASK | DMA_DCR_DSIZE_MASK);    //Clear source size and destination size fields 4)添加源地址自动加1功能,因为之前的环形缓冲方式只是单字节数据,所以不需要源地址递增,但是由于我们这次需要发送整个数据包,所以这里我们就需要将源地址递增功能打开,而具体递增1,2还是4则取决于发送数据的最小单位(8bit,16bit or 32bit): /* Set DMA as follows: Source size is 8-bit size Destination size is 8-bit size Cycle steal mode External requests are enabled source address increments 1 automatically */ DMA_DCR0 |= (DMA_DCR_SSIZE(1) | DMA_DCR_DSIZE(1) | DMA_DCR_CS_MASK | DMA_DCR_ERQ_MASK | DMA_DCR_EINT_MASK | DMA_DCR_SINC_MASK); 5)配置DMAMUX通道为UART0 TX即发送通道(通道号为3),因为我们需要的是UART0_TX触发DMA传送: DMA_DAR0 = DMA0_DESTINATION;    //Set source address to UART0_D REG DMAMUX0_CHCFG0 = DMAMUX_CHCFG_SOURCE(3);    //Select UART0 TX as channel source DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;    //Enable the DMA MUX channel 6)在UART0_DMA_init()函数中修改UART0发送缓冲区为空时即触发DMA发送: void UART0_DMA_init(void) { UART0_C2 &= ~(UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Disable UART0 UART0_C5 |= UART0_C5_TDMAE_MASK;                      // Turn on DMA request(Transmit) for UART0 UART0_C2 |= (UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Enable UART0 } 7)在DMA发送完成中断服务函数中禁掉DMA通道,实现单次发送,即每个数据包发送完成之后即停止发送,否则不禁掉的话会一直触发DMA发送,造成串口堵塞: void DMA0_IRQHandler(void) {  /* Create pointer & variable for reading DMA_DSR register */ volatile uint32_t* dma_dsr_bcr0_reg = &DMA_DSR_BCR0; uint32_t dma_dsr_bcr0_val = *dma_dsr_bcr0_reg; if (((dma_dsr_bcr0_val & DMA_DSR_BCR_DONE_MASK) == DMA_DSR_BCR_DONE_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BES_MASK) == DMA_DSR_BCR_BES_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BED_MASK) == DMA_DSR_BCR_BED_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_CE_MASK) == DMA_DSR_BCR_CE_MASK)) { DMA_DSR_BCR0 |= DMA_DSR_BCR_DONE_MASK;                //Clear Done bit DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));      //Reset BCR dma0_done = 1; } /* once the array complete the transfer, then disable the DMA channel.*/ DMAMUX0_CHCFG0 &= ~DMAMUX_CHCFG_ENBL_MASK; }        将上述代码做完相应修改即可实现单次将内存缓冲区数据以DMA方式通过UART0发送出去,效果如下。此外,如果想周期性触发或者条件性触发,则只需再相应位置添加“DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;”这句代码即可打开通道,然后立即会触发UART0_TX发送数据,然后待数据包发送完之后再次停止等待下次使能。 另外,关于DMA的传输速度的话,因为其独立占用一条自己的总线,其搬运时钟为系统时钟(即coreclock/Systemclock),相比于总线上的传输速度,本例程中整个数据包的发送时间主要是取决于UART串口的波特率*数据包长度。 附件为修改好后的完整工程:
查看全文