Rev0.2 - 8/28/2012 NOTE: for an update to this patch for MQX v4.0.2, see TWR-K21D50M lowpower MQX Patch for v4.0.2 This patch addresses several issues with using the lowpower example in MQX on the twrk21d50m BSP. The lowpower example is provided to demonstrate the MQX Low-Power Manager (LPM) driver, and change low-power modes on the K21 board.  The BSP provided in MQX v4.0 has several issues interfering with these low-power modes, and the lowpower example. To use this patch, copy the patch directory into the MQX v4.0 root directory.  The patch will over-write some existing files in the MQX installation.  The changes addressed by this patch include the following: User_config.h MQX_ENABLE_LOW_POWER macro enabled.  Required for LPM driver and lowpower example. VLPR Clock configuration dividers Updated the clock dividers in the SIM_CLKDIV1 register to set the core/system/bus clock frequencies at 2MHz as expected, instead of 1MHz.  Modified Cpu_SetClockConfiguration() in bsp_cm.c.  Fixes issue in lowpower example where characters printed to terminal are incorrect baud rate in VLPR mode. UART settings for LPM Operation modes BSP has incorrect settings for UART2 (TTYC) for the LPM operation modes.  Causes UART2 to be disabled in Run mode when MQX_ENABLE_LOW_POWER is enabled, which causes a bus error exception, stopping the BSP startup before main() is entered.  Modified init_sci.c Over-writing internal oscillator trim value The BSP was not using the factory trimmed settings for the internal oscillators.  The BSP is configured for a user-trim value to be stored at 0x3FE and 0x3FF.  The BSP checks these flash locations, and if not erased having 0xFF, it writes these locations to the MCG trim registers.  The issue is the vector table filled the vector location at 0x3FC, fooling the BSP into thinking user-trim value was present.  Modified vector.c to replace final vector with 0xFFFFFFFF, forcing BSP to keep the factory trim settings.  Fixes issue in lowpower example where characters printed to terminal are incorrect baud rate in VLPR mode. Disabled clock monitor when entering a stop mode BSP had clock monitor enabled in BSP, and did not disable before entering a stop mode.  This prevents the lowpower example from recovering properly from LLS mode. Modified _lpm_set_cpu_operation_mode() in lpm_smc.c to clear the CME bit before entering a stop mode, and then restore CME setting after waking up. 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.

The new Freescale MQX™ 4.1 for TWR-K64F120M release is now available on the www.freescale.com ·         Files available # Name Description 1 FSL_MQX_TWRK64F120M_RELEASE_NOTES Freescale   MQX™ RTOS 4.1.0 TWR-K64F120M Release Notes 2 Freescale   MQX RTOS 4.1.0 for the TWRK64F120M Includes   an RTOS, File System, TCP/IP and USB host/device software stacks. Does not   require MQX™ 4.1 installation. ·         Target HW board o   TWR-K64F120M ·         New features o   PSP support for the K64F120M Microcontroller o   BSP for the TWR-K64F120M tower system module o   Standard set of I/O drivers supporting the K64F120M peripherals including: §  LWGPI/O driver §  Serial interrupt and polled driver §  DMI SPI driver §  I2C interrupt and polled driver §  ADC §  LWADC §  Flash Driver §  RTC Driver §  PIT Timer §  LPT Timer §  SD card driver §  SDHC §  FlexCAN §  SAI §  ENET o   USB Host and Device drivers and stacks o   Example and demo applications demonstrating MQX, USB, RTCS, and MFS usage o   RTCS TCP/IP stack o   MFS file system o   Shell command line interface ·         Known issues o   For known issues and limitations please consult the release notes.

