Wireless Charging Lets You Cut that Cord! If you may risk a dead battery in your Smartphone, table PC, or digital smart watch, or you get tangled up with the wrong charger cord on your nightstand or office desk, the simplicity of a wire-less charger is your dream come true! But wireless chargers need a lot of technology and are not created equal. NXP's family of Transmitter and Receiver components offer solutions for both the Qi and Rezence standards. We take a look at both and offer some practical hardware solutions to cut that cord. If you may risk a dead battery in your Smartphone, table PC, or digital smart watch, or you get tangled up with the wrong charger cord on your nightstand or office desk, the simplicity of a wire-less charger is your dream come true! But wireless chargers need a lot of technology and are not created equal. NXP's family of Transmitter and Receiver components offer solutions for both the Qi and Rezence standards. We take a look at both and offer some practical hardware solutions to cut that cord.

4-Layer Automotive Cyber Security Solution Demo NXP has developed a whole vehicle multi-layered approach to vehicle security.  This demo will demonstrate the NXP security products in action, and show the 4 steps to securing an automotive electrical architecture, and how these 4 steps provide a barrier to the recent public vehicle hacks.   Features: Try to hack a typical automotive network. Enable and disable NXPs security layers to see how they work to protect the vehicle. Demonstrates various NXP security IP, including: A700x family secured MCUs, MPC5748G connected gateway and HSM/CSE security engines. ___________________________________________________________________________________________________________________________   NXP Recommends MPC5748G|NXP A700x|NXP   ___________________________________________________________________________________________________________________________       Automotive

Example MPC5748G BCTU GHS614 ******************************************************************************** * Detailed Description: * This example implements ADC driver and demonstrated the usage of ADC in BCTU mode. * When PIT timer exceeds the trigger is sent to BCTU and BCTU triggers ADC_0 conversion. ******************************************************************************** * Test HW:  MPC57xx * Maskset:  1N81M * Target :  SRAM * Fsys:     160 MHz PLL * ******************************************************************************** Revision History: 1.0     Oct-29-2014     b21190(Vlna Peter)  Initial Version 1.1    Nov-20-2014    b21190(Vlna Peter)  Modified for Cut2.0 1.2    Nov-20-2014    b21190(Vlna Peter)  Added SWT_0 dissabling in startup 1.3    Mar-10-2016    b21190(Vlna Peter)  Fixed clock configuraion for PLL 1.4    Mar-10-2016    b21190(Vlna Peter)  Added ADC driver 1.5    Mar-16-2016    b21190(Vlna Peter)  Added BCTU and PIT drivers *******************************************************************************/ ******************************************************************************** * Detailed Description: * This example implements ADC driver and demonstrated the usage of ADC in BCTU mode. * When PIT timer exceeds the trigger is sent to BCTU and BCTU triggers ADC_0 conversion. ******************************************************************************** * Test HW:  MPC57xx * Maskset:  1N81M * Target :  SRAM * Fsys:     160 MHz PLL * ******************************************************************************** Revision History: 1.0     Oct-29-2014     b21190(Vlna Peter)  Initial Version 1.1    Nov-20-2014    b21190(Vlna Peter)  Modified for Cut2.0 1.2    Nov-20-2014    b21190(Vlna Peter)  Added SWT_0 dissabling in startup 1.3    Mar-10-2016    b21190(Vlna Peter)  Fixed clock configuraion for PLL 1.4    Mar-10-2016    b21190(Vlna Peter)  Added ADC driver 1.5    Mar-16-2016    b21190(Vlna Peter)  Added BCTU and PIT drivers *******************************************************************************/ General

Using QMAN Dedicated and Pool Channels in USDPAA and Linux Kernel When the frames on a FQ are ready to be processed, the FQ is enqueued onto a work queue(WQ). WQ are organized into channels. A channel is a fixed, hardware-defined association of 8 work queues, also though of “priority work queues”. There are two types of WQ channels defined in QMAN: Dedicated channels, which are always serviced by a single entity. Pool channels, which are serviced by pool of like entities, such as a pool of processor cores. This document describes the basic concept regarding dedicated and pool channels, how to use dedicated and pool channels in flow order Preservation scenarios, work queue channel assignment, dedicated and pool channel used in Linux Kernel and how to modify PPAC and USDPAA QMAN driver to using dedicated channels in USDPAA applications. 1. Basic Concept of QMAN Channels 2. Dedicated Channel Used in Flow Order Preservation Scenario 3. Pool Channel Used in Order Preservation with Hold Active Scheduling 4. Work Queue Channel Assignment 5. Dedicated and Pool Channels Usage in Linux Kernel 6. Using Dedicated Channel in USDPAA QorIQ P2 Devices QorIQ P3 Devices QorIQ P4 Devices QorIQ P5 Devices

