Essentials of MQX RTOS Application Development Free Online Training Series with Videos, Tutorials, and Example Software! 10-Part Series - even more coming later [Scroll down to see all Sessions] Session 1: MQX Architecture and Initialization (20 min) Creating tasks Setting priorities Scheduling Synchronization concepts Introduction to drivers Session 2: Designing for a Multi-Tasking Environment (15 min) Writing applications in a Multi-Tasking Environment Super Loop Programming Limitations, Task Coding Structure Task States What is a blocking call? Task Context Switching Session 3: Task Management and the Scheduler (21 min) How does the MQX scheduler work? Scheduling Policies Priority-based, Time-slice (Round Robin) Selecting Priority Levels for Tasks What is the Task Template List? Using Tasks in your Application Session 4: Synchronization and Message Passing (17 min) What is Synchronization?  What is it used for? Data Flow, Control Flow, Mutual Exclusion Synchronization Options Events, Semaphores, Mutexes, Message Passing Message Passing Types of Message Pools, Message Pool Creation, Sending and Receiving, Light-weight Message Passing Session 5: Introduction to Drivers (28 min) Driver Architecture and options Block vs. Byte modes, POSIX drivers, Low level drivers, Polled vs. Interrupt modes Driver Initialization I/O Subsystem (POSIX) Serial Driver Details Light-weight GPIO Driver Details Session 6: Interrupts (15 min) Interrupts and the scheduler Techniques for writing an ISR Hardware Vector Table Nested Interrupts MQX Interrupt ISR Table Installing ISRs Default Interrupt handler Session 7: Light Weight Events (15 min) Overview of events Working with light-weight & full-featured events Ways to wait on an event Session 8: Light Weight Timers (17 min) One shot vs periodic timers Use cases for timers Working with correlated timers Writing timer Interrupt Service Routines (ISRs) Light weight timers & timer queues Timers and the timer task Session 9: Light Weight ADC Driver (18 min) Light-weight ADC driver (LWADC) Details Attributes of ADCs Configuring and reading ADCs Scaling the ADC output Session 10: Logging (23 min) What is logging?  Why use logs? Working with light-weight logs Working with kernel logging Logging MQX function and ISR entries and exits, task and stack usage Working with full-featured logs

The MQX 4.0.2 BSP doesn't support VLPS mode out of box, and RXEDGE interrupt is not enabled either, so there are several steps to do before implementing the demo. modify user_config.h #define BSPCFG_ENABLE_TTYB                        0 #define BSPCFG_ENABLE_ITTYB                       1 MQX enables UART in polled mode by default, and here we enable the UART1 interrupt mode, the TTY port may vary depending on the platform. modify BSP_DEFAULT_IO_CHANNEL in twrk20d72,.h as below: #ifndef BSP_DEFAULT_IO_CHANNEL #if BSPCFG_ENABLE_ITTYB #define BSP_DEFAULT_IO_CHANNEL                      "ittyb:"    /* OSJTAG-COM   interrupt mode */ #define BSP_DEFAULT_IO_CHANNEL_DEFINED #else #define BSP_DEFAULT_IO_CHANNEL                      NULL #endif modify LPM_CPU_OPERATION_MODES[] in init_lpm.c as below: const LPM_CPU_OPERATION_MODE LPM_CPU_OPERATION_MODES[LPM_OPERATION_MODES] = { // LPM_OPERATION_MODE_RUN { LPM_CPU_POWER_MODE_RUN,                     // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_WAIT { LPM_CPU_POWER_MODE_VLPS,//LPM_CPU_POWER_MODE_VLPR,                    // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_SLEEP { LPM_CPU_POWER_MODE_WAIT,                    // Index of predefined mode LPM_CPU_POWER_MODE_FLAG_SLEEP_ON_EXIT,      // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_STOP { LPM_CPU_POWER_MODE_LLS,                     // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 LLWU_ME_WUME0_MASK                          // Mode wake up events from internal input sources - LPT } }; Here we map LPM_OPERATION_MODE_WAIT to VLPS mode add following code in _kuart_int_rx_tx_isr() from serl_int_kuart.c   if (sci_ptr->S2 & UART_S2_RXEDGIF_MASK)          {                     sci_ptr->S2 = UART_S2_RXEDGIF_MASK;                     sci_ptr->BDH &= 0xBF; /* clear RXEDGIE */          } so that RXEDG event is checked in _kuart_int_rx_tx_isr() for low power mode. replace main.c in "C:\Program Files\Freescale\MQX_4_0_2\mqx\examples\lowpower" with the attached one. After recompiling MQX libs as well as the low power demo, you may test the VLPS mode just as shown in the attached video.   Hope that helps, B.R Kan Original Attachment has been moved to: VLPS-test.7z.zip Original Attachment has been moved to: main.c.zip Original Attachment has been moved to: serl_int_kuart.c.zip Original Attachment has been moved to: user_config.h.zip Original Attachment has been moved to: init_lpm.c.zip

