NXP Designs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Designs Knowledge Base

Discussions

Sort by:
doc&project&patch&script explain to support GD qspi nor in lauterbach, flash tool,ivt,fls mcal, fls bootloader and linux/ chinese/english 目录 1    背景和参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 3 1.3  硬件连接... 5 2    Lauterbach脚本驱动开发(可选) 5 2.1  准备参考脚本... 5 2.2  QuadSPI_ReadID.. 6 2.3  配置QSPI NOR为DOPI模式... 7 2.4  使用DOPI模式 READ_8DTRD.. 10 2.5  测试结果... 13 3    Flash tool算法镜像开发... 14 3.1  Flash SDK实现的算法... 15 3.2  开发新的flash源代码... 17 3.3  测试结果... 20 4    开发IVT参数头... 22 4.1  S32G QSPI控制器配置区别... 24 4.2  QSPI的配置区别... 28 4.3  测试结果... 29 5    开发MCAL Fls驱动... 30 5.1  MCAL Fls驱动工程说明... 30 5.2  FlsMem配置页... 34 5.3  MemCfg配置页... 35 5.4  测试结果... 49 6    开发Bootloader工程中Fls驱动... 51 6.1  Bootloader工程说明... 51 6.2  Bootloader与MCAL Fls驱动的不同点... 53 6.3  镜像打包... 54 6.4  测试结果... 56 7    开发Linux驱动(可选) 57 7.1  Linux GD驱动支持情况... 57 7.2  时钟相关的修改... 58 7.3  在DTS中增加GD flash的支持... 60 7.4  修改源代码增加flash信息结构体... 61 7.5  修改源代码中flash的fixup支持DTR模式... 62 7.6  Turning dummy值解决读错位的问题... 64 7.7  测试结果... 65   Content 1    Background and References. 2 1.1  Background. 2 1.2  References. 3 1.3  Hardware Link. 5 2    Lauterbach Script development(Optional) 6 2.1  Preparing the refer script 6 2.2  QuadSPI_ReadID.. 6 2.3  Configure QSPI NOR to DOPI mode. 8 2.4  Use DOPI mode  READ_8DTRD.. 11 2.5  Test report 13 3    Flash tool algorithm image development 15 3.1  Algorithms implemented by Flash SDK. 15 3.2  Develop new flash source code. 17 3.3  Test Report 21 4    Develop IVT Parameter Header 23 4.1  S32G QSPI Controllder configuration difference. 25 4.2  QSPI Configuration Difference. 30 4.3  Test Report 30 5    Develop MCAL Fls driver 31 5.1  MCAL Fls Driver Project Details. 31 5.2  FlsMem Configuration page. 35 5.3  MemCfg Configuration page. 36 5.4  Test Report 51 6    Develop Bootloader Project Fls Drivedr 52 6.1  Bootloader Project Details. 52 6.2  Difference of Bootloader and MCAL Fls Driver 54 6.3  Image Package. 56 6.4  Test Report 58 7    Develop Linux Driver(Optional) 59 7.1  Linux GD Driver Details. 59 7.2  Modification of Clock. 60 7.3  In DTS add GD flash Support 62 7.4  Modify source code and add flash information structure  63 7.5  Modify the fixup of flash in source code to support DTR mode  64 7.6  Turning Dummy Value to Solve the Misplacement Problem   66 7.7  Test Report 67
View full article
本文说明S32G HSE On-demand SMR验证的应用方法,本文演示的示例应用为: Secure Bootloader对Linux Bootloader fip.bin的验证 目录 1    背景说明与参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 3 2    S32G On-demand SMR Verification说明... 4 2.1  SMR Verify的说明... 4 2.2  On-demand SMR Verify. 4 3    环境搭建... 5 3.1  EB配置说明... 5 3.2  ATF编译说明... 8 3.3  镜像烧写... 9 4    Bootloader代码开发... 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    测试... 16 5.1  Lauterbach跟踪... 17 5.2  Fip.bin破坏实验... 19 5.3  硬件确认... 19   This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin Contents 1    Background Description and Reference Materials. 2 1.1  Background Description. 2 1.2  Reference Materials. 3 2    S32G On-demand SMR Verification. 4 2.1  SMR Verify. 4 2.2  On-demand SMR Verify. 4 3    Build the Development Environment 5 3.1  EB Configuration. 5 3.2  ATF Compiling. 8 3.3  Burn Image. 9 4    Bootloader Codes Development 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    Testing. 16 5.1  Lauterbach Tracking. 16 5.2  Fip.bin Broken Test 19 5.3  Probe the Hardware. 19
View full article
this doc and project explain how to integrate S32G M stby demo and Linux STR demo to one demo to achieve the fast boot, chinese version: 本文说明如何在S32G2 RDB2板上搭建 一个M7 MCAL Standby Fullboot GPIO resume Demo加A53 Suspend to RAM的Demo,主要的 应用场景是电动汽车的快速启动。 G3与更新版本BSP的支持情况与此类 似,不再另外说明,客户可以自行参考开发。 请注意本文为培训和辅助文档,本文不是 官方文档的替代,请一切以官方文档为准。     目录 1 参考资料说明与声明 .................................................. 2 2 STBY+STR的硬件注意点 .......................................... 3 3 修改M7 MCAL Standby Demo代码 ............................ 5 3.1 Clock相关修改 ........................................................ 5 3.2 MCU相关修改 ......................................................... 5 3.3 UART Clock相关修改 ............................................. 7 3.4 Port相关修改 .......................................................... 7 3.5 I2C相关修改 ........................................................... 7 3.6 实现M核进入STDY状态等待功能 ........................... 8 3.7 Main函数的修改 ..................................................... 8 4 修改Bootloader工程来支持同时Boot M/A核Demo ... 10 4.1 I2C Clock相关修改 ............................................... 10 4.2 Port相关修改 ........................................................ 11 4.3 其它修改 ............................................................... 12 5 修改A53 Linux代码 .................................................. 13 6 Demo 运行测试 ........................................................ 13 6.1 硬件连接 ............................................................... 13 6.2 镜像烧写 ............................................................... 13 6.3 Demo运行 ............................................................ 14 7 工程发布包............................................................... 15 8 未来开发建议 ........................................................... 17 8.1 M/A核同步机制 ..................................................... 17 8.2 功能安全与信息安全 ............................................. 17 9 遗留问题 .................................................................. 17 9.1 IPCF STR支持 ...................................................... 18 9.2 PFE Slave STR支持 ............................................. 18 注意以下说明与声明: 说明: 汽车网关有快速启动要求,而电动车因为驻车时有更大的电池提供待机电源,所以希望是使 用Linux 的suspend to ram 的功能来实现Linux 的快速启动,而在S32G 上则需要考虑将M 核的 Standby 功能 与A 核的STR 功能 结合起来,目前可用的资源包括:  从BSP32 起支持ATF,可以支持Linux 端的STR 功能,文档《S32G_Linux_STR_V1-*.pdf》 (John.Li)说明linux STR 的原理和与M7 Standby Demo 结合时所需要的修改。  NXP 的M7 内部standby demo,可以支持M 核端的standby 功能,支持full boot 和standby ram boot。文档《S32G_Standby_Demo_V4-*.pdf》(John.Li)有详细说明,本文使用MCAL full boot+GPIO resume Demo。  本Demo 与本文主要说明如何将这两个Demo 结合起来,形成一个整体的Demo。  由于需要Boot M 核加A 核,所以也需要Bootloader 工程的支持,文档 《S32G_Bootloader_V1-*.pdf》(John.Li)说明了如何创建一个MCAL sample 加Linux 的 Bootloader 工程。 声明: 请注意:  M7 standby demo 本来为NXP 内部Demo,不保证运行质量。而Linux 本身也是reference software。  Linux STR 本身会引入比较复杂的电源管理切换,也会引起系统级的不稳定性。  本文所说的方法也是实验性质,不保证运行质量。 所以客户应该谨慎决定其产品功能并自行保证其产品质量,本文及本Demo 仅为Demo 性质。   This article explains how to build a demo of M7 MCAL Standby Fullboot GPIO resume Demo plus A53 Suspend to RAM on the S32G2 RDB2 board. The main application scenario is the quick start of electric vehicles. The support situation of G3 and the newer version of BSP is similar to this, no further explanation is given, customers can refer to it for development by themselves.  Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials and statement 2 2    STBY+STR hardware checkpoints. 3 3    Modified M7 MCAL Standby Demo codes. 5 3.1  Clock modification. 5 3.2  MCU related modification. 6 3.3  UART Clock related modificaiton. 7 3.4  Port related modification. 8 3.5  I2C related modification. 8 3.6  Enable the waiting function of M core entering STDY. 9 3.7  Main function modification. 9 4    Modify the Bootloader project to support simultaneous M/A core demo  11 4.1  I2C Clock related modification. 11 4.2  Port related modifcaiton. 11 4.3  Others modificaiton. 13 5    Modify A53 Linux codes. 14 6    Demo running and testing. 14 6.1  Hardware link. 14 6.2  Image burning. 14 6.3  Demo running. 15 7    Project release package. 16 8    Suggestion for the future development 17 8.1  M/A core sync mechanism.. 17 8.2  Function safety and Information security. 17 9    Remaining issues. 18 9.1  IPCF STR support 18 9.2  PFE Slave STR support 18   as need refer:   S32G_Linux STR This doc explain S32G Linux STR details and modify to integrate with M stdy demo https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Linux-STR/ta-p/1652680 S32G Standby Demo the project build a new Mcal standby demo and explain its details https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-M-kernel-Standby-demo-and-how-to-porting-to-Mcal/ta-p/1556313 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838
View full article
About this demo   Heads up! This article contains instruction updates due to changes in NXP's SDK and also on AWS website.   This demo will focus on the WIFI enablement and cloud connectivity through AWS by using MCUXpresso and an Amazon Alexa.   Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 165 fully-featured services from data centers globally. Millions of customers —including the fastest-growing startups, largest enterprises, and leading government agencies—trust AWS to power their infrastructure, become more agile, and lower costs. The LPC5500 used for this demo is the LPCXpresso55S69 development board which provides the ideal platform for evaluation of and development with the LPC55S6x MCU based on the Arm® Cortex®-M33 architecture. The board includes a high performance onboard debug probe, audio subsystem and accelerometer, with several options for adding off-the-shelf add-on boards for networking, sensors, displays, and other interfaces. The Alexa Skills Kit is a collection of self-service APIs, tools, documentation, and code samples that makes it easier to start building Alexa skills. Skills are like apps for Alexa, enabling customers to perform everyday tasks or engage with your content naturally with voice.   Block Diagram List of Products LPCXpresso55S69 WiFi 10 CLICK   Alexa Echo Dot USB A-to-Micro USB cable Step by Step Guides First, we need to create an account AWS and generate the “thing” that will be linked to the platform, this information can be followed step-by-step on this manual. Import AWS remote control WiFi Demo from the SDK Builder Select the LPCXpresso Board, click on the "Add software component" button, then select "Select All". Download the SDK Open MCU Xpresso and Import SDK examples, and then select the LPCXpresso 55 board and import into the aws_exaples find the aws_remote_control_wifi and also click on the UART for debugging. On the project find the amazon-freertos example, then demos and open the aws_clientcredential.h and change: The AWS IoT broker endpoint (Under thing settings “Interact” section) Write the “Things Name” And WiFi credentials. Replace the aws_clientcredential_keys.h with the one generated by the certification configuration tool from AWS, You can drag and drop it into the folder and then click overwrite. Build and download the application into your board. Video   External Links NXP Product Link LPCXpresso55S69 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc5500-cortex-m33/lpcxpresso55s69-development-board:LPC55S69-EVK WIFI 10 CLICK https://www.mikroe.com/wifi-10-click Amazon Web Services https://aws.amazon.com/?nc2=h_lg Alexa Skills Kit https://developer.amazon.com/en-US/alexa/alexa-skills-kit   Demo instructions update for 09/25/2020 Due to NXP's SDK updates, some file routes have changed inside the MCUXpresso project: The CertificateConfiguration Tool is located now on: SDKPackages\SDK_2.8.0_LPCXpresso55S69.zip\rtos\freertos\tools\certificate_configuration\ •Location of wifi_shield_silex2401.h \wifi_qca\port\shields\silex2401\wifi_shield_silex2401.h has changed location to wifi_qca\port\boards\lpcxpresso55s69\freertos\silex2401\wifi_shield_silex2401.h Additionally, there is now a clickboard define file available and these changes are already applied: #define BOARD_INITWIFI10CLICKSHIELD_PWRON_PIN 5U //Already done #define WIFISHIELD_WLAN_PINT_CONNECT (kINPUTMUX_GpioPort1Pin18ToPintsel) // IRQ Alexa_RC_json_skill.json.zip file changes:             AMAZON.StopIntent { "name": "AMAZON.StopIntent", "samples": [] },                
View full article
  Overview The NXP ®  Feature Phone reference design is designed to implement the Type 2 Feature Phone core. Includes support for on-hook GR-30 services such as Calling Number Delivery, Calling Name Delivery, Dialable Directory Number, Call Qualifier, and Visual Message Waiting Indicator Additional support for off-hook GR-30 services, such as Calling Identity Delivery on Call Waiting and Call Waiting Deluxe The Feature Phone reference design also includes a full duplex echo-cancelling speakerphone with solid sound quality; the demo is able to originate and terminate a call in full duplex speakerphone mode A HyperTerminal will be used to display the GR-30 messages Archived content is no longer updated and is made available for historical reference only.   Features DSP56858EVM and 5685X Digital Signal Controllers Telephony Daughter Card (TDC1) Microphone AKG Acoustics Type Q400Mk3, Code 2846Z003 Directional Mono Electret condenser microphone Use with Radio Shack adaptor: Stereo -to-Mono Headphone adapter number 274-374 Amplified Speaker On-Hook Data Transmission Protocol (GR-30-CORE) - CID_T1.DSP software module Adaptive Line Echo Canceller (SR-3004) - ALEC.DSP software module Off-Hook Data Transmission Protocol (SR-3004) - CIDCW_T2.DSP software module Acoustic Echo Cancellation Keypad LCD     IDE and Build Tools CodeWarrior® Development Tools for 56800/E DSC | NXP  Design Resources https://www.nxp.com/downloads/en/schematics/TDC1LD.zip
