DFU_PC_demo_source_code.zip

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.

There is new amazing feature in FreeMaster ver 1.4 ( www.freescale.com/freemaster ) - you can do the debugging and visualization of your application in FreeMASTER without adding any code in there (you do not need a serial driver of any kind to achieve the connection), just using the communication plug-in to OSDA embedded in new version of Freemaster connected instead of the debugger from IDE. The driverless use of Freemaster use is easy to use, just open the FreeMaster, assuming you have your own application, without any Freemaster driver in it. Load the application into flash memory of the KL device and close debugging session from IDE. Open FreeMaster and  go to Project/Options/Comm, use setup from picture below Choose Plug-in - use the FreeMASTER BDM Communication Plug-in, hit configure and take P&E Kinetis. you can test the connection there too. The next step is to go to Options/MAP files, navigate to *.ELF file of your project and set file format to ELF/DWARF (I have chosen .elf from some usb demo project just to show the way how to do so) well, the connection is established, now there is need to choose variables for display and visualization. Go to project/Variables and choose variables you want to follow (hit Generate.. to do so, list of variables available in your project will appear and you can choose the desired one and hit generate - it will check and generate the variable connection, you can do it for single variable, array or more variables - it is intuitive ) When desired variables are generated, close the dialog. You can make a scope or add variables to watch. To add variable to variable watch window click by right mouse button in watch area go to watch properties, Watch tab and hit Add---->> to add it between watched wariables and hit OK and value appears in the Variable Watch window. To create scope, go to project tree window and use right mouse button on NewProject, choose Create Scope... In scope properties chose the name for this scope and go to  Setup tab. You can add your variable to the scope here by choosing in drop down menu Hit OK and start the session (Ctrl+K) or hitting Stop icon in the menu, the variable is displayed in the window. The value in my case stays 0 however displays correctly... Pavel

