恩智浦设计知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

NXP Designs Knowledge Base

讨论

排序依据:
This guide is intended as a reference for creating a demo application using the SLN-VIZN-IOT kit. In this guide, we will be constructing a demo e-lock application using the SLN-VIZN-IOT kit for secure face recognition using liveness detection/anti-spoofing. If you haven’t already, be sure to check out the Getting Started Guide for the SLN-VIZN-IOT kit here. Build Process Our e-lock design will make use of GPIO_AD_B0_2 and GPIO_AD_B0_03 to drive an H-Bridge circuit which actuates a lock using a 9-volt battery. These pins (and our ground) can be found on the serial header located on the front of the kit as shown below: To build our e-lock, we will be modifying the sln_vizn_iot_userid_oobe application found in the SLN-VIZN-IOT SDK. Instructions for downloading the SDK and importing the userid_oobe application can be found in the ‘Get Software’ and ‘Build and Run’ sections of the Getting Started Guide. The following video shows the modifications necessary to implement the E-Lock demo using the sln_vizn_iot_userid_oobe project To enable these pins as GPIOs, we must modify pin_mux.h and pin_mux.c found under the board folder. For simplicity, we contained these initializations in a function called BOARD_InitDoorLockPins. The code to enable these pins was generated using MCUXpresso’s integrated Config Tools, although this is not necessary. The MCUXpresso Config Tools can be read about in-depth here. Next, we need to make sure that the BOARD_InitDoorLockPins function we just created actually gets called so that the GPIOs will work the way we want them to. To do this, we will add the function call inside of our main function in main.c. After adding the door lock initialization to main, we will modify sln_system_state.cpp found under the source folder to add the code which will toggle the GPIO’s we setup in the previous step. To do this, we will make use of the GPIO_PinWrite function found in “fsl_gpio.h.” Using this function requires us to add the line “#include fsl_gpio.h” at the top of sln_system.cpp like shown below: The GPIO_PinWrite functions here will be used to unlock the door whenever a face is recognized (sysStateDetectedKnownUser) and lock the door whenever no known users are in view of the camera (sysStateDetectedNoUser). With the software modifications complete, we need to compile the code and flash our kit with the updated firmware. This can be done by using the ‘Debug’ option found in the Quickstart Panel as shown below. Make sure that the project is compiled and flashed is the sln_vizn_iot_userid_oobe project by verifying the name of the project shown at the top of the Quickstart Panel. For more detailed instructions about flashing the SLN-VIZN-IOT, check out the Flash and Debug SLN-VIZN-IOT Project section under Build, Run in the Getting Started Guide.  With the software modifications complete and the updated firmware installed, all that’s left to do is to add some wires from the GPIO pins to the door lock and power on the kit. Now our e-lock is ready to go! When a user with an unrecognized face (indicated by a red LED) tries to turn the handle nothing happens.  But when a user with a recognized face (indicated by a green LED) tries to turn the handle, the lock is disengaged allowing the latch to move. Conclusion With just a few lines of code and some external hardware, we were able to create a fully-functioning face-controlled e-lock that works entirely offline just by using the SLN-VIZN-IOT. Not to mention the fact that there was no need for any ML experience whatsoever. Because the SLN-VIZN-IOT was designed with flexibility in mind, all sorts of use cases can be supported with only minimal effort when compared to a face recognition implemented from scratch. By using the production-ready software that comes provided with the kit, it’s now possible to add local (no cloud connectivity necessary) face and emotion recognition capabilities to all sorts of products in record time. We hope this guide was helpful in showing you how to jumpstart your face recognition project with the power of the SLN-VIZN-IOT. 
查看全文
Explore the MC34937, an industrial-grade 3-phase gate pre-driver for BLDC and PMSM motor control. The MC34937 can support 12V, 24V, and 36V motor control applications and easily interfaces to standard MCUs and DSPs. The demo shows the implementation of the MC34937 with Kinetis Microcontrollers E in a 36V battery-operated electric bike (eBike) application. This same system can be modified to be used in other industrial applications such as electric garden tools, industrial fans and pumps, and electric wheelchairs. Features Demo shows capability of Kinetis KE02 connecting to an MC34937 Motor Driver MC34937 able to drive 12V, 24V, 36V, 48V systems Featured NXP Products Kinetis E - KE02Z64 MC34937 3-phase gate pre-driver Block Diagram MC34937 Schematics and Software:
查看全文
This doc explain how to build a PFE master project on M7 and how to integration. chinese version. 目录 1 需要的软件与工具 ...................................................... 2 2 Master Demo编译说明 ............................................... 2 2.1 安装RTD_MCAL驱动 ............................................. 2 2.2 安装PFE_MCAL驱动 .............................................. 3 2.3 编译PFE master工程 .............................................. 3 3 修改为支持RDB板的RGMII接口 ................................ 4 3.1 硬件连接 ................................................................. 4 3.2 软件修改 ................................................................. 5 4 Master Demo测试 ...................................................... 7 4.1 硬件连接 ................................................................. 7 4.2 PFE_EMAC1(RGMII)测试过程 ............................... 7 5 Master Demo代码说明 ............................................... 8 6 集成中注意点 ........................................................... 11 6.1 PFE_PreInit .......................................................... 11 6.2 S32G3中的GENCTRL1的配置 ............................. 12 6.3 RX CLOCK重新锁定 ............................................ 13 7 Demo Debug建议 .................................................... 14 7.1 PFE相关寄存器说明 ............................................. 14   Contents 1 Required software and tools ...................................... 2 2 Master Demo compiling ............................................. 2 2.1 Install RTD_MCAL driver........................................ 2 2.2 Install PFE_MCAL driver ........................................ 3 2.3 Compile PFE master project .................................. 3 3 Change the demo to support RDB3 board RGMII port4 3.1 Hardware design .................................................... 4 3.2 Software modification ............................................. 5 4 Master DemoTest ...................................................... 7 4.1 Hardware design .................................................... 7 4.2 PFE_EMAC1(RGMII) test steps ............................. 7 5 Master Demo code flow ............................................. 8 6 Notes in integration .................................................. 11 6.1 PFE_PreInit .......................................................... 11 6.2 The GENCTRL1 configruation of S32G3 ............. 12 6.3 RX CLOCK relock ................................................ 13 7 Demo Debug suggestion ......................................... 14 7.1 PFE related registers ........................................... 14
查看全文
This doc explain how to support a new QSPI nor for boot, SDK and Linux, Contents as follows: 目录 1 硬件设计 .................................................................... 2 2 所需工具和相关资料 .................................................. 5 3 ROM Code的启动流程 ............................................... 5 4 S32G QSPI NOR flash配置表头定制 ......................... 7 4.1 S32G QSPI NOR启动配置表信息 .......................... 7 4.2 目前支持的配置表头分析说明 ............................... 10 4.3 LUT构成与Flash write Data说明 ........................... 16 4.4 具体分析已有的配置表头的LUT与Flash write Data的 配置方法 ...................................................................... 22 4.5 支持一款新的QSPI NOR Flash示例1:Micron........ 28 4.6 支持一款新的QSPI NOR Flash示例2:Winbond .... 31 5 使用IVT打包配置头 .................................................. 33 6 使用IVT工具中的flash image工具烧写镜像到QSPI NOR 中 34 7 软件定制M7 ............................................................. 35 8 软件定制uboot ......................................................... 37 9 软件定制Linux Kernel .............................................. 40 9.1 支持美光8bit DDR 模式(未验证) .......................... 44 9.2 支持1bit SDR fast read 模式 ............................... 46 10 Debug过程中需要注意的几点 .................................. 49 10.1 启动时ROM Code读取QSPI NOR时钟仅有12Mhz左 右 49 10.2 比较大的镜像如果不加参数头,无法从QSPI-NOR上启 动 55   add a new doc for lauterbach driver: S32G How to Develop the QSPI-Nor Lauterbach Script 目录 1    背景和参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 2 2    高速读开发流程... 3 2.1  时钟相关修改... 5 2.2  Lut配置说明... 6 2.3  QSPI NOR控制器配置... 12 2.4  QuadSPI_Write32BytesDOPI读函数分析... 15 2.5  增加AHB read寄存器配置... 17 2.6  测试结果... 18 3    高速写开发流程... 19 3.1  Erase lut分析及调用... 19 3.2  Write lut分析及调用... 21 3.3  测试结果... 22 3.4  Lauterbach烧写镜像脚本说明... 22
查看全文
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
查看全文
This post entry provides a guide to designing antennas for the NTAG I2C plus. This article has been structured as follows: How the NTAG I2C plus works The NTAG I2C plus is what we call a connected NFC tag. It combines a memory, a passive NFC interface and a contact I2C interface. Additionally, it has more features such as: A field detection pin, to send a wake-up signal to a connected MCU The Energy harvesting, able to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Memory access control options, available from both NFC and I2C interfaces And the originality signature, to protect your brand against clones As such, it supports bidirectional communication between an NFC-enabled device and the host MCU and it is an ideal solution for Industrial applications, IoT nodes, meters, consumer electronics and accessories among others.  To enable the NFC interface, the chip needs to be connected to an antenna coil using the two dedicated antenna pins. How to design this coil is the main goal for today. NTAG I2C plus antenna design files The NTAG I2C plus support package includes development kits, demo apps, sample code, application notes, and, the design files of the Class 4 PCB antenna, and the Class 6 Flex antenna, which are available for direct and free download from the website.   These design files include: The schematics  The Gerbers The BoM Therefore, if you do not have any antenna size or shape constrains in your application, the easiest is to just copy & paste these reference antennas. On the other hand, if you need to design your custom antenna, NXP also offers a coil design Excel sheet to help you. I will talk more about it along the article. Basic antenna theory for NTAG I2C plus tags The NTAG I2C plus is an 8-pin package, with: The field detection pin The Vout pin The I2C serial clock and data Iines to the MCU The ground The VCC wo antenna pins NTAG I2C plus electrical input capacitance The NTAG I2C plus equivalent circuit can be represented with: A resistor, representing its current consumption And a parallel capacitor, representing the chip internal capacitance For the NTAG I2C plus, this capacitance is 50pF for both the 1k and 2k memory versions. Precisely, the chip capacitance is the most important factor for the antenna tuning. Antenna coil electrical equivalent circuit The antenna coil itself is a resonant circuit with an input impedance. The electrical equivalent model of the antenna coil consists of: An inductance A capacitance And some resistive losses of the loop antenna itself. The actual impedance value depends on:  The antenna material The thickness of the turns, mainly affecting the resistance  The distance between the windings, mainly affecting the capacitance The number of turns, mainly affecting the inductance  And the nearby environment Tag with an NTAG I2C plus electrical equivalent circuit When the NTAG I2C chip and the antenna coil are assembled, we can consider a parasitic resistance and capacitance generated by the connections between the chip and the antenna. This parasitic impedance depends on the assembly process used and the antenna material.  As a result, what we can observe in the schematic of the figure is that the NTAG I2C plus capacitance together with the parasitic connection capacitance and the antenna capacitance forms a resonance circuit with the inductance of the antenna coil.   The self-resonance frequency of a system is given when the imaginary part of the circuit equivalent impedance is null, and the system is only purely resistive. Considering the antenna loop inductance, the parallel equivalent capacitance and the parallel equivalent resistance of the tag, the resonance frequency and the quality factor of the tag can be calculated by these formulas. Antenna design procedure for NTAG I2C plus tags The antenna design procedure for the NTAG I2C plus tags is:  Design the antenna coil. This is about the antenna specs in terms of number of turns, track width, spacing, shape, etc according to your application requirements. Characterize the antenna coil and find its R, L, and C parameters. Calculate the parallel capacitor value required to adjust the tag resonant frequency Assemble the calculated capacitor and measure the results. If the results are not accurate enough, fine-tune the capacitor value, assemble and measure again as needed. Design the antenna coil  As part of the ISO14443 standard, six PICC antenna classes are defined. Per each of the antenna class, the physical characteristics and dimensions are defined. For instance, Class 1 is the largest, with a size comparable to the size of a regular credit card, and Class 6, which is the smaller one. In addition, Class 3 to Class 6 define two antenna shapes: a rectangular and a circular one. However, tag manufacturers are not constrained to conform to any of these dimensions. Therefore, its use is optional and rather intended to improve interoperability. As such, you may consider using these antenna sizes as a reference for your designs. The major parameter of the antenna coil is the inductance. This inductance can be estimated based on geometrical parameters and the material properties such as: The diameter for a round antenna or the overall length and width for a rectangular shape. The track width The gap between track The thickness And the number of turns To avoid cumbersome formulas, NXP offers you an Excel-based coil calculation tool to estimate the inductance of rectangular and circular antennas. This tool uses some parameters related to the material used and the antenna dimensions. And with it, it estimates the antenna inductance for you. Typically, the coil design steps include: An estimation of the electrical parameters, like the operating frequency and the chip capacitance The definition of the target inductance, we define the dimensions, the track width, the gap between track, the thickness, etc that achieves our target inductance. The production of prototypes. Based on the matrix run, with different inductance values deviated between 10-20% plus and minus the original value. Characterization of the coil prototypes. Based on this characterization, select the one with the best parameters for your application.  If needed, you can execute a second matrix run, with new prototypes, based on the first results. Measure the antenna coil parameters The antenna characterization can be done using a network analyzer connected to the antenna pads, isolated from the rest of the circuit. For our case, a low-end solution, such as the miniVNA PRO is sufficient. This device is cheap compared with the high-end devices like Agilent but still, accurate enough for our needs.  As a remark, it is fundamental that this characterization is done with the antenna placed at its final mounting position, so that all environment effects, like metal plates or others, are considered. Calculate the resonant capacitor value We use a network analyzer to measure the system resonant frequency after connecting the NTAG I2C plus to the antenna coil. As I explained before, the self-resonant frequency of the tag is given when the system is purely resistive. Most likely, the actual resonant frequency will not be 13.56MHz as we would like, but some other value. If that is your case, calculate the system capacitance at the current resonant frequency based on the equation derived from the NFC tag equivalent circuit shown previously. At this point: We know the current resonant frequency We know the antenna inductance, because we measured it before with the network analyzer And, as design parameter, we define the target resonant frequency With this data, we can use once again, this formula to calculate which is the resulting capacitance that would make our tag resonate to our target resonant frequency. Knowing the required total capacitance and the actual capacitance, we can calculate the extra capacitance missing. This is given by this formula: Regarding the target resonant frequency, for single tag operation, a tuning slightly above 13.56 MHz would lead to maximum read-/write distance. However, due to manufacturing tolerances, a nominal frequency up to 14.5 MHz would still operate well. Assemble and measure resonant frequency Therefore, the last steps are: Solder the capacitor in parallel Connect the network analyzer And measure the new resonant frequency  If the resonant frequency measured is not the target one, repeat the process by fine tuning the capacitor value.  If the frequency is higher than expected, you can increase the capacitor value. On the other hand, if the frequency is lower than expected, you can decrease it. Example: Tuning for a 54x27mm PCB antenna Based on a real lab exercise, this section illustrates the steps to adjust the tuning of an antenna for the NTAG I2C plus. As described before, we need to start by characterizing our antenna coil. In this lab exercise, we have used a PCB antenna of 54 by 27 mm and, we have connected our miniVNA PRO to the antenna pads. The results that we have obtained from this measurement are that our PCB antenna has an inductance around 895 nH. After characterizing the antenna coil: We have soldered the NTAG I2C plus chip to this PCB antenna. Right after, we connect again the miniVNA PRO to measure the actual resonant frequency.  In this case, it returns a resonant frequency near 24 MHz. Using the formula, we calculate that the tag capacitance at 24 MHz is almost 50 pF. Note that, the actual capacitance is basically the chip capacitance as the antenna and connection capacitance is usually not impacting significantly. Obviously, a resonant frequency of 24MHz is way too high for a ISO14443 NFC tag like our NTAG I2C plus. Therefore, we need to add some capacitance to the system so that we can bring this resonant frequency down. As an example, for this lab exercise, we are adjusting the tag to around 13.6 MHz, intentionally a bit higher than the NFC operating frequency. With a target resonant frequency to 13.6MHz and an antenna inductance is around 895nH,  the result is that the tag needs a total capacitance of around 153 pF. This means that we need to solder an extra capacitance of 100pF to bring down the resonant frequency.  So we go to our component box, and select the closer commercial value (100pF). As a last step, it is worth to measure how well adjusted is our system after adding the 100pF. We connect the miniVNA to the system including the IC, the antenna and the 100pF. Now, the results obtained are that the resonant frequency is 13.8 MHz. In our case, we consider this as good enough. However, you are always free to repeat this process as many times as needed until you obtain the accuracy that you need. Summary The antenna tuning steps for the NTAG I2C plus that we followed are: Design the antenna coil. You can use the NXP reference antennas or design your own antenna coil using the NXP Excel-based calculation tool. Measure the antenna coil. Use a network analyzer connected to the antenna pads, without any other circuitry Calculate the extra capacitance. Measure the current resonant frequency, and we calculate the extra capacitance needed to achieve the desired operating frequency. Solder and measure. If the results are sufficient, you are done. Otherwise, repeat the process with a new capacitance value As you can see, the antenna tuning process is quite straight forward. Basically, it is a matter of adjusting the capacitance of the tag until the operating frequency is the right one. Further information You can find more information about NFC in: NTAG I2C plus website http://www.nxp.com/products/:NT3H2111_2211 NTAG antenna design guide support package https://www.nxp.com/docs/en/application-note/AN11276.zip NXP technical community: https://community.nxp.com/community/identification-security/nfc NXP design partners: https://nxp.surl.ms/NFC_AEC Video recorded session On 25 July 2018, a live session explaining this topic was delivered. You can watch the recording here:
查看全文
This post entry provides a detailed description of how the Device-to-device communication demo was developed so that you can leverage this knowledge to integrate NFC into your own system. This document has been structured as follows:   Introduction Device-to-device communication demo functionality NFC for communication with a batteryless unit NFC for communication between two devices mounted in close proximity NFC for communication with a rotating part as a cable replacement solution Hardware details Base board based on CLRC663 plus Rotating disk based on NTAG I2C plus Application logic Reader module to rotating disk communication Rotating disk to reader module communication MCU code details NTAG I2C plus pass-through mode data exchange synchronization considerations Reader module MCU code NTAG_Device2DeviceDemo  application workflow Rotating disk MCU code NTAG_I2C _Explorer_01_LEDs_ButtonXample application workflow Video recorded session Available resources Introduction The Device-to-device communication demo shows how NFC can be used as a cable replacement between two units or devices. It is based on the CLRC663 plus NFC Frontend and the NTAG I 2 C plus connected tag solutions. It demonstrates how NFC is used for: Wireless communication with a batteryless unit. Wireless communication between two devices mounted in close vicinity that need to be completely isolated (e.g. dust or water proof). Wireless communication with a rotating part and as a cable replacement solution.   Device-to-device communication demo functionality The purpose of the demo is to illustrate how to enable device-to-device communication via NFC. It consist of: A base board of 14x12 cm, which embeds the CLRC663 plus NFC reader IC for the RF field generation. A sensor embedded on a separate, rotating sensor disk of 8 cm diameter, which embeds the NTAG I 2 C plus connected tag.   The base board and the rotating sensor disk communicate via NFC and optionally, a tablet display can be connected via a Bluetooth Low Energy (BLE) connection (the BLE connection is beyond the scope of this post entry).     NFC for communication with a batteryless unit The first scenario demonstrates the use of NFC for communication with a batteryless unit or sensor. Energy from the RF field generated by an NFC reader can be harvested to power up small devices so that a battery or other power supply no longer needs to be included.   In this demo, only the base board is powered using a 5V supply input (e.g. USB battery bank) while the rotating disk electronics are powered using only the harvested energy from the RF field generated by the base board. To maximize energy transfer and avoid possible interference caused by the electronics, both the rotating disk and base board antennas are placed on the edges. In the following video, you can observe how as soon as the base board is supplied, it starts generating an RF field and automatically. Then,  all the electronics on the rotating disk are powered and its LED turns GREEN.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/f54/f54337d597118_12181097.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387b9f NFC for communication between two devices mounted in close proximity The second scenario demonstrates the use of NFC for communication between two devices mounted in close proximity. For instance, any machine or device where sensors are inside or in close vicinity and the sensor needs to be completely sealed (e.g. waterproof, dustproof, etc).   In this demo, the bidirectional communication between the two units is demonstrated using push buttons, which light up LEDs on the opposite unit. For the base board to rotating disk communication direction: While action button 1 is pressed, the LED on the rotating disk turns BLUE. While action button 2 is pressed, the LED on the rotating disk turns RED. While action button 1 and button 2 are pressed, the LED on the rotating disk turns WHITE.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/912/912db3bd13b06_12160248.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387c99 With the other way around, for the rotating disk to base board communication direction: While action button 3 is pressed, a pattern on the LED circle will appear.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/d0b/d0b0072da0120_12160391.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387e98   NFC for communication with a rotating part as a cable replacement solution The third and last scenario demonstrates the use of NFC to communicate wirelessly with two moving parts where cables may break. For instance, any solution consisting of a main unit and a sensing part recording mechanical-stress readings on moving parts.   In this demo, the accelerometer on the rotating disk continuously sends its coordinates to the base board, which lights up a specific LED according to the calculated angle between the two units. In the following video, you can see that the LED circle "follows" the movement of the rotating disk.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/c0e/c0e3daf347aed_12160349.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5438709a   Hardware details This section shows the architecture and main components of the base board and rotating disk.  The PCB schematics are attached at the end of this post entry.   Base board based on CLRC663 plus The disk has been dismounted so you can better appreciate the different components of the base board. The base board is driven by an LPC11U68 MCU, which is a low-cost Cortex-M0 USB solution, with 256 kB of flash memory, up to 80 GPIOs and several host interfaces (more details on the LPC11U68 product website).   From the LPC11U68 MCU, some of the GPIOs are used to connect the action buttons and the 12 LEDs of the circle, an SPI port is used to connect the CLRC663 plus NFC Frontend and, a USART port is used for connecting a BLE chip based on NXP's QN9021 chip.     The NFC functionality is provided by our CLRC663 plus reader IC, an NXP high performance multi-protocol reader. It is the evolution of CLRC663, with a larger LPCD detection range, more output power (2x times higher transmitter current), larger temperature operating range and pin-to-pin compatibility with the former version.   Rotating disk based on NTAG I 2 C plus The rotating disk is based on NXP solutions as well. This PCB board is driven by an LPC11U24 MCU, which is a low-cost Cortex M0 32 bit MCU, with 32 kB of flash memory, up to 40 GPIOs and several host interfaces (more details on the LPC11U24 product website).   From the LPC11U24 MCU, some of the GPIOs are used to connect the action button 3 and the RGB LED. In addition, an I 2 C interface port is shared to connect a temperature sensor, the accelerometer and the NTAG I 2 C plus.     The NTAG I 2 C plus is a family of connected NFC tags that combines a memory, a passive NFC interface with a contact I 2 C interface.  Functionally, the NTAG I 2 C plus behaves as a dual port memory. Therefore, the data can pass from an external NFC device to the embedded system. In addition, to this dual interface solution, it has more features: A field detection pin, to send a wake up signal The Energy harvesting, to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Several memory access management settings from both NFC and I2C interfaces And an originality signature, to protect against clones.   Application logic This section describes how data is exchanged between the reader module (base board) and the rotating disk using NTAG I 2 C plus as a bridge (pass-through mode) between the two embedded systems.   Reader module to rotating disk communication In this demo, the reader module sends data to the rotating disk when any of its two action buttons are pressed. The NTAG I 2 C plus is configured in pass-through mode and the SRAM memory is used as conduit between the twto units.  The figure below illustrates a simplified representation of NTAG I 2 C plus memory seen from the NFC perspective (organized in pages of 4 bytes each). The red area represents the EEPROM memory while the yellow one represents the SRAM memory location. While the button 1 is pressed: The GPIO 4 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x01). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 18 status to high level. The RGB LED turns blue.   The operation that takes place while button 2 is pressed is pretty similar. Basically, it changes: the data written by the CLRC663 plus in the SRAM and the GPIO activated by the LPC11U24 on the rotating disk. More precisely, the steps are: The GPIO 5 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x02). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 16 status to high level and sets GPIO 18 to low level. The RGB LED turns red.     In the same way, while the two buttons are pressed at the same time: The LPC11U68 detects that GPIO 4 and 5 are in high level The CLRC663 plus programs a different value on the last SRAM byte (0x03). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 sets to high the three GPIOs (16,17,18) controlling the RGB LED. The RGB LED turns white The key message is that: what it is written in the SRAM controls the behavior of the rotating disk LED, demonstrating wireless data exchange between the two embedded systems.   Rotating disk to reader module communication In this demo, the rotating disk keeps sending data to the reader module for as long as it is powered by the RF field. Precisely, it continuously sends the disk position (via the accelerometer axis coordinates) and the measured temperature value. Additionally, an extra byte is sent while the button 3 is pressed. The actual steps are: First, the LPC11U24 MCU triggers a read operation to the temperature sensor and accelerometer. The temperaturre reading occupies 2 bytes while the accelerometer axis coordinates occupy 6 bytes. This data is transfered the LPC11U24 via the I 2 C shared bus. The LPC11U24 writes these 8 bytes into the SRAM in page addresses 0xFD, 0xFE and 0xFF (see the figure below). The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With the read information, the LPC11U68 base board MCU calculates the angle and sets the appropriate GPIO to high level. Since the LED circle contains 12 LEDs, the base board is able to represent position changes of 30 degrees (360º / 12 LEDs).   As mentioned, this data transfer keeps going for as long as the disk is powered. The key concept here is that the LED circle operation is directly controlled by the disk position and the axis coordinates which are exchanged via the NTAG I 2 C plus SRAM at any given moment. To illustrate this, the disk is rotated 90 º clockwise. The steps that take place are: The LPC11U24 MCU triggers the next reading command, the accelerometer axis coordinates have changed to different ones representing the new disk position (in red in the memory map figure below). The LPC11U24 writes into the SRAM again these 8 bytes (now with the updated accelerometer axis coordinates) The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With this new reading, the LPC11U68 MCU recalculates the angle and applies a different GPIO configuration (which leads to a different LED turned on in the circle).     Last, while button 3 is pressed: The LPC11U24 GPIO 12 is set to high value. The LPC11U24 checks GPIO 12 pin status before writing into the SRAM. While it is high level, it adds an additional byte into the SRAM (third byte on page 0xFF- value=0x01). The CLRC663 plus reads the SRAM, getting the latest data from the moving part. With the current firmware, while the third byte on page address 0xFF is set to 0x01, the LPC11U68 performs a LED pattern activating all the GPIOs simultaneously (all the LEDs are ON).     MCU code details This section explains the firmware implementation details for both the base board (CLRC663 plus) and the rotating disk (NTAG I 2 C plus). Before going into the firmware implementation details, a few considerations for data exchange synchronization when using the NTAG I 2 C plus pass-through mode are explained.   NTAG I 2 C plus pass-through mode data exchange synchronization considerations In the demo, the pass-through mode is used to exchange data between the base board and the rotating disk. The pass-through mode provides the SRAM for data communication and the mechanisms for the synchronization of the data transfer. This signalling can be done through the field detection pin or by polling the equivalent registers over the I 2 C interface. For the NFC to I 2 C direction, the synchronization can be done: By checking the SRAM_I2C_READY register to learn if new data has been written by the RF interface. By checking the filed detection pin changing from HIGH to LOW voltage.   For I 2 C interface to NFC direction, the synchronization can be done: By checking the SRAM_RF_READY register to learn if new data has been written by the I 2 C interface. By checking the filed detection pin changing from LOW to HIGH voltage.   The following table includes register bits which can be used for communication synchronization. In addition, there is a dedicated application note providing more details on how NTAG I 2 C plus can be used for bidirectional data communication.   Register bit Use PTHRU_ON_OFF Detects if the pass-through mode is still enabled (gets reset in case of RF or I2C power down). TRANSFER_DIR Defines the data flow direction for the data transfer. I2C_LOCKED Detects if memory access is currently locked to I2C. RF_LOCKED Detects if Memory access is currently locked to RF. SRAM_I2C_READY Detects if there is data available in the SRAM buffer to be fetched by the I²C side. SRAM_RF_READY Detects if there is data available in the SRAM buffer to be fetched by the RF interface. RF_FIELD_PRESENT Shows if a RF field strong enough to read the tag is there.   Reader module MCU code The MCU firmware was developed using our LPCXpresso platform, which provides a complete development environment for LPC MCU and LPC boards. In the source code, there are five project folders: The FreeRTOS project folder, which is an open source real-time operating system (RTOS) for embedded systems supporting many different architectures and compiler toolchains The Lpc_chip_11u6x_lib and nxp_lpcxpresso_11u68b project folders, which belong to the LPCOpen libraries supporting the LPC11U68 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_Device2DeviceDemo  project folder, which implements the logic supporting the device-to-device communication demo for the reader module. The NxpNfcRdLib project folder, which is the NXP's NFC Reader Library software stack supporting the implementation of the demo, the contactless protocols, the LPC MCU host interfaces and the CLRC663 drivers.   The reader module MCU code leverages on the NFC Reader Library. The NFC Reader Library is a software stack for creating and developing contactless applications for NXP's NFC readers. This 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 and emulating cards.   In order to use the NFC Reader Library, a stack of components has to be built up from the bottom to the top layer. Precisely, the application requirements define which modules need to be enabled and which do not. For the reader module firmware: The FreeRTOS is used. The SPI is used as host interface. A CLRC663 plus reader IC is used. And, communication with NTAG I 2 C plus is needed ( ISO14443 Type A card and NFC Forum Type 2 Tag compliant)   As a result, the software components that need to be enabled within the NFC Reader Library are depicted in the following picture: NTAG_Device2DeviceDemo  application workflow The reader module firmware starts its execution as soon as it is connected to the power bank. The firmware initializes the GPIOs, the UART for the tablet connection and the NFC Reader Library for the contactless operation. After all these initializations, the firmware code generates a new thread in charge of dealing with the disk operation. In this separate thread, the discovery loop for detection of Type A and Type V cards is configured and started. After that, the firmware keeps listening until the NTAG I 2 C plus is detected (i.e. the disk is mounted). On detection, the operation with the rotating disk starts: The reader module waits until the SRAM is available for the RF interface. The SRAM is available for the RF interface while the pass-through mode is enabled (PTHROUGH_ON_OFF register is set) and the RF to I 2 C direction is set (TRANSFER_DIR register bit). The board buttons are checked and the SRAM is written with the corresponding information.   At this point, the program awaits to receive data from the rotating disk. For that, it keeps polling if new data was written in the SRAM by the I 2 C interface (SRAM_RF_READY register bit is set). If new data is available, the SRAM is read and the data is processed: The accelerometer axis coordinates are read, the angle is calculated and the appropriate LED on the circle is activated. While the button 3 is pressed, the MCU triggers the LED pattern on the circle. Optionally, if the tablet connection is established, data is also sent using the BLE channel.   The following figure depicts the reader module application workflow in detail:   Rotating disk MCU code The MCU firmware was also developed using the LPCXpresso platform.  In the source code, there are four project folders: The Lpc_chip_11uxx_lib and nxp_lpcxpresso_11u24h_board_lib project folders belong to the LPCOpen libraries supporting the LPC11U24 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_I 2 C _API project folder is a library providing a set of functions and procedures that allow you to communicate with the NTAG I 2 C from the I 2 C interface. Among others, functions to perform memory operations on EEPROM, SRAM, registers and for enabling the pass through mode The NTAG_I 2 C _Explorer_01_LEDs_ButtonXample project folder implements the logic for the rotating disk of this demo.   NTAG_I 2 C _Explorer_01_LEDs_ButtonXample application workflow The rotating disk firmware starts its execution as soon as it harvests enough energy from the reader's module RF field. The first operation taken is to enable the pass-through mode. Then, the firmware stays on a loop for as long as it is energized.   In this loop, it sets the SRAM into RF to I 2 C direction (TRANSFER_DIR register bit) and waits until the base board has written data. After data has been written from the RF side, it reads the SRAM and checks the last byte: While the last byte value is 0x01, it means the button 1 is pressed and the firmware sets the RGB LED to blue While the last byte value is 0x02, it means the button 2 is pressed and the firmware sets the RGB LED to red While the last byte value is 0x03, it means the button 1 and 2 are pressed and the firmware sets the RGB LED to white.   After receiving data from the base board, it prepares to send data back. For that: it checks the button status, it reads the temperature value and the accelerometer position. Once all the data has been collected: It changes the SRAM to I 2 C to RF direction (TRANSFER_DIR register bit). It writes into the SRAM and waits until the RF has read the data (SRAM_RF_READY register is cleared).   This loop is repeated for as long as the disk is powered. The following figure depicts the rotating disk application workflow in detail:     Video recorded session On 9 March 2017, a live session explaining the device-to-device communication demo was recorded. You can watch the recording here:   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/149/149fee5f5e282_12181079.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5439ff51 Available resources   Schematics Please see attached in the separate attachment section below. Device-to-device demo source code Please see attached in the separate attachment section below. Quick-start guide for showing the demo Please see attached in the separate attachment section below Android app The android app can be used on a tablet or smart phone connected via BLE to this demo to show additional parameters, and to have a bigger screen for demonstrations. You find it in Google play ("device2devicedemo") and attached below.  
查看全文
If we flash a RD-RW612-BGA binary into FRDM-RW612 the board will be locked, and we will no longer be able to write data into the flash until we unlock it. The reason why it locks is because the Winbond flash on the FRDM board has a lock bit that is enabled when flashing the RD application. Fortunately, there is a way to unlock it with the FlexSPI interface. In this document we will briefly show how to do this. In SDK 2.16.100, we will modify the frdmrw612_flexspi_nor_dma_tranfer SDK example. We're going to modify app.h, flexspi_nor_flash_ops.c and flexspi_nor_dma_transfer.c.   In app.h we modify/add some macros with the following values:       #define SECTOR_SIZE 0x10000 /* 64K */ #define NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD 0 #define NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG1 1 #define NOR_CMD_LUT_SEQ_IDX_WRITEENABLE 2 #define NOR_CMD_LUT_SEQ_IDX_ERASESECTOR 3 #define NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG2 4 #define NOR_CMD_LUT_SEQ_IDX_ERASECHIP 5 #define NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG3 6 #define NOR_CMD_LUT_SEQ_IDX_READ_NORMAL 7 #define NOR_CMD_LUT_SEQ_IDX_READID 8 #define NOR_CMD_LUT_SEQ_IDX_WRITE 9 #define NOR_CMD_LUT_SEQ_IDX_READSTATUSREG1 10 #define NOR_CMD_LUT_SEQ_IDX_READSTATUSREG2 11 #define NOR_CMD_LUT_SEQ_IDX_READSTATUSREG3 12 #define NOR_CMD_LUT_SEQ_IDX_READ_FAST 13 #define NOR_CMD_LUT_SEQ_IDX_ENABLE_RESET 14 #define NOR_CMD_LUT_SEQ_IDX_RESET_DEVICE 15 #define CUSTOM_LUT_LENGTH 64 /* Enable quad and update dummy cycle */ #define FLASH_QUAD_ENABLE 0xC740       Moving to flexspi_nor_flash_ops.c we will add/modify the following parameters: In flexspi_nor_wait_bus_busy(FLEXSPI_Type *base):     flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_READSTATUSREG1;       Right after the previous function we are going to add these new functions:     status_t flexspi_nor_write_status1(FLEXSPI_Type *base, uint8_t status1) { flexspi_transfer_t flashXfer; status_t status; uint32_t writeValue = status1; /* Make sure external flash is not in busy status. */ status = flexspi_nor_wait_bus_busy(base); if (status != kStatus_Success) { return status; } /* Write enable */ status = flexspi_nor_write_enable(base, 0); if (status != kStatus_Success) { return status; } /* Write the status register 1 */ flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Write; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG1; flashXfer.data = &writeValue; flashXfer.dataSize = 1; status = FLEXSPI_TransferBlocking(base, &flashXfer); if (status != kStatus_Success) { return status; } status = flexspi_nor_wait_bus_busy(base); /* Do software reset. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; } status_t flexspi_nor_write_status2(FLEXSPI_Type *base, uint8_t status2) { flexspi_transfer_t flashXfer; status_t status; uint32_t writeValue = status2; /* Make sure external flash is not in busy status. */ status = flexspi_nor_wait_bus_busy(base); if (status != kStatus_Success) { return status; } /* Write enable */ status = flexspi_nor_write_enable(base, 0); if (status != kStatus_Success) { return status; } /* Write the status register 1 */ flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Write; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG2; flashXfer.data = &writeValue; flashXfer.dataSize = 1; status = FLEXSPI_TransferBlocking(base, &flashXfer); if (status != kStatus_Success) { return status; } status = flexspi_nor_wait_bus_busy(base); /* Do software reset. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; } status_t flexspi_nor_write_status3(FLEXSPI_Type *base, uint8_t status3) { flexspi_transfer_t flashXfer; status_t status; uint32_t writeValue = status3; /* Make sure external flash is not in busy status. */ status = flexspi_nor_wait_bus_busy(base); if (status != kStatus_Success) { return status; } /* Write enable */ status = flexspi_nor_write_enable(base, 0); if (status != kStatus_Success) { return status; } /* Write the status register 1 */ flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Write; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG3; flashXfer.data = &writeValue; flashXfer.dataSize = 1; status = FLEXSPI_TransferBlocking(base, &flashXfer); if (status != kStatus_Success) { return status; } status = flexspi_nor_wait_bus_busy(base); /* Do software reset. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; }   In  status_t flexspi_nor_enable_quad_mode(FLEXSPI_Type *base):     flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG1;                   Delete status_t flexspi_nor_flash_program(FLEXSPI_Type *base, uint32_t dstAddr, const uint32_t *src, uint32_t length) & status_t flexspi_nor_flash_page_program(FLEXSPI_Type *base, uint32_t dstAddr, const uint32_t *src).     Modify status_t flexspi_nor_get_vendor_id(FLEXSPI_Type *base, uint8_t *vendorId) to:         status_t flexspi_nor_get_vendor_id(FLEXSPI_Type *base, uint8_t *vendorId, uint16_t *deviceId)           Right after status_t flexspi_nor_get_vendor_id(FLEXSPI_Type *base, uint8_t *vendorId, uint16_t *deviceId):         status_t flexspi_nor_get_status1(FLEXSPI_Type *base, uint8_t *status1) { uint32_t temp; flexspi_transfer_t flashXfer; flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Read; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_READSTATUSREG1; flashXfer.data = &temp; flashXfer.dataSize = 1; status_t status = FLEXSPI_TransferBlocking(base, &flashXfer); *status1 = temp; /* Do software reset or clear AHB buffer directly. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; } status_t flexspi_nor_get_status2(FLEXSPI_Type *base, uint8_t *status2) { uint32_t temp; flexspi_transfer_t flashXfer; flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Read; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_READSTATUSREG2; flashXfer.data = &temp; flashXfer.dataSize = 1; status_t status = FLEXSPI_TransferBlocking(base, &flashXfer); *status2 = temp; /* Do software reset or clear AHB buffer directly. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; } status_t flexspi_nor_get_status3(FLEXSPI_Type *base, uint8_t *status3) { uint32_t temp; flexspi_transfer_t flashXfer; flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Read; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_READSTATUSREG3; flashXfer.data = &temp; flashXfer.dataSize = 1; status_t status = FLEXSPI_TransferBlocking(base, &flashXfer); *status3 = temp; /* Do software reset or clear AHB buffer directly. */ #if defined(FSL_FEATURE_SOC_OTFAD_COUNT) && defined(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK) && \ defined(FLEXSPI_AHBCR_CLRAHBTXBUF_MASK) base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK; base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK); #else FLEXSPI_SoftwareReset(base); #endif return status; } status_t flexspi_nor_reset_device(FLEXSPI_Type *base) { status_t status; flexspi_transfer_t flashXfer; flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Command; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_ENABLE_RESET; status = FLEXSPI_TransferBlocking(base, &flashXfer); if (status != kStatus_Success) { return status; } status = flexspi_nor_wait_bus_busy(base); flashXfer.deviceAddress = 0; flashXfer.port = FLASH_PORT; flashXfer.cmdType = kFLEXSPI_Command; flashXfer.SeqNumber = 1; flashXfer.seqIndex = NOR_CMD_LUT_SEQ_IDX_RESET_DEVICE; status = FLEXSPI_TransferBlocking(base, &flashXfer); if (status != kStatus_Success) { return status; } status = flexspi_nor_wait_bus_busy(base); return status; }     Then in the last file flexspi_nor_dma_transfer.c:   We are modifying the prototype flexspi_nor_get_vendor_id to:     extern status_t flexspi_nor_get_vendor_id(FLEXSPI_Type *base, uint8_t *vendorId, uint16_t *deviceId);     And we are going to add the following prototypes:     extern status_t flexspi_nor_get_status1(FLEXSPI_Type *base, uint8_t *status1); extern status_t flexspi_nor_get_status2(FLEXSPI_Type *base, uint8_t *status2); extern status_t flexspi_nor_get_status3(FLEXSPI_Type *base, uint8_t *status3); extern status_t flexspi_nor_reset_device(FLEXSPI_Type *base); extern status_t flexspi_nor_write_status1(FLEXSPI_Type *base, uint8_t status1); extern status_t flexspi_nor_write_status2(FLEXSPI_Type *base, uint8_t status2); extern status_t flexspi_nor_write_status3(FLEXSPI_Type *base, uint8_t status3); extern status_t flexspi_nor_erase_chip(FLEXSPI_Type *base);       In flexspi_device_config_t deviceconfig modify the following:     .dataValidTime = 2,     Modify the const uint32_t customLUT[CUSTOM_LUT_LENGTH] as follows:     const uint32_t customLUT[CUSTOM_LUT_LENGTH] = { /* Normal read mode -SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_NORMAL] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x13, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x20), [4 * NOR_CMD_LUT_SEQ_IDX_READ_NORMAL + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Fast read mode - SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x0C, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x20), [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_SDR, kFLEXSPI_1PAD, 0x0A, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Fast read quad mode - SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0xEC, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_4PAD, 0x20), [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_SDR, kFLEXSPI_4PAD, 0x0A, kFLEXSPI_Command_READ_SDR, kFLEXSPI_4PAD, 0x04), /* Write Enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x06, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Erase Sector */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x21, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x20), /* Read ID */ [4 * NOR_CMD_LUT_SEQ_IDX_READID] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x9F, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Write status 1 */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x01, kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04), /* Write status 2 */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG2] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x31, kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04), /* Write status 3 */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG3] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x11, kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04), /* Dummy write, do nothing when AHB write command is triggered. */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0), /* Read status 1 register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUSREG1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Read status 2 register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUSREG2] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x35, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Read status 3 register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUSREG3] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x15, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Erase whole chip */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASECHIP] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0xC7, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Enable reset */ [4 * NOR_CMD_LUT_SEQ_IDX_ENABLE_RESET] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x66, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Reset device */ [4 * NOR_CMD_LUT_SEQ_IDX_RESET_DEVICE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x99, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), };       In int main(void) add the following variables:     uint16_t deviceID = 0; uint8_t status1 = 0, status2 = 0, status3 = 0;         in main, configure the DMAMUX as follows (this should be before DMA_Init(EXAMPLE_DMA):     /* Configure DMAMUX. */ RESET_PeripheralReset(kINPUTMUX_RST_SHIFT_RSTn); INPUTMUX_Init(INPUTMUX); INPUTMUX_AttachSignal(INPUTMUX, EXAMPLE_TX_CHANNEL, kINPUTMUX_FlexspiTxToDma0); INPUTMUX_AttachSignal(INPUTMUX, EXAMPLE_RX_CHANNEL, kINPUTMUX_FlexspiRxToDma0); /* Enable trigger. */ INPUTMUX_EnableSignal(INPUTMUX, kINPUTMUX_Dmac0InputTriggerFlexspiRxEna, true); INPUTMUX_EnableSignal(INPUTMUX, kINPUTMUX_Dmac0InputTriggerFlexspiTxEna, true); /* Turnoff clock to inputmux to save power. Clock is only needed to make changes */ INPUTMUX_Deinit(INPUTMUX);       in main, delete all the code from PRINTF("\r\nFLEXSPI dma example started!\r\n"); to one line before the last while(1). Before that while, add the following code:   PRINTF("\r\nFLEXSPI Unlock code started!\r\n"); /* FLEXSPI init */ flexspi_nor_flash_init(EXAMPLE_FLEXSPI); /* Get vendor ID. */ status = flexspi_nor_get_vendor_id(EXAMPLE_FLEXSPI, &vendorID, &deviceID); if (status != kStatus_Success) { PRINTF("Error getting flash ids: 0x%x\r\n", status); return status; } PRINTF("Vendor ID: 0x%x\r\n", vendorID); PRINTF("Device ID: 0x%x\r\n", deviceID); /* Get Status 1 */ status = flexspi_nor_get_status1(EXAMPLE_FLEXSPI, &status1); if (status != kStatus_Success) { PRINTF("Error getting status1: 0x%x\r\n", status); return status; } PRINTF("Status 1: 0x%x\r\n", status1); /* Get Status 2 */ status = flexspi_nor_get_status2(EXAMPLE_FLEXSPI, &status2); if (status != kStatus_Success) { PRINTF("Error getting status2: 0x%x\r\n", status); return status; } PRINTF("Status 2: 0x%x\r\n", status2); /* Get Status 3 */ status = flexspi_nor_get_status3(EXAMPLE_FLEXSPI, &status3); if (status != kStatus_Success) { PRINTF("Error getting status3: 0x%x\r\n", status); return status; } PRINTF("Status 3: 0x%x\r\n", status3); if(status2 & 0x01) { PRINTF("Error, The Flash Status register is locked! Disconnect and connect the board with the ISP button pressed to clear it and try again.\r\n"); return 0; } status1 = 0x00; status2 = 0x02; /* Write 0s to Status 1 */ status = flexspi_nor_write_status1(EXAMPLE_FLEXSPI, status1); if (status != kStatus_Success) { PRINTF("Error writing status1: 0x%x\r\n", status); return status; } /* Write 0x02 (Quad enabled only) to Status 2 */ status = flexspi_nor_write_status2(EXAMPLE_FLEXSPI, status2); if (status != kStatus_Success) { PRINTF("Error writing status2: 0x%x\r\n", status); return status; } /* Get Status 1 */ status = flexspi_nor_get_status1(EXAMPLE_FLEXSPI, &status1); if (status != kStatus_Success) { PRINTF("Error getting status1: 0x%x\r\n", status); return status; } PRINTF("Status 1: 0x%x\r\n", status1); /* Get Status 2 */ status = flexspi_nor_get_status2(EXAMPLE_FLEXSPI, &status2); if (status != kStatus_Success) { PRINTF("Error getting status2: 0x%x\r\n", status); return status; } PRINTF("Status 2: 0x%x\r\n", status2); PRINTF("Erasing the whole chip, it will take several minutes to complete. \r\n"); status = flexspi_nor_erase_chip(EXAMPLE_FLEXSPI); if (status != kStatus_Success) { PRINTF("Error erasing: 0x%x\r\n", status); return status; } PRINTF("Chip erased!\r\n");     Now we need to compile. But first, we need to link the application to RAM. Please right click on the project and go to Properties. in C/C++ Build go to Settings. In MCU Linker, select Managed Linker Script and check the Link application to RAM box. Apply and close.   Now compile the example in MCUXpresso. Once compiled, get the binary. Go to the Debug folder in the project, and you will see an .axf file. Right click on the file and select Binary Utilities > Create binary. Now, we need to modify that binary. Open you preferred binary editor and delete everything from 0x0 to 0x17FFFFFFF. The first address in the binary (0x0) must have the data from 0x18000000. Now we can flash the binary. We are going to do this with blhost. 2 USB C cables are needed. We are going to connect them via J10 and J8. But first we need to setup the board in ISP mode. Connect J8 to the PC. Press the ISP button (SW3) and with the button pressed connect the board via J10. In blhost run the following:     blhost -u 0x1fc9,0x0020 get-property 1     Disconnect and connect (J10) your board with the ISP button pressed. Now run the following (YOUR BINARY should be the path and file in which the binary is located):     blhost -u 0x1fc9,0x0020 -- fill-memory 0x20001000 0x4 0xC0100002 blhost -u 0x1fc9,0x0020 -- configure-memory 0x9 0x20001000 blhost -u 0x1fc9,0x0020 -- get-property 0x19 0x9 blhost -u 0x1fc9,0x0020 -- write-memory 0x20000000 <YOUR BINARY>.bin blhost -u 0x1fc9,0x0020 -- execute 0x2000026c 0x20000000 0x20120000     If the above steps were correct, you should be able to flash your board again. Please try with a hello world example in MCUXpresso.
查看全文
本文说明在S32G3 RDB3板上,Uboot中使能PFE驱动时,需要加载PFE FW,默认Uboot中,PFE FW是放在SD/eMMC的FAT分区,通过文件系统访问来读取。本文说明如何修改为从QSPI NOR中读取。主要的应用场景是:  在烧写镜像时,需要Uboot通过网口来烧写内核镜像及rootfs。而此时SD/eMMC还没有分区,所以无法将PFE网口需要的FW放在FAT分区中。 目录 1    背景与相关资料... 2 1.1  问题背景... 2 1.2  需要的软件,工具与文档... 3 2    将Uboot PFE FW放在QSPI Nor上... 4 2.1  Uboot代码说明与修改... 4 2.2  测试... 6
查看全文
本文探讨了如何解决i.MX8MP EMC测试遇到的问题,主要针对辐射超标问题。除了硬件方案,着重探讨了LVDS展频等软件方案。
查看全文
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
查看全文
This application note explain how to run M kernel PFE master and A kernel PFE slave demo without bootloader support. chinese version: 在真实的产品中,一般会使用一个基于M7_0核的bootloader来启动M和A核,这个bootloader负责所有M核和A核资源的初始化,解决M核和A核的资源冲突,并且启动M和A核。所以理论上运行M PFE Master Mcal驱动加A PFE Slave Linux驱动也是需要一个bootloader的。参考文档《S32G_Bootloader_V*》,Johnli,可以在公开community上搜索获得。 本文讨论一种简易的办法,就是: S32G3 RDB3板子配置为SDcard启动,插入SDcard,里面放有PFE SLAVE驱动的Linux镜像。 上电启动后运行PFE Master工程的lauterbach调试脚本:run_main_G3_REV1_1.cmm,这个脚本会重启整个S32G3。 然后在脚本中用wait 10S的操作,这个时候Linux已经启动,并且使用Uboot的代码调用ATF来完成PFE相关pre-init, partition reset和时钟与管脚初始化(如上分析, EMAC0~2的RGMII IOMUX已经配置好),然后Slave驱动会等待一段时间,等MCAL Master驱动加载,继续运行PFE Master MCAL代码后,Linux端Slave驱动也加载正确。然后就可以测试整个M Master/A Slave Demo。 总结:以上办法实际上是把bootloader应该做的PFE相关硬件初始化工作由Linux来完成,以便快速搭建Demo,这样客户在做真实的产品开发时,可以做为一个NXP release的标准参考。
查看全文
结合MPC5748G的Lifecycle机制,阐述如何使用Lifecycle机制来满足在开发阶段及最终消费阶段对各利益相关方的数据进行保护的需求,比如Tier1的IP(知识产权)、OEM的一些标定参数、车主的个人隐私等。并介绍Lifecycle在每个阶段所支持的主要安全特性及如何配置使用。
查看全文
This article explains the details and customization of the S32G M7 core Standby demo. And how to porting to Autosar Mcal demo. Contents 1    Description of reference materials. 2 2    Demo creation and running process. 2 2.1  Demo checkpoints. 2 2.2  The difference between Standby and StandbyRAMboot 4 3    S32G Standby principle and Code Description. 5 3.1  Peripheral initialization function. 5 3.2  standbyramc_cpy(optional) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby principle and code description. 15 4.1  PMIC_initConfig. 15 4.2  PMIC_standbyEntry. 17 5    Customization modification. 18 5.1  Do not enable RTC wakeup feaure. 18 5.2  Eable CAN1_RX wakeup feature. 19 5.3  Only support full boot 21 5.4  Open the DDR related power 21 5.5  Modify debug serial port to UART1. 24 5.6  Modify the device drive clock. 26 5.7  close other non-main core. 30 6    Build a new MCAL demo. 34 6.1  Modify the UART driver 35 6.2  Implement the clock shutdown code. 36 6.3  Configure the power mode switching driver 37 6.4  Confgure the wakeup source. 42 6.5  Add PMIC driver 51 6.6  Main function call routine. 59 6.7  Test 61 6.8  Future development plan. 62 本文说明S32G M7核Standby demo 详细情况及定制,以及如何新建一个mcal demo 录 1    参考资料说明... 2 2    Demo创建运行过程... 2 2.1  创建运行... 2 2.2  Standby和StandbyRAMboot的区别... 4 3    S32G Standby原理与代码说明... 5 3.1  外设初始化函数... 5 3.2  standbyramc_cpy(可选) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby原理与代码说明... 14 4.1  PMIC_initConfig. 14 4.2  PMIC_standbyEntry. 16 5    定制修改... 17 5.1  关闭RTC唤醒功能... 17 5.2  打开CAN1_RX唤醒功能... 19 5.3  只支持full boot 20 5.4  打开DDR相关电源... 21 5.5  修改调试串口为UART1. 23 5.6  修改设备驱动时钟... 25 5.7  事先关掉所有其它的非主核... 29 6    修改为MCAL Demo. 33 6.1  修改UART驱动... 34 6.2  实现时钟关闭代码... 35 6.3  配置电源模式切换驱动... 36 6.4  配置唤醒源... 41 6.5  加入PMIC驱动... 50 6.6  主函数逻辑实现... 58 6.7  运行测试... 60 6.8  未来开发计划... 61   attachment include chinese/english doc, s32ds codes with 2 zip package(remove the .7z), mcal codes.  
查看全文
This doc explain how to modify the bootloader to boot linux&mcal, to solve the conflict between bootloader, mcal and linux   本文说明在S32G2 RDB2板上如何定制开发Bootloader,本文示例主要实现功能是: Bootloader启动一个M核,MCAL驱动测试程序,本文分别测试了MCU,DIO,UART的MCAL驱动示例代码。 Bootloader同时启动A53 Linux 目录 1    需要的软件,工具,文档与说明... 3 1.1  软件与工具... 3 1.2  参考文档... 3 1.3  开发说明... 3 2    测试软件安装编译说明... 4 2.1  安装RTD_MCAL驱动... 4 2.2  编译MCAL驱动测试程序(以MCU为例) 5 2.3  优化重排M7 demo镜像及与MPU设置的配合... 5 2.4  去掉CLOCK INIT. 7 2.5  去掉MCU相关INIT. 8 2.6  DIO MCAL程序去掉PORT INIT. 9 2.7  UART MCAL程序去掉PORT INIT. 10 2.8  UART MCAL程序修改CLOCK TREE.. 10 2.9  解决中断冲突... 11 2.10 准备A53 Linux镜像... 12 3    Bootloader工程说明... 13 3.1  关掉XRDC支持... 13 3.2  关掉eMMC/SD支持(可选) 14 3.3  关掉secure boot(可选) 14 3.4  增加MCAL驱动所需要的PORT的初始化... 15 3.5  解决Bootloader,MCAL与Linux的clock冲突... 17 3.6  配置A53 Boot sources: 34 3.7  配置M7 Boot sources: 35 3.8  关闭调试软断点:... 36 3.9  编译Bootloader工程... 37 3.10 制造Bootloader的带IVT的镜像... 38 3.11 烧写镜像... 41 4    测试... 42 4.1  硬件连接... 42 4.2  MCU MCAL+Linux测试过程... 42 4.3  DIO MCAL+Linux测试过程... 43 4.4  UART MCAL+Linux测试过程... 43 5    Bootloader源代码说明... 43 6    Bootloader定制说明... 45 6.1  QSPI NOR驱动说明... 45 6.2  eMMC/SDcard启动支持... 46 6.3  DDR初始化... 46 6.4  Secure Boot支持... 46 7    调试说明... 46 7.1  Bootloader的调试... 46 7.2  MCAL驱动的调试... 46   add one more doc to explain how to modify atf to boot on G3.
查看全文
  本文说明S32G  RDB2板Linux板级开发包BSP32 的ATF细节,以帮助客户了解S32G的ATF是如何运行的,以及如何修改到客户的新板上。   从BSP32开始,默认启动需要ATF支持,所以部分定制需要移动到ATF中,Uboot会简单很多。 请注意本文为培训和辅助文档,本文不是官方文档的替代,请一切以官方文档为准。   目录如下: 目录 1    S32G Linux文档说明... 2 2    创建S32G RDB2 Linux板级开发包编译环境... 3 2.1  创建yocto编译环境: 3 2.2  独立编译... 8 3    NXP ATF 原理... 13 3.1  AArch64 Exception Leve: 13 3.2  ATF原理... 14 3.3  ATF目录 结构... 16 3.4  ATF初始化流程... 25 3.5  NXP ATF的SCMI支持... 28 3.6  NXP ATF的PSCI支持... 32 3.7  NXP ATF OPTEE接口(未来增加)... 36 4    ATF 定制... 36 4.1  修改 DDR配置... 36 4.2  修改调试串口与IOMUX定制说明... 39 4.3  启动eMMC定制说明... 48 4.4  I2C与PMIC定制说明... 58