View full article
Overview This reference design describes the design of a 3-phase BLDC (Brushless DC) motor drive, which supports the NXP® 56F80X and 56F83XX Digital Signal Controllers (DSCs). The speed-closed loop BLDC drive using a Hall sensor is implemented The system is targeted for applications in both industrial and appliance fields (e.g. washing machines, compressors, air conditioning units, pumps or simple industrial drives required high reliability and efficiency) Features Voltage control of BLDC motor using Hall sensor Targeted for 56F80X, 56F83XX, and 56F81XX Digital Signal Controllers Running on 3-phase Motor Board Control technique incorporates: Voltage BLDC motor control with speed-closed loop Current feedback loop Both directions of rotation Motoring mode Minimal speed 500 RPM Maximal speed 1000 RPM (limited by power supply) Manual interface (Start/Stop switch, Up/Down push button control, LED indication) FreeMASTER software control interface (motor start/stop, speed set-up) FreeMASTER software monitor Block Diagram Board Design Resources
View full article
Demo Owner: Derek Snell   This demo combines several solutions from NXP and our partners. The demo is a thermostat application, using the Kinetis family as a communication gateway between a ZigBee network and connecting to the cloud. The demo runs on the MQX Real-Time Operating System (RTOS). It also uses the NXP PEG graphics library for the user interface displayed on an LCD. The ZigBee communication uses NXP’s BeeStack ZigBee stack, and connects with an NXP wireless development board programmed as a remote temperature sensor. The demo will also connect with an off-the-shelf ZigBee light bulb, and wirelessly controls it. The demo network connection is setup for Wi-Fi, using a Wi-Fi module from Qualcomm. The cloud connection allows the thermostat to be monitored and controlled remotely with mobile devices, and uses a solution provided by deviceCloud.io.     NXP Products Product Link Shield Adapter Module for the Tower System Shield Adapter Module for the Tower System | NXP  Kinetis® KW2x Tower System Modules TWR-KW2x|Tower System Board|Kinetis® MCUs | NXP  Kinetis K70 120 MHz Tower System Module TWR-K70F120M|Tower System Board|Kinetis MCUs | NXP  Serial (USB, Ethernet, CAN, RS232/485) Tower System Module Serial (USB, Ethernet, CAN, RS232/485) Tower System Module | NXP  Graphical LCD Tower System Module with RGB Interface Graphical LCD Tower Module with RGB Interface | NXP    Design Resources Getting Started Guide Development Tools Thermostat Demo Software Firmware updated to v1.0 on 9/9/14      - DCIO Cloud agent now uses SSL from WolfSSL.  This improves WebSocket connections to cloud server through some protected networks. Firmware updated to v0.8 on 7/15/14      - Updated to support latest GT202 shield hardware from Qualcomm.  Rev 1.3 and newer boards changed pinout of CHIP_PWD signal. Firmware updated to v0.7 on 6/20/14      - Updated to use new SNTP server.  Previous server stopped responding and prevented cloud connection. Getting Started guide updated to v0.4 on 7/15/14
View full article
Demo This demo showcases a bluetooth headset using NXP’s Near Field Magnetic Induction device NxH2280, enabling truly wireless streaming of voice, audio and data. The demo is built using the NxH2280 Application Development Kit for hearables Features: very power efficient audio and data streaming from ear-to-ear: HQ audio < 2.5 mW works through human body with ultra-low absorption: SAR is 100 times lower than Bluetooth ensures reliable and private communication _______________________________________________________________________________________________________ Featured NXP Products: NxH2280: Near Field Magnetic Induction radio|NXP LPC1102: low power, space efficient microcontroller|NXP NT3H1101: Energy harvesting NFC Forum Type 2 Tag for bluetooth simple pairing|NXP _______________________________________________________________________________________________________ Picture of demo: implemented using headphone shells Picture of NxH2280 ADK C11
View full article
  Overview Near Field Communication (NFC) is used for real-time precision marketing based on time, local inventory and the individual when embedded in product displays or the products themselves. NFC is also becoming the preferred method for payment either in smartphones or smart payment cards. In this particular deployment , the overall system consists of Backend Servers, Top Up station and Household Meter. The Backend Server roles are to activate the new installed meter, to collect meter usage data and behaviors, to implement new tariff based on user behaviors, and to allocate energy usage in effective way. Top Up Stations are NFC Reader with SAM and they are connected to local Computer, Tablet or Mobile phone. They are located at retailers near by household to ease the user to buy the credits. Besides that, Top Up Station is also help to upload and download settings or parameter from the Backend Server Household Meters are those Contctless Prepaid Meter has been installed at end user Block Diagram Products Category MCU Product URL KM3x: 50–75 MHz Precision Metrology MCUs with Segment LCDs based on Arm® Cortex®-M0+  Product Description The KM3x MCU family enables single-chip one-, two-, and three-phase electricity meters, as well as flow meters and other precision measurement applications.   Category NFC Fronted Product URL CLRC663 plus family: High-performance NFC frontends  Product Description If you need high NFC performance or the lowest power consumption, use this remarkably efficient yet highly flexible frontend family to push your design further.   Category RTC Product URL PCF8563: Real-time clock/calendar  Product Description The PCF8563 is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption.   Category Secure Element Product URL A71CH: Plug and Trust - The fast, easy way to deploy secure IoT connections  Product Description A71CH is a ready-to-use secure element for IoT devices providing a root of trust at the IC level and delivers, chip-to-cloud security right out of the box, so you can safely connect to IoT clouds and services, including AWS, IBM Watson IoT™ Platform, and Google Cloud™ IoT Core without writing security code or exposing keys.   Category Power Management Product URL TEA1721BDB1065: TEA1721 Universal Mains White Goods Flyback SMPS Demo Board  Product Description This reference design demonstrates the TEA1721 as a -12 V and -3.3 V AC/DC SMPS converter that can provide 5 W into a load.   Category Smart Card Product URL 1 MIFARE® DESFire® EV3: High-Security IC for Contactless Smart City Services  Product Description 1 The features of the MIFARE DESFire EV3 IC reflect NXP’s continued commitment to secure, connected and convenient contactless Smart City services. Product URL 2 MIFARE Plus® EV2: Secure IC for Contactless Smart City Services  Product Description 2 As the next generation of NXP’s MIFARE Plus product family, the MIFARE Plus EV2 IC is designed to be both a gateway for new Smart City applications and a compelling upgrade, in terms of security and connectivity, for existing deployments.