Problem Analysis and solutions for booting from ROM BOOTLOADER in KL series 1 Abstract      When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, they have found a problem that if the code boot from the ROM instead of the flash, the application code about the LPUART and I2C will run in abnormal state, especially when use PTA1 as the  LPUART receive pin, UART transmit function has no problem, but when the PTA1 receive the UART data, the code will run to the abnormal area and can’t return back, the code will be crash. This problem only happens on booting from the ROM and the uart and i2c peripheral are enabled in BCA 0x3d0 address, uart peripheral enablement in BCA area will influence the application PTA1 uart receive, i2c peripheral enablement in BCA area will influence the i2c0 module in the application code. If booting from the flash or booting from ROM but the uart and I2C peripheral are disabled in the BCA 0x3d0 address, everything is working ok in the application code.      This document will take the UART problem as an example, give details of the problem reproduction, testing, analysis and the solutions. The I2C problem is the same when booting from the ROM bootloader. 2 Problem reproduction and analysis  Testing preparation: IDE: KDS 和IAR Hardware: FRDM-KL43 Software: 3.0 and KSDK2.0_FRDM-KL43      We mainly reproduce the uart receive problem in two ways: new KDS PE project based on KSDK1.3.0 and official newest sample code package KSDK2.0_FRDM-KL43. 2.1 Problem reproduction in new creating kds project Because the KSDK2.0 still doesn’t support the PE function in the KDS IDE, so we use the KSDK1.3.0 as the PE KSDK to create the new KDS project. 2.1.1 Create KDS KL43 project The new KDS PE project creating is very simple, here just describe the important points which is relate to the UART problem after booting from the ROM. At first create a new KDS PE project which is based on KSDK1.3.0, and choose the chip as MKL43Z256VLH4, select the MCG mode as HIRC, and configure core clock to 48Mhz, bus clock to 24Mhz. Then add the uart module fls_debug_console for testing, because the FRDM_KL43 is using PTA1 and PTA2, the console module can be configured like the following picture, after the module is configured, press the code generation button to generate the project code. Then add the simple code in file main.c main function for testing: char a; for(;;) {                 PRINTF(" test!\n");                 a= GETCHAR();                 PUTCHAR(a);               } The code function is: printf the “test!” to the COM port in the PC, then wait the uart data, if receive the data, then printf the received data back and run this loop function again.   2.1.2 Add the BCA area    From the KL43 reference manual, we can get that, BCA start address is 0X3C0:     The KDS newly created project didn’t contain the BCA area in the link file, so we need to add this area in the link file and add the BCA data in the start file by ourselves. 2.1.2.1 Divide the BCA flash are in .ld file Add the following code to define the BCA start flash address and the flash size in the ProcessorExpert.ld memory area: m_bca                 (RX)  : ORIGIN = 0x000003C0, LENGTH = 0x00000040 Then add this code in the SECTIONS area:   .bca :            {              . = ALIGN(4);              KEEP(*(.bca)) /* Bootloader Configuration Area (BCA) */              . = ALIGN(4);            } > m_bca At last, the ld file is like this: For the ld file protection, we can change the ld file properties to read-only, then this file won’t be changed to the initial one after building. 2.1.2.2 Add the BCA data in the start file      After add the BCA flash area divide code, we still need to define the BCA data in the start file:    /* BCA Area */     .section .bca, "a"                 .ascii "kcfg"                            // [00:03] tag                 .long 0xFFFFFFFF // [07:04] crcStartAddress                 .long 0xFFFFFFFF // [0B:08] crcByteCount                 .long 0xFFFFFFFF // [0F:0C] crcExpectedValue                 .byte 0x03                                             // [10] enabledPeripherals  I2C and UART                 .byte 0xFF                                              // [11] i2cSlaveAddress                 .short 3000                           // [13:12] peripheralDetectionTimeout (milliseconds)                 .short 0xFFFF                        // [15:14] usbVid                 .short 0xFFFF                        // [17:16] usbPid                 .long 0xFFFFFFFF  // [1B:18] usbStringsPointer                 .byte 0xFF                                              // [1C] clockFlags                 .byte 0xFF                                              // [1D] clockDivider                 .byte 0xFF                                              // [1E] bootFlags                 .byte 0xFF                                              // [1F] reserved*/    More details, please refer to this picture:       So far, we have create the FRDM-KL43 test project which contains the BCA area, and boot from the ROM that can be modified in the flash address 0X40D, bit 6-7 in 0X40D is the BOOTSRC_SEL bits, 00 boot from flash, 10 and 11 boot from ROM, more details about the FOPT, please refer to Table 6-2. Flash Option Register (FTFA_FOPT) definition in reference manual.     2.1.3 Test result and analysis       Now, list the test result after booting from ROM or flash, and boot from ROM but enable the peripherals. Boot from: ROM peripheral Test Result Flash XX OK ROM 0XFF, enable all NO, UART can’t receive 0X08, enable USB Yes, UART can receive 0X04, enable SPI Yes, UART can receive 0X02, enable I2C Yes, UART can receive 0X01, enable LPUART NO, UART can’t receive      From the test result, we can reproduce the problem. The UART receive problem just happens on booting from ROM and the LPUART is enabled, when we run it with debugger, and test it step by step, we can find after the PTA1 have received the data, the code will run to the abnormal area. Note: when debug this code, please choose the JLINK as the debugger, because the P&E tool will protect the FOPT area automatically in the KDS IDE when do debugging, the code will still run from flash, so if customer use the P&E tool, they will found the PTA1 still can receive the data, this is not the real result, but the JLINK won’t protect FOPT area in the KDS IDE, it can reflect the real result.      After using the JLINK as the debugger, and we have found after PTA1 getting data or pulling low, the code will enter to the abnormal area like this:      We can get that the code run to the defaultISR, and display with USB_IRQHander, but this is not really the USB_IRQHander, just caused by the PC abnormal. Normally, it is caused by the missing of interrupt service function.       Now, we test the NVIC data to check which module interrupt caused this, the following picture is the result by enabling the LPUART and I2C peripheral in the ROM BCA area. We can find, even we didn’t do the cpu and peripheral initialization after booting from ROM, there still have peripheral be enabled, what the interrupt is enabled? From the definitive guide to the ARM Cortex-M0.pdf: NVIC_ISER = 0x40000100, Vector46=IRQ30 and vector24=IRQ8 is enabled, it should be not disabled after booting from the ROM. Now check the KL43 reference manual, Table 3-2. Interrupt vector assignments, we can get that the I2C0 and PORTA interrupt is enabled. Checking the PORTA register before do the cpu and peripheral initialization, PTA1 is enabled the port interrupt, and choose Flag and Interrupt on falling-edge.     This can tell us why the PTA1 pin have the problem of uart receive data or give a falling edge in PTA1 will run abnormal, because in default, even we configure the PTA1 as the uart receive function, but the code didn’t clear IRQ and NVIC register, when the signal happens on PTA1 pin, it will caused the PORTA interrupt, but we didn’t add the PORTA interrupt ISR function, it is also not useful to us, then PC don’t know where to go, so it will run abnormal, enter the defaultISR, and can’t recover. If you have interest, you can add the PORTA_IRQHandler function, you will find the code will run to this function. 2.2 Problem reproduction in KSDK2.0 IAR project  Test project: SDK_2.0_FRDM-KL43Z\boards\frdmkl43z\demo_apps\hello_world  Test the official project just to make sure, it is really the chip hardware function, not only the problem from new generated code in KDS.   Because the IAR IDE will protect the 0X400 area, then if we want to modify the FOPT, we need to modify the .board, add –enable_config_write at first.    Then modify the FOPT in startup_MKL43Z.s: __FlashConfig         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFF         DCD 0xFFFFFFFE   ; 0xFFFF3FFE   __FlashConfig_End   Because the BCA peripheral area is in default as 0XFF, it enables all the peripheral, we don’t need to define the BCA area independently.  For getting the real test result, we add the NVIC and PORTA_PCR1 register printf code in the main function,    PRINTF("PORTA_PCR1=%X \n", PORTA->PCR[1]);    PRINTF("NVIC=%X \n", NVIC->ICER[0U]); And download the modified KSDK sample code to the chip, after testing, we get this result: hello world. PORTA_PCR1=A0205 NVIC=40000100 It is the same result as the new created project after booting from the ROM, PORTA interrupt and I2C interrupt is enabled, and it caused the PTA1 receive data problem.  3 Solutions and test result 3.1 Solutions      From the Chapter 2 testing and analysis, we can get that UART receive problem is caused by the PORT interrupt and NVIC is enabled after booting from the ROM, this should be caused by exiting the ROM, the ROM forget to disable it. We also can find some descriptions from the KL43 reference manual page 211: So, if customer want to solve this problem, to avoid the application enter to the abnormal area, we can disable the NVIC in the application code like this, the I2C NVIC is the same:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt 3.2 Test result   From the test result after adding the NVIC I2C and PORTA disable code, we can get the uart can works ok, if you have interest to test, the I2C will also work ok. 4 Conclusion When customer use the kinetis chip KL43, KL27 and KL17 which flash size is above 128K, and want to boot from the ROM and enable the LPUART and I2C in BCA area, please add the NVIC I2C(IRQ8) and PORTA(IRQ30) disable code in the application code:     NVIC_DisableIRQ(8);//disable I2C0 interrupt     NVIC_DisableIRQ(30); //disable PTA interrupt So far, I just find KL43, KL27 and KL17 which flash size is above 128K have this problem, other kinetis chip which have ROM bootloader don’t have this problem.

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 )