Flash memory is critical component to any system, and it’s important to be able to access flash memory efficiently. In this document, we will look at the differences between the two main types of flash used today, NAND flash and NOR flash, how to erase and access flash. Then we will look at the MQX flashx driver, which can be used for both types of flash. Accessing NOR and NAND Flash There are two main types of flash memory, the first being nor flash , and the second being nand. For an interface point of view, the main difference is how the data is accessed. Nor flash is a full address and data  bus, similar to random devices, and nand devices is using io bus with commands , address and data being multiplexed to share the same bus. It is greatly reduces the number of pins to require connectivity in devices , But for software and data access perspective , there are more significant differences between the two types of memory. At the core, each bit is storing using different tech knowledge. With nor flash , the memory region is divided by equal size units called blocks.  The size of each block in today’s technology ranges from roughly 32k bytes to 128 kbytes, but this is  totally dependent on the devices select and over the years this is changed.  The internal circuitry of nor flash allows each byte of the device can be individually addressable in the same way that you can address bytes stored in ram, or in an EEPROM and this is why a full bus is used with nor flash. However this only applies for reading a byte or programming an individual byte, the racing skimming must be done at the block level,  so unlock a  race state requires the entire block to be affected. Nand flash , however, has being purposely architected differently in order to increase the storage density.  It too has a memory region divided in equal size of  blocks, but each of these blocks are further broken down into samll regions that are called pages, the page is typically 2k bytes in size and a block often has 64 pages, so 128 kbytes , to the lead data you still be working at the block level, but if you want to read and program part of flash, this is done page by page. However storing or retrieving data one page at a time is actually an advantage for many applications. Since you are often working with a large files such as  a phone, a song or an app.  So this is can be more efficient. The main draw back then of not being able to access bytes  individually is that nand flash can’t  be used to store a program code that you want to be executed in place. Since a CPU needs to read a single instruction, unless your CPU can specifically support this arrangement. There are a couple of downsize that the nand flash you maybe aware of however,  the first is in getting bit errors when you reading a page,  this is may not be a disater for musical file but obviously not acceptable for a data file or a backup for your image. To compensate for this , each page of flash has two sections,  the first is where your data is stored and the second is a smaller section is where error correction code is stored. There are differenct algorithm used to detect and correct for errors but the ideal is the data stored in ecc is used by the algorithm to detect errors  in the data,  and in some cases  correct an error in the data  field.  There is a limit to how much corruption can be detected, but minor errors such as a single bit error are dealt with regular basis without the application ever knowing it occurred. The second issue with nand to be aware of that it is more prone to developing a faulty bit. And this is caused an entire block to be declared as being bad, in fact even a new flash device will have a small percentage of blocks bad and over time some of the active blocks can be come bad. Circuitry in the flash device detects the block’s bad during erase or progam cycle and a bad block manager keeps track of this . Blocks of bad are automatically remapped, and since this happens behind,  the interface of software  doen’t know the difference. So to summarize the key differences between nor and nand, we saw you have to access data in pages with nand which is randly access in bytes . and there are differences in access time to erase, write and read from flash. The capacity  the flash  device contiues to rise for writes that is a steady rate,  but currently the largest nand devices have 10 times capacity of largest nor devices. And in terms of issues don’t impact the application code, we saw the nand flash requries bad block management  and error correction codes to deal with failure rate that experiences, the pin count is higher in nor given a type of interfaces has, which couple of with different capacity makes it more expencsive. And depending on how you using memory you maybe concered about the expected life cycle  of a chosen device . Eraing Flash Before getting into the driver though, the only other thing to cover you may come across when working with the flash has to do with the erase process, you may expect to read back the erased portion of memory has been all zeros but in fact  the erased flash memory has all bits set to the high state, so it read back the erased byte as being FF. When you write data to your address location  , the corresponing bits need to be zero are programed as logical zero and efficiently you can rewrite this location with first erase it providing you unwanted any of these bits transition from 0 to 1.  You can also write to a different address in the same block without first erasing block,  but in most cases you writing a large chunk of data, not a single byte,  and typically you don’t want to bother keeping in track of data   as being where to written to .  And for block should be erased before  write or not. This is what the driver does for you, which keeps your application quite simple, however,  be aware the overhead associated with the right command won’t  always be consistant.  As you sometimes you endure an erase and rewrite cycle, and other times you won’t. Where Flashx Driver Resides There are two groups of drivers in MQX, the first group contains io drivers, go through the io subsystem.  And it includs block mode drivers and byte mode drivers . The second group is a set of low level drivers such as the ADC and the lightweight GPIO driver. Since flash driver supports the writing and reading data of large chunks, it is categorized as blocked mode driver . In the SDK verison of MQX, the io sub system is limited. But the flash driver is still be considered as block mode driver. Similar to the structure of other drivers we’ve looked at, there is an upper layer and lower layer component in the flash driver. and before you can begin using any dirver, it has to be installed. If you selected flash using a configuation file, MQX will automaticly install the flash driver at boot up.  And when you install function is called,  the upper level will install function is passed a pointer to the low level configuration information. The installed function registered it’s called back function to the IO subsystem, once it’s associations are in place , your application code can use a normal a high level calls that access the flash device.  So for example,  before using the flash driver , you must open it , which will set up internal structures for the flash chip if hasn’t been opened before.  And will fetching the addressing for this device . You can then read from flash or write to it as you like using the high level commands. Accessing Flash Before getting further with using the driver though, it will be helpful to see how to access the flash itself.  The flash is organized to a series of blocks and you can structure those in different groups.  If you are using a kinetis processor, and using the flashx driver to access the internal flash, then as a minimum you need have a room for code base and reserve a saparate area for your data. You can also set your flash for equal size banks or however you wish to organize your  flash,  just keeping in mind the boundaries of these regions must be falled into block boundaries in the    flash . Each of these regions are effectively  a partition of the flash and the flashx driver refer to each partition  is a file or see in a monent the region of a flash you use for a file may not be continuously from address point of view , but for application point of view it can be considered to be continuous memory space. Accessing Flash Mqx maitans an index into a file and when you read from the file, the reading starts from an index, similarly, when you write to the file, it starts writing from the  index point , and the index  commands , as you wirte more data. Your application code can  adjust the location index, using  the fseek function , you maybe familiar with the fseek function found in a formatted  io section of starndard C library , and mqx’s fseek function is used in the same way. It can be used to set the index to provide  the offset from the beginning of a file, with an offset from the end of this file  , or to an offset in either  direction from the current position of the index. Data structures To understand flashx driver how it works , you need to farmilar with some key data structures that it uses. The first one to cover is the block info structure which defines how the flash is organnized. Some flash has different size blocks inside of it or maybe there is gaps between addressing . So this is a way of define a flash infrastructure. Your device will be represented by an array  or a block info structures,  one section for each section a  flash has continuous addressing  and all blocks  are in equal size.  The terminal is a bit  confusing here,  within each section of flash  there will be a number of blocks,  and the data structure   refers to is a  sector,   as mqx considers a sector to be the smallest eraseable units. The next element of this structure is the starting address of this section which is followed by the size section. The final element is reserved for any special flags and currently not being used. You can have a number of files in flash, the file block structure is used to define  a file, and it cantains a name for the file , the starting address for the file, and an ending address for the file, And the third data structure called the init structure is used to tie everything together , this contains a pointer to a array of block info structure, and a pointer to a array of file block structures, this also contains the base address of the flash device and some additional elements used to access the total flash address base . Flash Driver API So to summarized before we look  at the driver code, accessing the flash is very straight forward.  You must open the file  with the fopen function , and with the flashx driver , flags are not typically used.  To read from the file , you speciafy with reading data to be stored , and the number of bytes to read. And to write the flash you should provide  a pointer to the data to be written, and the numbe of bytes to transfer. And the last function we used, is the ioctl function, which can be used to retrieve or change the various parameters. When you using the ioctl function, you specify the command you want to use. And a point to where the result will place if you request a value as parameter . So what source code can you make .  you can retriev various values,  such as the base address, or the number of sectors.  You can flush the buffer, or control the buffering feature, erase all or part of flash chip, control the sector caching, or control the write protect. This document is the 19th Installment of the "Essentials of MQX RTOS Application Development" training course. Please watch the vedio for more details Essentials of MQX RTOS Application Development, Ses|NXP

