# MQX Software Solutions Knowledge Base

cancel
Showing results for
Did you mean:

# MQX Software Solutions Knowledge Base

Sort by:

## Creating MQX 4.0 BSP for K10

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

## Writing to a Compact flash

If anybody meets an issue with MQX 3.8 (also 3.8.1, 4.0 and 4.0.1) writing to a Compact flash (/mfs/examples/cfcard), there is an error in the cfcard io driver. Compact flash can be read, but writing doesn't work. Fix for this is in the source file: c:\Freescale\Freescale MQX 3.8\mqx\source\io\pcflash\apcflash.c in function _io_apcflash_write() on line 452, change from: results = _io_apcflash_read_write_blocks(fd_ptr, info_ptr, data_ptr, num, FALSE); change to: results = _io_apcflash_read_write_blocks(fd_ptr, info_ptr, data_ptr, num, TRUE); Tested on M5329EVB and MQX 3.8.1.

## Using TWR-SER2 with TWR-K70F120M for Ethernet

TWR-K70F120M running MQX and RTCS can work with the Dual Phy on TWR-SER2. Below I list the modifications I did to the default BSP: 1) I add phy_dp83xxx.c and phy_dp83xxx.h to the bsp_twrk70f120m build project. These files are with MQX in /mqx/source/io/enet/Phy 2) I modify the BSP to use DP83xxx PHY for the Ethernet MACNET: in the /mqx/source/bsp/twrk70f120m/init_enet.c: #include "phy_dp83xxx.h" const ENET_IF_STRUCT ENET_0 = {      &MACNET_IF,      //&phy_ksz8041_IF,      &phy_dp83xxx_IF,      MACNET_DEVICE_0,      MACNET_DEVICE_0,      BSP_ENET0_PHY_ADDR,      BSP_ENET0_PHY_MII_SPEED }; 3) MDIO line requires an external pull up resistor, per DP83849I Data sheet. As I didn't have one at the moment, I enable internal pull up on MCU pin PTB0. in the /mqx/source/bsp/twrk70f120m/init_gpio.c: //pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK; /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* internal pull up enabled on MDIO */ pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK | PORT_PCR_PE_MASK | PORT_PCR_PS_MASK; With these changes, the RTCS applications work over TWR-SER2 Dual PHY channel A. On TWR-SER2, J8 and J9 are un-shunted, SW1 = 11000000, SW2 = 10100000 on TWR-K70F120M, J18 is configured to disable 50 MHz OSC, as I use 50 MHz clock source from TWR-SER2 U504 50 MHz output. This clock is used to provide reference clock for the MCU (EXTAL), as well as for the Dual PHY X1 input (RMII reference clock).

## Introduction to SPI interface

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 v5 is Coming!

MQXv5 is Coming! NXP has teamed up with Embedded Access to continue active development of MQX software solutions, providing regular updates, enhancements and ports to new processors. With the introduction of MQX v5, an extension to MQX Classic v4.2, and with new commercial licensing, developers can continue to use MQX with the latest Kinetis, i.MX, and other processors. Compare MQX Classic and MQX v5 by visiting nxp.com/MQX. Then, give us your feedback on which devices and features you’d like supported in this newest addition, MQX v5. Note, the first MQX v5 products are expected to be available near the end of Q3, 2016. MQX v5 products will be purchasable at nxp.com/mqxv5 and through distribution partners.

## Now Available: MQX v4.2.0.2 Patch

A new patch, MQX v4.2.0.2, is now available at www.nxp.com/mqxclassic​.This release comes in one download that contains both .zip packages and patch files. See the Release Notes (attached) for a full list of issues that are fixed in this release. The Release Notes also contain instructions for how to install via the .zip or patch files. To Download the patch: 1. go to www.nxp.com/mqxclassic 2. Click the "Download" button (below the Overview paragraph) -- you may be prompted to Sign In 3. Click on "MQX RTOS v4.2 releases and patches" 4. Review and click through the license agreement 5. Click on "MQX 4.2.0.2 Patch.zip"