How to install/check if my floating license file is running ? (known issues) How to install/check if my floating license file is running ?                                                   + Known issues for CW for PA V10.4, CW for MCU V10.6, CW for HC12 V5.1, ...       Most of the time the “Product Licenses” is working fine but there are some cases where the information provided in the Product Licenses dialog are wrong. This is the case for: USBdongle license file is used for NL, Floating license file.     What’s about the Floating License file ? A Floating license requires a PC defined as server (which can be a client too) and other PC(s) defined as client(s).     How to install a floating license file ?   A client has 3 ways to contact the server (in fact the service running on server): Using license.dat file – same file used by server and client Using Environment variable LM_LICENSE_FILE= port@host  (METROWKS_LICENSE_FILE=port@host) Using Environment variable LM_LICENSE_FILE= port-daemon@host  (METROWKS_LICENSE_FILE=port-daemon@host)     On server side On server you must have a service managing the floating license file. You must download the Flexlm tool available on web site: http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_LICENSE_FXDL_LMI   Please have a look to the documentation for more details: http://cache.freescale.com/files/soft_dev_tools/doc/brochure/FLTLICINSTWINBR.pdf   The license must be locked on the Server DiskID (vol C:) or HostID. You can check if the license is running by: Server Status + Perform Status Enquiry, Server Diags + Perform Diagnostics     On Client side The client has 3 ways to contact the server but only 1 of these ways must be used. Sometimes the 3 ways are running and sometimes only the port@host or port-daemon@host can be used. This is directly linked to your LAN structure.     How the tool is checking the license ?   Case A: By default the tool tries to find the license.dat in the installation folder. It could be C:\Freescale\CW_PA_v10.4.0\PA\license.dat -> this is the first way   Else if a LM_LICENSE_FILE or METROWKS_LICENSE_FILE environment variable is defined, the system will check all variables defined in this environment variables. Here there are 2 ways to define the license.dat.   Case B: If the license.dat is not placed in the default folder (Case A). You must set the environment variable. For instance the license.dat is placed in C:\Freescale\license_all\license.dat You should have: LM_LICENSE_FILE=C:\Freescale\license_all\license.dat or METROWKS_LICENSE_FILE=C:\Freescale\license_all\license.dat   Case A and B required than the same license file used by the server is used on the client.   Case C: No license.dat file is used on client. Using LM_LICENSE_FILE or METROWERKS_LICENSE_FILE environment variables allow you to define a server and a port. This information must be compliant with the license file defined on server. Example of license file: SERVER My_server_name 00123456789A 1710 Server Name: My_server_name Port: 1710 To access this server you must use: LM_LICENSE_FILE=1710@My_server_name or METROWKS_LICENSE_FILE=1710@My_server_name   Case 😧 Now depending of your LAN, this is the case for complex architecture (different subnets, access via VPN, etc),the Case C (as case A & B) could not work. The solution is to define a port on the daemon. Extract of new license file: SERVER My_server_name 00123456789A 1710 VENDOR metrowks port=27000 To access the license file you can use port-daemon@host LM_LICENSE_FILE=27000@My_server_name or METROWKS_LICENSE_FILE=27000@My_server_name   Most of the time we recommend to check floating license in order: - Case A, - Case B, if it's not working then you can try - Case C, - Case D.     How to check if a license file is running ?   For floating license, the info provided in the License details could be corrupted. You can have a message saying the license file is not found or not running whereas the tool is working fine. The information is not really relevant for Floating license. The right way to check if the license is running is to: - open/create a project, - build the project. On the server, the log file captures all accesses done to the service If there is an issue, the problem will be captured in the log file.   The log file contains lot of information to understand what is the problem (If there is one). To generate this file, on the server, launch lmtools and select Config Services tab. Inside "Path to the debug log file" field define a file as - for instance CW for PA v10.4: If the C:\FSL_FlexLM\license_PA_10_4.log is already generated, I recommend you to: - stop the service, - delete the log file via explorer, - re-start the service, - reproduce the problem on client, - try with an example project requiring a license file, - stop the service.   Open the log file to check how the floating license file is used.       Specific trouble for CW for PA V10.4 & CW for MCU V10.6     Under PA V10.4 for instance when the port@host environment variable is used and the service is running on server, when we launch Eclipse we get a wrong license information: According to the message the license file is not found.   For MCU V10.6, the Help + Freescale Licenses menu is not available. PA v10.4 and MCU V10.6 using port@host protocol gives you the same message than if no license file was used/defined. It seems the Product is not detect when the LM_LICENSE_FILE Environment variable is using port@host.   Most of the time the license file is running fine. Is there a way to check it ?                 ……….. YES, generate the log file as explained above.   You can use the project examples for CW for MCU V10.6 and CW for PA V10.4 provided in the                                 https://community.freescale.com/docs/DOC-105542   Attached a video showing the behavior when port@host is used with CW for MCU V10.6       Specific trouble for CW for HC12 V5.1   As explained above a client has 3 ways to contact the server:      - Using license.dat file – same file used by server and client      - Using Environment variable LM_LICENSE_FILE= port@host (METROWKS_LICENSE_FILE=port@host)      - Using Environment variable LM_LICENSE_FILE= port-daemon@host  (METROWKS_LICENSE_FILE=port-daemon@host)   We used the following configuration:           Server: Win 7 64 bit           Client: Win XP 32 bit           CodeWarrior for HC12 v5.1 using a project requiring a suite Basic or higher (attached license_test_project.zip - using the simulator)   Description Using the license.dat or the LM_LICENSE_FILE= port@host, we can build the project but not debug it:      - When the IDE is launched, we got a message “This is the last day …”      - We can build the project without problem. The license file is reconized      - When we launch the debugger we got an error saying the debugger is running at demo mode. If we check the log file generated by the server, we see the client is asking for compiler and linker keys but no entries for the debugger key. If the Server and Client is the same PC, the license is working as expected. The problem occurs only when the server and client are different PCs   Solution: We found the LM_LICENSE_FILE= port-daemon@host is working. The IDE is launched without message (This is the last day …) and we can build and debug an application without problem. General