I have just implemented an I2C demo for my customer, he found no demo for MMA8451Q based on MQX 4.1, so I personally wrote one for him based on the I2C EEPROM demo, as well as the driver code for MMA8451Q supporting both polled and interrupt mode. I think maybe it would be interesting for someone else, so I posted it here. The demo is for TWR-K60D100M, but I think it should be easy to port to some platform else, for example , TWR-K21F120M, all you have to do is creating a new MQX project and replace the source code with the attached one, Please also note the I2C device address might be different in tower boards. You may change the deifintion of I2C_MMA8451_BUS_ADDRESS in MMA8451.h according to the schematics. Please kindly refer to the attached result.txt for more details. Hope that helps, B.R Kan

MQX Chinese User Manual

Store web pages externally step by step Web pages can be stored on any media accessible via MFS, such as USB memory stick, SD card. It is also possible to use FFS and store web pages on NAND flash. The following example is a step by step guide on how MQX can use nandflash on TWR-K70F120M, we start with the httpsrv demo. 1. Add FTP server  and nandflash flush support This demo starts with default HTTPSRV example, Shell console is enabled in the default httpdsrv.c. Ping, ipconfig and help commands are enabled by default. We add ftpsrv application to support FTP protocol , and nandflash support. 2. Allow RTCS for more sockets We will use two TCP servers. There is one socket need for HTTPSRV listening socket, second listening socket for FTP server. One socket for each connected client. 3 .Add MFS library to the HTTPSRV build project By default, MFS library is not enabled in the HTTPSRV project. It uses only TFS for web pages storage. We add path to MFS library into HTTPSRV build project   4. Add FFS support to the HTTPSRV build project Ffs library is not enabled by default. We need to add path into HTTPSRV build library. Install FFS driver and open it. 5. Resolve build errors When we try to build now the HTTPSRV example, we have compile errors. This is because by default the HTTPSRV example does not include MFS and FFS library head files. We need to add a path for MFS and FFS 6. Configure HTTPSRV root directory Web pages of this demo are to be stored in nandflash within web_pages folder. We need to set rootdir and index Before we can view the web page in browser, we need to copy web pages to nand flash. This is the purpose of FTP server, as one example how to copy files. If you wish to be sure the web pages survive power cycle, make sure you flush the FFS file system after “web_pages” are copied. 7. Build, Download, Execute As hardware we use TWR-K70F120M and TWR-SER. After you download the executable and run, start FTP server by issuing command “ftpsrv  start” on serial console; start FTP client; copy over files from PC host to TWR nandflash. Keep the folder structure of the copied files; now open your web browser (support for HTML5 is required); open Url http://192.168.1.202

This is report from internal USB flash drive plugfest (tested with MQX 4.0). VID PID VID Manufacturer Photo Vendor info Product info 0x0dba 0x0120 Realtek Generic Card Reader 0x8564 0x1000 Transcend JetFlash Transcend 4GB 0x0951 0x1654 Kingston Technology Kingston DT R500 0x0951 0x1647 Kingston Technology Kingston DT Mini Fun G2 0x0204 0x6025 Chipsbank Microelectronics CMB USB2.0 0x1516 0x1213 Myson-Century Technology USB DISK 2.0 0x1b1c 0x1ab1 Corsair Technology Corsair Voyager 0x0001 0x7778 Fry's Electronics Generic Flash Disk 0x125f 0xc08a ADATA ADATA USB Flash Drive (C008/32GB) 0x0dda 0x2026 Apacer ICSI IC1210 CF 0x0ea0 0x6828 Ours Technology 32MB HardDrive 0x0781 0x5530 SanDisk SanDisk SanDisk Cruzer (SDCZ36-004G) 0x111d 0x0000 IDT CENTON Swivel 0x0781 0x5406 SanDisk SanDisk SanDisk Cruzer (SDZ6-8192RB) 0x8564 0x1000 Transcend JetFlash Transcend 16GB 0x0951 0x1642 Kingston Technology Kingston DT 101 G2