View full article
Overview The reference design demonstrates sensorless control of the 3-Phase Switched Reluctance (SR) motor using 56F80x or 56F83XX Digital Signal Controllers. It can also be adapted to 56F81XX Digital Signal Controllers. The concept of this application is that of a sensorless speed closed loop SR drive using flux linkage position estimation. An inner current loop with PI controller is included. The change in phase resistance during motor operation due to its temperature dependency creates errors in the position estimation and significantly affects the performance of the drive. Therefore, a novel algorithm for on-the-fly estimation of the phase resistance is included. The Digital Signal Controller runs the main control algorithm. Rotor position is evaluated using the sensorless flux linkage estimation algorithm. The actual flux linkage is calculated at the rate of the PWM frequency and is compared with the reference flux linkage for a given commutation angle. When the actual flux linkage exceeds the reference, the commutation of the phases is done; the actual phase is turned off and the following phase is turned on. Flux linkage error is used for estimation of the phase resistance at low speeds (US Patent No.: 6,366,865). The actual speed of the motor is determined using the commutation instances. Based on the speed error, the speed controller generates the desired phase current. When the phase is commutated, it is turned on with a duty cycle of 100%. Then, during each PWM cycle, the actual phase current is compared with the desired current. As soon as the actual current exceeds the desired current, the current controller is turned on. The current controller controls the output duty cycle until the phase is turned off (following commutation). Finally, the 3-Phase PWM control signals are generated. The procedure is repeated for each commutation cycle of the motor. Features Sensorless control of an SR motor using a flux linkage estimation technique Targeted for 56F80X, 56F83XX, and 56F81XX Digital Signal Controllers Running on a 3-Phase SR HV Motor Control Development Platform The control technique: current control with a speed closed loop Position estimation based on flux linkage estimation Phase resistance measurement during start-up Phase resistance estimation at low speeds Motor starts from any position with rotor alignment Encoder position reference for evaluation of sensorless position estimation Manual interface FreeMASTER software control interface and monitor Fault protection Block Diagram Board Design Resources
View full article
Overview This reference design enables development of a vector control algorithm for a three-phase AC induction motor implemented on NXP® digital signal controllers MC56F8013/MC56F8023. Targeted mainly at consumer and industrial applications Cost-effective and highly reliable, the algorithm implements a single shunt current sensing, eliminating the need for more than one sensor High range of motor operating speeds up to 18000RPM An adaptive closed loop rotor flux estimator enhances control performance and increases the overall robustness of the system A reference manual provides a detailed description of the application, including a design of hardware and software Features 3-phase AC induction motor drive Designed to fit into consumer and industrial applications Uses 56F8013 or 56F8023 32 MIPS Digital Signal Controller Running on a 3-phase High Voltage Power Stage Control technique incorporating: Vector control of three-phase AC induction motor with position encoder Closed-loop speed control Both directions of rotation Both motor and generator modes Reconstruction of three-phase motor currents from DC-Bus shunt resistor Closed loop current control Flux and torque independent control Adaptive rotor flux space-vector estimator Field-weakening for high speeds High-speed range, max speed – 18000 RPM (2-pole motor) FreeMASTER software control interface (motor start/stop, speed setup) FreeMASTER software monitor FreeMASTER software graphical control page (required speed, actual motor speed, start/stop status, DC-Bus voltage level, motor current, system status) FreeMASTER software speed scope (observes actual and desired speeds, DC-Bus voltage and motor current) FreeMASTER software high-speed recorder (reconstructed motor currents, vector control algorithm quantities) DC-Bus overvoltage and undervoltage, overcurrent protection Block Diagram Board Design Resources
View full article
NFC Tandem offers best of both worlds: An NFC reader and a passive connected tag sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can interact with cards, P2P devices or other connected tags.                                                             NFC Tandem Uses Cases and Applications: One-touch pairing WiFi with phone, or card Bluetooth with phone, headset, speaker IoT network node commissioning User identification with badge or phone Authentication and configuration of consumable and accessory Zero-power parametrization Zero-power firmware update Zero-power diagnosis and maintenance NFC Tandem Demo: NFC Tandem concept is demonstrated using NFC Tandem reference board: The demo can run on either: UDOO Neo Download UDOO Neo demo image or Raspberry Pi Download Raspberry Pi demo image Video of the demo: <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) NFC Tandem References: PN7150 High performance NFC controller, supporting all NFC Forum modes, with integrated firmware and NCI interface NTAG I²C plus NFC Forum Type 2 Tag with I²C interface NFC Tandem Documents: User Manual and reference schematics are attached to this document
View full article
        S32G just support serial download a M7 image to run by internal rom codes, our S32G DS IDE have a flash tools to use this feature to burn the image to external device. So current image burn method will divide into 2 step: 1: burn a uboot into the external device by S32G DS flash tools. 2: reboot the codes with uboot and run with network to burn the linux image into external device.      which need two working place on manufacture line, and customer wish to have a one time on-line tools, which means we need use serial port to boot uboot directly but S32G rom codes do not support it.       We have a reference tools of S32V but which IP difference is big between on S32V and S32G, So we can not reuse it and have to develop a new one.       The development working include: 序号 开发工作 说明 开发者 1 开发 根据S32G的serial boot协议要求,开发PC端的串口工具来下载M7镜像 John.Li 2 开发 根据自定义协议要求,开发PC端的串口工具来下载A核Bootloader到SRAM中 John.Li 3 开发 根据自定义协议要求,开发M7镜像的串口接收与Checksum逻辑 John.Li 4 开发 修改M7镜像支持串口0 John.Li 5 开发 开发实现M7镜像的串口单字节同步收发函数 John.Li 6 开发 开发实现A53启动功能 John.Li 7 调试与Debug 调试解决串口接收乱码问题(Serial boot rom codes仍然在回送消息串口) John.Li 8 调试与Debug 提供 解决A核启动串口halt思路(Serial boot rom codes仍然占用串口) John.Li 9 调试与Debug 优化M7镜像,缩小大小 Tony.Zhang 10 调试与Debug 根据M7镜像和A核 Uboot在SRAM中的内存分配要求,重排M7镜像位置,避免冲突 Tony.Zhang 11 调试与Debug 在M7中初始化SRAM空间 Tony.Zhang 12 调试与Debug 在M7中设置SRAM可执行空间 Tony.Zhang 13 调试与Debug 调试解决由于cache没有及时回写导致的下载镜像错误的问题 Tony.Zhang 14 调试与Debug 集成,调优与文档 John.Li   Pls check the attachment for the doc/codes/binary release which include:    Release      |->M7: Linflexd_Uart_Ip_Example_S32G274A_M7: S32DS M7工程。      |->PC: s32gSerialBoot_Csharp: PC端的Visual Studio的C#的串口工具工程。      |->Test:      |    |-> 115200_bootloader.bin: S32DS M7工程编译出来的bin文件,波特率为115200      |    |-> 921600_bootloader.bin: S32DS M7工程编译出来的bin文件,波特率为921600      |    |->load_uboot.bat: 运行工具的批处理文件,运行成功后打开串口可以看到Uboot执行,默认使用的波特率是115299         |    |->readme.txt:其它测试命令 |    |->s32gSerialBoot.exe:编译出来的PC端串口工具 |    |->u-boot.bin: BSP29默认编译出来的u-boot.bin.      Product Category NXP Part Number URL Auto MPU     S32G274     https://www.nxp.com/s32g    
