A pair of TCP server & client and a pair UDP server & client are implemented to demo socket API in RTCS. It supports K60N512 and K70F120M on IAR EWARM 6.50 at this moment. You can port it to other boards and IDE easily. 1) Copy Freescale_MQX_4_0 folder and override the default MQX folder 2) RTCS Socket Example Guide.doc can be found in ..\Freescale_MQX_4_0\rtcs\examples\socket

Quick Overview of FreeRTOS vs MQX RTOS MQX  real-time operating system is designed for uniprocessor, multiprocessor, and distributed-processor embedded real-time system. Freescale semiconductor adopted this software platform for its microprocessors.  This includes Kinetis, Coldfire, PowerPC, ARC,ARM, StrongARM, xscale CPUs. The main features of MQX RTOS are scalable size, component-oriented architecture and easy of use. FreeRTOS is a popular real-time operating system kernel for embedded devices, that has been ported to 35 architectures. It is distributed under the GPL with an optional exception. FreeRTOS provides a very small footprint, low overhead and very fast execution. The kernel itself consist of only three or four C files. 4-8k bytes of flash minimum. Similar features : [to be done] Tasks, events, semaphores,mutex, message queues, power saving when idle                                                                  Freertos unique features : 1 Task nofifications: Each RTOS task has a 32-bit notification value which is initialized to zero when the RTOS task is created. An RTOS task notification is an event sent directly to a task that can unblock the receiving task, and optionally update the receiving task’s notification value. 2 Recursive mutex:  A mutex used recursively can be 'taken' repeatedly by the owner. The mutex doesn't become available again until the owner has called xSemaphoreGiveRecursive() for each successful xSemaphoreTakeRecursive() request. For example, if a task successfully 'takes' the same mutex 5 times then the mutex will not be available to any other task until it has also 'given' the mutex back exactly five times. 3 Stack overflow hook/notification: Each task maintains its own stack. The memory used by the task stack is allocated automatically when the task is created, and dimensioned by a parameter passed to the xTaskCreate() API function. Stack overflow is a very common cause of application instability. FreeRTOS therefore provides two optional mechanisms that can be used to assist in the detection and correction of just such an occurrence 4 Deferred interrupt handling:  Used from application interrupt service routines to defer the execution of a function to the RTOS daemon task. A mechanism is provided that allows the interrupt to return directly to the task that will subsequently execute the pended function. This allows the callback function to execute contiguously in time with the interrupt - just as if the callback had executed in the interrupt itself 5 Blocking on multiple objects:  Queue sets are a FreeRTOS feature that enables an RTOS task to block (pend) when receiving from multiple queues and/or semaphores at the same time. Queues and semaphores are grouped into sets, then, instead of blocking on an individual queue or semaphore, a task instead blocks on the set. MQX unique features: 1 Destruction of resource based on ownership:  [to be done] 2 Name services:  tasks can associate a 32-bit number with a string or symbolic name.MQX RTOS stores the association in a names database that all tasks on the processor can use. The database avoids global variables. 3 Inter-Processor Communication:  An application can run concurrently on multiple processors with one executable image of MQX RTOS on each processor. The images communicate and cooperate using messages that are transferred by memory or over communication links using inter-processor communication. The application tasks in each image need not be the same and, indeed, are usually different. 4 Watchdogs: Watchdogs are option components that let the user detect task starvation and deadlock conditions at the task level. 5 Task Queue Scheduling:  you can use task queues to explicitly schedule tasks or to create more complex synchronization mechanisms. Because task queues provide minimal functionality, they are fast. An application can specify a FIFO or round robin scheduling policy when it creates the task queue