Summary:   This tool is based upon the Audio BiQuad Cookbook Here:   http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt   Very useful for configuring the FRDM-JAM and the MonkeyJam software!     Requirements:   You need a machine with the .net 4.0 Framework (or greater) Installed (Windows 7 or Greater).    If you have issues go here:   Download Microsoft .NET Framework 4 (Standalone Installer) from Official Microsoft Download Center   Instructions:   Just unzip and run the .exe   Please report any problems in the comments section Original Attachment has been moved to: BiQuadFilterView---1.0.0.zip

        在我们嵌入式工程应用中，中断作为最常用的异步手段是必不可少的，而且在一个应用程序中，一个中断往往是不够用的，多个中断混合使用甚至多级中断嵌套也经常会使用到，而这样就涉及到一个中断优先级的问题。         以我们最熟悉的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  */ }

Here you will find the code and project files corresponding to the I2C-Accelerometer project. The accelerometer/magnetometer is connected to the I2C port, although bot the accelerometer and magnetometer are contained within a single package, they must be initialized individually. In this example the measurements from both devices (X,Y and Z axis) is performed and displayed at the serial terminal. In order to compile the project, the following library must be imported: FXOS8700Q.h Code: #include "mbed.h" #include "FXOS8700Q.h" //I2C lines for FXOS8700Q accelerometer/magnetometer FXOS8700Q_acc acc( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); FXOS8700Q_mag mag( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); //Temrinal enable Serial pc(USBTX, USBRX); MotionSensorDataUnits mag_data; MotionSensorDataUnits acc_data; int main() {     float faX, faY, faZ;     float fmX, fmY, fmZ;     acc.enable();     printf("\r\n\nFXOS8700Q Who Am I= %X\r\n", acc.whoAmI());     while (true)     {         acc.getAxis(acc_data);         mag.getAxis(mag_data);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", acc_data.x, acc_data.y, acc_data.z);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", mag_data.x, mag_data.y, mag_data.z);         acc.getX(&faX);         acc.getY(&faY);         acc.getZ(&faZ);         mag.getX(&fmX);         mag.getY(&fmY);         mag.getZ(&fmZ);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", faX, faY, faZ);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", fmX, fmY, fmZ);                 wait(1.0);     } }

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

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