i.MX6SX SDB 板的 PCIE 测试报告 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 当客户想在i.MX6SX SDB板上使用PCIE模块时，可以使用振荡器进行预设置，并有测试报告。 i.MX6S

Example MPC5604P PinToggleStationery CW210 ******************************************************************************** * Detailed Description: * Application performs basic initialization, setup PLL to maximum allowed freq., * initializes interrupts, blinking one LED by interrupt, * initializes and display notice via UART terminal and then terminal ECHO. * * You can choose TRK or Minimodule version using USED_BOARD macro * * ------------------------------------------------------------------------------ * Test HW:         XPC560P 100LQFP, XPC56XX EVB MOTHEBOARD Rev.B, TRK-MPC5604P Rev.B * MCU:             PPC5604PEFMLL 0M36W * Terminal:        19200-8-no parity-1 stop bit-no flow control on LINFLEX_0 * Fsys:            64/40 MHz * Debugger:        Lauterbach Trace32 *                  PeMicro USB-ML-PPCNEXUS * Target:          RAM, internal_FLASH * EVB connection:  Jumper J8 1st position fit LED1 connected to PE4, jumpers J22,23 position 2-3 fit SCI tx and rx connected * ******************************************************************************** ******************************************************************************** * Detailed Description: * Application performs basic initialization, setup PLL to maximum allowed freq., * initializes interrupts, blinking one LED by interrupt, * initializes and display notice via UART terminal and then terminal ECHO. * * You can choose TRK or Minimodule version using USED_BOARD macro * * ------------------------------------------------------------------------------ * Test HW:         XPC560P 100LQFP, XPC56XX EVB MOTHEBOARD Rev.B, TRK-MPC5604P Rev.B * MCU:             PPC5604PEFMLL 0M36W * Terminal:        19200-8-no parity-1 stop bit-no flow control on LINFLEX_0 * Fsys:            64/40 MHz * Debugger:        Lauterbach Trace32 *                  PeMicro USB-ML-PPCNEXUS * Target:          RAM, internal_FLASH * EVB connection:  Jumper J8 1st position fit LED1 connected to PE4, jumpers J22,23 position 2-3 fit SCI tx and rx connected * ******************************************************************************** General

DwFワルシャワ - 2015-06-18 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 自動車およびコネクテッドカー スマートインダストリー インサイトとイノベーション スマートシティ スマートホームとスマートビルディング スマートネットワーク

DwF Kinetis MCUs Based on ARM® Technology - Wuhan - 2015-05-27 Design, Software and Services ZLG: Core Boards Insight and Innovation Smart Industry Analog and Sensor in Industrial Applications Freescale Motor Control Solutions

Example MPC5748G Flash RW ******************************************************************************** * Detailed Description: * * Unlock, erase and program of flash mid block 0x00FB_8000 - 0x00FB_FFFF. * ------------------------------------------------------------------------------ * Test HW:        X - PC5748G - MB (rev C) * MCU:             PPC5748GMMN6A * Maskset:       1N81M * Fsys:             160 MHz * Debugger:     Lauterbach Trace32 *             * Target:     Internal_FLASH * ******************************************************************************** General Re: Example MPC5748G Flash RW Hi Lukas Zadrapa !!!    Where can I download  Green Hills MULTI IDE v6.1.4 ? Think you!!! Re: Example MPC5748G Flash RW Is it right? Re: Example MPC5748G Flash RW Hi Anoop, thanks for your comment. You are right, that's copy-paste issue. I uploaded corrected version. Regards, Lukas Re: Example MPC5748G Flash RW Lukas, In the "MPC5748G-Flash_RW-GHS614\source\main.c" file I see the bit settings for LOCK/SEL for Flash blocks on MPC5748G. Shouldn't the Large blocks be using SEL2 instead of SEL0 ? thanks Anoop