Sharing notes taken during creation of MQX 4.0 K10 BSP. These particular notes are for 72 MHz version of K10 (part number K10DX128VLL7), so the baseline BSP for this is twrk20d72m, tested with CodeWarrior IDE. (I believe analogous steps could be taken for other K10 versions as well, just need to select appropriate baseline BSP.) For the K10 BSP, we need to remove USB related code (as there is no USB module on K10) and add #elif into some *mk20.c files such as adc_mk20.c and spi_mk20.c.      1. Add a new unique CPU ID into c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\psp_cpudef.h. For example: #define PSP_CPU_MK10DX128       (PSP_CPU_NUM(PSP_CPU_ARCH_ARM_CORTEX_M4, PSP_CPU_GROUP_KINETIS_K1X, 4))      2. Copy processor header file MK10D7.h from c:\Freescale\CW MCU v10.3\MCU\ProcessorExpert\lib\Kinetis\iofiles\MK10D7.h to c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\cpu\mk10d7.h      3. In the header file: c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\kinetis.h add #include "MK10D7.h" for your processor. For example: #elif   (MQX_CPU == PSP_CPU_MK10DX128)    #include "MK10D7.h"      4. Use BSP clone tool to clone baseline BSP (twrk20d72m) into a new BSP with a new name such as "board_k10d72m".      5. In user_config.h of the new BSP, c:\Freescale\Freescale_MQX_4_0\config\board_k10d72m\user_config.h change MQX_CPU as it follows: #define MQX_CPU                 PSP_CPU_MK10DX128      6. PSP builds OK. From BSP, we need to remove USB related code in init_gpio.c comment lines 609 and 612 c:\Freescale\Freescale_MQX_4_0\mqx\source\bsp\board_k10d72m\init_gpio.c: /* SIM_SOPT2_REG(SIM_BASE_PTR) |= SIM_SOPT2_USBSRC_MASK | SIM_SOPT2_PLLFLLSEL_MASK;*/ /* SIM_SCGC4_REG(SIM_BASE_PTR) |= SIM_SCGC4_USBOTG_MASK;*/      7. In CW IDE, remove USB source code from "bsp_board_k10d72m" build project under "Peripheral IO Drivers". Remove complete "usb" virtual folder from the BSP build project. Remove "init_usb.c" from "board_k10d72m BSP Files"      8. In BSP source file "spi_mk20.c" c:\Freescale\Freescale_MQX_4_0\mqx\source\io\spi\spi_mk20.c add #elif for k10: #elif (MQX_CPU == PSP_CPU_MK10DX128) static const pointer dspi_address[] = {    (pointer)SPI0_BASE_PTR,    (pointer)SPI1_BASE_PTR, }; static const uint_32 /*PSP_INTERRUPT_TABLE_INDEX*/ dspi_vectors[][1] = {    { INT_SPI0 },    { INT_SPI1 }, }      9. Similar change need to adc_mk20.c c:\Freescale\Freescale_MQX_4_0\mqx\source\io\adc\kadc\adc_mk20.c: #elif (MQX_CPU == PSP_CPU_MK10DX128) static const pointer adc_address[] = {    (pointer)ADC0_BASE_PTR,    (pointer)ADC1_BASE_PTR };      10. BSP project builds OK.      11. MFS, RTCS, SHELL projects build OK.      12. If you wish to build an MQX application with this new BSP, don't forget to change the paths to MQX libs and include files in your application project: C compiler "-i" option:   (for Debug build configuration)     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\psp     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\mfs     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\rtcs     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\shell     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp\Generated_Code Linker additional libraries:   psp.a, bsp.a, mfs.a, rtcs.a, shell.a Linker Library search paths:   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\psp   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\mfs   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\rtcs   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\shell Path to linker command file:   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp\intflash.lcf