As we know, uC/OS –II is a scalable, ROMable, preemptive real-time kernel that manages multiple tasks and it has been ported to more than 45 CPU architectures.  In this article, you can learn the steps of porting uC/OS –II to MAPS-22. Downloading uC/OS-II source code and application project To obtain the μC/OS-II source code and projects, simply point your favorite browser to: www.Micrium.com/Books/Micrium-uCOS-II. You will be required to register. This means that you’ll have to provide information about yourself. Download and execute the following file: Micrium-Book-uCOS-II-TWR-K53N512.exe. Fig 1 shows the directory structure created by this executable. All files are placed under the \Micrium directory. There are two main sub-directories: \Examples and \Software and they are described below. Fig 1 Directories and Files μC/OS-II is fairly easy to use once it is understood exactly which source files are needed to make up a μC/OS-II-based application. Fig 2 shows the μC/OS-II architecture and its relationship with hardware. Of course, in addition to the timer and interrupt controller, hardware would most likely contain such other devices as Universal Asynchronous Receiver Transmitters (UARTs), Analog to Digital Converters (ADCs), Ethernet controller(s) and more. Fig 2 F2-(1) The application code consists of project or product files. For convenience, these are simply called app.c and app.h, however an application can contain any number of files that do not have to be called app.*. The application code is typically where one would find the main(). F2-(2) The Board Support Package (BSP) code needed by μC/OS-II is typically quite simple and generally, μC/OS-II only requires that you initialize a periodic interrupt source which is used for time delays and timeouts. This functionality can be placed in a file called bsp.c along with its corresponding header file, bsp.h. Semiconductor manufacturers often provide library functions in source form for accessing the peripherals on their CPU or MCU. These libraries are also part of the BSP. F2-(3) This is the μC/OS-II processor-independent code. This code is written in highly portable ANSI C. F2-(4) This is the μC/OS-II code that is adapted to a specific CPU architecture and is called a port. F2-(5) Configuration files are used to define μC/OS-II features (os_cfg.h) to include in the application, specify the size of certain variables and data structures expected by μC/OS-II, such as idle task stack size and tick rate among others. Below is a summary of all directories and files involved in a μC/OS-II-based project (Fig 3). The“<-Cfg” on the far right indicates that these files are typically copied into the application directory and edited based on the project requirements. Fig 3 Porting Steps 1. Copy uC/OS-II source code to ~\MAPSK22_SC\Libraries which includes peripheral driver files, startup code and devices header 2. Copy os_cfg.h, app_cfg.h which reside in ~\Micrium-Book-uCOS-II-TWR-K53N512\Micrium\Examples\Freescale\TWR-K53N512\(project name) to ~\MAPSK22_SC\Project\MAPSK22\1-Template\src Summary: configuration files os_cfg.h, app_cfg.h should be adapt to the specific requirements of the application code 3. Copy lib_def.h which resides in ~\Micrium\Software\uC-LIB to ~\MAPSK22_SC\Libraries\drivers\K\inc 4. Adds systick timer initialization function in system_MK22F51212.c void SystemTickInit (void) {   uint32_t cpu_clk_freq;   uint32_t cnts;   cpu_clk_freq = SystemCoreClock;    cnts  = cpu_clk_freq / (uint32_t)OS_TICKS_PER_SEC;            OS_CPU_SysTickInit(cnts);     5. Modify the interrupt vector 6. Create uC/OS-II group in the workspace, then add the uC/OS-II source code and os_cfg.h, app_cfg.h 7. Add application code in the main.c and please check the attachment. 8. Modify the Include Directories    Run the uC/OS-II application After build the modified application code, then run it on MAPS-K22 board(Fig 4). Fig 4 You can find the LED3 and LED4 flash every 2s, however for the LED1 and LED2, it’s 1s. And some informations’re illustrated in the Hyper Terminal (Fig 5)

Hi,, Can anyone please post the code for SPI (Serial peripheral interface) using MK22D5.h....I tried doing using processor expert but im getting errors in the main program..please post the code for SPI Thank you