Freescale Semiconductor is to demonstrate its Kinetis L series microcontrollers (MCUs) built on the ARM Cortex-M0+ processor at DESIGN West in San Jose, California, with alpha sampling due to start in the second quarter of 2012. Freescale  says the ability to demonstrate these devices is possible due to its  close partnership between ARM during the Cortex-M0+ core development  process and as a lead partner provided  input that helped ARM define and  develop the processor. The devices are slated for applications  such as domestic appliances, portable medical systems, smart meters,  lighting, power and motor control systems. "Our close partnership  with ARM throughout the design and development of their new core has  positioned us as the first MCU supplier to produce and demonstrate an MCU based on the Cortex-M0+ and continues our strategy of driving to  market new products based on the ARM architecture," said Reza  Kazerounian, senior vice president and general manager of Freescale’s  Automotive, Industrial and Multi-Market Solutions Group. Mike  Inglis, executive vice president and general manager of ARM’s Processor  Division, added "With the addition of the L series to their Kinetis  line, Freescale is creating one of the industry’s broadest, most  scalable ARM Cortex-M MCU portfolios, ranging from very low-cost,  entry-level products based on the ARM Cortex-M0+ processor, up to 4 MB,  200 MHz devices based on the Cortex-M4 processor." Manufactured  using Freescale’s low-leakage, 90 nm thin film storage (TFS) process  technology, the Kinetis L series will have a selection of on-chip flash  memory densities and analog, connectivity and HMI peripheral options. Upward  migration through the Kinetis portfolio is available via compatible Kinetis K series devices (built on the ARM Cortex-M4 processor) that  provide access to DSP performance and advanced feature integration. The  ARM Cortex-M0+ processor includes a reduced two-stage pipeline,  allowing faster branch instruction execution, single-cycle access to I/O  and critical peripherals, optimized access to program memory, linear 4  GB address space that removes the need for paging, reducing software  complexity and ensuring a more 8-bit-like user experience and a micro  trace buffer, providing a low-cost trace solution that allows faster bug  identification and correction without the need for additional I/O  resources. Freescale will demonstrate the ARM Cortex-M0+ core at its exhibition booth #1604 at DESIGN West , March 26-29 at the San Jose McEnery Convention Center.

Freescale's Jeff Bock highlights the awesome features of the Kinetis 32-bit microcontrollers based on the ARM Cortex-M4 core

by: Carlos Musich, Luis Garabito Microcontrollers Application Engineers with Freescale. This application note is intended to demonstrate http client implementation using Freescale MQX RTOS capabilities. The hardware used to illustrate this is the TWR-K60N512-KIT. The remote controlling and monitoring have become a need rather than an option in the embedded world. This application note takes advantage of two social media interfaces for these purposes. One is used to enter commands to the MCU; http://twitter.com/. The other one is used to pull out data from the MCU; https://www.supertweet.net/. It is important to focus in the fact that with these methods the MCU is reachable through Internet without the need of a public IP address or without mounting a HTTP server in the MCU. The application source code described in this document can be found in the AN4417SW.zip file. For a full description of Freescale MQX RTOS, please visit https://www.freescale.com. This application defines two tasks in MQX. The first task is main. It is meant to configure GPIO, the RTCS and create the second task. The name of this second task is httpclient. The purpose of this task is to carry out the communication with the Twitter server and read the commands to be executed. To retrieve the input commands, the httpclient task reads them from the last tweet published by a specific Twitter account. The command then is parsed and executed according to the implementation. The main task enters into an infinite loop where the httpclient is restarted in each loop to allow a cycle behavior for reading commands. The time for each loop is controlled by a sample rate value that can be configured by the user via a command. Get the full application note...

This application note provides guidelines on Kinetis K53 family for using the internal Operational Amplifiers (OPAMP), Transimpedance Amplifiers (TRIAMP), and the Analog-to-Digital Converter (ADC) modules to measure the temperature through a thermocouple and a thermistor and the result is shown on a LCD display using the LCD Controller (LCD) module. All these modules are available on the K53 MCU. The application uses different OPAMP configurations, such as internal gain and external gain using external resistor. TWR-K53N512 board was used as base hardware for performing this application. Watch the Freescale Kinetis K53 family in action. The internal Operational Amplifiers (OPAMP), Transimpedance Amplifiers (TRIAMP), and the Analog-to-Digital Converter (ADC) modules are used to measure the temperature through a thermocouple and a thermistor. The result is shown on a LCD display using the LCD Controller (LCD). Get the full Application Note

Symptoms As we know: Flash must be programmed after an erase operation. Violation of this rule will cause programming fail and even hardfault(when AHB reading) on Kinetis K64 parts. Customer accidently uses SDK’s API programming same sector twice(over-programming) without an erase operation. Then when perform AHB reading of this sector(include using JFLash to read this sector), an Hardfault occurs. Diagnosis K64 flash has internal ECC on each sector. When over-programming happens, ECC will be crushed and trigger Hardfault when AHB reading of this sector. Solution Using SDK API FLASH_VerifyErase to check if this sector is erased. Call FLASH_VerifyErase every time before you want to program the flash. This problem will impact all Kinetis device which has FTFE flash module.   Thanks for Alex Yang provide the material.