Hello All,   I want to share a client-server project. In this example the server can accept more than one client (Daemon server implementation). This example was created and tested using MQX4.2, CodeWarrior 10.6 and FRDM-K64F boards.     In general, the client-server model is the most common communication model used by the applications such as HTTP, Telnet, FTP, SSH, and others. In a client-server model, the server listens to client requests and waits for new connections. When a client needs to connect to a server, it sends a request. The server acknowledges the request, and if the client is supported by the server, the connection is established.   A TCP client-server communication can be implemented as in the following figure.         SETTING THE RTCS Below are presented the steps required to set the RTCS with the default settings: Create the RTCS. This step reserves memory for different RTCS parameters and initializes the TCP/IP task. Each project (server and client) contains an RTCS.c file which contains the initialize networking function with the RTCS configuration.     Set the RTCS IP address to the device after initialization. The main.h files have the macros and variables that store the IP parameters. You can change the IP address according your needs. In RTCS.c files,  the following code sets the address, mask, gateway and server IP addresses. ip_addr = IPADDR(A,B,C,D); phy_addr = BSP_DEFAULT_ENET_DEVICE; . . . ip_data.ip = ip_addr; ip_data.mask = ENET_IPMASK; ip_data.gateway = 0;     Calculate the MAC address for the device using the variables. Use the ENET_get_mac_address() function to build a valid MAC address for the application. MAC address calculation takes the device number and IP address as parameters, and returns a valid MAC address in the IPCFG_default_enet_address variable.   Initialize the Ethernet device available in the board with the calculated MAC address. Use the ipcfg_init_device() function to tell the RTCS task what Ethernet device should be used and to set the calculated MAC address to that device. Once the MAC address is set and the device is initialized, it is possible to bind the device to the IP address. error = ipcfg_init_device (phy_addr, serverAddress);     After Ethernet device initialization, bind the device to the IP address and it is ready to communicate. /* If DHCP Enabled, get IP address from DHCP server */              if (dhcp) {                     printf("\nDHCP bind ... ");                     error = ipcfg_bind_dhcp_wait(phy_addr, 1, &ip_data);                     if (error != IPCFG_ERROR_OK) {                            printf("Error %08x!\n", error);                     }                     else {                            printf("Successful!\n");                     }              } else {        /* Else bind with static IP */                     printf ("\nStatic IP bind ... ");                     error = ipcfg_bind_staticip(phy_addr, &ip_data);                       if (error != IPCFG_ERROR_OK) {                            printf("Error %08x!\n",error);                     }                     else {                            printf("Successful!\n");                     }              }     SERVER IMPLEMENTATION              For the server implementation, MQX uses a socket structure that is created and filled in this way: laddr.sin_family      = AF_INET; laddr.sin_port        = CONNECT_PORT; laddr.sin_addr.s_addr = INADDR_ANY;   The socket() function creates an unbound socket in a communications domain. This function also returns a handler used in later function calls that operate on sockets. /* Listen on TCP port */ listensock = socket(PF_INET, SOCK_STREAM, 0); if (listensock == RTCS_SOCKET_ERROR) { error = RTCSERR_OUT_OF_SOCKETS; }   The bind() function assigns a local socket address to a socket and the listen() function marks a socket as accepting connections. error = bind(listensock, &laddr, sizeof(laddr)); if (!error) {        error = listen(listensock, 0); }   The accept() function extracts the first connection on the queue of pending connections, creates a new socket with the same socket type protocol and address family as the specified socket, and allocates a new file descriptor for that socket. child_sock = accept(listensock, NULL, NULL);   The recv() function receives a message from a socket. error = recv(sock, (void *)cRecvBuff, sizeof(cRecvBuff), MSG_WAITALL);                     The send() function initiates transmission of a message from the specified socket to its peer. The send() function sends a message only when the socket is connected. error= send(sock, (void *)cRecvBuff, sizeof(cRecvBuff), 0);     The messages received are checked in order to toggle a LED or shutdown the connection. while(1)        {              error = recv(sock, (void *)cRecvBuff, sizeof(cRecvBuff), MSG_WAITALL);              printf("Received: %s\n", cRecvBuff);              if (error == RTCS_ERROR)              {                     printf("There was an error code %lx\n", RTCS_geterror(sock));                     shutdown(sock, FLAG_CLOSE_TX);                     return;              }              if(cRecvBuff[0]=='T')              {                     printf("Received: %s\n", cRecvBuff);                     printf("LED was toggled from child\r\n");                     lwgpio_toggle_value(&led1);              }              if(cRecvBuff[0]=='G')              {                                              printf("Received: %s\n", cRecvBuff);                     printf("Shutting down connection\n");                     shutdown(sock,FLAG_CLOSE_TX);                     _time_delay(2000);                      _task_abort(MQX_NULL_TASK_ID);              }            }            CLIENT IMPLEMENTATION   For the client implementation, it uses a socket structure that is created and filled in this way: addr.sin_family      = AF_INET; addr.sin_port        = DESTPORT; addr.sin_addr.s_addr = IPADDR(192,168,1,200); //Server address   The socket() function creates an unbound socket. sock = socket(PF_INET, SOCK_STREAM, 0);     The connect() function attempts to make a connection on a socket. error = connect(sock, &addr, sizeof(addr));        The recv() function receives a message from a socket. error= recv(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);          The send() function sends a message only when the socket is connected (including when the peer of a connectionless socket has been set via connect() function). error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);          In addition the client example can toggle a LED in the server board or destroy the socket. /*****Infinite loop waiting for user to push a button***/ while(1){        if(lwgpio_get_value(&btn1) == LWGPIO_VALUE_LOW)        {              _time_delay(150);              sprintf((char *)cReadBuff, "Toggle from client2\n");              printf("Sending: %s", cReadBuff);              error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);              if (error == RTCS_ERROR)              {                     printf("There was an error trying to send to the server\n");                     return;              }        }        if(lwgpio_get_value(&btn2) == LWGPIO_VALUE_LOW)        {              _time_delay(150);              sprintf((char *)cReadBuff, "GoodBye\n");              printf("Sending: %s", cReadBuff);              error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);              if (error == RTCS_ERROR)              {                     printf("There was an error trying to send to the server\n");                     return;              }              printf("Shutting down connection\n");              shutdown(sock,FLAG_CLOSE_TX);              _task_abort(MQX_NULL_TASK_ID);        }       I hope this helps, Soledad Original Attachment has been moved to: ClientD_FRDM-K64_MQX4_2_CW10_6.zip Original Attachment has been moved to: ServerDeamon_FRDM-K64_MQX4_2_CW10_6.zip