General MQX FAQ page on the Freescale MQX product support page FAQ specific to the TWR-MCF51CN-KIT MQX labs Q: What software tools do I need for TWR-MCF51CN-KIT demos and lab tutorials? A: The TWR-MCF51CN-KIT requires CodeWarrior for Microcontrollers 6.2 Professional Edition (30-day evaluation available) with the 6.2.2 patch to unlock the full potential of the demos and labs. Is version 6.2.2 necessary?  Yes, the 6.2.2 patch contains the necessary support for the MCF51CN128. What about CodeWarrior Special Edition? Due to the code size limitation (<64k) of Microcontroller Special Edition, the labs for the TWR-MCF51CN-KIT will not compile. What about CodeWarrior Basic and Standard Edition? Those versions will work with the labs. Q. Where is MQX Task Aware Debugging? A: The TAD feature is only available on V2 cores or above. Q. Why must I install the CW 6.2.2 patch after Processor Expert Update? A: Due to a bug in Processor Expert Update 3.05, the 6.2.2 patch must be installed after Processor Expert. This issue was fixed in PE 3.06 or later. If you did not install PE before the 6.2.2 patch, simply re-run the 6.2.2 patch installer again, and the problem should be solved. Q: I'm having trouble establishing an Ethernet connection between my PC and the board.  What do I do? A: 1) Hit the Reset button on the board after you plug in the cable.  2) Wait a minute or two for your computer to connect. Connect the board directly to your computer with an ethernet crossover cable. You must wait a minute or two for your computer to try to aquire a network address.  Since you're no longer connected to your network the computer will eventually revert to an Auto IP address on the same subnet as board (169.254.x.x). 3) Disable your wireless router if you have one. 4) Disable proxy server settings in your web browser. Notes: When connected your computer might report limited or no connectivity, but it should still work. If all else fails, configure your IP address manually as instructed by the quick start guide. Q. I'm using Windows Vista and when I type telnet into a command prompt, it tells me it cannot find the program. Where is it? A: The telnet client is not enabled by default in Windows Vista. To enable it, perform the following steps: 1. Go to Start > Control Panel > Programs and Features. 2. Select "Turn Windows features on or off" 3. Select the check box next to "Telnet Client" and hit OK. Q. Why does the debugger say it's hitting an illegal breakpoint when executing the labs, and the Run button keeps flashing on and off? A: This is a bug in the OSBDM and CW6.2.2 where it loses debug connection when it encounters a stop instruction. The code is still executing so it will not affect the running of the labs. A new version of OSBDM and installation instructions will be available soon. Message Edited by amh on 2009-12-09 02:44 PM This document was generated from the following discussion: TWR-MCF51CN-KIT MQX Lab FAQs - Updated

Table of Contents Product Information on Freescale.com MQX Software Solutions Product Summary Page MQX Software Solutions Documentation MQX Software Solutions Downloads MQX Software Solutions Training Frequently Asked Questions (FAQ) General MQX FAQs Technical MQX FAQs Other Resources MQX Training Videos MQX Add-On Software

Introduction the BSP configuration file in MQX for Kinetis SDK 1  Overview of BSP directory in MQX classic  and MQX for KSDK If you compare the BSP directory of MQX classic and MQX for KSDK , you will find that there are significant differences in how the Board Support Package for MQX for KSDK and classic MQX are configured.  For MQX classic directory, the compiled BSP library is used for drivers and hardware configuration (see picture 1), there are 35 files, while for MQX for KSDK directory (see picture 2), the BSP directory is nearly empty, much of the equivalent functionality of the BSP library is now moved to the example board directory. See picture 3. If you want to port your application to your custom board, these files are very important, you need to review them carefully. Picture 1   BSP in MQX classic Picture 2  BSP in MQX for KSDK Picture 3   board directory in MQX for KSDK 2  Introduction of the BSP configuration file in MQX for KSDK The BSP configuration  files are located at  sdk_install_folder/examples. Please see picture 3. We need to modify these files according to schematic and reference manual 2.1 Board.c/h: The C file contains clock and oscillator initialization functions. The header file contains board-specific configuration macros for things such as debug terminal configuration, push buttons, LEDs and other board-specific items. 2.2 Gpio_pins.c/h: Kinetis SDK uses pin configuration structures for each pin --Pin configuration structures in gpio_pin.c configures input/output, pull-up/pull-down, pin filtering, interrupt enabled/disabled, initial output polarity, slew rate and driver strength setting Gpio_pins.h --declares Pin names used by board, PORT pin to use  (ie: PTE3) --contains definitions for LED, switch, and SD card chip select /*! @brief Pin names */ enum _gpio_pins_pinNames{   kGpioSW2      = GPIO_MAKE_PIN(GPIOC_IDX, 6U),   kGpioSW3      = GPIO_MAKE_PIN(GPIOA_IDX, 4U),   kGpioSdhc0Cd  = GPIO_MAKE_PIN(GPIOE_IDX, 6U),   kGpioLED1     = GPIO_MAKE_PIN(GPIOE_IDX, 26U),   kGpioLED2     = GPIO_MAKE_PIN(GPIOB_IDX, 22U),   kGpioLED3     = GPIO_MAKE_PIN(GPIOB_IDX, 21U), }; #endif Gpio_pins.c Contains GPIO options for each pin const gpio_output_pin_user_config_t ledPins[] = {   {     .pinName = kGpioLED1, .config.outputLogic = 1,     .config.slewRate = kPortSlowSlewRate,     .config.isOpenDrainEnabled = false, .config.driveStrength = kPortLowDriveStrength,   },   {     .pinName = kGpioLED2, .config.outputLogic = 1,     .config.slewRate = kPortSlowSlewRate, .config.isOpenDrainEnabled = false, .config.driveStrength = kPortLowDriveStrength,   },   {     .pinName = kGpioLED3, .config.outputLogic = 1,     .config.slewRate = kPortSlowSlewRate, .config.isOpenDrainEnabled = false, .config.driveStrength = kPortLowDriveStrength,   },   {     .pinName = GPIO_PINS_OUT_OF_RANGE,   } }; 2.3  Pin_mux.c/h: Kinetis devices provide great flexibility in muxing signals, each digital port pin has up to 8 signals muxed on pin, some peripherals route same signals to multiple pins. In Pin_mux.c:  It implements functions to set pin mux option for all pins used on board, and functions for each peripheral type, like configure_can_pins() void configure_can_pins(uint32_t instance) {   /* PORTB_PCR19 */   PORT_HAL_SetMuxMode(PORTB,19u,kPortMuxAlt2);   /* PORTB_PCR18 */   PORT_HAL_SetMuxMode(PORTB,18u,kPortMuxAlt2); } Not all instances will be populated so may need to add void configure_i2c_pins(uint32_t instance) {   switch(instance) {        case I2C0_IDX:                       /* I2C0 */       /* Affects PORTE_PCR24 register */ PORT_HAL_SetMuxMode(PORTE,24u,kPortMuxAlt5);       PORT_HAL_SetOpenDrainCmd(PORTE,24u,true);       /* Affects PORTE_PCR25 register */ PORT_HAL_SetMuxMode(PORTE,25u,kPortMuxAlt5); PORT_HAL_SetOpenDrainCmd(PORTE,25u,true);       break;     case I2C1_IDX:                       /* I2C1 */       /* Affects PORTC_PCR10 register */ PORT_HAL_SetMuxMode(PORTC,10u,kPortMuxAlt2); PORT_HAL_SetOpenDrainCmd(PORTC,10u,true);       /* Affects PORTC_PCR11 register */ PORT_HAL_SetMuxMode(PORTC,11u,kPortMuxAlt2); PORT_HAL_SetOpenDrainCmd(PORTC,11u,true);       break;     default:       break;   } 2.4  hardware_init: Project specified hardware initialization, it uses functions provided in board configuration layers in pin_mux.c during startup void hardware_init(void) { /* enable clock for PORTs */ CLOCK_SYS_EnablePortClock(PORTA_IDX); CLOCK_SYS_EnablePortClock(PORTB_IDX); CLOCK_SYS_EnablePortClock(PORTC_IDX); CLOCK_SYS_EnablePortClock(PORTE_IDX); /* Init board clock */ BOARD_ClockInit(); dbg_uart_init(); } 3   Kinetis SDK Porting example—Change Default UART To change default UART port, we need to change the UART instance in board.h, and change the pin muxing in pin_mux.c 3.1   Modify board.h to select the UART and baud rate to use /* The UART to use for debug messages. */ #ifndef BOARD_DEBUG_UART_INSTANCE     #define BOARD_DEBUG_UART_INSTANCE   0     #define BOARD_DEBUG_UART_BASEADDR   UART0 #endif #ifndef BOARD_DEBUG_UART_BAUD     #define BOARD_DEBUG_UART_BAUD       115200 #endif 3.2  Modify pin_mux.c to select the pins to use void configure_uart_pins(uint32_t instance) {   switch(instance) {        case UART0_IDX:                      /* UART0 */       /* Affects PORTB_PCR16 register */ PORT_HAL_SetMuxMode(PORTB,16u,kPortMuxAlt3);       /* Affects PORTB_PCR17 register */ PORT_HAL_SetMuxMode(PORTB,17u,kPortMuxAlt3);       break;     case UART4_IDX:                      /* UART4 */       /* Affects PORTC_PCR14 register */ PORT_HAL_SetMuxMode(PORTC,14u,kPortMuxAlt3);       /* Affects PORTC_PCR15 register */ PORT_HAL_SetMuxMode(PORTC,15u,kPortMuxAlt3);       break;     default:       break;   } }

