Kinetis Microcontrollers Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis Microcontrollers Knowledge Base

Discussions

Sort by:
Overview          KBOOT v2.0 had been released in the Q2 of the 2016 and it has a lot of new features versus the previous version. For instance, the USB peripheral can work as Mass Storage Class device mode now, not just only supports the HID interface. And in following, USB MSD Bootloader implementation will be illustrated. Preparation FRDM-K64F board Fig1 FRDM-K64F KBOOT v2.0 downloading: KBOOT v2.0 IDE: IAR v7.50 Application demo: KSDK v2.0   Flash-resident bootloader           The K64_120 doesn’t contain the ROM-based bootloader, so the flash-resident bootloader need to be programmed in the K64 and the flash-resident bootloader can be used to download and program an initial application image into a blank area on the flash, and to later update the application.         I. Open the the bootloader project, for instance, using the IAR and select the freedom_bootloader demo         The Fig 2 illustrates the bootloader project for K64 which resides in ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloade r_2_0_0\targets\MK64F12. Fig 2      II. After compiles the demo, then clicks the  button to program the demo to the K64 Linker file modification       According to the freedom_bootloader demo, the vector table relocation address of the application demo has been adapted to the 0xa000 (Table 1), however the default start address of the application is 0x0000_0000. So it’s necessary to modify the linker file to fit the freedom_bootloader and the Table 2 illustrates what the modifications are.                                                     Table 1 // The bootloader will check this address for the application vector table upon startup. #if !defined(BL_APP_VECTOR_TABLE_ADDRESS) #define BL_APP_VECTOR_TABLE_ADDRESS 0xa000 #endif                                                   Table 2 define symbol __ram_vector_table_size__ = isdefinedsymbol(__ram_vector_table__) ? 0x00000400 : 0; define symbol __ram_vector_table_offset__ = isdefinedsymbol(__ram_vector_table__) ? 0x000003FF : 0; //define symbol m_interrupts_start       = 0x00000000; //define symbol m_interrupts_end         = 0x000003FF; define symbol m_interrupts_start       = 0x0000a000; define symbol m_interrupts_end         = 0x0000a3FF; //define symbol m_flash_config_start     = 0x00000400; //define symbol m_flash_config_end       = 0x0000040F; define symbol m_flash_config_start     = 0x0000a400; define symbol m_flash_config_end       = 0x0000a40F; //define symbol m_text_start             = 0x00000410; define symbol m_text_start             = 0x0000a410; define symbol m_text_end               = 0x000FFFFF; define symbol m_interrupts_ram_start   = 0x1FFF0000; define symbol m_interrupts_ram_end     = 0x1FFF0000 + __ram_vector_table_offset__; define symbol m_data_start             = m_interrupts_ram_start + __ram_vector_table_size__; define symbol m_data_end               = 0x1FFFFFFF; define symbol m_data_2_start           = 0x20000000; define symbol m_data_2_end             = 0x2002FFFF; /* Sizes */ if (isdefinedsymbol(__stack_size__)) {   define symbol __size_cstack__        = __stack_size__; } else {   define symbol __size_cstack__        = 0x0400; } if (isdefinedsymbol(__heap_size__)) {   define symbol __size_heap__          = __heap_size__; } else {   define symbol __size_heap__          = 0x0400; } define exported symbol __VECTOR_TABLE  = m_interrupts_start; define exported symbol __VECTOR_RAM    = isdefinedsymbol(__ram_vector_table__) ? m_interrupts_ram_start : m_interrupts_start; define exported symbol __RAM_VECTOR_TABLE_SIZE = __ram_vector_table_size__; define memory mem with size = 4G; define region m_flash_config_region = mem:[from m_flash_config_start to m_flash_config_end]; define region TEXT_region = mem:[from m_interrupts_start to m_interrupts_end]                           | mem:[from m_text_start to m_text_end]; define region DATA_region = mem:[from m_data_start to m_data_end]                           | mem:[from m_data_2_start to m_data_2_end-__size_cstack__]; define region CSTACK_region = mem:[from m_data_2_end-__size_cstack__+1 to m_data_2_end]; define region m_interrupts_ram_region = mem:[from m_interrupts_ram_start to m_interrupts_ram_end]; define block CSTACK    with alignment = 8, size = __size_cstack__   { }; define block HEAP      with alignment = 8, size = __size_heap__     { }; define block RW        { readwrite }; define block ZI        { zi }; initialize by copy { readwrite, section .textrw }; do not initialize  { section .noinit }; place at address mem: m_interrupts_start    { readonly section .intvec }; place in m_flash_config_region              { section FlashConfig }; place in TEXT_region                        { readonly }; place in DATA_region                        { block RW }; place in DATA_region                        { block ZI }; place in DATA_region                        { last block HEAP }; place in CSTACK_region                      { block CSTACK }; place in m_interrupts_ram_region            { section m_interrupts_ram }; SB file generation     I. Brief introduction of SB file         The Kinetis bootloader supports loading of the SB files. The SB file is a Freescale-defined boot file format designed to ease the boot process. The file is generated using the Freescale elftosb tool. The format supports loading of elf or srec files in a controlled manner, using boot commands such as load, jump, fill, erase, and so on. The boot commands are prescribed in the input command file (boot descriptor .bd) to the elftosb tool. The format also supports encryption of the boot image using AES-128 input key.          And right now, the USB MSD bootloader only support SB file drag and drop.    II. Generate the BIN file         After open the hello_world demo in the IAR, using project options dialog select the "Output Converter" and change the output format to "binary" for outputting .BIN format image (Fig 3). Next, build the application demo, then the .BIN file will be generated after the building completes. Fig 3      III. Create BD file There is a template BD file which resides in the ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\src. Next, adapt the BD file by referring to the Kinetis Elftosb User's Guide, the following table shows the BD file content.                                                    Table 3 sources {         # BIN File path         myBINFile = "hello_world.bin"; } section (0) {         #1. Erase the internal flash         erase 0x0000a000..0x0010000;         #2. Load BIN File to internal flash         load myBINFile > 0xa000;         #3. Reset target.         reset; }      IV.  SB file generation          After creating the BD file shown in the following figure, copy the "hello_world.bin", elftosb.exe, and the BD file into the same directory. Then, open the window with command prompt and invoke elftosb such as “elftosb –V –c FRDM-K64F.bd –o image.sb”. The elftosb processes the FRDM-K64F.bd file and generates an image.sb file. Elftosb also outputs the commands list as shown in Fig 4. Fig 4     V. Application code updating       Plug a USB cable from the PC to the USB connector J26 to power the board , then keep holding the button SW2 down until press and release the Reset button SW1, it can force the K64_120 enter the BOOTLOADER mode. Next, plug another USB cable from the PC to the USB connector J22 (Fig 5), the FSL Loader will come out after completes the enumeration and it will appear as a removable storage driver (Fig 6).  Copy & paste or drag & drop the image.sb to the FSL Loader drive to update the application code, and the Fig 7 illustrates the result of application code runs. Fig 5 Fig 6 Fig 7
View full article
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
View full article
I have definitely experienced some of the growing pains of using the Kinetis tools as they have underdone some changes.  I started tinkering with KDS last year when KSDK and MQX were separate packages.  I didn't mess around with it much, other than to prove that I could toggle some GPIO.  I then got more serious with KDS 2.0 and KSDK 1.1 when MQX was integrated into the installer.  I started with simple projects, and eventually got a pretty good demo put together that incorporated ethernet (using lwIP), RS485, Modbus TCP/RTU, motion control, and barcode reading.  Unfortunately, at that time there were some small issues with the KSDK 1.1 which prevented us from being able to easily write applications in C++.  I definitely think better in C++ than in C, so this was a bummer. I was quite excited when the C++ issues were fixed in KSDK 1.2.  So now I need to port my application from C to C++.  At this point, I am faced with two hurdles: Directly porting my currently-working application (written for KDS 2 / KSDK 1.1) doesn't work.  I have written some posts here about it and could use some help solving those problems. lwIP project that was working in KDS 2.0 with MQX and PEx no longer works in KDS 3.0 How do you force PEx to be totally C++ compatible? Adding HardFault handlers in KDS3/KSDK1.2? Figuring out how to call into C++ wrappers This post is about #2, where I believe I have a usable solution.  It's basically covered in Re: How to call C functions that use "restrict" keyword from C ?  but with a small twist or two.  I am currently using KDS 3, KSDK 1.2, and my project requires MQX Standard as well as Processor Expert.When you create a project like mine, you will likely go through the following basic steps: Create new project Enable KSDK and Processor Expert Change osa from BareMetal to MQX Change MQX from Lite to Standard Disable DbgCs1 Enable new fsl_uart in MQX settings and disable its pins Add OS_Task components and other PEx components Specify your CPU type in the C++ compiler settings, as shown below Generate code In addition to main.c, after you generate code, you'll also end up with os_tasks.c.  Your PEx components will have C code added to the Generated Code folder.  At this point, it should be possible to wrap components in C++ classes.  Tonight, I ran a simple test where I wanted one of my MQX tasks to blink an LED.  The LED blink code was wrapped in a simple C++ class, and in order to be able to create the C++ object to call into, you have to call it from C++ code! The solution ends up being pretty simple.  Rename main.c to main.cpp, and rename os_tasks.c to os_tasks.cpp.  Then generate code again.  Click on your Sources folder and hit F5.  You will see that main.c and os_tasks.cpp reappear, because they get re-created.  Right click on each of them and click Resource Configuration -> Exclude from Build. Click Select All, then Close.  This will prevent those files from being compiled.  Note that if you add more OS_Task components, you will need to manually update os_tasks.cpp accordingly. At this point, it's very simple to create a wrapper class and call it.  I wrote one called DebugLed.cpp: #include <DebugLed.h> #include "Cpu.h" #include "gpio_comp.h" namespace Peripherals { DebugLed::DebugLed() {   // TODO Auto-generated constructor stub } DebugLed::~DebugLed() {   // TODO Auto-generated destructor stub } void DebugLed::BlinkGreen() {   GPIO_DRV_SetPinOutput( LEDRGB_GREEN);   OSA_TimeDelay(150);                 /* Example code (for task release) */   GPIO_DRV_ClearPinOutput( LEDRGB_GREEN);   OSA_TimeDelay(150);                 /* Example code (for task release) */ } } /* namespace Peripherals */ (hopefully all of the code shows up when I post this!  I don't see all of it in the preview) Then you can instantiate the DebugLed object before the while(1) in your OS_Task: void Blink_task(os_task_param_t task_init_data) {   /* Write your local variable definition here */   Peripherals::DebugLed led; #ifdef PEX_USE_RTOS   while (1) { #endif     /* Write your code here ... */    led.BlinkGreen(); #ifdef PEX_USE_RTOS     } #endif    } /* END os_tasks */ #ifdef __cplusplus }  /* extern "C" */ #endif Build, debug, and set a breakpoint on your call into your C++ object, and it should hit it! It's a lot easier than I thought it would be.  I figured there would be more manual labor involved with the code generation aspect of it, but it seems to basically boil down to two files, and you don't even need to disable code generation for any of the PEx components, which means you can still use the GUI to change settings if necessary (even though manually changing the header is just as simple). When I get to the office tomorrow, I'll probably start wrapping more complex peripherals, but I really need to figure out the HardFault problem with my lwIP project.  If you have any suggestions, please visit my post: Adding HardFault handlers in KDS3/KSDK1.2? and comment if you can.  I hope my first document here on the Freescale Community was helpful to someone here!
View full article
For Remote Control means, that is needed two computers - Server Computer and User Computer, which will be in connection. There are two types of connection, which can be used - HTTP or DCOM. There are two different ways how to set up the remote control in Windows. I made the tutorial, which describes both types of Remote Control. Ok - so, let´s start! HTTP Settings On the Server Computer side: 1. Plug the board to the Server Computer 2. Go to Remote Communication Server 3. Set HTTP connection and choose the right COM Port according the plugged board If the plugged board is on e.g. COM23, it is possible to edit number of Port in Device Manager On the User PC side: 1. Open FreeMASTER,  go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (HTTP) and type the IP address of the server, do not forget join to IP address :8080 3. And start communication by STOP button to successful connection DCOM Settings On the Server Computer side: 1. Plug board to the Server Computer 2. Launch DCOM in FreeMASTER Remote Server Choose COM according plugged board or edit COM according to step 2 - Server Computer in HTTP Connection (up). 3. Setting permissions for the user, User PC. Right click on Computer -> Manage. In Computer Management click to Distributed COM Users. In Distributed COM Users Properties add the user, User Computer. After that, set the permissions in Component Services. In cmd type dcomcnfg.exe In Component Services go to Computers -> My Computer -> DCOM Config -> MCB FreeMASTER Remote Server Application Right click on MCB FreeMASTER Remote Server Application and go to Properties. In Security Tab is possible to add the permissions. There are 3 types of permissions. First permission - Launch and Activation Permissions. There are 4 permission options. Local Launch and Remote Launch means, that user, User Computer can launch e.g. FM Remote Server Application. But for success communication is needed allowing Local Activation and Remote Activation. Second permission - Access Permissions. Click to Edit and Allow Local Access and Remote Access for the user. Do not forget that if there is a change of permissions, specifically allowing, it is necessary for User to log out and log in. On the User Computer side: 1. Open Freemaster, go to Project -> Options 2. Choose Plug-in Module: FreeMASTER CommPlugin for Remote Server (DCOM) and for filling Connect string is possible to use Configure. Definitely, type the IP address of the server and ;Port Name. 3. And start communication by STOP button in FreeMASTER to successful connection And now.. you can do anything 🙂
View full article
最近搞了一个基于TWR-K20D50M的的USB MSD device bootloader, 可以打开文件夹CW中的K20D5下的.project来查看。 在原始的MSD的基础上移植了FAT过来。 其他IAR和Kinetis的其他chip没有测试,如果需要使用,一个是新增相关头文件,二是在bootloader.h中修改相应的MCU_K20D50M定义下的flash及ram配置
View full article
Hello All, Power consumption of devices and implications around designing on embedded systems is a common topic nowadays. Kinetis MCUs offer different power modes to fit user's needs. Among these low power modes, we can find the lowest consumption modes: Low-Leakage Stop (LLS) and Very Low-Leakage Stop modes (VLLS). Attached document provides a brief introduction/explanation on these modes and lists the steps needed to configure MCU to operate in any of these modes. It is a bare-board project for FRDM-KL26Z but same principle applies to other Kinetis families. Also, two projects for KDS v3.2 are attached for reference. I hope you can find them useful! Regards, Isaac
View full article
La serie Kinetis L es una combinación de eficiencia energética, escalabilidad, valor y facilidad de uso que revolucionará el mercado de microcontroladores de nivel básico. Ofrece a los usuarios de arquitecturas heredadas de 8 y 16 bits una ruta de migración hacia la gama de microcontroladores Kinetis de 32 bits y les permite aumentar el rendimiento y ampliar la funcionalidad de sus productos finales sin incrementar el consumo de energía ni los costes del sistema. La serie Kinetis L se compone de cinco familias de microcontroladores: KL0, KL1, KL2, KL3 y KL4. Cada familia combina excelentes corrientes dinámicas y de parada con una capacidad extraordinaria de procesamiento, una amplia selección de memorias flash y una gran variedad de opciones analógicas, de conectividad y de periféricos HMI. La familia KL0 es compatible en pines con la familia S08Px de 8 bits (lo que tiende un puente entre el desarrollo de 8 bits y la cartera Kinetis) y compatible en software con otras familias de la serie Kinetis L. Las familias KL1, KL2, KL3 y KL4 presentan una compatibilidad mutua en hardware y software, además de ser compatibles con sus equivalentes de la serie Kinetis K basada en el Cortex-M4 (KL1 -> K10, KL2 -> K20…). De este modo, los desarrolladores disponen de una ruta de migración ascendente/descendente hacia mayor/menor rendimiento, memoria y funcionalidad integrada, lo que les permite reutilizar el hardware y el software en todas las plataformas de productos finales y reducir el tiempo necesario para la comercialización. Las primeras familias disponibles en el mercado serán KL0, KL1 y KL2 a finales de septiembre de 2012. La disponibilidad de las familias KL3 y KL4 está prevista para el primer trimestre de 2013. Procesador ARM Cortex-M0+ El procesador ARM Cortex-M0+ ofrece niveles más altos de eficiencia energética y de rendimiento y es más fácil de usar que su antecesor, el Cortex-M0. En cuanto a las instrucciones, mantiene plena compatibilidad con todos los demás procesadores de la clase Cortex-M (Cortex-M0/3/4), por lo que los desarrolladores pueden reutilizar sus compiladores y herramientas de depuración existentes. Principales características: 1,77 coremarks/MHz: entre 2 y 40 veces más que los microcontroladores de 8/16 bits, un 9 % más que el Cortex-M0. Coremarks/mA: entre 2 y 50 veces más que los microcontroladores de 8/16 bits, un 25 % más que el Cortex M0. Pipeline de 2 etapas: reducidos ciclos por instrucción (CPI), lo que permite instrucciones de bifurcación y entradas ISR más rápidas. MTB (Micro Trace Buffer): solución ligera y no intrusiva; la información del rastreo se guarda en una pequeña área de la SRAM del microcontrolador (tamaño definido por el programador), lectura a través de SWD/JTAG. Amplio soporte para el entorno ARM. Acceso E/S monociclo: frecuencia de conmutación de la interfaz GPIO un 50 % más alta que la de la E/S estándar, lo que mejora el tiempo de respuesta a eventos externos y permite manipular bits (bit-banding) y emular protocolos de software. Espacio de direcciones lineal de 4 GB: elimina esquemas de paginación complejos y simplifica la arquitectura de software. Solamente 56 instrucciones: mayoritariamente codificadas en 16 bits; opción para MUL rápida de 32 x 32 bits en un ciclo. Conjunto de instrucciones: totalmente compatible con el procesador Cortex-M0, subconjunto de instrucciones del procesador Cortex-M3/4. La mejor densidad de códigos de su categoría en comparación con arquitecturas de 8/16 bits; menor tamaño de memoria flash y reducción del consumo de energía; mayor rendimiento que sus equivalentes de 8 y 16 bits. Acceso a la memoria del programa; reducción del consumo de energía. Familias de microcontroladores de la serie Kinetis L Los microcontroladores de la serie Kinetis L se basan en la funcionalidad del procesador ARM Cortex-M0+, que presenta un diseño de plataforma de bajo consumo energético así como modos operativos y dispositivos periféricos que ahorran energía. El resultado es un microcontrolador que ofrece la mejor eficiencia energética de la industria, consume menos de 50 μA/MHz en el modo VLPR (Very Low Power Run) y puede despertarse rápidamente desde el estado de reposo, procesar datos y restablecer el modo de reposo, lo cual alarga la vida útil de la batería en las aplicaciones. Para ver una demostración de la eficiencia energética de la serie Kinetis L, visite www.freescale.com/ftf. Familias de microcontroladores: Familia KL0: la puerta de entrada a la serie Kinetis L; microcontroladores de 8-32 kB y de 24-48 pines, compatibles en pines con la familia S08P de 8 bits y en software con todas las demás familias de la serie Kinetis L. Familia KL1: microcontroladores de 32-256 kB y de 32-80 pines con comunicaciones adicionales y periféricos analógicos, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K10 (CM4) de la serie K. Familia KL2: microcontroladores de 32-256 kB y de 32-121 pines con USB 2.0 de máxima velocidad tipo host/device/OTG, compatibles en hardware y software con todas las familias de la serie Kinetis L y con la familia K20 (CM4) de la serie K. Características comunes a todas las familias de microcontroladores de la serie Kinetis L: Procesamiento extremadamente eficiente Procesador ARM Cortex-M0+ de 48 MHz Tecnología flash de bajo consumo de energía: 90 nm Funciones de manipulación de bits < 50 μA/MHz; 35,4 coremarks/mA Barra cruzada de puente periférico Controlador de memoria flash con estado de espera cero Modos de consumo de energía ultrabajo Tecnología flash con baja fuga: 90 nm Múltiples modos RUN, WAIT y STOP Activación en 4,6 μs desde el modo de reposo profundo Bloqueo de reloj y de potencia (clock & power gating), opciones de arranque con bajo consumo de energía Reloj VLPR: precisión con un 3 % máximo de margen de error, que normalmente es del 0,3-0,7 % Consumo de corriente en modo de reposo profundo: 1,4 μA con retención de registros; LVD activo y activación en 4,3μs Periféricos que ahorran energía Los periféricos funcionan en modos de reposo profundo y son capaces de tomar decisiones inteligentes y de procesar datos sin despertar al núcleo: ADMA, UART, temporizadores, convertidor analógico-digital (ADC), pantalla LCD con segmentos, sensores táctiles... ADC de 12/16 bits Convertidor digital-analógico (DAC) de 12 bits Comparadores analógicos de alta velocidad Temporizadores de alta capacidad para una gran variedad de aplicaciones, incluyendo el control de motor Para tener más información del fabricante y de los servicios, por favor visiten nuestra microsite. Via Arrow Europe
View full article
Introduction This document is being written to communicate the need for serialization of memory operations and events in an end application.  In addition, directions will be provided to properly serialize memory operations in the end application.  Memory operations and event serialization applies to all Kinetis devices but is only necessary in specific scenarios. These scenarios include memory writes and reads, clearing status flags, and changing mode control operations. Serialization of memory operations Serialization of memory operations or events is the action of guaranteeing that said memory operations or events are executed in a specific order.  This action is required when making a change to a peripheral module when that change must complete before continuing with program execution.  Users often make the mistake of assuming that since a peripheral register has been written to, the change is in effect immediately.  However, this is not always the case.  The Kinetis series devices implement a crossbar and peripheral bridge interface system that allows masters (the CPU, DMA, etc.) to interface with the peripherals.  The crossbar allows multiple masters to access the individual peripherals on the bus, and the peripheral bridge functions as a bus protocol translator between the crossbar switch and the slave peripheral bus.  Wait states can be inserted at either stage of the communication channel (crossbar or peripheral bridge).  When a master attempts to access a slave and another master is already accessing this slave or the slave is busy, wait states will be inserted.  If the access is a write, then the master's write is simply pushed to the peripheral bus and the master continues.  However, if the access is a read, the master must wait for a response from the slave.  The slave may insert wait states in this communication as it must finish any commands (or writes) it was previously given before responding.    Peripheral module changes that require serialization actions include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  If the events or memory operations are not serialized in these situations, the CPU could go on to execute code with undesired effects. When do I need to serialize my memory operations and events? Memory operations and events require serialization anytime the program needs to guarantee that a peripheral access happens before code execution continues.  Examples of these situations includes: Exiting an interrupt service routine (ISR) Changing a clock mode or power mode Configuring a function Configuring a hardware change Software triggering a hardware event How do I serialize my memory operations and events? Memory operations are serialized by performing the following operations: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations By simply reading the register that was just written, the core is forced to wait for a response from the peripheral module that was written before code execution can continue.   In this manner, it is guaranteed that the peripheral module will have completed the desired operations. Example event serialization The following is an example of a function that services the LPTMR ISR flag and implements the event serialization discussed in this document.  void lptmr_isr(void) {   // Declare dummy variable to store the read of the LPTMR0_CSR register volatile int dummy_var; /****   STEP #1  ****/   // Clear the flag; enable interrupts; enable the timer   LPTMR0_CSR = ( LPTMR_CSR_TEN_MASK | LPTMR_CSR_TIE_MASK | LPTMR_CSR_TCF_MASK  );   /****  STEP #2  ****/    // Store CSR register in dummy_var to serialize the clearing of the TCF flag   dummy_var = LPTMR0_CSR; } Conclusion In conclusion, there are situations where code execution can continue before a peripheral change has taken effect. These situations include clearing interrupt service flags, changing power modes (of the module or the SOC as a whole), or software triggering a hardware event.  Sometimes these events can cause unexpected results or even cause your application to crash.  These situations call for the serialization of memory operations and events, which is simply the act of guaranteeing that events and code are executed in a specific order.  To serialize memory operations, simply follow these directions: Write the desired peripheral register Read the peripheral register that was just written Continue with the subsequent operations Following these steps, you will be guaranteed that peripheral configurations have taken effect before continuing with the application. 
View full article
The following document contains a list of documents , questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in Kinetis processors or MCUXpresso, you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools  Getting Started with MCUXpresso and FRDM-K64F  Generating a downloadable MCUXpresso SDK v.2 package  Quick Start Guide – Using MCUXpresso SDK with PINs&amp;CLOCKs Config Tools  Moving to MCUXpresso IDE from Kinetis Design Studio Kinetis Microcontrollers Guides and examples Using RTC module on FRDM-KL25Z  Baremetal code examples using FRDM-K64F Using IAR EWARM to program flash configuration field Understanding FlexIO  Kinetis K80 FAQ How To: Secure e-mail client (SMTP + SSL) with KSDK1.3 + WolfSSL for FRDM-K64F  Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+  PIT- ADC- DMA Example for FRDM-KL25z, FRDM-K64F, TWR-K60D100 and TWR-K70  USB tethering host (RNDIS protocol) implementation for Kinetis - How to use your cellphone to provide internet connectivity for your Freedom Board using KSDK Write / read the internal flash Tracking down Hard Faults  How to create chain of pbuf's to be sent? Send data using UDP.  Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading  USB VID/PID numbers for small manufacturers and such like  Open SDA and FreeMaster OpenSDAv2  Freedom OpenSDA Firmware Issues Reported on Windows 10 Let´s start with FreeMASTER!  The Kinetis Design Studio IDE (KDS IDE) is no longer being actively developed and is not recommended for new designs. The MCUXpresso IDE has now replaced the Kinetis Design Studio IDE as the recommended software development toolchain for NXP’s Kinetis, LPC and i.MX RT Cortex-M based devices. However, this documents continue to receive considerable amount of views in 2019 which means it could be useful to some people. Kinetis Design Studio New Kinetis Design Studio v3.2.0 available Using Kinetis Design Studio v3.x with Kinetis SDK v2.0  GDB Debugging with Kinetis Design Studio  KDS Debug Configurations (OpenOCD, P&amp;E, Segger) How to use printf() to print string to Console and UART in KDS2.0  Kinetis Design Studio - enabling C++ in KSDK projects  Using MK20DX256xxx7 with KDS and KSDK  Kinetis SDK Kinetis SDK FAQ  Introducing Kinetis SDK v2  How to: install KSDK 2.0  Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt 
View full article
1 Abstract Stepper motor can be controlled by the electrical pulse signal with the open loop system, it use the electrical pulse signal realize the angular movement or linear movement.  The speed and position of the stepper motor is determined by the pulse frequent and the pulse number. Stepper motor can be used in the low speed area application, with higher work efficiency and low noise. KE02 is the 5V kinetis E series MCU, it is based on ARM Cortex M0+ core, KE series are designed to maintain high robustness for complex electrical noise environment and high reliability application. For these advantages, KE02 is fit the Stepper motor control application. This document is mainly about how use the KE02 realize the Stepper motor speed, step and direction control. It can use the UART in the PC to control the Stepper motor speed. The following picture is the control diagram.                                                                              Fig.1 2. Motor control parameter calculation      Just as Fig.1 shows, KE02 should control the EN, DIR, PWM signal to the motor driver, then realize the stepper motor control. EN is the motor driver enable signal, 0 is enable, 1 is disable; DIR is the stepper motor direction control, 0, clockwise, 1 anticlockwise; PWM is the pulse signal to control the step and speed for the stepper motor.       Stepper motor is 1.8’, it means a round have 360’/1.8’= 200 steps. But because the Motor driver have the divider, it is 32, so one stepper motor round should have 200*32 = 6400 steps.       KE02 system, it use the external 10Mhz crystal, and configure both core and bus frequent to 20Mhz,  it use FTM0 module as the motor pulse generate module, bus clock with 32 prescale used as the FTM0 clock source, choose up counter. If need to change the motor speed and control step, just control the FTM PWM frequent and PWM counter. For Stepper motor, one FTM period means one motor step. From the reference manual of KE02, we get that, the FTM period in up counting mode is: (MOD-CNTIN+1)*period of the FTM counter clock, if want to change the frequent of motor, just calculate the MOD of FTM is ok, then count the number of the FTM cycle, now assume CNTIN =0, then: Tftm= (32/20Mhz)*(MOD+1) From the Stepper Motor and it’s driver, we get that one step time is : Tmstep= 60/(V*6400) V is the speed of Motor, the unit is round/minute. Because Tftm=Tmstep, then we know: MOD= (60/(V*6400))*(20Mhz/32)-1                     (F1) In this document, we calculate the speed of 150 round/minute, 110 round/minute, 80 round/minute, 50 round/minute and 0.1 round/minute, according to (F1), we can get the MOD for each speed as the following: 150 round/minute   MOD=38 110 round/minute   MOD=52 80 round/minute     MOD=72 50 round/minute     MOD=116 0.1 round/minute    MOD=58592 If each speed need to do 10 Stepper motor round, then just control the speed counter number to: 10*6400=64000. 3. MCU pin assignment PTF0 : DIR PTF1 : EN PTA0 : PWM PTC6 : UART1_RX PTC7 : UART1_TX 4. code writing (1)FTM initial code void STEEPMOTOR_PWM_Init(uint16 MODdata) {                    SIM_SCGC |= SIM_SCGC_FTM0_MASK;                 FTM0_SC = 0;                 FTM0_C0SC = 0 ;                 FTM0_C0SC = FTM_CnSC_MSB_MASK |FTM_CnSC_ELSA_MASK ;                 FTM0_C0V = 0;                 FTM0_C0V = MODdata>>1;                 FTM0_MOD=MODdata;                 FTM0_SC |=FTM_SC_CLKS(1) | FTM_SC_PS(5) | FTM_SC_TOIE_MASK                 enable_irq(17); //enable interrupt } MODdata can choose the different Stepper motor speed, eg, 150 round/minute, MODdata is 38. (2) interrupt service function void FTM0_IRQHandler(void) {                                 FTM0_SC  &= ~FTM_SC_TOF_MASK;//clear the TOF flag. roundcount++;                 if(roundcount >= 64000) {FTM0_C0SC = 0x00; FTM0_SC &= ~(FTM_SC_TOIE_MASK);} } It can used for the step counter, and when reach the 10round, then stop the motor( stop the FTM output). (3)Speed choose with UART input void Motor_Speed_GPIO_CTRL_30round(void) {                 char motormode=0;                 uint32 COMPDATA=0;                                 printf("\n 1 for 150 round/minute\n\r");                 printf("\n 2 for 110 round/minute\n\r");                 printf("\n 3 for 80 round/minute\n\r");                    printf("\n 4 for 50 round/minute\n\r");                    printf("\n 5 for 0.1 round/minute\n\r");                 motormode = UART_getchar(PC_TERM_PORT);                                     switch(motormode)                                 {                                    case '1':                                                       STEEPMOTOR_PWM_Init(38);//150 round/minute                                                         break;                                   case '2':                                                       STEEPMOTOR_PWM_Init(52);//110 round/minute                                                         break;                                   case '3':                                                                       STEEPMOTOR_PWM_Init(72);//80 round/minute                                                          break;                                   case '4':                                                                       STEEPMOTOR_PWM_Init(116);//50 round/minute                                                         break;                                   case '5':                                                                       STEEPMOTOR_PWM_Init(58592);//0.1 round/minute                                                         break;                                                                                default: break;                                 }                                 while( roundcount < 64000 ) {} //10 round                                 Disable_PWM;                                 printf("\n %c 10round PWM is finished ", motormode);                                 roundcount=0; } 5 DEMO About the test code, please find it from the attachment.
View full article
I’ve noticed some comments about Kinetis MCUs availability and status that I’d like to address for the entire community. The Kinetis MCU portfolio has seen significant growth in the mass market and is on track for continued strong growth in the coming years. Due to this growth, the demand on the Kinetis MCUs has outstripped the available supply, leading to extended leadtimes.  We have invested additional resources across the manufacturing line for 2018 and beyond to increase overall capacity and are pleased to be able to communicate that the lead time is being reduced from 39 weeks to low 30's this month.  It is anticipated there will be further reduction in Q3 2018 with a target of being back to a typical 12-14wk lead time in Q1 2019.  Additionally, we have increased our product longevity commitment on Kinetis K, L, E, V, M and W MCUs to 15 years to support the strong pipeline of design-in activity across the Kinetis portfolio that we are seeing in the market.  This document was generated from the following discussion: Kinetis Availability &amp; Longevity
View full article
分享自China-FAE team同事,在此谢过! 有客户需要bootloader功能,于是从网上下到最新版本的AN2295,发现里面添加了很多的内容,包括支持了很多新的器件,比如KM系列,但是真正把它在板子上跑起来,却花了2天时间,为了减少大家工作量,不在重蹈覆辙,我在这里share给大家,目前该代码在FRDM_KL25以及TWR-K60D100M上跑起来了。遇到的问题主要有如下几点: 问题1: 在工程中使用除法命令: a =a /100; 会报错: Error[Li005]: no definition for "__aeabi_uidiv" [referenced from D:\Customer\XinRuiYang\an2295sw_Kl25\src\Kinetis\IAR_6_4\Kinetis L Debug\Obj\bootloader.o] 原因是: 这里Lib选择的是None,说明没有使用任何库,所以不能使用除法。 打开库后,可能会占用比较大的空间,所以不推荐使用。 问题2: FRDM_KL25使用默认代码频率,波特率有问题,发送data = 0但是实际发送值为0x80,通过更改主频为48M,然后分频解决。附件有参考代码。TWR-K60100DM没有此问题。 问题3: FRDM_KL25板子,如果不使能BOOTLOADER_AUTO_TRIMMING这个宏,即不调用SlaveFrequencyCalibration();函数时, 代码上电不能直接运行,而使能该函数后,会一直进行校准频率,上位机无法通讯,查找代码发现: 上版代码为         #if BOOTLOADER_AUTO_TRIMMING == 1                       if(UART_GetChar() != BOOT_CMD_ACK)              {                SlaveFrequencyCalibration();              }                                        #endif 本版代码为:         #if BOOTLOADER_AUTO_TRIMMING == 1                         SlaveFrequencyCalibration();                     #endif 修改为上版代码,可以正常运行并跑起来。 但是不使能BOOTLOADER_AUTO_TRIMMING这个宏,代码依旧跑不起来,现象就是仿真时没有问题,可以正常跑起来,但是如果是上电直接运行,就不能正常通讯: 这个问题出在了USB插拔瞬间,KL25会收到一个数据,该数据并不是上位机下发的FC码,如果不使能BOOTLOADER_AUTO_TRIMMING这个宏,代码会误认为自己进入 等待上位机下发数据的状态机,导致通讯错误。在SlaveFrequencyCalibration(); 函数中,有软件复位功能,会让插拔稳定后KL25不在接收到异常数据,以此保证状态机的正确。 问题4: 仿真时全速跑起来时,指针经常回到__main,说明波特率有问题,代码进入SlaveFrequencyCalibration中,复位了。 AN2295引导MQX Keil工程 AN2295的文档已经说明如何修改CW IAR的工程以便让Bootlaoder引导,但是没有Keil工程的说明,这个就只能自己动手啦。 首先肯定会想到修改scf文件: #define USERFLASH_BASE_ADDR    0x00060000 #define INTFLASH_BASE_ADDR     0x00000000 #define INTFLASH_SIZE          (USERFLASH_BASE_ADDR - INTFLASH_BASE_ADDR) #define MY_ALIGN(address, alignment) ((address + (alignment-1)) AND ~(alignment-1)) LOAD_REGION_INTFLASH INTFLASH_BASE_ADDR INTFLASH_SIZE {     VECTORS INTFLASH_BASE_ADDR     {         vectors.o (.vectors_rom,+FIRST)         vectors.o (.cfmconfig)     }     CODE +0     {         * (InRoot$$Sections)      ; All library sections for example, __main.o,                                   ; __scatter*.o, __dc*.o, and * Region$$Table         * (KERNEL)         * (TEXT)         * (+RO)     }     RAM_VECTORS 0x1FFF0000 ; For ram vector table. Used when  MQX_ROM_VECTORS is set to zero.     {         vectors.o (.vectors_ram)     }     NOUSER +0     {         * (.nouser)     }     ROUSER MY_ALIGN(ImageLimit(NOUSER), 32)     {         * (.rouser)     }     RWUSER MY_ALIGN(ImageLimit(ROUSER), 32)     {         * (.rwuser)     }     DATA MY_ALIGN(ImageLimit(RWUSER), 32)     {         * (+RW)         * (+ZI)     }     USB_BDT MY_ALIGN(ImageLimit(DATA), 512)     {         * (.usb_bdt)     }     KERNEL_DATA_START MY_ALIGN(ImageLimit(USB_BDT), 0x10)     {         * (KERNEL_DATA_START)     ; start of kernel data     }     KERNEL_DATA_END 0x2000FFF0      ; RAM_END     {         * (KERNEL_DATA_END)     ; end of kernel data     }     ; mem_init writes a storeblock_struct at the end of kernel data,     ; max size 32 bytes, so use 0x100 offset     BOOT_STACK_ADDR 0x2000FEF0     {         * (BOOT_STACK)     } } 都是按偏移算的,应该只改INTFLASH_BASE_ADDR     0x00004000就O了,找了个最简单的工程:mqx\examples\hello,编译生成S19文件,通过bootloader下载进片子, 按reset后看屏幕,始终木有出现hello world,没办法,只能上debug了。 打开AN2295工程,加载调试环境,然后在JumpToUserApplication函数上下断点,中断后,单步执行到在__asm("mov pc, r1"); 函数,继续在汇编窗口点单步执行,之后就完全跟crack有点类似,一直点,直到芯片复位,说明之前点那一下是key point,然后对照map文件,于是找到了复位点: init_hardware->_bsp_initialize_hardware->_bsp_watchdog_disable();执行后会复位 不管啦,直接把它屏蔽掉,反正之前就已经关闭看门狗了。 重新编译,继续上。 还是没看到期待已久的hello world,肿么办? 重复上面的方法,发现又一个key point: _sched_start_internal 查看代码发现,这是一个系统call,应该是从vector 11调用的,查看下寄存器: SCB_VTOR 肿么变成0了,bootloader中已经改成0x4000了,什么时候变成0了....... 代码太多了,不知道从哪儿看起,内存断点是个好东西哈,IAR中没找见在哪儿下,算了,换Keil吧。 用Keil打开AN2295工程,加载调试,然后在0xE000ED08(SCB_VTOR )下写断点,直接run,等待中断吧: _time_set_timer_vector函数修改了SCB_VTOR, 大概路径是_bsp_enable_card->BSP_INTERRUPT_VECTOR_TABLE->BSP_TIMER_INTERRUPT_VECTOR 哈哈,找代码看看: __VECTOR_TABLE_ROM_START 是这个宏搞的鬼。 仔细对比代码,发现__VECTOR_TABLE_ROM_START 这个宏是通过条件编译区分开的,IAR是通过icf文件定义的 而Keil是通过#define 来实现的。好了,修改对应的值为0x4000,重新编译,下载,搞定,可以看到hello world喽。 总结一下,使用AN2295引导MQX Keil工程需要做以下3点修改: 1.scf文件INTFLASH_BASE_ADDR     0x00000000改为0x00004000 2.屏蔽_bsp_watchdog_disable()该函数 3.修改__VECTOR_TABLE_ROM_START为0x00004000.
View full article
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)
View full article
Hi, all The default AN2295 UART bootloader doesn't work well on K21/other Kinetis because of using FEI and complicated autocalibration mechanism. I made a simple version to make it works on MK21DX128VMC5, FYI. Readm.txt: UART bootloader for K21. (Default is MK21DX128VMC5) 128KB_Pflash_64KB_Dflash.icf is application link script example for MK21DX128 used together with UART bootloader, UART bootloader use 0x0 - 0xFFF. Q: Why need this patch? A: The original AN2295 use internal RC and FLL output as system clock. The calibration mechanism is not stable. The main change of this patch is to use external cystal plus PLL as system clock to communicate with PC software. Changes to AN2295 1) Add MK21D5.h for K21 support 2) Add AN2295_TWR_K21_cfg.h for K21 support(Copy from AN2295_TWR_K60_cfg.h) 3) AN2295_TWR_K21_cfg.h    1> #define KINETIS_MODEL K21_50MHz    2> #define KINETIS_FLASH FLASH_128K    3> #define BOOT_UART_BASE UART2_BASE_PTR       #define BOOT_UART_GPIO_PORT PORTE_BASE_PTR       #define BOOT_UART_GPIO_PIN_RX   17       #define BOOT_UART_GPIO_PIN_TX   16    4> #define BOOT_PIN_ENABLE_NUM        7 4) Add mcg folder and mcg.c/mcg.h 5) kinetis_params.h:    1> Modify SRS_REG/SRS_POR_MASK/INIT_CLOCKS_TO_MODULES to meet MK21D5.h    2> Add PORT_PCR_PS_MASK for BOOTLOADER_PIN_ENABLE_INIT to enable Pull-up. 6) bootloader.h: #define BOOT_WAITING_TIMEOUT 500. PC software can't communicate to bootloader if only 1s delay. 7) bootloader.c:    1> #include "mcg.h"    2> Use 25MHz PEE:       SIM_CLKDIV1 = ( 0    | SIM_CLKDIV1_OUTDIV1(1)                            | SIM_CLKDIV1_OUTDIV2(1)                            | SIM_CLKDIV1_OUTDIV4(1));             (void)pll_init(8000000,       /* CLKIN0 frequency */                      LOW_POWER,     /* Set the oscillator for low power mode */                      CRYSTAL,       /* Crystal or canned oscillator clock input */                      4,             /* PLL predivider value */                      25,            /* PLL multiplier */                      MCGOUT);       /* Use the output from this PLL as the MCGOUT */    3> Restore to FEI mode before jump to Application:       pee_pbe(8000000);       pbe_fbe(8000000);       fbe_fei(32768); Knowing issues: 1) Don't use virtualCOM from OSJTAG, it's very hard to communicate with PC software. Use RS232 in TWR-SER2. 2) BOOTLOADER_CRC_ENABLE must be 0, otherwise PC software will report unknown protocol version
View full article
1 Abstract      LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive multiplex networks. LIN is based on the UART/SCT protocol. It can be used in the area of automotive, home appliance, office equipment, etc. The UART module in NXP kinetis L series contains the LIN slave function, it can be used as the LIN slave device in the LIN bus. Because there is few LIN slave KL sample code for the customer’s reference in our website, now this document mainly take KL43 as an example, explain how to use the FRDM-KL43 board as the LIN slave node to communicate with the LIN master device. LIN master use the specific LIN module: PCAN-USB Pro FD. Master send the publisher ID and subscriber ID, slave give the according LIN data response. This document will share the according code, hardware connection and the test result. 2 LIN bus basic knowledge review         For the convenient to understand the LIN bus, this chapter simply describe the basic knowledge for LIN bus. Mainly about the LIN topology and the LIN frame. 2.1 LIN bus topology structure       LIN bus just use the simple low cost single-wire, it uses single master to communicate with multiple slaves. The bus voltage is 12V, the speed can up to 20 kbit/s. LIN network can connect 16 nodes, but in the practical usage, normally use below 12 nodes. Figure 2-1. LIN bus topology 2.2 LIN bus frame structure          LIN Frame consists of a header (provided by the master task) and a response (provided by a slave task).     Master send publisher frame: Master send header+ data +checksum; slave just receive.     Master send subscriber frame: Master send header; slave receive send data +checksum.     The following figure is the structure of a LIN frame: Figure 2-2. LIN frame structure      LIN frame is constructed of one Break field, sync byte field (0X55), PID, data and checksum. 2.2.1 Break filed and break delimiter Break filed is consist of break and break delimiter. Break should at least 13 nominal bit times of dominant value (low voltage). The break delimiter shall be at least one nominal bit time long (high voltage). Figure 2-3. break field 2.2.2 Sync byte field Sync is a byte field with the data value 0X55. The byte field is the standard UART protocol. Figure 2-4. The sync byte field 2.2.3 Protected identifier field A protected identifier field consists of two sub-fields: the frame identifier and the parity. Bits 0 to 5 are the frame identifier and bits 6 and 7 are the parity.     ID value range: 0x00-0x3f, 64 IDs in total. It determine the frame categories and direction. Figure 2-5. The sync byte field P0 = ID0 xor ID1 xor ID2 xor ID4 P1 = -(ID1 xor ID3 xor ID4 xor ID5) -is NOT。  ID can be split in three categories:   Frame categories Frame ID Signal carrying frame Unconditional frame 0x00-0x3B Event triggered frame Sporadic frame Diagnostic frame Master request frame 0x3c Slave response frame 0x3d Reserved frame   0x3e,0x3f     2.2.4 DATA       A frame carries between one and eight bytes of data. The number of data contained in a frame with a specific frame identifier shall be agreed by the publisher and all subscribers.      For data entities longer than one byte, the entity LSB is contained in the byte sent first and the entity MSB in the byte sent last (little-endian). The data fields are labeled data 1, data 2,... up to maximum data 8. 2.2.5 checksum  The checksum contains the inverted eight bits sum with carry over all data bytes or all data bytes and the protected identifier.        Classic checksum: Checksum calculation over the data bytes. Enhanced checksum: Checksum calculation over the data bytes and the protected identifier byte.  Method: eight bits sum with carry is equivalent to sum all values and subtract 255 every time the sum is greater or equal to 256, at last, the sum data do bitwise invert.  In the receive side, do the same sum, but at last, don’t do invert, then add the received checksum data, if the result is 0XFF, it is correct, otherwise, it is wrong. 3 KL43 LIN slave example    This chapter use KL43 as the LIN slave, and communicate with the specific LIN master device, realize the LIN data sending and receiving. 3.1 Hardware prepare Hardware: FRDM-KL43,TRK-KEA8,PCAN-USB Pro FD       LIN bus voltage is 12V, but the FRDM-KL43 don’t have the LIN transceiver, so we need the external LIN transceiver connect the KL43 uart, to realize the LIN voltage switch. Here we use the TRK-KEA8 on board LIN transceiver MC33662LEF for the KL43. The MC33662LEF circuit is like this:    Figure 3-1. LIN transceiver schematic 3.1.1 FRDM-KL43 and TRK-KEA8 connections      FRDM-KL43 need to connect the UART port to the LIN transceiver. The connection shows in this table: No. FRDM-KL43 TRK-KEA8 note 1 J1-2 J10-5 UART0_RX 2 J1-4 J10-6 UART0_TX 3 J3-14 J14-1 GND 3.1.2 TRK-KEA8 and LIN master connections         LIN bus is using the signal wire.  TRK-KEA8 J14_4 is the LIN wire, it should connect with the LIN wire in PCAN-USB Pro FD. GND also need to connect together.        TRK-KEA8 P1 need a 12V DC supplier. Master also need 12V DC supplier. 3.1.3 Object connection picture   Figure 3-2. Object connections 3.2 Software flow chart and code      Now describe how to realize the LIN master and the LIN slave data transfer. LIN master send a publisher frame, the slave will receive the according data. LIN master send a subscriber frame, the slave will send the data to the master. The code is based on the KSDK2.2_FRDM-KL43 lpuart, add the LIN operation code.  3.2.1 Software flow chart         Figure 3-3. Software flow chart   3.2.2 software code     Code is based on KSDK2.2_FRDM-KL43 lpuart project, add the LIN operation code, the added code is list as follows: void LPUART0_IRQHandler(void) {      if(LPUART0->STAT & LPUART_STAT_LBKDIF_MASK)      {        LPUART0->STAT |= LPUART_STAT_LBKDIF_MASK;// clear the bit        Lin_BKflag = 1;        cnt = 0;        state = RECV_SYN;        DisableLinBreak;          }     if(LPUART0->STAT & LPUART_STAT_RDRF_MASK)      {                  rxbuff[cnt] = (uint8_t)((LPUART0->DATA) & 0xff);                  switch(state)          {             case RECV_SYN:                           if(0x55 == rxbuff[cnt])                           {                               state = RECV_PID;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_PID:                           if(0xAD == rxbuff[cnt])                           {                               state = RECV_DATA;                           }                           else if(0XEC == rxbuff[cnt])                           {                               state = SEND_DATA;                           }                           else                           {                               state = IDLE;                               DisableLinBreak;                           }                           break;             case RECV_DATA:                           recdatacnt++;                           if(recdatacnt >= 4) // 3 Bytes data + 1 Bytes checksum                           {                               recdatacnt=0;                               state = RECV_SYN;                               EnableLinBreak;                           }                           break;          default:break;                                    }                  cnt++;      }     } void uart_LIN_break(void) {     LPUART0->CTRL &= ~(LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);   //Disable UART0 first     LPUART0->STAT |= LPUART_STAT_BRK13_MASK; //13 bit times LPUART0->STAT |= LPUART_STAT_LBKDE_MASK;//LIN break detection enable LPUART0->BAUD |= LPUART_BAUD_LBKDIE_MASK;         LPUART0->CTRL |= (LPUART_CTRL_TE_MASK | LPUART_CTRL_RE_MASK);     LPUART0->CTRL |= LPUART_CTRL_RIE_MASK;     EnableIRQ(LPUART0_IRQn);    } int main(void) {     uint8_t ch;     lpuart_config_t config;     BOARD_InitPins();     BOARD_BootClockRUN();     CLOCK_SetLpuart0Clock(0x1U);     LPUART_GetDefaultConfig(&config);     config.baudRate_Bps = BOARD_DEBUG_UART_BAUDRATE;     config.enableTx = true;     config.enableRx = true;     LPUART_Init(DEMO_LPUART, &config, DEMO_LPUART_CLK_FREQ);     uart_LIN_break();     while (1)     {        if(state == SEND_DATA)        {           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X01;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X02;           while((LPUART0->STAT & LPUART_STAT_TDRE_MASK) == 0); // hex mode                   LPUART0->DATA = 0X10;//Checksum   0X10 correct, 0xaa is wrong           recdatacnt=0;           state = RECV_SYN;           EnableLinBreak;        }     } }     4 KL43 LIN slave test result   Master defines two frames: Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c    Now, master send 0X2C and 0X2D data, give the test result and the according waveform. 4.1 LIN master configuration Uart baud rate is: 9600bps 4.2  Send ID 0X2C and 0X2D frame       From the PC software of LIN master, we can find 0X2D ID can send the data successfully, and 0X2C ID can receive the correct data (0x01, 0x02) and checksum (0x10) from the KL43 LIN slave side. 4.2.1 0X2D ID frame oscilloscope waveform and debug result      From the debug result, we can find the buff can receive the correct ID, data and checksum from the LIN master.    4.2.2 0X2C ID frame oscilloscope waveform 4.2.3 0X2C ID SLAVE send back the wrong checksum     From the PC software, we can find if the KL43 code modify the checksum to the wrong data 0XAA, then the PC software will display the checksum error. This is the according oscilloscope waveform for the wrong checksum data. From all the above test result. We can find, KL43 as the LIN slave, it can receive the correct data from the LIN master, and when LIN master send the subscriber ID, kl43 also can send back the correct LIN data to the master. More detail, please check the attached code project. BTW, LIN spec can be downloaded from this link: http://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf   Attached is the code and the pdf version of this document:                  
View full article
Fast Startup Guide for Freescale MCU, wirtten by China IMM FAE team for mass market users.
View full article
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.     
View full article
ROM Bootloader KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports. When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash. The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader. For example:       When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;       When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application). There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT]  = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0. blhost utility application The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder. About how to use blhost application, please check KBLHOSTUG document for more detailed info. Call Rom Bootloader from customer application In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example. Set a signal for application code to call the ROM bootloader, such as press a button. In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader. //Initalize PTEC3 as GPIO button PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL); GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3); The bootloader entry point for customer application to call the ROM bootloader.  //prototype of the entry point definition void run_bootloader(void * arg); //Variables uint32_t runBootloaderAddress; void (*runBootloader)(void * arg);   // Read the function address from the ROM API tree. runBootloaderAddress = **(uint32_t **)(0x1c00001c); runBootloader = (void (*)(void * arg))runBootloaderAddress; in <main.c> routine to call the ROM bootloader:   while (1)   {     if ((GPIOC_PDIR & (1 << 3)) == 0)     {       // Start the bootloader. runBootloader(NULL);     }   } Press SW3 button of FRDM-KL43Z board will call ROM bootloader.  Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0. In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43. When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product. More detailed info, please check attached demo code. BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.
View full article
下面简单介绍下Kinetis M0+相关的几大系列MCU: 1. Kinetis L    Kinetis L系列MCU的最大特点是它具有非常出色的低功耗特性,L系列目前包含KL0X、KL1X、KL2X、KL3X、KL4X和KL8X六个子系列,除了KL8X的主频为72 Mhz以外,其他主频都为48 Mhz。KL0X系列是入门级MCU,它的Flash相对较小,引脚数量相对较少。KL1X系列是通用型MCU,KL2X系列带有USB功能,KL3X系列支持段式LCD,KL4X系列同时带有USB和支持段式LCD。KL8X系列具有很多Security相关的特性,包括篡改检测、真正的随机数生成器和低功耗可信加密引擎,支持AES、DES、3DES、SHA、RSA和ECC。 2. Kinetis E    Kinetis E系列MCU的最大优势是电磁抗噪性能,Kinetis E系列是业界首款在Cortex M0+基础上构建5V (2.7~5.5V)MCU系统的产品,结合了低成本、高性能、先进的EMC和ESD保护功能,E系列目前包括KE02、KE04和KE06三个子系列,KE02主频有20M和40M两种,KE04和KE06都为48M,KE06相比KE02和KE04主要是多了1个CAN接口。 3. Kinetis V    Kinetis V系列MCU专为BLDC、PMSM和ACIM电机控制以及数字电源转换应用而设计。V系列目前包含KV1X、KV3X、KV4X和KV5X四 个系列,其中Kinetis KV1X系列是入门级产品,Cortex-M0+内核,采用75 MHz M0+内核及硬件平方根和除法模块,与同等级32位MCU相比,在无传感器PMSM控制应用中的性能提高27%。 4. Kinetis W Kinetis W系列集成了领先的Sub-GHz和2.4 GHz射频收发器,可创建可靠、安全、低功耗的嵌入式无线解决方案。W系列目前包含KW0X、KW2X 、KW3X和KW4X四个系列,其中KW0X是M0+内核,48 Mhz,Sub-GHz无线电,超低功耗无线微控制器,KW3X是M0+内核,48 Mhz,具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1射频连接。KW4X也是M0+内核,具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1和IEEE® 802.15.4-2011射频连接。 5. Kinetis M      Kinetis M系列 MCU适用于单芯片1、2和3相电表和流量计,以及其它高精度测量应用。M系列目前包括KM1X、KM2X两个系列,KM1X主要用作计量,KM3X不仅具有计量功能,同时还有段式LCD控制器。 选型的方法主要有以下几种: 1)如果您已经知道要查找的产品的基本信息,最常用的方法是在飞思卡尔官网主页进行查找; 2)如果您并不清楚需要查找的芯片基本信息,飞思卡尔还提供了一些辅助的选型工具来帮助用户进行芯片的选型,包括:i)参数选型工具;   ii)选型神器Cross Check;  iii)解决方案顾问; 具体的选型操作流程可以参考:针对飞思卡尔单片机的快速上手指南中的2.2小节,其中有非常详细的介绍。
View full article
Basic baremetal example to use I2C registers configuration. Original code obtained from TWR-K64F, usable on FRDM-K64F with adjustment. I hope it's useful.
View full article