查看全文
This project include the codes and doc to support optimize the EMI of S32G by frequency changing and SSC. Contents as follows: 目录 1 展频的基本概念 ......................................................... 2 2 获取测试用uboot源代码 ............................................. 5 3 DDR_PLL的改频 ........................................................ 5 4 DDR_PLL的展频 ........................................................ 9 5 总结修改后的源代码 ................................................ 17
查看全文
This doc explain our Linux BSP driver and how to custom them. Contests as follows: include bsp30/32 目录 1 S32G Linux文档说明 ................................................. 2 2 创建S32G RDB2 Linux板级开发包编译环境 .............. 2 2.1 创建yocto编译环境: ................................................ 2 2.2 独立编译 ................................................................. 8 3 Device Tree ............................................................. 11 3.1 恩智浦的device Tree结构 ..................................... 11 3.2 device Tree的由来(no updates) ............................ 13 3.3 device Tree的基础与语法(no updates) ................. 15 3.4 device Tree的代码分析(no updates) .................... 37 4 恩智浦S32G BSP 包文件目录结构 .......................... 70 5 恩智浦Linux BSP的编译(no updates) ...................... 72 5.1 需要编译哪些文件 ................................................ 72 5.2 如何编译这些文件 ................................................ 73 5.3 如何链接为目标文件及链接顺序 ........................... 74 5.4 kernel Kconfig ...................................................... 76 6 恩智浦BSP的内核初始化过程(no updates) .............. 76 6.1 初始化的汇编代码 ................................................ 78 6.2 初始化的C代码 ..................................................... 82 6.3 init_machine ......................................................... 94 7 恩智浦BSP的内核定制 ............................................. 97 7.1 DDR修改 .............................................................. 98 7.2 IO管脚配置与Pinctrl驱动 .................................... 100 7.3 新板bringup ........................................................ 121 7.4 更改调试串口 ...................................................... 125 7.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 129 7.6 GPIO驱动 ........................................................... 137 7.7 GPIO_Key 驱动定制 .......................................... 145 7.8 GPIO_LED 驱动定制 ......................................... 150 7.9 芯片内thermal驱动 ............................................. 155 7.10 CAN接口驱动 ..................................................... 157 7.11 I2C及外设驱动 .................................................... 162 7.12 SPI与SPI Slave驱动 ........................................... 183 7.13 Watchdog test. ................................................... 190 7.14 汽车级以太网驱动定制 (未验证) (未完成) ........... 191
查看全文
About this demo This Demo contains fully working software to show the implementation of two great features from the QN9080SIP-DK. The BLE in this board provides a Beacon solution to be implemented, based on the SDK example downloaded in the https://mcuxpresso.nxp.com/en/select As previously mentioned, this demonstration is based on the Beacon example from the QN9080 SDK, along with the AN12319SW for using the NT3H2211 Tag. The main objective of this demo software is to write a string in the NTAG memory and be able to read the content using the NTAG stack (from the AN12319 project). Then trigger a message update to be advertised from the beacon. Project Scope Write an NDEF message with a smartphone, using NXP's TagWrite App into the NT3H2211. Be able to start advertising the 6-byte code/message using the BLE stack from the SDK version 2.2.3 into the MCUXpresso v11.2.1. Useful Links Link Description https://mcuxpresso.nxp.com/en/builder SDK Builder https://www.nxp.com/products/wireless/bluetooth-low-energy/fully-certified-module-supporting-bluetooth-and-nfc:QN9080SIP QN9080SIP full documentation https://www.nxp.com/docs/en/application-note/AN12319.pdf A document explaining brief integration for pairing using the NTAG https://www.nxp.com/docs/en/application-note-software/AN12319SW.zip  The respective Software for the AN12319   Required Items Link Description https://www.nxp.com/products/wireless/bluetooth-low-energy/a-highly-extensible-platform-for-application-development-of-qn908x:QN9080DK Board in which the demo was created and tested Android Smartphone Smartphone with IoT Toolbox and TagWriter App IoT Toolbox App https://play.google.com/store/apps/details?id=com.freescale.kinetisbletoolbox TagWriter App https://play.google.com/store/apps/details?id=com.nxp.nfc.tagwriter   Hardware Diagram     Step-by-Step Guide for testing the Demo Get the QN9080 SDK form SDK Builder  Install the QN908x SDK into your MCUXpresso Import the attached file into MCUXpresso on File > Open Projects from File System   Connect properly the NTAG antenna from the kit as shown in the Hardware Diagram. Connect the QN9080SIP-DK using a micro-USB cable. Flash the project into the board and Push Button 1 from the board while running. Open the TagWriter App from your phone and select the Write option. Create a New Plain text element and write any positive float number (< 0.0). Select the Save and Write button. Approach the phone into the NFC antenna. Press Button 1 again to restart the BLE advertising Open the IoT Toolbox App. Select the Beacons option. You should be able to visualize the new payload messages from the device. Note: These messages are representation in decimal from the actual 4-byte (32-bit) number. Each letter is composed of 2, 8-bit numbers. This RAW representation is for proof of concept purposes. This application can be replaced by another BLE device in scanning mode to perform a data post-process.  Additional Demo Information These next steps are intended to guide the developer to an easier understanding of the modifications that were made from the base project. This example provides a guide to learn the basic functionality of the high-level NTAG stack.   Select the FreeRTOS Beacon example from wireless_examples -> Bluetooth in the QN9080 SDK. After being sure that this demo works properly on our QN9080SIP-DK we need to import from the file system the AN12319 project. For being sure everything works, we can also test this project, inside it there is a file called: app_ntag.c inside the source directory. Inside this file, on the Public Functions section, we are able to modify the NDEF_Pairing_Write() and NDEF_Demo_Write() functions for our purposes. The first function is used as the name mentions, to execute the example for pairing our phone with the board without the need to type any pairing code. The second function writes an NDEF in the NTAG and can be read from the phone App TagInfo or TagWriter. To start with the actual creation of the application I used this project: "qn908xcdk_wireless_examples_bluetooth_hid_device_freertos" and started importing the beacon files needed from the beacon FreeRTOS example. As you can observe, this job facilitates a lot because of the similar structure between both projects, this will simplify the tasks and will help us not to get lost. Due to the fact that we started using the HID Device project, all the NTAG stack was already there so we will only be going to focus on the source directory for the additions and modifications. Starting with the erasing of the hid_device.c and .h, these files won't be required for this project. The beacon.c and .h are required to be in this project for the beacon functionalities and routines, this files depend on the Bluetooth stack, the general framework files, and the common files from the source directory. The app_config file has all the BLE needed configurations to set the parameters and respective structures. This is where the initial advertising message will be configured. For the NTAG configurations, the app_ntag file containing the high-level nTag functions for Read/Write capabilities that depends on the NTAG stack (NTAG_I2C/XXX) The ApplMain had some of the most significant changes due to being the main file that calls the BLE functions at the start and also manages the Interrupt used to trigger our own project functions using FD. The files that changed were, as mentioned above, ApplMain.c and app_ntag.c/.h . This has to do with the fact that we will only are going to change the functions called when a Tag Writer is in the field of the NFC antenna and how this data is processed in order to be read and sent to the aData array by using its structure. As you can see in the app_ntag.c file, the last two functions: NDEF_read_test() and getDataNDEF() represent the main changes in this file. Along with the pin configuration for FD managing in the ApplMain.c
查看全文
Demo The driver does not use a steering wheel or pedals to control a car on a race. All he uses is the movement of his head to turn the car and his mouth to accelerate and stop.       Featured NXP Products   K64_120 |Kinetis K64 120 MHz MCUs|NXP Freedom Development Platform for Kinetis|NXP Sensor Fusion|NXP   Links Arrow SAM Project   Videos          
查看全文