Introduction Official support for MQX in KDS is slated for August of this year (2014), but what if you want to start building up your libraries now? Through Mingw and the files included in MQX 4.1, we can compile libraries and programs using KDS’ gcc_arm compiler. This is essentially a modification of the process used to compile MQX on a generic gcc_arm compiler. Original documentation can be found in: <MQX_ROOT_DIR> \doc\tools\gnu\MQX_GNU_Getting_Started.pdf I will try to explain a bit more of the setup process and the file changes that must be made to correctly compile, along with debugging your executable in processor expert. This guide is written for Windows and a version of the guide including a few screenshots of important screens is attached. Setup You will need: Mingw installed, along with mingsys-SED. This can be found at http://sourceforge.net/projects/mingw/ Make sure ‘c:\MinGW\bin’ has been added to system ‘PATH’ variable SED is part of a cmd improvement suite called mingsys. You can install the whole suite, but we only need SED KDS installed A suitable text editor that allows find and replace of text in all files of a selected directory. I recommend Notepad++ and it is what I will use in the tutorial. MQX file changes The original makefiles and batch scripts were created for gcc_arm v4.7.4, but KDS 1.0.1 is using 4.8.0. This means some directory paths have changed and these changes must be updated within MQX’s files. First, let us define the toolchain for the builder to use, in <MQX_ROOT_DIR> \build\common\make\global.mak, modify the following definition: ifeq ($(TOOL),gcc_arm)      TOOLCHAIN_ROOTDIR = <KDS_INSTALLION_DIR>\toolchain Endif Next we need to update the directory listings for gcc_arm components within its root directory. This comes down to replacing all instances of “/4.7.4/” with “/4.8.0/” in all ‘gcc_arm.mak’ files (you could choose to only edit the .mak files of boards you intend to use,  but it’s just as easy to replace all instances). In notepad++, this is simple process of running a “Find in Files”. The files themselves will be located in directories associated with building mqx for each platform: <MQX_ROOT_DIR> \mqx\build\make\<SPECIFIC_PLATFORM>\tools\gcc_arm.mak Along with some entries within application builds: <MQX_ROOT_DIR> \mqx\examples\<project>\build\make\<project>_<platform>\tools\gcc_arm.mak Lastly, specifically for demo application builds, there is one more directory change and one exclusion to make: remove ‘armv7e-m/’ from directory paths and comment out ‘libnosys.a’ (I must clarify I don’t understand the importance of libnosys and couldn’t find a suitable replacement with KDS’ gcc_arm toolchain. I have build hello2 successfully without it, but maybe other projects will require it) Again, this is a simple ‘Find in Files’, replacing “armv7e-m/” with no characters, then replacing the line: RT_LIBRARIES += $(TOOLCHAIN_ROOTDIR)/arm-none-eabi/lib/armv7e-m/softfp/libnosys.a With #RT_LIBRARIES += $(TOOLCHAIN_ROOTDIR)/arm-none-eabi/lib/armv7e-m/softfp/libnosys.a to comment it out. Building Libraries The build process is now incredible easy, as we can use the batch scripts provided in MQX to build our libraries. Either use “<MQX_ROOT_DIR> \build\<BOARD>\make\ build_gcc_arm.bat” to create the full set of libraries for the chosen board (bsp, psp, usb, shell, mfs,rtcs), or use any “build_gcc_arm.bat” found in the component and board area of your choice. These will automatically build the libraries and move the created libraries and code to ““<MQX_ROOT_DIR> \lib\<BOARD>.gcc_arm\” Note: when building full libraries the system will sometimes throw up errors when calling ‘mkdir’, saying that the folder structure already exists.  I have found if you re-run the script again it will not complain the second time and behaves fine. Building Examples So far only tested ‘hello2’on twrk60n512, but principles should apply to all boards and projects Again, we use the batch scripts provided in MQX, found in locations such as: <MQX_ROOT_DIR>\mqx\examples\<PROJECT>\build\make\<BOARD>\build_gcc_arm.bat Running these batch scripts will create another folder within the directory, called “gcc_arm”, in which you can find “initflash_debug” and “initflash_release”.  Inside each of these folders is your compiled application. Debugging your examples Now let’s actually do something in KDS: debugging the examples and showing that they work. For this you need to have a workspace (otherwise KDS won’t run), but you can close any open projects if you wish.  Then Click on the debug menu and select “Debug Configurations...” Double click on your chosen debug interface and under the option for “C/C++ Application”, choose browse and select the ‘.elf’ file from the ‘initFlashdebug’ folder of your application. I hope this helps some people who need to get MQX running through KDS before the official support becomes available. For information on when MQX will be supported on KDS, see https://community.freescale.com/docs/DOC-95477