ftf-ins-f1223.pdf During this session you will learn about the principal requirements of key classes of sensor applications, Freescale’s sensor portfolio and learn to help solve problems with Freescale sensors. During this session you will learn about the principal requirements of key classes of sensor applications, Freescale’s sensor portfolio and learn to help solve problems with Freescale sensors.

iWave announces i.MX6UL SODIMM Module iWave's i.MX6 UltraLite (i.MX6UL) based SODIMM CPU module integrates power efficient high performance ARM Cortex A7 CPU core operating up to 528MHz speed. iMX6 UL SOM is ultra-compact in size and integrated with on-board PMIC, Flash, DDR3 and dual Ethernet PHY. The SOM is ideally suitable for the cost & power optimized general embedded and industrial applications.                                                                                                                                                                                                                                                                                                    i.MX6UL SODIMM Development Kit    i.MX6UL SODIMM SOM                                                                                                                                                                                                                                                                                                 Benefits: Ultra-compact form factor module with size of 67.6mm x 29mm Long term support: 7+ years Technical & Quick customization support Compatible with ARM Cortex A9 i.MX6 Q/D/S SODIMM SOM Highlights: Power efficient ARM Cortex-A7 @ 528MHz Advanced hardware enabled security PMIC with DVFS support Industrial temperature support available  Features: CPU: Freescale’s i.MX6UL1/2/3 @ 528MHz ARM Cortex A7 PMIC: Freescale PF3000 Memory: 256MB DDR3 RAM(Expandable) 256MB NAND Flash (Expandable) MicroSD Slot (Optional) 1 eMMC Flash (Optional) 1 QSPI Flash (Optional) 1 Communication: 10/100 Ethernet PHY – 2 Ports SODIMM Edge Interfaces: Debug UART Data UART – 2 Ports CAN – 2 Ports SD(4-Bit) – 1 Port 10/100 Ethernet – Up to 2 Ports 2 USB OTG – 2 Ports 24bpp RGB display port 8-Bit Parallel Camera Port I2S Audio or JTAG I2C x 1 Port PWM GPIOs OS Support: Linux 3.14.28 Power Supply: 3.3V @ 1A through SODIMM edge Note 1: At a time either NAND Flash or eMMC & QSPI flash or uSD & QSPI flash can be used in the SOM. By default NAND Flash is supported. Note 2: If 2 nd Ethernet (ENET2) not used, it can be used as additional 3 UARTs or Key pad 4x4 or RMII interface. Target Applications: Industrial HMI & Access Control Energy management & IOT gateway Industrial control & automation White goods & Smart appliances Medical & Healthcare equipments Mobile POS & Secure e-commerces To send us an enquiry on this product, please click here Enquiry Form To get more details on this product, please write us on [email protected]

モーター制御とスマートエネルギーコミュニティへようこそ! <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このコミュニティは、モーター制御とスマートエネルギー全般に関する情報を共有しています。   PMSM、BLDC、ACIM、SR、スマートエネルギーのトピックなど、すべてのモータータイプの制御について議論することができます。通常、アプリケーションはモーター制御ライブラリ(FSLESLおよびAPIトランスレータ)とフレームワークに基づいているため、ソリューションは非常にシンプルになります。   今すぐ貢献を始めましょう! 全般

One-Chip Qi transmitter NXQ1TXH5 Demo The NXQ1TXH5 is a one-chip low power Qi transmitter, and it enables an ultra-low cost wireless charging transmitter dramatically reducing application cost while still providing latest WPC version 1.2 Qi compliant performance.   The NXQ1TXH5 demo is provided in an exciting form-factor with a backlight module on which Qi enabled phones can be charged. The demonstration shows the extremely low component count, which is interesting for professionals to understand, and at the same time showing a real-life eye-catching form-factor that draws non-technically skilled person attention. The demonstration challenges people to actually charge their phone and experience charging without wires.   One of the table modules is provided with a table-fan in which there is a Qi power receiver built-in. It can be used as a standby-demo to further draw attention to the demo, even when no phone is placed, and it avoids phones getting lost when there is no expert attending the demo.     The Qi wireless charging demo consists of a module that can be built into any table, using a 181mm round hole and it can simply be dropped into the hole. It is delivered with a universal mains power supply and hence easy to install. Below pictures show the Qi wireless charging table module demo, as well as dimensions to help building it into available infrastructure.   Demo / product features   Ultra low component count solution. Reducing application cost by 30-50% compared to other solutions Easy to layout on 2-sided PCB Excellent EMI behaviour without additional external filtering Ultra low standby power of 10 mW meeting 5-start smartphone charger standby rating High efficiency of 75% Excellent thermal behaviour due to NXPs proprietary low RDSon power silicon technology NXP Recommends   NXQ1TXH5 - Low cost version; contact your local sales representative for information on NXQ1TXL5 Mobile