Making and Downloading Security Image for Kinetis Device   Introduction KINETIS devices have Flash base bootloader or ROM bootloader. They have same structure and same download tools. MCUBOOT shows supported device. The bootloader not only support plaintext image, but also encrypted image which is encrypted by AES. This can protect user’s application code from unauthorized using. Due to different internal Flash structure, security image making, key download and image download flow is a bit different to each Kinetis devices. This hands-on will introduce Flash base bootloader and ROM base bootloader security image making and downloading.   2 Security image to Flash bootloader Many NXP Kinetis device SDK have integrated bootloader. Take FRDM-K64F as example, the bootloader project is in SDK_2.8.0_FRDM-K64F\boards\frdmk64f\bootloader_examples\freedom_bootloader The bootloader support security format image by default. User can download security format image via UART and USB interface. In K64 bootloader, the key is stored in 0xb000. But the application code is start from 0xa000. That means each time the application is upgraded, key file need to be download again.   2.1 Generate key The elftosb tool can generate a key. But of course, you can take any string as key.     2.2 Image encryption Use the key to encrypt application image. Here is the bd file. options {  flags = 0x4; // 0x8 encrypted + signed, 0x4 encrypted  buildNumber = 0x1;  productVersion = "1.00.00";  componentVersion = "1.00.00";  keyCount = 1; }   sources {  inputFile = extern(0);  sbkey = extern(1); }   section (0) {  erase 0xa000..0xF6000; load inputFile > 0xa000; }       2.3 Download key and image Connect FRDM-K64F openSDA usb port. Then download key and image.     2.4 Download key with KinetisFlashTool Use keyboard to input key is really annoying. There is a GUI tool named KinetisFlashTool which can download image same as blhost.exe. To download encrypted image by this tool, we can make a sb file to download key first. Here is the bd file.   sources { } section (0) {        erase 0xb000..0xc000;        load {{E0BAA2C8231283CAF1D327CEDB82AFF9}} > 0xb000; }   Using elftosb to generate the sb file. The elftosb command line is as below \>Elftosb -V -c program_key.bd -o program_key.sb   This sb file should be download at first, then download the encrypted application image. When customer want to download security image via USB MSC or HID, this is the only way to download key. There is a limitation in those bootloader which version is lower or equal to v2.7.0. MSC function and HID function can’t be enabled together. Otherwise bootloader will fail when copy encrypted sb file to MSC disk.   2.5 About the key But it is really strange that key file should always come with encrypted file. It is reasonable to keep the key in secure status, for example, an untouched place in flash. K64 has a program once field which is located in program flash IFR. This is a standalone space different from main space. It’s address is from 0x3C0 to 0x3FF. MCU core can read or write this area by special flash command. We can put the AES key here. Again, we can use sb file to download this key. sources { } section (0) {        load ifr 0xE0BAA2C8 > 0x3c0;        load ifr 0x231283CA > 0x3c1;        load ifr 0xF1D327CE > 0x3c2;        load ifr 0xDB82AFF9 > 0x3c3; } Then we should modify sbloader_init() in sbloader.c. The source code only read key form 0xb000. We should have it read key from IFR.   Security image to ROM bootloader Some Kinetis device has ROM bootloader. They are different with flash base bootloader. This document use FRDM-K32L2A as example.   3.1 Generate AES key and download the key The key can be set as 0x112233445566778899aabbccddeeff00. Besides sb file, it can also be programmed to IFR by blhost command. \>blhost -p COM9 – flash-program-once 0x30 4 11223344 msb \>blhost -p COM9 – flash-program-once 0x31 4 55667788 msb \>blhost -p COM9 – flash-program-once 0x32 4 99aabbcc msb \>blhost -p COM9 – flash-program-once 0x33 4 ddeeff00 msb If you do not write anything to IFR, the ROM bootloader will use all-zero key. Here I use all-zero key.   3.2 Encryption algorithm The ROM bootloader hasn’t encryption algorithm. Application should include algorithm code and assign the address to bootloader, or preprogram BCA table and MMCAU code into flash. You can find MMCAU code (mmcau_cm0p.bin) and BCA(BCA_mmcau_cm0p.bin) table in MCUBoot2.0.0 package. Before you program these code into flash, new address must be written into it. For example, we put MMCAU code into 0x7f800, then we should modify the BCA table as below     And then, according this new address, modify the MMCAU_function_info structure in mmcau_cm0p.bin.   After that, download BCA to 0x3c0 and mmcau_cm0p.bin to 0x7f800.   In order to avoid using manual operation in production, above steps can be integrate in a single sb file.   3.3 Encrypt the image and download The bd file in K64 example can be reused, just need to change the image address to 0x00.   Press the reset button, after 5 second, the led will blink.   References: Kinetis Bootloader v2.0.0 Reference Manual Kinetis Elftosb User's Guide Kinetis Bootloader QuadSPI User's Guide Kinetis blhost User's Guide