Video Tutorial 1 of 6 for the iDigi Connector for MQX: Installing and Configuring the iDigi Connector for MQX (1 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

Several reasons may lead to a hard fault, for example, calling a function pointer with an invalid address, stack overflow, trying to read or write to an on-chip peripheral that is powered down or not being clocked, accessing non-mapped memory etc. It is often difficult to find out what caused the hard fault, fortunately the cortex-M stores some information in ARM fault status register, the hardware automatically pushes several CPU register on the stack before entering the Hard Fault Handler. This document below shows a way to debug a Hard Fault in MQX. For Hard Fault, we can hook our exception handler into the vector table. we will find vector table in the vector.c source file in the BSP library. By default, isr is configured to DEFAULT_VECTOR, which is the _int_kernel_isr() function of the MQX dispatcher. We cam put our own function, like void my_kernel_isr (void), to vector table offset 0x0c.  Inside my_kernel_isr(), we can get the interrupt stack frame, CPU register content at the time of exception and use directly the my_kernel_isr - just remove the static keyword, as we need the my_kernel_isr to be global, as it is referenced from vectors.c and it will be implemented in the application, main.c, for example.  Now, put breakpoint to this my_kernel_isr and see the registers read by prvGetRegistersFromStack(). Typically at most interest would by "lr" and "pc". For example, "lr" would have an address of an instruction that a return from a function call would return to. By looking into the .map file or using the debugger, we will know, which function has been executed by the CPU when exception occurred. Hook our own kernel isr into the vector table In file vectors.c,   the default ISR for Hard_Fault is DEFAULT_VECTOR Now we modified it to my_kernel_isr, so when hard fault happens, my_kernel_isr will be executed. Read the register value The following code is for CodeWarrior/Kinetis Design Studio to a C module, for IAR/KEIL, we need to write the same function as an assembler source file. void my_kernel_isr( void ) __attribute__( ( naked ) ); /* The fault handler implementation calls a function called prvGetRegistersFromStack(). */ static void my_kernel_isr(void) {     __asm volatile     (         " tst lr, #4                                                \n"         " ite eq                                                    \n"         " mrseq r0, msp                                             \n"         " mrsne r0, psp                                             \n"         " ldr r1, [r0, #24]                                         \n"         " ldr r2, handler2_address_const                            \n"         " bx r2                                                     \n"         " handler2_address_const: .word prvGetRegistersFromStack    \n"     ); } void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress ) { /* These are volatile to try and prevent the compiler/linker optimising them away as the variables never actually get used.  If the debugger won't show the values of the variables, make them global my moving their declaration outside of this function. */ volatile uint32_t r0; volatile uint32_t r1; volatile uint32_t r2; volatile uint32_t r3; volatile uint32_t r12; volatile uint32_t lr; /* Link register. */ volatile uint32_t pc; /* Program counter. */ volatile uint32_t psr;/* Program status register. */     r0 = pulFaultStackAddress[ 0 ];     r1 = pulFaultStackAddress[ 1 ];     r2 = pulFaultStackAddress[ 2 ];     r3 = pulFaultStackAddress[ 3 ];     r12 = pulFaultStackAddress[ 4 ];     lr = pulFaultStackAddress[ 5 ];     pc = pulFaultStackAddress[ 6 ];     psr = pulFaultStackAddress[ 7 ];     /* When the following line is hit, the variables contain the register values. */     for( ;; ); } Notes about Cortex M4 registers: MQX sets active stack pointer to PSP in boot.s The core automatically switches the active stack pointer to MSP in handler mode and switches back to PSP with exception return Compare with .map file we need to find out which function executes while hard fault occurs. To determine application , Use trace debugging tool (DSTREAM, ULINK-PRO, J-Trace, Lauterbach uTrace for Cortex-M …) or enable Kernel log and explore its content with MQX TAD #define MQX_KERNEL_LOGGING 1   _klog_create(2048,LOG_OVERWRITE);   /* Enable kernel log */   _klog_control(KLOG_ENABLED | KLOG_CONTEXT_ENABLED |                 KLOG_INTERRUPTS_ENABLED| KLOG_FUNCTIONS_ENABLED | KLOG_INTERRUPT_FUNCTIONS |                 KLOG_MEMORY_FUNCTIONS | KLOG_PARTITION_FUNCTIONS, TRUE); By this we only find, which function causes the problem. Next, we will have to think why this occurs, and give more application specific debugging effort to find the root cause.