Rev0.1 - 8/28/2013 This is an update to the previous patch TWR-K21D50M lowpower Patch In MQX v4.0.2, most of the issues reported in the earlier patch have been fixed in the BSP.  But the lowpower example for this board still fails to enter LLS mode because of a conflict with the SPI peripheral.  There is only a minor edit in one file needed to fix the example. User_config.h MQX_ENABLE_LOW_POWER macro enabled.  Required for LPM driver and lowpower example. Disabled SPI0 peripheral before entering a stop mode lowpower example was aborting the stop mode entry, and never entered stop mode.  The issue was caused by the SPI0 peripheral preventing the entry to LLS mode.  Modified _lpm_set_cpu_operation_mode() in lpm_smc.c to disable SPI0 clock gate before entering a stop mode, and re-enabled after waking up.  If SPI0 peripheral is required in a stop mode, register the SPI driver with the LPM driver to properly configure when LPM changes operation mode to a stop mode.  Refer to LPM documentation for details.  Replace the file \Freescale_MQX_4_0_2\mqx\source\io\lpm\lpm_smc.c with the attached.

Hi Community, Based on How to add RTCS to a Processor Expert Project Using KDS and KSDK​,  below you can find the steps to include MFS and Shell to a KDS3.0 project using KSDK1.2 and Processor Expert. Thank you Carlos_Musich for his great document and for providing the draft of this document. Regards, Isaac Avila