View full article
Description    NXP’s Personal Network Attached Storage (NAS) solution enables portable personal storage to be shared through an internal protocol (IP) or Wireless network allowing users to share photos, data, stream music or videos, backup and recovery of data over the local area network in a completely secure environment. In addition, the solution can support gateway features such as packet forwarding, cloud connectivity via Ethernet, Wi-Fi or LTE. This NAS solution offers significant advantages to consumer and SMB environments, including: Hardware-accelerated Raid for data parity and recovery, a reduced bill of materials (BOM) and ease-of-use associated with an IP network that most business and consumers already find familiar. Based on the QorIQ Layerscape LS1012A processor and the Network Attached Storage Application Solution Kit (ASK), the personal/consumer NAS solution offered by NXP allows developers to easily build storage applications leveraging the highly-optimized and feature rich ASK software stack along with the small form factor, low-power consumption and packet processing capabilities enabled by LS1012A processor. NXP provides an integrated platform solution (SW and HW) helping the customer to reduce his time to market, increase security and increase performance by leveraging the packet accelerators within the QorIQ® Layerscape LS1012A processor while delivering high NAS performance and IP forwarding applications with reduced load on the Arm® core. In addition, NXP LS1012ARDB supports a full set of popular interfaces such as SATA, USB 3.0, PCIe and 2.5/1Gigabit Ethernet for LAN and WAN, allowing customers and operators to securely connect storage devices with the cloud. Features Integrated Platform Solution Commercial Market Proven Software Solution Hardware Offloading Popular Connectivity Flexible and Optimized Software Architecture Use Cases Personal Storage Consumer Network Attached Storage (NAS) Consumer Direct Attached Storage (DAS) Battery Powered Portable NAS Wireless Personal Storage Media Gateway Chip on Drive Wi-Fi SSD and Small/Portable Drive Ethernet Drives Block Diagram Products Category Name MPU Product URL Layerscape LS1012A Communication Processor for the IoT | NXP  Product Description The QorIQ® LS1012A processor, optimized for battery-backed or USB-powered, space-constrained networking and IoT applications Category Name DC Regulator Product URL MC34VR500 | Multi-Output DC/DC Regulator | NXP  Product Description The NXP® MC34VR500 power management solution for network processor systems is a high-efficiency, quad buck regulator with up to 4.5 A output and five user-programmable LDOs. Tools Product URL QorIQ® LS1012A Development Board QorIQ® LS1012A Development Board | NXP  Layerscape FRWY-LS1012A board FRWY-LS1012A Development Platform | NXP 
View full article
This doc explain how to compile PFE driver into kernel to accelerate the network boot time, chinese version: 目录 1    需要的软件,工具与文档... 2 2    目前PFE驱动的情况... 2 3    将PFE Slave驱动编译进内核... 3 3.1  将PFE驱动代码加入内核... 3 3.2  开发Makefile文件... 6 3.3  编译与测试... 8 4    将PFE Master驱动编译进内核... 10 4.1  编译Master工程... 10 4.2  测试... 11 4.3  解决FW的加载问题... 11 Contents 1    Related Materials. 2 2    Current PFE Driver 2 3    Compiled PFE Slave into Kernel 3 3.1  Put the PFE driver source into kernel source. 3 3.2  Develop the Makefile. 6 3.3  Compilation and Testing. 8 4    Compiled PFE Master Driver into Kernel 10 4.1  Compiling the Master driver 10 4.2  Testing. 11 4.3  Solve the FW loading fail issue. 11    
View full article
Overview This NXP® reference design of a 3-phase sensorless PMSM vector control drive with a sliding mode observer (SMO) is targeted mainly for compressor control and other consumer and industrial applications. This cost-effective solution uses the NXP MC56F8013 device dedicated for motor control. Software written in C-code using some library algorithms Available for the MC56F8013 and MC56F8346 digital signal controllers Hardware-based on the NXP universal motor control h/w modules Features The system is designed to drive a three-phase PM synchronous motor. Application features are: 3-phase sensorless PMSM speed vector control (FOC) Sliding mode observer with adaptive velocity estimation Based on NXP ®  MC56F8013 (resp. 56F8346) controller Running on a 3-phase high voltage (230/115V) power stage FreeMASTER software control interface and monitor Block Diagrams Design Resources
View full article
Overview The 3-phase PMSM Vector Control using Quadrature Encoder on based on Kinetis® K40 MCUs reference design demonstrates the ability of the Kinetis K40 Arm® Cortex®-M4 MCU to drive the advanced motor control application. Targeted at the NXP® Tower® rapid prototyping system as a hardware development platform. Together with available embedded source code, you can quickly build own industrial drive application. For the successful execution of the vector control algorithm, the information on the motor shaft position is critical. The quadrature encoder position information is known in the entire motor speed range, allowing the motor start with full torque at zero speed. Features Vector control of the PMSM using the quadrature encoder as a position sensor Targeted at the Tower ®  rapid prototyping system (K40 tower board, Tower 3-phase low voltage power stage) Vector control with a speed closed loop Rotation in both directions Application speed range from 0% to 100% of nominal speed (no field weakening) Operation via the user buttons on the Kinetis ®  K40 Tower board or via FreeMASTER software Block Diagram Design Resources
View full article
Linux kernel is not real time OS, while some applications is time sensitive tasks running in Linux environment, this request to extend the real time feature in common Linux kernel, and RT_PREEMPT is one of the methods to enable Linux kernel with real time processing requirement. But RT_PREEMPT is not accepted by kernel, so it needs extra effort to porting this patch-set to i.MX8M family products. This patch-set is based on L4.14.78 for i.MX8M products, customer need to apply patches based on this release.
View full article
This post entry provides a detailed description of how to port the NFC Reader Library to Kinetis K64F MCU. It is used a real porting example exercise to show the steps required to adapt the NFC Reader Library to a sample target MCU. The goal of this post is to serve as a guide for software developers requiring to port the NFC Reader Library to their MCU of choice for their designs. NFC Reader Library overview The NFC Reader Library is a software stack for creating and developing contactless applications for NXP’s NFC frontends and NFC controllers with customizable firmware. This library provides an API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices or emulating cards. The NFC Reader Library: It is based on a modular approach It has been designed with a flexible and multilayered architecture It is written in ANSI-C programming language It is supported in multiple design environments and platforms and it has been developed with a strong focus on portability. It is available for free download. The NFC Reader Library v5.02.00 currently supports: All our NFC frontends (CLRC663 plus PN5180) and PN7462 NFC controller. Their corresponding development boards, used as NXP reference HW (CLEV6630B, PNEV5180B, PNEV7662B) And built-in MCU support for LPC1769, LPC11U68, FRDM-K82F and Raspberry Pi. In addition, the release includes several examples to get familiar with the library and which can be used as reference for your developments and, it is also included an HTLM-based API documentation for all the components, which is generated from source-code annotations. NFC Reader Library architecture The NFC Reader Library is encapsulated into layers, differentiated by colors, and components, differentiated in boxes. From top to bottom, we have: The Application Layer (AL), which implements the command sets to interact with MIFARE cards and NFC tags. The NFC activity, which implements a configurable Discovery loop for the detection of contactless cards, NFC tags or other NFC devices. Next to it, the HCE and P2P components, for the emulation of Type 4 tags and P2P data exchange respectively. The protocol abstraction layer (PAL), which contains the RF protocol implementation of the ISO14443, Felica, vicinity and NFC standards. One level down, the hardware abstraction layer (HAL), which implements the drivers for controlling the NFC frontends RF interface and capabilities. Below, the Driver Abstraction Layer (DAL), newly introduced in the latest release, which implements the GPIO pinning, the timer configuration and the physical interface (BAL) between the host MCU and the reader IC. Finally, the OSAL module, in charge of abstracting the OS or RTOS specifics (handles tasks such as timers, events, semaphores and threads) This layered architecture is helpful for several reasons: The eleven software examples, the Application Layer (AL) and the Protocol Abstraction Layer (PAL) are HW-independent, so that can be used on top of any NFC frontend. The the Application Layer (AL), the Protocol Abstraction Layer (PAL) and the Hardware Abstraction Layer (HAL) are platform-independent, so that can run in any MCU without any additional change. In case the reader MCU is part of the built-in support, the examples can be directly imported and executed straight forward. On the other hand, in case the reader MCU is not supported by default, the major advantage is that only adaptations in the DAL and OSAL layers are required, while the rest of the layers can be used without any modification. The NFC Reader Library structure can be seen more clearly when imported in the MCUXpresso development environment. After completing the import wizard, all projects are listed in the “Project Explorer” window. As can be seen in the screenshot, it contains different folders: API documentation folder Driver Abstraction Layer FreeRTOS support The platform support (in the screenshot, corresponding to the LPC support) The software examples (11) The Reader Library implementation And the OS abstraction layer NFC Reader Library porting to FRDM-K64F steps In the existing NFC Reader Library v5.02.00 release there is no native support for Kinetis K64F. However, it is included a pre-compiled package for Kinetis K82F MCU. We use the K82F NFC Reader Library package as a reference project to start the porting to K64F MCU. This package can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. The steps required to port the library to Kinetis K64F are: Prearing the HW (i.e the pining between the Kinetis and the NFC reader board). Setting up the development environment (i.e workspace). Perfoming some changes in project configuration settings Performing some code modifications in the DAL and application code for adding Kinetis K64F support. NFC Reader Library porting to FRDM-K64F - Preparing the hardware The hardware used for this porting exercise is: A CLEV6630B board (CLRC663 plus) as an NFC transceiver  A FRDM-K64F board (Kinetis K64F) as host MCU, used to load and run the application logic. The CLRC663 plus evaluation board is connected by default to an LPC1769 µC via SPI. However, the board is made in such a way that the LPC1769 MCU can be bypassed to connect an external MCU easily. For doing so: Six resistors from the board need to be removed. These are highlighted in red. Use the SPI pin connectors available on the left hand side, on the board edge. Next, to connect the two boards together, the pining routing was done as follows: We use the Kinetis K64F jumper 2 pin line for the MOSI, MISO, chip select and clock lines of the SPI communication. The IRQ, interface selection and reset pins of CLRC663 plus are connected in jumper 1 pin line. And, one ground pin used for reference. Therefore no complex HW manipulation was required since all interfaces are easily accessible via dedicated headers or test points. NFC Reader Library porting to FRDM-K64F - Setting up the development environment Once the HW connection is prepared, we can move to setting up the development environment and workspace. Get the latest NFC Reader Library release From the software perspective, first we need to download the latest NFC Reader Library package. To do so: Go to NXP dot com slash pages slash NFC Reader Library (www.nxp.com/pages/:NFC-READER-LIBRARY) Go to the Downloads tab and click on the download button Click download on the NFC Reader Library for Kinetis K82Fpackage. Generate a downloadable SDK package for FRDM-K64F board As part of the NXP support, an SDK with drivers, middleware, RTOS demos and more is available for any of its Kinetis and LPC micros.We need to build the corresponding one to K64F SDK. For that: Navigate to www.mcuxpresso.nxp.com and select SDK builder option. Then, use the drop-down menus to customize your SDK configuration, middleware and optional software components be included in the package. Select Request build. In a few minutes, you will receive an email with a link to download the SDK package, very similar to the one showed in the figure below. Import the NFC Reader Library into MCUXpresso workspace Next step to configure the development environment is to import the library package in the workspace. The easiest way is to use the Quick Start Panel on the left hand side. Click on Import project from file system Then, browse the library package in your file system. Click Finish to import it all to your workspace. Install and link FRDM-K64F SDK into MCUXpresso workspace The last step is to import the K64F customized SDK we configured from the MCUXpresso tools. To do so: Just drag and drop the SDK into the installed SDKs tab of the MCUXpresso IDE. (It will appear in the bottom part, in the center) Import the SDK into the workspace and link it with the software examples. It will appear as another folder in the project explorer window. If the K64F SDK has been properly imported in the workspace, we should see a new drop-down menu for K64F. From there, we should select K64F and click Apply so that the memory details for K64F are set to the project example NFC Reader Library porting to FRDM-K64F - Project configuration changes At this point we have the hardware and the workspace for software development ready. In this step, we will start porting the NfcrdlibEx1_BasicDiscoveryLoop  software example provided as part of the NFC Reader Library release. Select FRDM-K64F SDK in the project MCU settings One of the first configurations to be changed is the project MCU settings. These settings indicate which target host device is running the application code. These settings can be found if: You right click on the project example > Properties In the left-hand list of the Properties window, open “C++ build” and select “MCU settings” In the right-hand panel, we can observe the corresponding settings for K82F micro. The left figure indicates the project configuration settings used by the default SW example prepared for K82F while the right figure indicates the final project configuration settings used by the SW example ported to K64F. Define FRDM-K64F SDK preprocessor symbols in the project After that, we need to change the compiler preprocessor settings, which can be found in C++Build > Settings. In the project examples of the NFC Reader Library, the conditional directives like #ifdef and #ifndef are used to include or exclude portions of the code from the actual compilation. The conditional codes are included in the program compilation only if the MACROs are defined in the project compiler preprocessor settings. In the left side we can see the defined macros for the original project. Among them, includes one which defines that the HW used is PN518 and K82F board. Therefore, in the ported project, we need to replace the macros corresponding to K82F with the new ones corresponding to K64F.  For instance, the PHDRIVER_K64_CLRC663 macro includes in the compilation the files related to the new HW used in the ported project (for the board pin and GPIO config, SPI settings or timers). Precisely, these files are included inside BoardSelection.h file in the Driver Abstraction Layer (DAL). Add include paths for FRDM-K64F SDK files When including header files into our project, the compiler must be told which directories must be searched to find those files. To do this: Open the project properties. In the left-hand list, open “C++ Build” and Select “Settings”. In the right-hand pane, choose the “Includes” section. Click the “Add icon”. In the left figure, we see the compiler include paths for the K82F SDK of the original example. In the ported example, the K64F SDK sources will not yet compile since we did not tell the compiler about all the new include paths. Therefore, we need to add the new include paths pointing to the K64F SDK and put them into the MCUXpresso IDE project. In the right figure, you can see the paths we included for this purpose. Mainly, these paths reference to the board system init, board drivers, CMSIS files and debug utils. Add include path for FRDM-K64F MCU assembler The last MCUXpresso settings to be changed is in the MCU Assembler. This can be found in the right-hand panel, choose the “MCU Assembler” and select “General”. In the original source code, a path is used to the K82F SDK. In the ported example, we just need to remove the previous include path and replace it with the corresponding one pointing to the K64F SDK in our workspace. NFC Reader Library porting to FRDM-K64F - Code changes So far, we have the HW, the development environment prepared and the project configuration settings changed. At this point, there are only a few code changes to be done before the porting is completed and the software example can be run in K64F. DAL driver adaptation for FRDM-K64F The layered architecture of the NFC Reader Library makes porting easier since only the lower drivers need to be adapted. This driver includes functions for: The physical link connection establishment between the CLRC663 plus and K64F The init functions for timers and interrupts so they are correctly used by the application layer. Going to the NfcrdlibEx1-BasicDiscovery loop project structure, it contains several folders. If we open the DAL > board folder, we can observe one source file per each supported platform (LPC with PN5180 and CLRC663, and the same for Raspberry Pi and Kinetis K82F). Our task for the porting would be to create an equivalent source file for the new supported board, the K64F together with the CLRC663 (e.g. Board_FRDM_K64FRc663.h). This file includes The related board pin and GPIO configurations The SPI configuration The timer configuration In addition, we need to include the board, pin_mux and clock config files. Use SDK examples to get FRDM-K64F board specific configuration Implementing these board specific files, in some cases, could be time consuming and may require experience. However, you do not need to do so but rather use the existing source files. For that, you can use any of the existing SDK software examples. You can easily import one SDK example by: Clicking the “Import SDK” example in the quick start menu > select the FRDM-K64F board. Selecting the demo example. Each example application has its own unique copy of the board, pin mux, and clock config files that you can reuse for the porting (Note: this process could be different depending on the MCU used). Add FRDM-K64F macro definitions in the source code Next, along the project tree, we need to add the #ifdef directives, indicating that K64F board files that need to be compiled. This is the case for: The BoardSelection.h file The ph_NxpBuild_App.h, which links the board with the reader IC by enabling the CLRC663 plus module in the HAL layer. The ph_AppInit.h so that the board is initialized when the reader device boots. Add FRDM-K64F CPU initialization code The ph_AppInit.h  file takes care of the code initialization and code specific to the HW used to run the example. As part of this ph_AppInit.h file, there is a function in charge of initialization the host MCU. Here, we need to implement the corresponding function for the K64F init, based on the SDK example source code selected earlier. If we look within this routine, we actually find functions for: Configuring the MCU clocks. Configuring the MCU pins. Configuring the interrupts (PIT). NFC Reader Library porting to FRDM-K64F: NfcrdlibEx1_BasicDiscoveryLoop execution After following the previous steps, the source code is succesfully ported to K64F. The following video demonstrates the correct execution of the NfcrdlibEx1_BasicDiscoveryLoop example in FRDM-K64F host MCU connected to CLRC663 plus NFC frontend (CLEV6630B). The video includes a webcam, which records the HW, including all the witing wiring between the K64F and the CLRC663 plus antenna. After the code is built and compiled, the video shows how some tags are tapped to validate that the example is working as expected (tag's UIDs are displayed in the MCUXpresso console). . General considerations to port the NFC Reader Library to your target MCU Overall, the general steps required to port the NFC Reader Library to your target MCU are: Adapt the MCU drivers to the DAL layer in the NFC Reader Library. This typically includes: timers, interrupts, pining and host interface configuration between the NFC reader and host MCU sides. Adapt the OS layer (i.e. you might need to port the FreeRTOS or to your target OS platform). Adapt the source code examples: project settings (macros, include paths, MCU configuration) and perform the required code modifications (Code for HW initialization, board files, etc). Available resources NFC Reader Library:  www.nxp.com/pages/:NFC-READER-LIBRARY CLRC663 plus: www.nxp.com/products/:CLRC66303HN CLRC663 plus development kit: www.nxp.com/demoboard/OM26630 FRDM-K64F board: www.nxp.com/demoboard/FRDM-K64F Video recorded session
View full article
This doc explain bootloader secure boot feature and how to re-develop it to support: .FW update .OTP attribute access .IVT protect: 目录 1 参考资料 .................................................................... 2 2 S32G Secure Boot说明 ............................................. 2 2.1 IVT头格式与Secure Boot相关 ................................ 3 2.2 Secure Boot流程 .................................................... 3 2.3 Secure Boot配置 .................................................... 4 2.4 Secure Boot涉及到的HSE内容 ............................... 6 3 环境搭建 .................................................................... 7 3.1 搭建编译环境 .......................................................... 7 3.2 IVT镜像制造 ........................................................... 7 3.3 镜像烧写 ................................................................. 8 3.4 Bootloader Secure Boot测试 .................................. 8 4 Bootloader Secure Boot代码与功能说明 ................... 9 4.1 EB配置说明: ........................................................ 9 4.2 EB生成代码说明: ............................................... 15 5 定制1:HSE FW update .......................................... 22 5.1 代码开发 ............................................................... 22 5.2 测试 ...................................................................... 25 6 定制2:HSE OTP Attribute设置 ............................... 26 6.1 代码开发 ............................................................... 26 6.2 模拟测试 ............................................................... 33 7 定制3:IVT签名 ....................................................... 35 7.1 代码开发 ............................................................... 35 7.2 模拟测试 ............................................................... 40 Contents 1 Reference Materials .................................................. 2 2 S32G Secure Boot ..................................................... 3 2.1 IVT header format for the Secure Boot part .......... 3 2.2 Secure Boot Flow ................................................... 3 2.3 Secure Boot Configuration ..................................... 4 2.4 HSE background of Secure Boot ........................... 6 3 Build the Project ........................................................ 7 3.1 Build the Compiling Environment ........................... 7 3.2 Create IVT Image ................................................... 7 3.3 Burning Image ........................................................ 8 3.4 Bootloader Secure Boot Testing ............................ 9 4 Bootloader Secure Boot Codes and Function Description 9 4.1 EB Configuration .................................................... 9 4.2 EB output codes ................................................... 15 5 Customization 1:HSE FW update ......................... 22 5.1 Codes development ............................................. 23 5.2 Testing ................................................................. 26 6 Customization 2:HSE OTP Attribute Setting ......... 26 6.1 Code Development .............................................. 27 6.2 Simulation test ...................................................... 34 7 Customization 3:IVT Signature ............................. 36 7.1 Codes Development ............................................. 36 7.2 Simulation Testing ................................................ 40  
View full article