MQX RTOS Task Aware Debugging plug-in (TAD) is an optional extension to a debugger tool which enables easy debugging of multi-tasking applications. With TAD, we can inspect task contexts and kernel objects. Typical use cases include --view task error codes --Examine stack usage for each task --Examine memory usage -- Debug TCP reception problems --Examine socket and PCB data --Observe memory pool / message pool utilization levels -- Observe synchronization objects The following is a description of MQX task aware debugger and an example to debug a stack overflow. It is based on web_hvac demo in the MQX installation folder, it also applies to other applications. The MQX pull down menu is as below picture shows. The task summary window shows all the tasks in the system, the task name , task id , task state, priority and Task error code. The idle task is also listed since this is still treated by MQX  as a task, and can be helpful to know what’s happening with it. The stack usage window shows what percentage that allocated for a task interrupt have been used so far. This is a high watermark not the amount of the stack currently been used. If more than allocated stack is being used as some point, then you will see an over flow has been indicated at last column. Also for reference, the address for both the base for up and down are  shown. The kernel data window can be useful for confirming the environment you are running is actually what was loaded. You give them some key data such as the version of MQX running, the CPU, the PSP.  The settings of the time component and a number of the compile time configuration settings to confirm if you have things like the kernel logging or stack monitor turned on. The memory blocks window shows all of the blocks of memory that memory manager has currently reserved for kernel objects or application tasks.  Listed is starting address for each block , the size of each block in hexadecimal , who is the owner of each block.  Which can be either the system or specific tasks, and shows the type of block. We see different types such as the block for interrupts stack, system stack, task ready queue, block associated with interrupts.  The logging feature, message pools etc. Down to the bottom, we see the stacks specific memory blocks including the task descriptor and task space.  TAD knows what the task descriptor is so it gives all the information related to the task. The next group of windows  are related to various synchronizations  that MQX supports.  Such as semaphores and events ,mutexes. If some are greyed out and that because application doesn’t use it.  Example of Debugging with TAD In order to gain experience using the Task Aware Debugging (TAD) feature and to learn how it can be used to debug an application, I created a stack overflow in the shell task in web_hvac demo by reducing the task stack size from 2400 to 500. If I now run the application, we can see the application run into idle task quickly. Opening up the stack usage window, we see that indeed an overflow was detected. And that the stack information for the Shell task has been corrupted as a result.  The task summary window also has the corrupted information for the shell task. If you look closely, the listed tasks are short than before, and if you compare the list of tasks what you expected to be there. You noticed to shell task has completed disappear. But when we look at the console, we see that it clearly started. So where did it go? The stack overrun is a good clue. But also recommend scanning check for errors window. By reviewing the task summary, stack usage and errors windows, and doing a sanity check again the states values that expecting   can be very helpful ,make sure all the tasks are there. Check for error codes, and look for stack issues. To debug an application, the following steps should be follow: Review key TAD windows:                  Task Summary Window Stack Usage Window MQX Errors Window Audit various system parameters: -     Which tasks are running. -     Task states -     Check for identified errors -     Look for stack overflows

Hi all, I want to share this document that describes steps to create a new driver using MQX 4.1 and CW 10.6.  I used the Null-Device Driver,  the null device driver provides an I/O device that functions as a device driver but does not perform any work. I hope it helps. Regards Sol

Freescale MQX incluye un BSP que soporta funciones y periféricos comúnmente usados. Sin embargo en aplicaciones muy específicas puede ser necesario el desarrollo o modificación de uno o varios “Drivers”. El siguiente documento explica cómo crear y agregar un nuevo driver al BSP en MQX. El documento está escrito en español. Espero que les sea útil. Saludos Sol