Hello all, This document describes how to create a FreeRTOS project in KDS using the Kinetis SDK Project Generator tool. If you are interested in how to Create a FreeRTOS project using KDS and Kinetis SDK Project V2.0 please check the below link: https://community.freescale.com/docs/DOC-330183 In order to follow this document, first it is necessary to install: Kinetis Design Studio (KDS) Kinetis Design Studio Integrated Development |NXP KINETIS-SDK: Software Development Kit for Kinetis MCUs Software Development Kit for Kinetis MCUs|NXP KSDK Project Generator tool Software Development Kit for Kinetis MCUs|NXP Creating a new project using the Project Generator tool Kinetis SDK Project Generator tool is a supplement to the KSDK. It is intended to provide users with a convenient method for generating KSDK based projects for their intended target hardware. The KSDK Project Generator requires the user to install an instance of KSDK 1.2.0 or 1.3.0 before generating new projects. The KSDK Project Generator requires operates on Windows, Linux, and Mac OSX. 1. Launch the Project Generator executable. 2. Introduce the Project Name and choose the board used. For this example it is used the TWR-K64F120M. 3. In order to generate a FreeRTOS project, click on the "Advanced" button. 4. Choose the operating system, in this case FreeRTOS, the IDE KDS and select Generate standalone project. 5. After that, click on "Advanced Generate" button to create the project. Open the project in KDS Every application/example created using the KSDK Project Generator tool has one associated working set description file which includes the path to the example project file and the dependent RTOS library project file. Simply import that file into KDS working space. At this point you should be able to build the library and the project created. Developing a FreeRTOS with KSDK application Operating System Abstraction layer (OSA) provides a common set of services for drivers and applications so that they can work with or without the operating system. OSA provides these services: task management, semaphore, mutex, event, message queue, memory allocator, critical part, and time functions. An easy method to create a task is using  the OSA_TASK_DEFINE macro and the function OSA_TaskCreate(). The macro OSA_TASK_DEFINE declares a task handler and task stack statically. The function OSA_TaskCreate() creates task base-on the resources declared by OSA_TASK_DEFINE. The parameters for this function are: The stack size in byte. Pointer to the stack. The stack size in byte. Pointer to the stack. Initial priority of the task: OSA supports task priorities 0∼15, where priority 0 is the highest priority and priority 15 is the lowest priority. Pointer to be passed to the task when it is created. If this task will use float register or not. Pointer to the task handler. NOTE: The disadvantage with this method is that task function can only create one task instance. The project created using the Project Generator tool creates one  task (task_example) implementing OSA. For more information about functions, macros and drivers please consult the Kinetis SDK v.1.3 API Reference Manual. This is located, after install Kinetis SDK, at the path: <install_KSDK_1.3.0_path>\doc GPIO Example 1. Add a new task named task_led. Add also a macro for OSA_TASK_DEFINE, the priority of the task and the prototype. To initialize and start RTOSes, OSA uses abstract functions OSA_Init() and OSA_Start(). Call OSA_Init() after calling hardware_init(). 2. Create the empty body of task_led 3. Add the following code initialization code for GPIO driver. PRINTF("\nLED TASK is running \n"); /* Enable clock for PORTs */ CLOCK_SYS_EnablePortClock(PORTA_IDX); CLOCK_SYS_EnablePortClock(PORTE_IDX); //Initializes GPIO driver GPIO_DRV_Init(switchPins, ledPins); 4. Now add logic to toggle a LED when a button is pressed. while(1) { //  check if SW2 is pressed if(GPIO_DRV_ReadPinInput(kGpioSW3) == 0) { GPIO_SW_DELAY; GPIO_DRV_TogglePinOutput(BOARD_GPIO_LED_BLUE); } } 5. It is needed a delay for the push buttons debounce. In this case it is GPIO_SW_DELAY which is defines as follows: /*Delay for Switch debounce*/ #define GPIO_SW_DELAY \ do \ { \ uint32_t i; \ for (i = 0; i < 0x2FFFFF; i++) \ { \ __asm("nop"); \ } \ } while (0) GPIO 6. Build and debug the project. Enjoy...