U-Boot Migration Example 1. INTRODUCTION:      This document explains the general and basic steps to customize U-Boot for your own board. The board used in this document it is a working and stable board, the UDOO board (http://udoo.org). 2. REQUIREMENTS:     Install Yocto Project. See the Freescale Yocto Project User's Guide.     Generate and install the meta-toolchain. Follow this great training to do so  Yocto Training - HOME     Generate core-image-minimal of L3.14.28 of FSL BSP obtained from https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_iMX6QDLS_BUNDLE&appType=license&location=null&Parent_no…   3. ADDING i.MX6 CUSTOM BOARD SUPPORT FOR U-BOOT.     This section follows the steps found in Chapter 1 of the i.MX6 BSP Porting Guide of the Yocto documentation (L3.14.28) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… . Obtain U-Boot Source Code. After having installed Yocto project and generate a valid imx6 image, the U-Boot code should be located at /tmp/work/ -poky-linuxgnueabi/u-boot-imx/ /git. Prepare the Code. Choose a board as reference, this board should be as similar as possible to your custom board. Copy the board directory :                $ cp -R board/freescale/mx6sabresd/ board/freescale/mx6_udoo Copy the existing mx6sabresd.h configuration file as mx6_udoo.h                $ cp include/configs/mx6sabresd.h include/configs/mx6_udoo.h Create one entry in boards.cfg. Add a configuration entry in the boards.cfg file. Active  arm  armv7  mx6  freescale  mx6_udoo mx6_udoo mx6_udoo:IMX_CONFIG=board/freescale/mx6_udoo/mx6dl_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE="imx6q-udoo.dtb",DDR_MB=1024 Rename .c file. Rename board/freescale/mx6sabresd/mx6sabresd.c   to   board/freescale/mx6_udoo/mx6_udoo.c Modify Makefile. Change the line of COBJS to your custom board at  board/freescale/mx6_udoo/:      obj-y  := mx6sabresd.o Create a Shell script. Create a script to compile your new configuration. The script for this example is shown below and its name is build_u-boot.sh: #!/bin/bash export ARCH=arm export CROSS_COMPILE=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- make distclean; make mx6_udoo_config make Run the script to verify if the new configuration is correct.      $./build_u-boot.sh 4. CUSTOMIZING BOARD CODE      The fist part to customize is the DCD table. The DCD table contains configuration data for the DDR controller and memory. The DCD is read by the BootROM code in the iMX family and executed before copying the Uboot image to DDR. The DCD is built in the .cfg file pointed in the new entry we just added in the boards.cfg file (mx6dl_4x_mt41j128.cfg). Below you can find an example of the data that can be found in this file: /* * Device Configuration Data (DCD) * * Each entry must have the format: * Addr-type           Address        Value * * where: *      Addr-type register length (1,2 or 4 bytes) *      Address   absolute address of the register *      value     value to be stored in the register */ DATA 4, 0x020e0774, 0x000C0000 DATA 4, 0x020e0754, 0x00000000 DATA 4, 0x020e04ac, 0x00000030 DATA 4, 0x020e04b0, 0x00000030 DATA 4, 0x020e0464, 0x00000030 DATA 4, 0x020e0490, 0x00000030 DATA 4, 0x020e074c, 0x00000030 DATA 4, 0x020e0494, 0x00000030 DATA 4, 0x020e04a0, 0x00000000 The .cfg files used in this example were taken from an old U-Boot version (2009) non dtb capable. The used files are found in the attached .zip file. The specific initialization code for each board is found in mx6 .c in board/freescale/mx6 .c  in this case board/freescale/mx6_udoo/mx6_udoo.c file. Below it is explained the needed changes to route the serial console to the correct UART module, disable an external watchdog, configure and initialize the Ethernet PHY, change the lvds clock and configure the correct USDHC module.        U-Boot calls already defined functions from a function pointer array that takes care of the board initialization at different stages. For example the board_early_init_f() is called at an        early phase where we can disable the wdog and initialize the uart pins; board_init() and board_late_init() are called after board_early_init_f(). The UDOO board features an external watchdog that needs to be disabled with a GPIO, otherwise U-Boot resets after a few seconds:          The WDOG pins need to be configured and in the mx6_udoo.c file a global struct configuration for those pins is declared, as well as macros for each pin #define WDT_EN  IMX_GPIO_NR(5, 4) #define WDT_TRG IMX_GPIO_NR(3, 19) iomux_v3_cfg_t const wdog_pads[] = {         MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),         MX6_PAD_EIM_D19__GPIO3_IO19, }; static void setup_iomux_wdog(void) {         imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));         gpio_direction_output(WDT_TRG, 0);         gpio_direction_output(WDT_EN, 1);         gpio_direction_input(WDT_TRG); } This configuration needs to be called at some point of the board_early_init_f() int board_early_init_f(void) {         setup_iomux_wdog();         This way the board_early_init_f() calls the iomux for the external wdog and disables it. The UART console is routed to UART2, EIM_D26/UART2_TXD and EIM_D27/UART2_RXD. A different structure is defined with the pin configuration for the UART2.      iomux_v3_cfg_t const uart2_pads[] = {         MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),         MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), }; This configuration should be called at early stage too. static void setup_iomux_uart(void) {         imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); } int board_early_init_f(void) {         setup_iomux_wdog();         setup_iomux_uart(); Also the UART BASE register has to be defined as well as the console device. This is defined in the include/configs/mx6_udoo.h file. #define CONFIG_MXC_UART_BASE   UART2_BASE #define CONFIG_CONSOLE_DEV      "ttymxc1" The UDOO board features only one micro SD slot to boot and U-Boot environment storage. It uses only 4 bits and it has to be configured too. In the include/configs/mx6_udoo.h file the USDHC module has to be defined and the MMC environment device. #define CONFIG_SYS_FSL_USDHC_NUM   3 #define CONFIG_SYS_MMC_ENV_DEV       0     /* SDHC3 */          The USDHC3 pin configuration has to be defined:      iomux_v3_cfg_t const usdhc3_pads[] = {         MX6_PAD_SD3_CLK__SD3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_CMD__SD3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_NANDF_D0__GPIO2_IO00    | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ }; struct fsl_esdhc_cfg usdhc_cfg[1] = {         {USDHC3_BASE_ADDR, 0, 4}, }; This must be called and configured from the board_mmc_init() function: int board_mmc_init(bd_t *bis) {         s32 status = 0;         imx_iomux_v3_setup_multiple_pads(         usdhc3_pads, ARRAY_SIZE(usdhc3_pads));         usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);                 status |= fsl_esdhc_initialize(bis, &usdhc_cfg[0]);         return status; } The Ethernet PHY is configured in the board_eth_init() function. This function should initialize the pins for the external ethernet phy, mdio and phy configuration.  Just a piece of code is shown below: iomux_v3_cfg_t const enet_pads1[] = {         MX6_PAD_ENET_MDIO__ENET_MDIO            | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_MDC__ENET_MDC              | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TXC__RGMII_TXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD0__RGMII_TD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD1__RGMII_TD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD2__RGMII_TD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD3__RGMII_TD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_REF_CLK__ENET_TX_CLK       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RXC__RGMII_RXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         /* RGMII reset */         MX6_PAD_EIM_D23__GPIO3_IO23              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* alimentazione ethernet*/         MX6_PAD_EIM_EB3__GPIO2_IO31              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 32 - 1 - (MODE0) all */         MX6_PAD_RGMII_RD0__GPIO6_IO25            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 31 - 1 - (MODE1) all */         MX6_PAD_RGMII_RD1__GPIO6_IO27            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 28 - 1 - (MODE2) all */         MX6_PAD_RGMII_RD2__GPIO6_IO28            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 27 - 1 - (MODE3) all */         MX6_PAD_RGMII_RD3__GPIO6_IO29            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */         MX6_PAD_RGMII_RX_CTL__GPIO6_IO24         | MUX_PAD_CTRL(NO_PAD_CTRL), }; static iomux_v3_cfg_t const enet_pads2[] = {         MX6_PAD_RGMII_RD0__RGMII_RD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD1__RGMII_RD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD2__RGMII_RD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD3__RGMII_RD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL), }; static void setup_iomux_enet(void) {         imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));         udelay(20);         gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on enet */         gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* assert PHY rst */         gpio_direction_output(IMX_GPIO_NR(6, 24), 1);         gpio_direction_output(IMX_GPIO_NR(6, 25), 1);         gpio_direction_output(IMX_GPIO_NR(6, 27), 1);         gpio_direction_output(IMX_GPIO_NR(6, 28), 1);         gpio_direction_output(IMX_GPIO_NR(6, 29), 1);         udelay(1000);         gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* deassert PHY rst */         /* Need delay 100ms to exit from reset. */         udelay(1000 * 100);         gpio_free(IMX_GPIO_NR(6, 24));         gpio_free(IMX_GPIO_NR(6, 25));         gpio_free(IMX_GPIO_NR(6, 27));         gpio_free(IMX_GPIO_NR(6, 28));         gpio_free(IMX_GPIO_NR(6, 29));         imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2)); }           Let's notice that the external PHY is not the same as the SABRESD AR8031. The UDOO features the MICREL KSZ9031 PHY. The latter needs to be defined and the former undefined in the include/configs/mx6_udoo.h file. #undef  CONFIG_PHY_ATHEROS #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031 Besides the PHY address has to be changed. #define CONFIG_FEC_MXC_PHYADDR  6 At this point, the serial console, SD card saving arguments and ethernet should be working. The last point is to configure the LVDS display. The LVDS display of the UDOO board is connected in the same port as the SABRE-SD board, but the operation frequency is different and it has to be modified to work at ~ 33.26MHz for the 7 inches LVDS display.      The mx6_udoo.c file contains a setup_display function that configures the LDB module. This functions is called in the board_early_init_f(). With the current clock configuration is not possible to get  the 33.2MHz for the LVDS and a different clock source for the LDB module must be chosen. The backlight and lvds power signals must be on.           The current configuration uses the mmdc_ch1 clock and to get closer to 33.26MHz the PLL2_PFD0 is chosen.        gpio_direction_output(IMX_GPIO_NR(1, 2), 1); /* LVDS power On */         gpio_direction_output(IMX_GPIO_NR(1, 4), 1); /* LVDS backlight On */         imx_iomux_v3_setup_multiple_pads(di0_pads, ARRAY_SIZE(di0_pads));         enable_ipu_clock();         imx_setup_hdmi();         /* Turn on4LDB0, LDB1, IPU,IPU DI0 clocks */         reg = readl(&mxc_ccm->CCGR3);         reg |=  MXC_CCM_CCGR3_LDB_DI0_MASK | MXC_CCM_CCGR3_LDB_DI1_MASK;         writel(reg, &mxc_ccm->CCGR3);         /* set LDB0, LDB1 clk select to 011/011 */         reg = readl(&mxc_ccm->cs2cdr);         reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK                  | MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);         reg |= (1 << MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)               | (1 << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);         writel(reg, &mxc_ccm->cs2cdr); With this changes you can compile the new U-Boot image with ./build_u-boot.sh and then just copy the uboot.imx file to your sd: # sudo cp if=uboot.imx of=/dev/sdX bs=512 seek= 2 && sync 5. TESTING YOUR CHANGES Inser the sd with the U-Boot image to micro sd slot and power up the board. You should get the U-Boot serial console like shown below. In the console you can test the ethernet and phy configuration with the PING command: I hope you find these basic steps useful for different boards. i.MX6_All Re: U-Boot Migration Example Can you give the solution for below screenshots Re: U-Boot Migration Example Hi, Thank you for this valuable information. Does the iomux in kernel (from device tree) shall override the iomux in u-boot ? Regards, Ran

Max input voltage of PSWITCH and DCDC_CFG pins on MKW40 Our customer, who is considering MKW40, is asking NXP regarding max input voltage of PSWITCH and DCDC_CFG pins. Especially they plan to use buck mode with input voltage 4.2[v] as shown below. Would you comment if max voltage of PSWITCH and DCDC_CFG pins is 4.2[v] as well as DCDC_IN pin? Regards, Koichi BLE Software Re: Max input voltage of PSWITCH and DCDC_CFG pins on MKW40 Hello Andrei, Thank you for your comment. According to your comment, do you plan to update MKW40 datasheet? Because our customer want NXP's guarantee with MKW40 datasheet. Regards, Koichi Re: Max input voltage of PSWITCH and DCDC_CFG pins on MKW40 Hi Koichi, The above configuration shall work without any problem. According to chip reference manual, chapter DCDC, in buck configuration mode, DCDC_IN voltage is between 1.8V and 4.2V, the DCDC_CFG is tied to DCDC_IN and PSWITCH will also be tied to DCDC_IN each time the pushbutton is pressed. Please see the below picture from reference manual. Regards, Mihai

トリノ工科大学チーム POLIedro フリースケールカップ テクニカルレポート <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> トリノ工科大学のチームPOLIedroからのテクニカルレポート - EMEAファイナル2015 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> トリノ工科大学のチームPOLIedroからのテクニカルレポート - EMEAファイナル2015

HardAndSoftIronCompensationExplained Attached is a PDF dump of a classic blog post.  Please forgive the format problems.  I'll work with the web team in January to get it reposted to the NXP site. Mike Attached is a PDF dump of a classic blog post.  Please forgive the format problems.  I'll work with the web team in January to get it reposted to the NXP site. Mike SensorFusion

Example MPC5744P eTimer CTU ADC synchronization GHS614 ******************************************************************************** * Detailed Description: * * * This example shows synchronization between eTimer, CTU and ADC modules. * The eTimer0 module timer 2 is initialized to generate PWM signal, and rising edge * of this signal is used to generate trigger signal for CTU module. The CTU module * use one command list with 4 ADC_0 channels. Single conversion mode is used, * so ADC0 ch0, ch1, ch2 and ch3 are sampled. * ------------------------------------------------------------------------------ * Test HW:  MPC57xx * Maskset:  1N65H * Target :  internal_FLASH * Fsys:     200 MHz PLL with 40 MHz crystal reference * * EVB connection: * * P8.1  - A[0]  .. GPIO output, used to see CTU-ADC ISR period * P9.1     - B[7]  .. ADC0 AN[0] input * P9.2     - B[8]  .. ADC0 AN[1] input * P16.4 - I[3] .. CTU0 EXT TRG output * * see CTU0 EXT TRG output signal (toggle on each trigger) on P16.4 with respect of eTimer PWM signals. * ******************************************************************************** ******************************************************************************** * Detailed Description: * * * This example shows synchronization between eTimer, CTU and ADC modules. * The eTimer0 module timer 2 is initialized to generate PWM signal, and rising edge * of this signal is used to generate trigger signal for CTU module. The CTU module * use one command list with 4 ADC_0 channels. Single conversion mode is used, * so ADC0 ch0, ch1, ch2 and ch3 are sampled. * ------------------------------------------------------------------------------ * Test HW:  MPC57xx * Maskset:  1N65H * Target :  internal_FLASH * Fsys:     200 MHz PLL with 40 MHz crystal reference * * EVB connection: * * P8.1  - A[0]  .. GPIO output, used to see CTU-ADC ISR period * P9.1     - B[7]  .. ADC0 AN[0] input * P9.2     - B[8]  .. ADC0 AN[1] input * P16.4 - I[3] .. CTU0 EXT TRG output * * see CTU0 EXT TRG output signal (toggle on each trigger) on P16.4 with respect of eTimer PWM signals. * ******************************************************************************** General Re: Example MPC5744P eTimer CTU ADC synchronization GHS614 Hi Pat, Feel free to create a new thread. So others can also join a discussion. If your questions are related to any issues in my examples than feel free to write here. Peter

Example MPC5744P FlexPWM SGEN synchronization GHS614 ******************************************************************************** * Detailed Description: * * * This example shows usage of FlexPWM and Sine Wave generator (SGEN) modules. * The setting is selected in the way to have a PWM output signal synhronized with * SGEN output signal. This is necessary for resolver usage in motor control appls. * * See attached Excel sheet for calculation of parammeters used here (AUX0_clk_DIV0, * AUX0_clk_DIV1, SGEN_IOFREQ, PWM_PRESCALER, PWM_MODULO). * * This example is set for 2.44140625 kHz SGEN/PWM frequency. * * * ------------------------------------------------------------------------------ * Test HW:  MPC57xx * Maskset:  1N65H * Target :  internal_FLASH * Fsys:     200 MHz PLL with 40 MHz crystal reference * * EVB connection: * * P20.1 - D[7] .. SGEN output *          connected to FEC PHY's MIIMODE input on motherboard, *          to see full amplitude remove J26    * * P8.12    - A[11] .. FlexPWM A[0] output * P8.11    - A[10] .. FlexPWM B[0] output * * ******************************************************************************** ******************************************************************************** * Detailed Description: * * * This example shows usage of FlexPWM and Sine Wave generator (SGEN) modules. * The setting is selected in the way to have a PWM output signal synhronized with * SGEN output signal. This is necessary for resolver usage in motor control appls. * * See attached Excel sheet for calculation of parammeters used here (AUX0_clk_DIV0, * AUX0_clk_DIV1, SGEN_IOFREQ, PWM_PRESCALER, PWM_MODULO). * * This example is set for 2.44140625 kHz SGEN/PWM frequency. * * * ------------------------------------------------------------------------------ * Test HW:  MPC57xx * Maskset:  1N65H * Target :  internal_FLASH * Fsys:     200 MHz PLL with 40 MHz crystal reference * * EVB connection: * * P20.1 - D[7] .. SGEN output *          connected to FEC PHY's MIIMODE input on motherboard, *          to see full amplitude remove J26    * * P8.12    - A[11] .. FlexPWM A[0] output * P8.11    - A[10] .. FlexPWM B[0] output * * ******************************************************************************** General