The Kinetis Software Development Kit (KSDK) is a software framework for developing applications on Kinetis MCUs. The software components in the framework include peripheral drivers, middleware and real time operating systems. KSDK provides FreeRTOS OS, selected drivers provide FreeRTOS support in form of an additional layer. This solution enables simple driver integration in RTOS-based applications. Drivers with FreeRTOS layers are: • UART / LPUART / LPSCI • I2C / LPI2C • SPI / LPSPI The drivers for FreeRTOS OS is a layer built on top of standard KSDK peripheral drivers to achieve multithread (RTOS) awareness. The wrappers provide an API which blocks the calling task until the I/O operation completes and allows other tasks to run in the background. This is achieved by using the asynchronous API of the underlying driver along with RTOS task synchronization objects. Underlying drivers require enabled interrupts for proper operation. In addition, it is possible to use the KSDK bare metal drivers. This document shows how to use the LPTMR Driver in a FreeRTOS and SDK 2.0 project. For this example it is used SDK 2.0, FRDMK64F and FreeRTOS. If you want to know how to create a new SDK 2.0 with FreeRTOS project please check the below link: https://community.freescale.com/docs/DOC-330183 GPIO AND LPTMR EXAMPLE: Introduction This example toggle the Blue LED every 1 second. This example check the Timer Compare Flag bit, when this flag is set blue LED changes status. Writing the example code First it is necessary to create a new SDK 2.0 with FreeRTOS project, please check the below link for do that.      https://community.freescale.com/docs/DOC-330183    2. After create a new project, open the pin_mux.c file in order to enable the port clock and configure the necessary pins as GPIO (for FRDM-K64F the RGB LED is connected   through GPIO signals: RED to PTB22, BLUE to PTB21 and GREEN to PTE26).   3. In addition, it is necessary to enable the clock for the lptmr module, in the pin_mux.c file.   4. In main.c file it is necessary to include the fsl_lptmr.h and fsl_gpio.h.   5. In main function, create a new task. This task will initialize the LPTMR and GPIO drivers. For this example the new task function was named task_init. /* Create RTOS task */    xTaskCreate(                  task_init,                  "Task_Init",                  configMINIMAL_STACK_SIZE,                  NULL,                  task_PRIORITY,                  NULL);     6. Write the task_init function code.                   a. Using the KSDK GPIO driver: To initialize the GPIO, define a pin configuration, either input or output, in the user file. Then, call the GPIO_PinInit() function. In this case the pin PTB21 where blue LED is connected was configured as output. gpio_pin_config_t ledB_config = {kGPIO_DigitalOutput, 0,}; GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config); After configure the GPIO pins, it is possible to use the below GPIO operations: GPIO OUTPUT OPERATIONS. GPIO_WritePinOutput  (GPIO_Type *base, uint32_t pin, uint8_t output) GPIO_SetPinsOutput (GPIO_Type *base, uint32_t mask) GPIO_ClearPinsOutput (GPIO_Type *base, uint32_t mask) GPIO_TogglePinsOutput (GPIO_Type *base, uint32_t mask) GPIO INPUT OPERATIONS. GPIO_ReadPinInput (GPIO_Type *base, uint32_t pin) The board.h file contains definitions for this operations. For example: /*!< Toggle on target LED_BLUE */ #define LED_BLUE_TOGGLE() \ GPIO_TogglePinsOutput(BOARD_LED_BLUE_GPIO, 1U << BOARD_LED_BLUE_GPIO_PIN)                   b. Using the KSDK LPTMR driver: The LPTMR_Init () should be called at the beginning of the application using the LPTMR driver. This function initializes the lptmr_config_t structure, this structure holds the configuration settings for the LPTMR peripheral. To initialize this structure to reasonable defaults, call the LPTMR_GetDefaultConfig () function and pass a pointer to your config structure instance. The config struct can be made const so it resides in flash. The default values are: config->timerMode = kLPTMR_TimerModeTimeCounter; config->pinSelect = kLPTMR_PinSelectInput_0; config->pinPolarity = kLPTMR_PinPolarityActiveHigh; config->enableFreeRunning = false; config->bypassPrescaler = true; config->prescalerClockSource = kLPTMR_PrescalerClock_1; config->value = kLPTMR_Prescale_Glitch_0; After configure the LPTMR, it is necessary to set the timer period. The LPTMR_SetTimerPeriod(), the timer counts from 0 till it equals the count value set here. The count value is written to the CMR register. Finally start the timer using the LPTMR_StarTimer (). After calling this function, the timer counts up to the CMR register value. Each time the timer reaches CMR value and then increments, it generates a trigger pulse and sets the timeout interrupt flag. An interrupt will also be triggered if the timer interrupt is enabled. For this example the below lines configure and start the LPTMR. /* Configure LPTMR */ LPTMR_GetDefaultConfig(&lptmrConfig); /* Initialize the LPTMR */ LPTMR_Init(LPTMR0, &lptmrConfig); /* Set timer period */ LPTMR_SetTimerPeriod(LPTMR0, USEC_TO_COUNT(1000000U, LPTMR_SOURCE_CLOCK)); /* Start counting */ LPTMR_StartTimer(LPTMR0);                   c. This example check the Timer Compare Flag bit, when this flag is set blue LED changes status. So in an infinity loop the LPTMR_GetStatusFlags() function check                       the status flag, if this flag is set then toggle the LED and clear the flag using the the LPTMR_ClearStatusFlags() function. while (1)    {    if (LPTMR_GetStatusFlags(LPTMR0) )           { LED_BLUE_TOGGLE();                       LPTMR_ClearStatusFlags(LPTMR0, kLPTMR_TimerCompareFlag);                } }   7. At this point you can build and debug the example. Complete Code GPIO and LPTMR Example #include <string.h> #include "board.h" #include "pin_mux.h" #include "clock_config.h" #include "fsl_debug_console.h" #include "fsl_device_registers.h" #include "fsl_lptmr.h" #include "fsl_gpio.h" /* FreeRTOS kernel includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "timers.h" /* Task priorities. */ #define task_PRIORITY (configMAX_PRIORITIES - 1) /******************************************************************************* * Definitions ******************************************************************************/ /* Get source clock for LPTMR driver */ #define LPTMR_SOURCE_CLOCK CLOCK_GetFreq(kCLOCK_LpoClk) static void task_init(void *pvParameters); /******************************************************************************* * Variables ******************************************************************************/ volatile uint32_t lptmrCounter = 0U; int main(void) {        /* Init board hardware. */        BOARD_InitPins();        BOARD_BootClockRUN();        BOARD_InitDebugConsole();        /* Add your code here */        /* Create RTOS task */        xTaskCreate(                      task_init,                      "Task_Init",                      configMINIMAL_STACK_SIZE,                      NULL,                      task_PRIORITY,                      NULL);        vTaskStartScheduler();        for(;;) { /* Infinite loop to avoid leaving the main function */               __asm("NOP"); /* something to use as a breakpoint stop while looping */        } } static void task_init(void *pvParameters) {        for (;;) {               lptmr_config_t lptmrConfig;               PRINTF("You are running the initialization task.\r\n");               /* Init output LED GPIO. */               gpio_pin_config_t ledB_config = {kGPIO_DigitalOutput, 0,};               GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config);               PRINTF("LED BLUE initialized \r\n");               /* Configure LPTMR */               /*                * lptmrConfig.timerMode = kLPTMR_TimerModeTimeCounter;                * lptmrConfig.pinSelect = kLPTMR_PinSelectInput_0;                * lptmrConfig.pinPolarity = kLPTMR_PinPolarityActiveHigh;                * lptmrConfig.enableFreeRunning = false;                * lptmrConfig.bypassPrescaler = true;                * lptmrConfig.prescalerClockSource = kLPTMR_PrescalerClock_1;                * lptmrConfig.value = kLPTMR_Prescale_Glitch_0;                */               LPTMR_GetDefaultConfig(&lptmrConfig);               /* Initialize the LPTMR */               LPTMR_Init(LPTMR0, &lptmrConfig);               /* Set timer period */               LPTMR_SetTimerPeriod(LPTMR0, USEC_TO_COUNT(1000000U, LPTMR_SOURCE_CLOCK));               PRINTF("Low Power Timer module initialized \r\n");               /* Start counting */               LPTMR_StartTimer(LPTMR0);               while (1)               {                      if (LPTMR_GetStatusFlags(LPTMR0) )                      {                            lptmrCounter++;                            LED_BLUE_TOGGLE();                            LPTMR_ClearStatusFlags(LPTMR0, kLPTMR_TimerCompareFlag);                      }               }        } }

The new Freescale MQX™ 4.1.2 GA for Vybrid release is now available on www.freescale.com/mqxrtos ·      Files available                   # Name Description 1 Freescale MQX RTOS 4.1.2 for Vybrid Linux Base This   release has the same basic code as the 4.1.2 version, with just the changes   needed to build and debug on Linux systems. 2 Freescale MQX RTOS 4.1.2 for Vybrid MQX™ Source   code. Includes an RTOS, File System, TCP/IP and USB host/device software   stacks. Does not require MQX™ 4.1.1 installation. ·         What is New? ·         New Board Support Package ·         X-SVF522R-EVB Vybrid Evaluation Board Rev. B with the SVF522R3MK4 processor. ·         TWR-VF65GS10 Development Kit Rev. H with the MVF61NS10MK50 processor. ·         New Features and Updates ·         BSP package for TWR-VF600 was replaced by new TWR-VF65GS10 ·         Vybrid Auto EVB board was replaced by new X-SVF522R-EVB board ·         MFS library was updated ·         New USB stack was added ·         Exception support for cortex A kernel ·         Video ADC + VIU example application ·         RTCS package was updated ·         Known issues ·         For known issues and limitations please consult the release notes