Hello I want to share this document that describes steps to configure and use the MQXLite Performance Tool to analyze and debug the applications of the Freescale MQXLite operating system. I hope this helps!! Regards Soledad

SPI, which stands for Serial Peripheral Interface, is a standard with a very specific hardware interface. A connection is between a master and a slave, with the master typical being a processor, and the slave being a peripheral such as a sensor, flash memory device, or a modem chip.   It can also be used for processor to processor communications, but in this case, an additional handshake signal is often used. There are normally four signals between a master and a slave, the first is a clock signal, and this signal is always driven by the master, regard which device is transmitting.  The second line is a data line for data going from the master to the slave, and this is designated as the master output, slave input line, are MOSI for short. It connects the SPI data out connection on the master and to the SPI data in connection on the slave. The next conductor is for data in the opposite direction and is labelled as the master input slave output line, are MISO for short. The last conductor is slave select with the slave chip selecting input, and is active low. If you have more than one slave, with the first being perhaps a sensor of some kind, the slave will be dedicated to slave 1. If you add a second sensor, the top 3 interface line will be shared, but it dedicates for slave’s line will be required for the second device, and the same is true of course for each of additional slave device. Most processors have a maxim of 4 slave selected lines.  The four lines could be used effectively as a multiplexed address lines to access more than 4 slaves. You cannot have more than one master on the bus,   since the interface is not support coordination between two masters as to which one is controlling the bus. Transmissions are typically sent as a sequence of bytes, but without a formal protocol, there is nothing restricting communication being   byte based. Typical by frame sizes, are in 8 to 32 bits range.  Also note the bytes and packets are not acknowledged as they are in i2c, and you could have a master synching communicating with the slave but, you don’t really know of your communications are being received OK. However, some slave devices will echo bytes sent to it, which provides an acknowledgement to the master.  it is how the data lines are synchronized with a clock signal. Clock Polarity and Phasing There are four different modes available, one mode each combination clocking in a low state and high state, with a data being read in a rising edge or falling edge of the clock signal.  For modes 0 and 1, the clock is low in idle, which is referred to  as clock and 0,  For modes 2 and 3 then the clock is in high state when idle, so it has  polarity  , one , For modes 0 and 2, the data will be sampled by the receiving device  on the leading edge of a clock signal.  Relative to the idle state, which is referred to a clock phase of zero. So for mode 0, this means the rising edge of the clock and for mode 2, means the following edge of the clock, the other two modes, use a clock phase 1 which means that trailing edge of clock as a returns to an  idle state.  And this translates to a following edge for mode 1 and the rising edge for mode 3.  Mode 0 is the most commonly supported setting. If multiple slaves in the same bus, you may have to reconfigure the settings for the master to which modes when you want to communicate with a different slave.

MQX RTOS developers can now build and debug MQX RTOS on Linux computers right out-of-the-box without extensive setup steps.  Linux support is provided in a separate version of MQX 4.1.0, repackaged for use on Linux systems.  Kinetis & Vybrid BSPs from MQX 4.1.0 are supported.  The new package is in beta stage.  It includes the same basic code as the previous 4.1.0 version, with just the changes needed to build and debug on Linux systems. Download Freescale MQX RTOS 4.1.0 for Linux Beta Depending on the popularity of this release, Freescale may extend Linux support to future MQX RTOS mainline releases.  Stay tuned. Give us your feedback!  Post to the MQX community.  Let us know what you think. Development tools Supported: DS-5 Vybrid Controller Edition 5.16.0  (Vybrid) GNU Tools for ARM Embedded Processors version 4.7-2013-q3  (Kinetis & Vybrid) Here are some brief instructions I put together when using with Ubuntu 12.04: - Download and install gcc for arm (comes with gdb for debugging)   See other post:  gcc compiling + gdb debugging on Kinetis on a Linux host - Kinetis L Examples available - Download and extract the .tar.gz file to a location of your choice    mac@mac-VirtualBox:/$  tar -zxvf Freescale_MQX_4_1_LINUX_beta.tar.gz - Edit global.mk to tell it where your gcc toolchain is located.    mac@mac-VirtualBox:/$ cd <directory where you extracted mqx>/Freescale_MQX_4_1_LINUX_beta/build/common/make/    mac@mac-VirtualBox:/$ vi global.mak    un-comment the section on gcc_arm and set the TOOLCHAIN_ROOTDIR.  For my toolchain gcc is installed to the path /usr/    ifreq ($(TOOL),gcc_arm)        TOOLCHAIN_ROOTDIR  =  /usr/   endif - See  MQX GNU Getting Started Guide for instructions on how to build and debug.     This document is located at /Freescale_MQX_4_1_LINUX_beta/doc/tools/gnu/ Good luck with your next project.  Happy developing!

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.

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

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 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

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.

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