Hello All, This document explains how to add GPIO pins to the default BSP configurations. This example shows how add a LED pin for the BSP TWR-K70FN1M board. The procedure is the same for other ports and peripherals, using Kinetis devices. MODIFY THE TWRK70F120M.h FILE The TWR-K70F120M Tower Module contains two pushbutton switches connected to GPIO/interrupt signals, one pushbutton connected to the master reset signal, four capacitive touch pad electrodes, four user controllable LEDs, and a potentiometer connected to an ADC input signal. The following table provides details on which K70FN1M0 pins are used to communicate with the LEDs and switches onboard the TWR-K70F120M.  Feature Connection Port Pin Pin Function Pushbuttons SW1 (IRQ0) PTD0 PTD0 SW2 (IRQ1) PTE26 PTE26 SW3 (RESET) RESET_b RESET_b LEDs E1 / Orange LED PTA11 PTA11 E2 / Yellow LED PTA28 PTA28 E3 / Green LED PTA29 PTA29 E4 / Blue LED PTA10 PTA10 Touch Pads E1 / Touch PTA4 TSI0_CH5 E2 / Touch PTB3 TSI0_CH8 E3 / Touch PTB2 TSI0_CH7 E4 / Touch PTB16 TSI0_CH9 Table 1. I/O Connectors and Pin Usage Table NOTE: Some port pins are used in multiple interfaces on-board and many are potentially connected to off-board resources via the Primary and Secondary Connectors. Take care to avoid attempted simultaneous usage of mutually exclusive features. For more information please consult the “TWR-K70F120M Tower Module User's Manual”. http://cache.freescale.com/files/microcontrollers/doc/user_guide/TWRK70F120MUM.pdf?fpsp=1&WT_TYPE=Users%20Guides&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation The <board>.h file is used to provide information needed by an application program using the kernel running on the Freescale Evaluation board. This file contains the GPIO board specifications.  It is located at the next path: <Freescale_MQX_4_x_install_path>\mqx\source\bsp\<name_board> Figure 1. GPIO board specifications for the TWR-K70F120M. The twrk70f120m.h file contains the GPIO board definition for the TWR-K70F120M, however if customer creates his own board and he needs to connect LEDs in deferent pins to the TWR-K70F120M, it is necessary to modify this file. Suppose a custom_board where is connected a LED to PTE18 pin, in order to add this pin definition it is necessary to follow the below steps, the pin will be called BSP_LEDCustom. 1. Define the pin name and assign the port and pin number. #define BSP_LEDCustom               (GPIO_PORT_E | GPIO_PIN18) 2. Assigning the requested functionality to the pin for the GPIO mode or any other peripheral mode. #define BSP_LEDCustom_MUX_GPIO (LWGPIO_MUX_E18_GPIO) 3. Save and close the twrk70f120m.h file. USE THE NEW LED IN A PROJECT   The following example shows one task named LEDCustom_TASK, where the LEDCustom is used. 1. Open a new MQX project. 2. In the main.h module replace the following lines: #define MAIN_TASK 1 extern void Main_task(uint_32); With the next lines: #define LEDCustom_TASK 5 extern void ledCustom_task(uint_32); 3. In main.c, modify the MQX_template_list entry for the Main_Task. Replace the following line: {MAIN_TASK, Main_task, 1500, 9, "main", MQX_AUTO_START_TASK}, With the next line: { LEDCustom_TASK, ledCustom_task, 1500, 9, "init", MQX_AUTO_START_TASK, 0, 0}, NOTE The last entry in the MQX_template_list must be all zeros. 4. In main.c, comment out the Main_task. /*void Main_task(uint_32 initial_data) { print(“/n Hello World /n”); _mqx_exit(0); } */ 5. It is necessary to write the tasks code. This task uses LWGPIO driver in order to toggle a pin. The lwgpio_init() function has to be called prior to calling any other API function of the LWGPIO driver. This function initializes the LWGPIO_STRUCT structure. The pointer to the LWGPIO_STRUCT is passed as a handle parameter. To identify the pin, platform-specific LWGPIO_PIN_ID number is used. It is necessary to have a variable to assign the pointer to the LWGPIO_STRUCT, for do that it is required to add the following line: LWGPIO_STRUCT ledC; The following lines initialize lwgpio handle for LWGPIO_MUX_E18_GPIO pin. The BSP already knows the address and the pin number for each GPIO PORT and each PIN. This is defined in mqx/source/bsp/<bsp_name>/<bsp_name>.h file. That is the reason the twrk70f120m.h file was modified. if (!lwgpio_init(&ledC, BSP_LEDCustom, LWGPIO_DIR_OUTPUT, LWGPIO_VALUE_NOCHANGE))   {             printf("Initializing Port TE pin18 GPIO of the K70 as output failed.\n");     _task_block();   } 6. Once it is initialized, it is necessary to assign the requested functionality to the pin like GPIO mode or any other peripheral mode. The lwgpio_set_functionality() function sets the functionality of the pin. The value of the functionality parameter represents the number stored in the multiplexer register field which selects the desired functionality. For the GPIO mode, you can use the pre-defined macros which can be found in the lwgpio_ <mcu>.h file. Add the following lines switch pin functionality to GPIO mode: lwgpio_set_functionality(&ledC, BSP_LEDCustom_MUX_GPIO); The lwgpio_set_value() function sets the pin state (low or high) of the specified pin. In order to toggle the pin value write the following code: while (TRUE)   {     _time_delay(1000);     lwgpio_set_value(&ledC, value); /* toggle pin value */     value = value^1;   } 7. Create the other three functions. The name of each function, delay, and the first parameter must be different in LWGPIO functions use (lwgpio_init(), lwgpio_set_functionality(), lwgpio_set_value()). 8. At this point it is possible to build the project, flash it to the board and run the project; for more details about building, flashing and running please refer to the compiler documentation of your choice, that is located at the next path:  C:\Freescale\Freescale_MQX_4_x\doc\tools\cw  Thanks!!!!     a. main.c /**************************************************************************** * *   This file contains MQX only stationery code. * ****************************************************************************/ #include "main.h" #if !BSPCFG_ENABLE_IO_SUBSYSTEM #error This application requires BSPCFG_ENABLE_IO_SUBSYSTEM defined non-zero in user_config.h. Please recompile BSP with this option. #endif #ifndef BSP_DEFAULT_IO_CHANNEL_DEFINED #error This application requires BSP_DEFAULT_IO_CHANNEL to be not NULL. Please set corresponding BSPCFG_ENABLE_TTYx to non-zero in user_config.h and recompile BSP with this option. #endif TASK_TEMPLATE_STRUCT MQX_template_list[] = { /*  Task number, Entry point, Stack, Pri, String, Auto? */   {LEDCUSTOM_TASK, ledCustom_task, 1500, 9, "init", MQX_AUTO_START_TASK, 0, 0}, {0,         0,         0, 0,   0,     0,                  0, 0} }; /*TASK*----------------------------------------------------- * * Task Name    : Main_task * Comments     : *    This task prints " Hello World " * *END*-----------------------------------------------------*/ void ledCustom_task(uint_32 initial_data) {       int value = 0;       LWGPIO_STRUCT ledC;                 printf("\n LedCustom task \n");                 /* initialize lwgpio handle for LWGPIO_MUX_TC0_GPIO pin (defined in mqx/source/bsp/<bsp_name>/<bsp_name>.h file) */         if (!lwgpio_init(&ledC, BSP_LEDCustom, LWGPIO_DIR_OUTPUT, LWGPIO_VALUE_NOCHANGE))           {             printf("Initializing Port TE pin18 GPIO of the K70 as output failed.\n");           _task_block();         }                 /* swich pin functionality to GPIO mode */         lwgpio_set_functionality(&ledC, BSP_LEDCustom_MUX_GPIO);                  while (TRUE)           {             _time_delay(5000);             lwgpio_set_value(&ledC, value); /* toggle pin value */             value = value^1;           }       } /* EOF */     b. main.h #ifndef __main_h_ #define __main_h_ #include <mqx.h> #include <bsp.h>   #define LEDCUSTOM_TASK 5   extern void ledCustom_task(uint_32);    /* PPP device must be set manually and ** must be different from the default IO channel (BSP_DEFAULT_IO_CHANNEL) */ #define PPP_DEVICE      "ittyb:" /* ** Define PPP_DEVICE_DUN only when using PPP to communicate ** to Win9x Dial-Up Networking over a null-modem ** This is ignored if PPP_DEVICE is not #define'd */ #define PPP_DEVICE_DUN  1 /* ** Define the local and remote IP addresses for the PPP link ** These are ignored if PPP_DEVICE is not #define'd */ #define PPP_LOCADDR     IPADDR(192,168,0,216) #define PPP_PEERADDR    IPADDR(192,168,0,217) /* ** Define a default gateway */ #define GATE_ADDR       IPADDR(192,168,0,1) #endif /* __main_h_ */

The links below provide useful design resources for MQX Software Solutions product developers. Products Latest Releases and Patches Announcements & Information Training MQX Classic​ MQX v4.2.0.2 Patch MQX RTOS Announcements MQX RTOS Training Space MQX v5​ MQX RTOS v4.2 General MQX FAQs​ MQX Essentials - Training Videos​ CyaSSL for MQX RTOS MQX Roadmap

Hello All, Next document lists the steps needed to install a basic NIO driver in MQX for KSDK 1.3. In this document, a basic SPI driver for FRDM-K64F was created in order to serve as guidance for any user's driver. Source and header file for this NIO SPI are attached as well as hello.c source files that was taken from hello_world example in order to test this driver. I hope you can find it helpful! Best Regards, Isaac Avila

Hi, I want to share a document, the purpose of this document is to indicate step by step how to get the memory footprint of a MQX project. The Freescale MQX RTOS includes the tool Codesize.exe, this document is a guide for people who want to use this tool in order to know the memory RAM/ROM utilization of a MQX project. Regards Soledad

Interrupts can be handled by MQX (MQX managed ISR) or bypassing MQX (MQX kernel ISR). If you want that MQX handled all the ISR process, you can use MQX managed ISR.  By this ISR,  MQX catches all hardware interrupts in the range that the BSP defined and saves the context of the active task. For most interrupts, MQX calls the ISR that is stored in the interrupt vector table at the location identified by its interrupt vector number. The disadvantage with this is the interrupt latency is longer and depends completely on MQX. Hardware vector table for all MQX managed isrs points to MQX kernel function _int_kernel_isr()). This function invokes user isr by jumping into instruction pointed by "isr_ptr" , as the below graph shows. A task can install an MQX managed ISR interrupt using:  _int_install_isr(interrupt_vector_number,isr_ptr,isr_data_ptr) _bsp_int_init(Vector, Pri, Subpri, TRUE); Vector – number of non-core vector (for example, 37 for LLWU, defined in IRQInterruptIndex in the MCU header file) Pri – priority of the interrupt source. Allowed values: MQX_HARDWARE_INTERRUPT_LEVEL_MAX, MQX_HARDWARE_INTERRUPT_LEVEL_MAX + 1, …, 7, where 7 is the lowest application interrupt priority level. Subpri – zero on Kinetis. Enable – TRUE to enable the interrupt vector source in NVIC.  At this level of interrupt, you can call MQX services. The other option is MQX kernel ISR. Some real-time applications need special event handling to occur outside the scope of MQX. The need might arise that the latency in servicing an interrupt be less than the MQX interrupt latency. If this is the case, an application can use _int_install_kernel_isr() to bypass MQX and let the interrupt be serviced immediately. You will have the very same Performance as if you were running bare metal. A kernel ISR must save the registers that it needs and must service the hardware interrupt. When the kernel ISR is finished; it must restore the registers and perform a return-from-interrupt instruction. Even though the compiler handles this for you.   In this case, you can't use MQX services.  However, you can put data in global area, which a task can access. The disadvantage on this is shared data problem and you can impact the kernel if the restoring stack fails.   If you need faster MQX kernel ISR, you can install Kernel ISR with : _int_install_kernel_isr(vector_num, isr_ptr)  _bsp_int_init(Vector, Pri, Subpri, TRUE); Vector – number of non-core vector (for example, 79 for FTM1, defined in IRQInterruptIndex in the MCU header file) Pri – priority of the interrupt source. Allowed values: 0 for highest priority kernel isr, 1, ..,MQX_HARDWARE_INTERRUPT_LEVEL_MAX-1 for lowest priority kernel isr. Subpri – zero on Kinetis. Enable – TRUE to enable the interrupt vector source in NVIC. And very important, to install a HW interrupt handler, you need the HW interrupt table in RAM, so your user_config.h has to define MQX_ROM_VECTORS to 0.   Next is a demo to show how to use mqx kernel ISR, you can download it for more details.   static void GPIO_Init(void); static void IRQ_Init (void); void PortA_ISR(void); void PortE_ISR(void);                TASK_TEMPLATE_STRUCT MQX_template_list[] = { /*  Task number, Entry point, Stack, Pri, String, Auto? */    {MAIN_TASK,   Main_task,   1500,  9,   "main", MQX_AUTO_START_TASK},    {0,           0,           0,     0,   0,      0,                 } };   char SW=0;     /*TASK*----------------------------------------------------- * * Task Name    : Main_task * Comments     : *    This task prints " Hello World " * *END*-----------------------------------------------------*/   void Main_task(uint_32 initial_data) {    int counter=0;                printf("\n Hello World \n");       GPIO_Init();       IRQ_Init();       while(1){                   if(SW==1){                                  SW=0;                                  printf("IRQ A was generated\n");                   }                   if(SW==2){                                  SW=0;                                  printf("IRQ E was generated\n\r");                   }                   printf("Waiting for IRQ... %d\n\r", counter);                   counter++;                   _time_delay(1000);    }       _mqx_exit(0); }   static void GPIO_Init(void){                               SIM_SCGC5 = (0|SIM_SCGC5_PORTA_MASK|SIM_SCGC5_PORTE_MASK); /* Enable clock for PORTA */                               PORTA_PCR19 |= (0|PORT_PCR_MUX(1)|PORT_PCR_IRQC(0xA));//|PORT_PCR_PE_MASK;//|PORT_PCR_PS_MASK;                PORTE_PCR26 |= (0|PORT_PCR_MUX(1)|PORT_PCR_IRQC(0xA))|PORT_PCR_PE_MASK|PORT_PCR_PS_MASK; }   static void IRQ_Init (void){                uint32_t result;                                                  /* install the interrupt routine */                _int_install_kernel_isr (103, PortA_ISR);                _int_install_kernel_isr (107, PortE_ISR);                                              result = _cortex_int_init(107, 2, TRUE);                result = _cortex_int_init(103, 3, TRUE);                }   void PortA_ISR(void){                SW=1;                PORTA_ISFR=0xFFFFFFFF;  //Clear Port A ISR flags }   void PortE_ISR(void){                SW=2;                PORTE_ISFR=0xFFFFFFFF;  //Clear Port E ISR flags }

May 7, 2014   MQX plugins were rebuilt to support latest DS5.18.   Zip attached to this email contains following plugins:   - com.freescale.projectofprojects   - com.freescale.buildtoolbar   - com.freescale.mqx.configuration.editor   The plugins installation procedure is described in the MQX DS5 getting started manual (chapter 2). Plugins are backward compatible and should work also in older DS5 versions.   https://community.freescale.com/thread/323233   Regards, David Seymour

Tutorial 5 of 6 for the iDigi Connector for MQX: Enabling iDigi Remote Firmware Update (5 of 6) - iDigi Device Cloud More information and free download at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_IDIGI_M2M