This post entry provides a detailed description of how to develop an NFC pairing solution for audio devices. For that, we will describe in detail an audio speaker prototype made by NXP. This post entry has been structured as follows: Use cases for Bluetooth and Wi-Fi pairing via NFC As the number of connected devices grow, the more important it becomes to connect them in a simple way. At the same, it is required to provide a consistent and pleasant user experience. NFC pairing is one popular NFC use case, just bringing two NFC-enabled devices close together is all it takes to create a connection. For instance: To connect to your TV, to transfer a video from your phone, or sharing screens between your tablet and the TV. To connect to your camera to transfer pictures. To connect your phone to a wireless speaker. To connect your new devices to the home network. To connect to your wearables to read your heart rate. Or, to set-up a multi-audio system with NFC. Precisely, this post will guide you through the implementation of the NFC pairing solution for a multi-audio system. Benefits offered by the NFC pairing solution There are several benefits to consider adding NFC to your consumer device. First, from the consumer perspective: It provides a faster and simpler way to link wireless devices, only one touch. The credentials for establishing this connection are exchanged in a secure way. The device is identified instantly, without conflicts. In addition, from the manufacturer perspective, the benefits come mainly from: Making the device more attractive, by adding a new feature. And making the device easier to use, reducing the cost associated to customer technical support. Overall, NFC pairing is an interesting solution since it combines the simple, one-touch setup of NFC with the higher speed, longer distance communication of BT or Wi-Fi networks Pair and unpair Bluetooth headsets with just a tap with NFC NFC pairing process steps To pair and send music to a BT headset is as simple as: Select and play a music track in our phone. Tap the BT headset with the phone. When doing so, the BT pairing credentials are exchanged securely via NFC without any manual settings. The phone automatically initiates a BT connection request. After a second, audio is streamed via BT to the headset without entering any manual configuration. Furthermore, this is not only restricted to phones and headsets, but in general between any two NFC-enabled devices. Therefore, it is also possible to pair and send music to two Bluetooth headsets at the same time, creating what is known as “a silent disco”. Again, the process is simple: First, tap the two headsets with NFC capabilities. When doing so, the headsets automatically exchange the pairing credentials. The headsets establish a BT connection. And audio is streamed between them without requiring any manual setting. Similarly, instead of creating a silent disco, wireless speakers can be paired together via NFC to create a multi-audio system.  As such, NFC offers a real one-touch solution. It works with any NFC phone and no dedicated app needs to be installed. NFC unpairing process steps To stop sending music and un-pair the headset is easy as well. A second tap is the only action required to disconnect the headsets. After the tap, the second headset automatically de-activates the audio streaming and switches off. Best of all, we have instant identification of the device to be disconnected. Therefore, zero chances to unpair the wrong device as might happen through the phone settings, where we can unintentionally pick the wrong one. Multi-audio wireless speaker demo with NFC pairing capabilities During the rest of this post, we will tear-down an NFC multi-audio wireless speaker prototype developed by NXP based on PN7120 NFC controller solution. Hardware architecture This demo consists of two speakers with the same components, and therefore, the same functionality. If we dismount one of the speakers, the components we can find in the device PCB are: A system on chip solution, with an application processor, embedded flash memory and BT wireless connectivity. A system crystal clock, the BT antenna and two audio speakers A power supply unit, which includes three 1.5V batteries providing a stable 1.8V output. A NFC reader module, based on PN7120 chip, with an integrated antenna and a compact form factor. Application circuit for Bluetooth power on by NFC triggering If we have a closer look to the power unit interface, we see that: The VBAT pin is directly connected to the batteries. (PN7120 it supports a wide range of power supply voltages, from 5.5V down to 2.75V) The pad supply (PVDD), for the host interface operation, is connected to the 1.8V from the PMU. A wake-up trigger is built so that the BT controller is powered when an RF-field is detected. Regarding the host interface between the NFC controller and the main system MCU: The PN7120 module is connected to the BT controller via I2C slave interface. It supports standard, fast and high speed I2C modes (100 kHz SCL, 400 kHz SCL, 3.4 MHz SCL) The corresponding pull-up resistors are connected on the data and clock lines (SDA and SCL). The IRQ pin is used for ensuring the data flow control between PN7150 and the BT controller. The VEN (RESET) pin, used for setting the device in hard power down mode.  And, in respect to the antenna interface: The PN7120 VGA package Some discrete components for the antenna matching And the antenna coil surrounding the PCB edge. Software architecture and NCI interface In this section, we detail the solution software stack and how the NFC application logic works within the overall system. Using the block diagram, we have added the software blocks in orange.First, the PN7120 module includes: The NCI firmware & transport mapping layer for I2C communication (nothing to take care of from the developer side, since this firmware already comes embedded in the chip). Similarly, the host controller side requires: The NCI driver & transport mapping layer to communicate with PN7120 On top of these layers, the application logic for the BT pairing is implemented. Finally, the BT stack for the audio streaming, , but this software piece is not detailed here as it is out of the scope of the NFC implementation. NFC controller interface (NCI) specification details NCI describes the internal interface between an NFC Controller and the main host platform (in this case, between PN7120 and the BT chip). NCI is defined by the NFC Forum organization. As such, it provides manufacturers with a standard interface they can use for whatever kind of NFC-enabled device they build (making integration easier, saving time and effort). The next figure represents the NCI architecture: At the bottom, we find the transport mapping blocks, which map the NCI protocol to an underlying physical connection (I2C, SPI, UART, etc) The NCI core defines the messages, commands and data format for the different communications On top, the NCI modules implement specific functionalities, like the RF discovery which configures the NFC controller to communicate with other NFC tags or devices. From the overall NCI architecture, this implementation makes use of: The transport mapping is the I2C block The RF discovery is configured so that the speaker iterates between the reader, card and P2P modes NFC controller interface: RF Discovery PN7120 firmware can combine the three NFC modes of operation using the RF Discovery as defined in NCI spec. The RF discovery is a cyclic activity which activates various modes of operation. This consists of a loop which alternates two phases: The polling and the listen phases. In the polling phase, the PN7150 acts as Reader or NFC Initiator for the P2P mode, searching for passive tags or an NFC target device. If no card or target was detected, it enters a listening phase, to potentially be activated as card or P2P target If no device to interact is detected in the polling or listening phase, it switches back to polling phase after a timeout. All RF technologies supported by PN7120 can be independently enabled within this discovery loop. However, the PN7120 is in poll phase generates RF field and consumes current. Therefore, the more technologies to be polled, the larger the average current consumption. Multi-audio speaker prototype: RF dscovery configuration To enable the speaker-to-speaker pairing functionality, each of the speakers needs: To have the capability to discover a remote speaker and initiate a pairing operation. Or the other way around, be discovered by a remote speaker to complete a pairing operation. To accomplish this, the speakers need to sequentially move from polling and listening phases. As such, the discovery loop configured in the application iterates between reader, P2P and card modes.During the polling phase, the speaker generates an RF field, and uses an NFC-A polling sequence looking for: A remote card or device in card emulation. If found, the NDEF data with the pairing info will be retrieved and processed. Next, it looks for a remote P2P device. If found, it pushes an NDEF message with the pairing info to this remote peer. On the other hand, during the listening phase, the speaker turns off its RF field and waits to be discovered by a remote device: If it is discovered while operating as P2P target, it will pull an NDEF message coming from the remote speaker. If it is discovered while operating in card mode, its NDEF message will be read by the remote speaker. The precise communication that takes place between the two speakers will differ every time. It will depend on the polling loop status of both speakers at the instant they are tapped. Application logic Until now, we have described how both speakers are discovered, and therefore, how they can start a communication to exchange pairing data via NFC. The next step is to  describe which data and which data format is used to exchange the pairing details. NFC Forum specifications The NFC Forum organization defined a set of specs explaining how to exchange pairing data over NFC in an interoperable way with just a tap, independent of the manufacturer and without installing any dedicated application for it. These are: Connection handover: This spec defines how two NFC devices can negotiate and activate an alternative communication carrier.  NDEF: The NDEF spec defines a message format to exchange data between NFC devices, including pairing data. Tag 1 Type to Tag 5 Type specs: These specs define how NFC devices can interact with five different types of tag technology. As a result, any NDEF message store in any of these five types of tags will be processed by any NFC-compliant device. NFC pairing: Static handover As mentioned earlier, how pairing data is transferred between the two speakers will depend on the discovery loop status. The static handover takes place when: One speaker is in reader mode / polling mode. (left hand side) The other speaker is in card mode / listening mode, showing a Type 4 Tag with an NDEF message on it (right hand side). The process is as follows: The speaker in reader mode activates RF field and generates a NFC-A polling sequence. The remote speaker in card mode responds to the polling command. The reader retrieves the NDEF data from the remote speaker, using the commands as defined in Type 4 tag NFC forum spec. The reader processes the carrier data from the NDEF message and establishes a BT connection according to BT protocol. The speaker in card emulation mode deploys a Handover Select NDEF record, advertising its BT carrier. In The NDEF message, we store: The BT device address (MAC address) Bluetooth local name (Friendly name for the user) Class of the device (e.g. headset, mobile, etc) This is the carrier data that will be used by the application to trigger the BT connection. After this proces, both devices start streaming music over BT. NFC pairing: Negotiated handover The other possibility is that when both speakers are tapped, they find themselves during the P2P operation. In such a situation, the pairing process will be conducted according to the Negotiated handover mechanism. One of them will take the role of initiator, the other the target role: The initiator will poll for target devices The target will respond to the initiator command The initiator will send a handover request message, with the carrier details The target will respond with a handover select message, indicating the selected carrier option. On the received data, the initiator will establish a connection according to BT protocol. After that, both devices start streaming audio over BT. In this case, both speakers exchange data with their alternative carrier capabilities, could be more than one. The initiator communicates to the target device its carrier capabilities with a Handover request record followed by an NDEF record per each available carrier (in this case, just one BT carrier). After that, the target replies to the initiator with the selected carrier to be used for the out of band data transfer. As before, the BT configuration in the NDEF message includes fields such as: BT address, device class, BT local name, and optional data if secure pairing according to BT spec is required.The key here is that, this negotiation protocol and these message formats are specified and defined in the NFC Forum specs, so they offer an interoperable solution for any compliant-platform Support package  This section details resources and information provided by NXP you can use to replicate your own multi-audio speaker solution with NFC pairing capabilities. PN71xx family of NFC controllers PN71xx family are solutions integrating an RF frontend together with an embedded microcontroller with dedicated FW and NCI interface. They fully comply with the NFC Forum, include Linux®, Android™, and WinIoT drivers and sample code for bare metal and RTOS integration. Additionally, they support direct supply from a battery, different power states and an ultra-low power polling loop. Their features make it ideal for NFC integration into any application, especially those with OS system. Hardware support From a hardware point of view, several demokits are available to evaluate PN71xx family. They interface into popular platforms, such as: Raspberry Pi BeagleBone Black Any board featuring an Arduino compatible header like LPCXpresso or Kinetis Freedom among others. In case you have to evaluate PN71xx into any other platform, these kits can be reused, The PN71xx board provides all required signal pins easily accessible so that you can design and build your own interface board for your target platform. Software support From a software support point of view,  device manufacturers can easily integrate PN71xx family in Linux, Android and Win IoT systems through the available SW drivers. But also, NXP supplies a set of code examples running on LPC and Kinetis MCUs for Bare metal RTOS integration. Precisely, the demo presented in this post, leverages on the NullOS/RTOS SW examples. The software example for PN71xx integration into RTOS / Bare metal system is made of 3 components: The NXP-NCI module offers an API for configuring, starting and processing the NFC device discovery The NDEF library offers an API for processing NDEF data over reader, card and p2p modes: The transport mapping layer providing HW abstraction for the host – NFC controller connection On top of it, developers can implement their own application. Available resources PN7120 product website: www.nxp.com/products/:PN7120 PN7120 demokits: www.nxp.com/products/:OM5577 PN7120 product website: http://www.nxp.com/products/:PN7150 PN7120 demokits: www.nxp.com/products/:OM5578 Reference source code and related documentation: https://www.nxp.com/doc/SW4325 and http://www.nxp.com/docs/en/application-note/AN11990.pdf  Video recorded session

The Cypherbridge Systems SDKPac is a collection of embedded device SDKs and Toolkits that can be used out of box to add secure device connectivity to a target project. The SDKPac includes features and standards based protocols for secure IoT connect-to-cloud, gateway, embedded servers and clients, secure file transfer protocols, and electronic data privacy. This SDKPac demo kit contains applications for the FRDM-K64F Freedom Development Board to demonstrate: uSSL/TLS server demo - connect to the FRDM-K64F Development Board from desktop browser. uSSH server demo - connect to the FRDM-K64F Development Board from uSSH client. uFTP secure FTP file transfer client - connect from the FRDM-K64F Development Board to FTPS server using FTPS secure file transfer protocol. uMQTT subscribe and publish examples interfacing to broker service Just drag and drop any of these pre-built binary applications on the FRDM-K64F Development Board to hit the ground running with your SDKPac demo today.   https://community.nxp.com/players.brightcove.net/4089003392001/default_default/index.html?videoId=4282648281001   Features uSSL SDK micro-content HTTPS server uSSH SDK server for secure telnet replacement uFTPS Secure file transfer Toolkit and command line client uMQTT client mmCAU Crypto Engine Support Integrated with MQX/RTCS 4.1 OpenSDA CMSIS-DAP Debug using SWD connection USB Serial Port Interface 10/100 Ethernet   SDK Connectivity uSSL/TLS 1.2 server and client, X.509 uSSH 2.0 server and client uSCP Secure Copy Protocol uFTPS RFC 959, 2228, 4217 uMQTT 3.1 Client subscribe and publish Links SDKPac Follow up System Diagram Software Diagram  

This post entry aims at explaining the debugging process oriented to EMVCo Contactless certification of a device integrating NXP's PN5180. The structure is the following: PN5180 Antenna design considerations Before going into the debugging process for the EMVCo Contactless Analog tests we will see some important considerations for an antenna design and impedance tuning oriented for an EMVCo compliant device. Antenna tuning recommendations The first recommendation is that with the Dynamic Power Control feature the PN5180 allows us to perform symmetrical antenna tuning instead of the typical asymmetrical tuning. This symmetrical tuning provides us with a better transfer function, being able to drive more power to the antenna. The following figure shows the Smith Chart with the S11 parameter plot of a device using a symmetrical antenna tuning:   The only disadvantage of the symmetrical tuning is that we need a current limiter to avoid destroying the chip because of exceeding the chip’s limits. In the case we are documenting today, the PN5180 DPC feature is used to limit the supply voltage and therefore the transmitter current depending on the load detected by the chip. Regarding the EMC filter, the inductor should fit with the following condition to guarantee a good relation between the AGC and the ITVDD: Another consideration is about the resistor used in the reception branch. This resistor controls the receiver sensibility and as a starting point is recommended to use a value to obtain an AGC in free air of: Reader Mode only design: AGC value in free air around 600dec Full NFC design: AGC value in free air around 300dec Finally, EMV contactless transactions are performed at 106kbps which would allow us to work with a high Q factor of the overall system. This means that the power gain can be higher, but at the same time it might also lead to some issues because of the lower bandwidth. In light of this, we have to bear in mind, that if the Q factor is too high it may lead to problems in the waveform tests. PN5180 DPC calibration The Dynamic Power Control is a feature that uses the AGC value to establish different power configurations depending on the load applied to the antenna. As I mentioned before, the main goal is to protect the chip from a transmitter current level that might destroy it. The first step before calibrating the DPC is to check the correlation between the AGC value and the transmitter current or ITVDD when different loads are applied to the antenna. Basically, we will play with the distance between the load and the device to get several points with different AGC values. Based on those measurements, we can plot a graph like the following: Normally we would use a reference PICC and a metal plane or phone to check that the behavior is linear and with no big difference between those loads. Once we have checked the correlation we can proceed with the calibration process, which can be done very easily with the NFC Cockpit software. Here the important thing is to control the ITVDD and keep it always below the chip’s limit. As you can see in the figure below, without the DPC, this symmetrical tuning would lead to a voltage above the limit for positions close to the reader antenna. However, with DPC we can control that voltage at any moment. Another consideration is that we have to make sure that the DPC is calibrated to have maximum power when the reference PICC is far from the reader to avoid a lack of power in the tests at those positions. EMV L1 Analog Tests Debugging process We are going to divide this debugging process into 3 main phases which are the power tests in the first instance, followed by the waveform tests and the reception tests. The reason why we set this order is to first debug the tests that may require HW modifications which have a strong impact on the other tests. This way, for example, if you have passed all power and waveform tests, debugging the reception tests may not have an impact on the results obtained previously. Power tests Tests setup In order to debug the power tests, we will need just an oscilloscope and an EMVCo reference PICC. We will need to connect the outputs J9 and J1 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the reference PICC in non-linear load mode. The J9 of the EMVCo reference PICC is the DC_OUT output that we will use to measure the power received by the antenna. The J1 is the LETI_COIL_OUT output and we will use it to capture the command in the oscilloscope. The overall setup is depicted in the figure below. Performing tests We have to use the trigger to capture the REQA command sent from the DTE when the reference PICC is in the position we want to test. This capture can be seen in the two figures below. The yellow channel is the LETI_COIL_OUT of the EMVCo reference PICC and the blue channel represents the DC_OUT obtained from the J1 connector. As said previously, we will use the DC_OUT to measure the voltage in the period of the signal where there is no modulation, like this part highlighted with the red squared. We have zoomed into the period to get the average value using the oscilloscope measurement features. We will use this same procedure to evaluate the power tests in all positions. Depending on the position tested, the specifications define and certain range where the voltage measured should be fitted. In this sense, the maximum voltage level is common for all planes, but the minimum voltage allowed will decrease for positions further from the terminal.  In order to identify the critical positions for the power tests, we have to identify two different scenarios, the first one with the positions that might not reach the minimum voltage established, and the positions that might exceed the maximum value. For the first scenario the critical positions are the outer positions of the plane z = 4cm and the plane z=3cm as the external positions for plane z= 3cm have a bigger radius. The other scenario is that where you can be exceeding the maximum level. This situation can happen in the central positions of the lower planes, like plane z=1 or z=0. Debugging hints In order to overcome possible issues, we will give some tips that can be used for your design. Regarding a case of lack of power, first, we have to make sure that the DPC is correctly calibrated, meaning that you are operating in gear 0 for the external positions of planes 3 and 4 and that gear 0 is operating with full power. If we have verified those two things and we still have issues, we would need to change the tuning of the antenna and reduce the target impedance. This is graphically represented in the following Smith Chart: By reducing the impedance we increase the current that the PN5180 is driving to the antenna so the voltage would increase. Is important to always verify that we are working within the recommended operating range of the chip and that we are not exceeding the transmitter current limit. In a worst-case scenario, if we cannot achieve the voltage with these HW changes we would need to evaluate changes in the hardware design, like adding a ferrite sheet or changing the antenna dimensions or position. On the other hand, if the problem comes because we are exceeding the maximum voltage allowed by the specifications we can easily solve it by reducing the power configuration of the gear used in that specific position. Waveform tests Test setup For the waveform group of tests, we will use a setup consisting of the EMVCo reference PICC along with an oscilloscope and a PC software to evaluate the signal obtained from the oscilloscope. In our case, we will use the Wave Checker software from CETECOM. We need to connect the output J9 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the EMVCo reference PICC in the fixed load position. The oscilloscope needs to be connected to the PC or laptop, so the software is able to get the waveform and analyze the parameters needed. Type A tests The waveform group of tests for Type A consists of the following test cases: TA121: t1 TA122: Monotonic Decrease TA123: Ringing TA124: t2 TA125: t3 and t4 TA127: Monotonic Increase TA128: Overshoot Some of these test cases are directly related to the parameters defined for the specific modulation phase for Type A at 106 kbps. This modulation phase along with the respective parameters is depicted in the figure below. When the Wave Checker gets the oscilloscope capture, it automatically analyzes the signal, performing all the measurements and comparing them with the specifications limits. Debugging hints for Type A The PN5180 has a few registers and parameters to control the wave shape generated by the NFC chip and transmitted by the antenna. These are the most relevant ones: TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) Rise and Fall times (RF_CONTROL_TX register) TX_OVERSHOOT_CONFIG register From all the different test cases we will show how to debug the t3 and t4 test case as it is usually the most problematic. For this purpose, we will start from a certain configuration where the waveform tests show the following results, with a fail in the t3 and t4 test case. In order to tackle this problem, we will rely on the TAU_MOD_RISING parameter from the RF_CONTROL_TX register of the PN5180. In this case, as the timings are slightly above the maximum allowed in the specifications we will decrease the TAU_MOD_RISING 3 points and execute again the tests. The results after the modification show that all test are passing with a certain margin:   Another parameter that the PN5180 has and can be used for the waveform tests is the TX_CLK_MODE_RM parameter from the RF_CONTROL_TX_CLK register. Below you can see two graphs that clearly illustrate the effect of this parameter over the waveform.  As you can see from the two figures, by changing the default high impedance configuration of 001, to a low side pull configuration the waveform results in a smoother decay of the envelope. Type B tests For Type B waveform, the specifications define the following test cases:  TB121: Modulation Index TB122: Fall time TB123: Rise time TB124: Monotonic Increase TB125: Monotonic Decrease TB126: Overshoots TB127: Undershoots Again, these tests are based on the different parameters that can be identified for the modulation phase of the Type B commands: Debugging hints for Type B The register and parameters that the PN5180 includes to control the waveform for type B are: TX_RESIDUAL_CARRIER (RF_CONTROL_TX register) TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) TX_UNDERSHOOT_CONFIG register TX_OVERSHOOT_CONFIG register For Type B, we will study the modulation index test case, as it is the one that needs to be adjusted more often. In this case, we start from a situation where the device presents problems in the modulation index at 1 cm, with a value below the limit. In order to make corrections of the modulation index we will use the TX_RESIDUAL_CARRIER parameter from the RF_CONTROL_TX register. This parameter controls the amplitude of the residual carrier during the modulated phase. For the present problem, we will increase it by 4 points and rerun the test. As you can see in the picture below, the modulation index is within the specifications limits with margin.  Adaptative Waveform Control The PN5180 has another interesting feature called Adaptative Waveform Control that is used to set a different transmitter configuration depending on the gear and protocol used at any moment. This way we can easily debug by positions and use specific configurations for a certain group of positions without the need of rerunning all the tests for the rest of the positions. With the AWC feature we can control the: TAU_MOD_FALLING TAU_MOD_RISING TX_RESIDUAL CARRIER We can see in the table an example of an AWC configuration for Type B. Where we have changed the Residual Carrier from gear 2 onwards. As you can see, It is also configured with a change in the falling and rising times from Gear 1. As you can see this Adaptative Waveform Control feature along with the DPC represent a powerful tool to easily debug waveform tests without a change in the HW. Reception tests The reception tests purpose is to evaluate the ability of the device to identify and correctly demodulate the responses from the PICC when this response comes in the limits of the specifications for amplitude and polarity of the modulation.  Tests setup The tools and setup needed to debug the reception tests for EMVCo are depicted in the following figure: Oscilloscope to capture the signal received by the reference PICC. Arbitrary Waveform Generator to generate the response of the PICC. PC Software to control the AWG and load the EMVCo responses to the EMVCo reference PICC. For our case, we will use the Wave Player software from CETECOM. EMVCo reference PICC. This time, we will use the output J9 of the reference PICC to the oscilloscope to capture the command from the reader and trigger the injection of the response from the waveform generator to reference PICC, connected to J2. We should connect the waveform generator to the computer that has the Wave Player software installed to load the EMVCo responses. Performing tests As said previously, the reception tests aim at testing the ability of the device to correctly interpret the response when it is generated at the limit of the amplitude and polarity of the modulation. Considering the positive and negative polarity and the maximum and minimum amplitude of the modulation we have the following four test cases that are performed both for Type A and Type B: Tx131: Minimum positive modulation Tx133 - Maximum positive modulation Tx135 - Minimum negative modulation Tx137 - Maximum negative modulation To debug these tests with the PN5180 we will use: RX_GAIN (RF_CONTROL_RX register) RX_HPCF (RF_CONTROL_RX register) MIN_LEVEL (SIGPRO_RM_CONFIG register) MIN_LEVELP (SIGPRO_RM_CONFIG register) The procedure is basically to use the Waveplayer to set the amplitude and polarity of the response and check in the device is the response was correctly received and demodulated. Debugging hints To debug the reception we will test different configuration for the RX_GAIN and RX_HPCF parameters that control the reception filters, amplifier and ADC blocks from the receiver branch. These receiver blocks are pictured in the diagram below. Depending on the values used for the RX_GAIN and RX_HPCF parameters, the filter will be defined accordingly. The following table shows the filter characteristics in relation to those values: If we don’t find a correct value to pass the test at a certain position, we should modify the Rx resistor in order to increase or decrease the receiver sensibility. Adaptative Receiver Control In the same line as the Adaptative Waveform Control, the PN5180 includes the Adaptative Receiver Control that can be used to define different reception configurations depending on the gear and protocol used. With the ARC we can control all the registers involved in the reception and apply a correction to the preconfigured value depending on the gear used.  We can see an example of the Adaptative Receiver Control configuration in the following table, where we have defined a correction of -1 to the MIN_LEVEL and the HPCF parameters from gear 1. We can also see that the RX_GAIN parameter has a correction of +2 from gear 0. The ARC is very useful when we can't find a proper configuration for all positions and we need a different set of values depending on the positions tested. Rx Matrix tool Another interesting tool for debugging the reception tests is the Rx Matrix tool. This tool is used to launch and tests different receiver configuration in an automated way. The Rx Matrix tool is integrated into NXP's NFC Cockpit and you can control the Arbitrary Waveform Generator to set the amplitude of the modulation used for the tests. We can select which parameters we want to change and in which range we want them to be tested and the Rx Matrix will automatically run all the possible combinations in a sweep.   With the Rx Matrix tool, we can select the expected response and the number of iterations we want to try for every possible configuration. That way we can obtain a success ratio for the communication and easily identify the best configuration for the position tested. An example of the Rx Matrix is given in the figure below. We have fixed the RX_GAIN and RX_HPCF parameters and performed a sweep for the MinLevel, testing it from a value of 0 to 8. We have set the Rx Matrix to execute 50 iterations for every configuration, obtaining the success ratio results plotted below. As you can see the Rx Matrix along with a Waveform Generator is a powerful tool to find the optimum receiver configuration in a short time and in an effortless way. PN5180 Ecosystem The PN5180 comes with a complete and useful product support package including: The demokit, that can be used to get introduced to the product and check its features. The NFC Cockpit, that we have talked about during this article, and that represents a powerful tool to control the PN5180 with a very intuitive and useful interface. We srongly recommend that you integrate this tool in your final device as it may save you a lot of time during the debugging phase. A complete documentation including the updated product datasheet, or a set of application notes to guide you through all the designing process, from the antenna design guide to the DPC configuration or use of the Rx Matrix tool. Last but not least, the NFC Reader library which is the recommended software stack for NXP's NFC frontends and NFC controllers with customizable firmware. NFC Reader Library The NFC Reader Library comes with built-in MCU support, but it can also run on different MCU platforms, as well as non-NXP. The library has been built in such a way that you can adapt it and implement the required driver for your host platform. Other characteristics are: It is free of charge and you can download the latest release from NXP’s website. It is a complete API for developing NFC and MIFARE-based applications. Includes an HTML-based API documentation for all the components, which is generated from source-code annotations.  Finally, the release includes several examples and applications. Among the examples and applications included in the NFC Reader Library we can highlight two applications that are very useful for the preparation of the Device Test Environment required for the EMVCo certification:  The SimplifiedAPI_EMVCo for the digital testing The SimplifiedAPI_EMVCo_Analog for the Analog testing. You can control all the parameters involved in both applications using the phNxpNfcRdLib_Config.h configuration file. The identification and modification of these parameters should be very easy as the code is well documented, like you can see in the code chunk in the image: Further information You can find more information about NFC in: Our NFC everywhere portal: https://www.nxp.com/nfc You can ask your question in our technical community: https://community.nxp.com/community/identification-security/nfc You can look for design partners: https://nxp.surl.ms/NFC_AEC And you can check our recorded training: http://www.nxp.com/support/online-academy/nfc-webinars:NFC-WEBINARS Video recorded session

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

  Demo Owner Mike Stanley   Tire Pressure Monitoring Systems (TPMS) help drivers with precise direct tire pressure measurement by providing individual tire readings – including the spare. NXP's world’s smallest, lowest-power, with highest memory for customer use TPMS is highly integrated with a pressure sensor, temperature sensor, accelerometer, MCU and a transmitter. Watch Mike Stanley explain the pressure sensor readings, temperature sensor display and the accelerometer/motion readings. These readings are time based periodic measurements where the data is given as an output to the driver.   Features Simulation that portraits the TPMS as if it were inside the vehicles tires and sending reports to the vehicle's display unit about tire pressure Module has the following: Pressure sensor, accelerometer, temperature sensor, low-frequency radio, Microcontroller   Featured NXP Products FXTH87 product page FXTH87 Fact Sheet Links Tire Pressure Monitoring Sensors Pressure Sensors Block Diagram  

Near Field Communication (NFC) is already present in more than 1.5 Billion smartphones. Well-known applications like payment and access control are enabled by NFC, but also emerging and innovative use cases which are just appearing on the horizon now. This article gives you more information, background and how-to guides around our NFC demos, first exhibited at embedded world 2018 in Nürnberg - to help you put NFC Everywhere. Accessories and consumables Identifying and authenticating accessories and consumables can add significant value to a product, and for the first time we show live how this works: The demo showcases tool identification via NFC for 3 different kinds of tools: A drill bit, a standard flat-blade screwdriver and a Phillips screwdriver. Each of the tools has an embedded NTAG213 NFC tag, and the electric drill contains an NFC reader (CLRC663 plus). As soon as a tool is inserted, the main unit reads the tool type and usage (wear). Based on this information, it can reject non-genuine or worn-out tools, and adjust internal settings like max/min speed based on the tool type. The demo is based on the brand new NFC Nutshell kit by our partner GMMC, and the demo shows how easily an existing product can be retrofitted with NFC using this kit. Find a detailed description of accessory and consumable identification and authentication here: https://community.nxp.com/docs/DOC-340283 Parameterization, Diagnosis and Firmware update This demo shows how you can use an NFC phone to parameterize/configure a DIN rail module (or any other piece of electronics) with an NFC phone - even if the module is completely unpowered. The smart phone app lets you set the behavior of the lamps and also the language of the display. After the configuration (a simple tap) you switch on the main power, and the device comes up as configured. And NFC also lets you read out diagnostic data - no matter whether the device is powered on or off. So you can even replace your service UART by NFC. Thirdly, the demo shows how easy it is to even flash your firmware via NFC. Again, this works even when the device is switched off. This application is based on the NTAG I²C plus passive connected tag IC.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333834. Interested how this looks like in a commercial product? Watch this video showing how easily the Schneider Zelio NFC Timer Relay can be configured via NFC. Access Management In the Access Management corner, we demonstrate the ultimate contactless connectivity for residential or hospitality applications through NXP NFC and BLE solutions and a superior contactless experience and security with MIFARE ® DESFire ® credential on cards, mobile devices and wearables. Our demonstrator is based on the PN7462 family, the all-in-one full NFC controller, the QN9021, a low power BLE system-on-chip, and the PCF8883T, capacitive proximity switch with auto-calibration, for very low power consumption. We also show two commercial products by our partners: 1) The Salto XS4 range of smart doorlocks, a simple to use and very efficient access control system. 2) A modular access control solution by Kronegger, using their tiny NFC reader boards. We also reveal a very small footprint complete reader board based on the new BGA package (VFBGA64; 4.5x4.5 mm²) for the PN7462 family complementing the existing HVQFN64 package.   NFC Tandem - The Best Of Two Worlds If you need NFC functionality both in powered and unpowered state, have a look at the NFC Tandem demo: An NFC reader (PN7150) and a passive connected NFC tag (NTAG I²C plus) 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 read cards, tags or other connected tags. Find design files, a user manual and further downloads here: https://community.nxp.com/docs/DOC-340244 Single-Chip Integrated Solution: LPC8N04 MCU with passive NFC interface In this demo, we show our latest integrated NFC solution, the LPC8N04, a cost-effective MCU with integrated (passive) NFC connectivity. This MCU offers multiple features, including several power-down modes and a selectable CPU frequency of up to 8 MHz for ultra-low power consumption. The demo showcases its features in a conceptual clock format: - Easily set current time/date of the clock via an NFC phone - Real-time clock with optional alarm, programmed and controlled using an Android app - GPIO controlled bar graph indicating programmable "safe operating range" - I2C controlled OLED user display - Data (temperature) logging, configured using an Android App To learn more about this device, please visit: www.nxp.com/LPC8N04 Single-Chip Integrated Solution: NTAG SmartSensor NTAG SmartSensor allows consumers and brand owners to confirm that temperature sensitive products – like fish, wine or pharmaceuticals – have been properly handled. The NTAG SmartSensor allows for temperature sensing at the item level, so each individual product can be confirmed as safe to use. And a single tap with your NFC smartphone is all that's needed to read out the temperature history of the NTAG SmartSensor. Learn more about NTAG SmartSensor on our webpage or watch the video. If you are looking for a ready-made logger using the NTAG SmartSensor, here is a list of manufacturers offering NTAG SmartSensor based loggers. Electronic Shelf Labels With NFC-enabled Electronic Shelf Labels (ESL), wrong price indication, non-transparent processes, and unsatisfactory customer interactions are a thing of the past. In this demo we show labels from 2 manufacturers, one commercial electronic shelf label from SES Imagotag and one ePaper label from MpicoSys. Find more information in the article by Fabrice Punch, Senior Marketing Manager at NXP. Why NFC on ePaper label? NFC allows for creating a product with no batteries, so no recharging, and labels can be in constant use  No cables and connectors - labels can be fully sealed and made waterproof NFC is a well-proven and widely-supported standard  Allows for easy integration with both PC and smartphones    Applications for PicoLabel - MpicoSys ePaper labels Logistic labels (warehousing, supply chain management)  ID Badges (show image on employee, visitor and conference badges)  Authentication badges (identity, authentication, cryptographic security) Door signage (shared offices, conference centers) Manufacturing (replacing paper labels) NFC Cube The NFC Cube is the universal demo for NFC applications: It shows communication between a device and a card/tag, between a device and a phone, and between two devices. It uses the PN7462AU single-chip NFC controller with integrated Cortex M0 core. The NFC Cube kit is interoperable with our NTAG I 2 C plus Explorer board, which enables you to demonstrate how 2 devices can communicate via NFC. NFC Portfolio and Package Options Find here an overview of the package options of our NFC reader and connected tag ICs. Our Partners In The NFC Everywhere Demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Salto: Smart door lock demo GMMC: NFC Nutshell Kit for easy demonstration, retrofitting and development of small NFC reader solutions SES Imagotag: Commercial electronic shelf label with customer interaction via NFC MpicoSys: Commercial PicoLabel based on ePaper and content update via NFC Find out more Discover NFC Everywhere: https://www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/identification-security/nfc List of Approved Engineering Consultants (AEC) for NFC: https://nxp.surl.ms/NFC_AEC NFC Everywhere Brochure: https://www.nxp.com/docs/en/brochure/NFC-EVERYWHERE-BR.pdf 

Overview The NXP® Healthcare Analog Front End reference platform is a complete set of portable medical solutions that enable designers with rapid development tools. Provides ready-to-develop hardware and software that facilitates the design of medical assets such as vital signs monitors, glucose meters and digital stethoscopes, among other portable and healthcare professional devices Based on the Kinetis® K53 high-performance, low-cost, low-power MCU Embeds a complete analog measurement engine including Opamps, TRIAMPS, ADCs, DACs and analog comparators among other modules, reducing costs and PCB sizes Features Developed using the Kinetis ®  K53 MCU, featuring an Arm ®  Cortex ® -M4 core Kinetis K53 MCU also provides low-power operation, DSP capabilities, USB and graphic interface support and a complete analog measurement engine Includes six healthcare-specific analog front ends with reusable software and hardware NXP ®  provides a full set of software tools (CodeWarrior ® , USBSTACK, MQX™ RTOS) NXP product longevity program offers up to 15-year availability for selected products Block Diagram Board Video Design Resources

Demo Owner AngelC This demo shows the ability to control various wireless devices within a home network with a smart phone / Tablet. This is done by having a so-called gateway system consisting in Tower System TWR K60 Kinetis development module connected via Ethernet/Wi-Fi with a wireless router,  plus a Kinetis KW2x MCU device controls a ZigBee-based home automation 1.2 and a TCP/IP network using a single radio (Dual PAN) . In brief, the Android application running in the tablet connects via Wi-Fi to the gateway, which translates every command to both ZigBee HA 1.2 and TCP/IP networks, thus enabling any Wi-Fi enabled device to control several devices even if using different communication protocols. Features ZigBee and TCP/IP connection Android application Featured NXP Products Product Link Kinetis® K60-100 MHz, Mixed-Signal Integration Microcontrollers based on Arm® Cortex®-M4 Core Arm® Cortex®-M4|Kinetis K60 100 MHz 32-bit Microcontrollers|NXP | NXP  Kinetis K60 100 MHz MCU Tower System Module TWR-K60D100M|Tower System Board|Kinetis MCUs | NXP 

本文说明在S32G上如何只用QSPI Nor启动一个最小Linux，最主要的作用是：Linux的紧急/升级/测试模式，或快速启动 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 2 2    S32G QSPI Nor镜像布局说明... 3 2.1  S32G Linux BSP对QSPI Nor启动的支持情况... 3 2.2  S32G  Yocto fsl-image-flash机制分析... 5 2.3  S32G QSPI Nor启动的镜像布局和修改目标... 7 3    镜像修改与编译... 8 3.1  镜像修改... 8 3.2  Yocto编译方法... 10 3.3  Standalong编译方法... 11 4    如何缩小Linux内核镜像... 12 5    如何制造最小Rootfs. 12 5.1  基于现有rootfs直接缩小... 12 5.2  其它方法... 14 6    测试... 14 6.1  烧写办法... 14 6.2  运行log. 16 7    如何在Rootfs加入应用... 17 7.1  Yocto环境中加入方法... 17 7.2  其它方法... 17 7.3  测试结果... 17 8    附件... 17    

本文说明如何检查S32DS Flash Tool的默认波特率，以便确认下载相关的失败问题，以及如何解决。 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 4 2    S32G波特率设置说明... 4 3    检查FlashTool Target image的默认波特率... 6 3.1  运行FlashTool下载Target image. 6 3.2  连接lauterbach检查波特率相关配置... 6 4    G2的检查情况... 8 5    如何解决此问题... 9  

this doc explain how to support high baudrate, such as 3M, 4M in S32G Mcore, even MCAL currently just support 1.8M. and to change uart clock source to avoid the wrongbaudrate value. and after that, still need modify the linux clock tree. 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 3 2    S32G波特率设置说明... 4 3    创建UART工程... 7 3.1  打开工程... 7 3.2  修改波特率... 7 3.3  编译与运行... 7 3.4  默认工程说明... 8 4    配置UART更高波特率... 9 4.1  以PERIPH_PLL_PHI3_CLK 100Mhz为LIN_CLK时钟源    9 4.2  以FIRC_CLK 48Mhz为LIN_CLK时钟源... 14 5    Linux的修改... 15 5.1  以PERIPH_PLL_PHI3_CLK 100Mhz为LIN_CLK时钟源    15 5.2  以FIRC_CLK 48Mhz为LIN_CLK时钟源... 19

this doc explain the S32G PCIe HW design checkpoints and How to debug HW issue with SW. 主要包括：         1：S32G PCIe硬件设计说明。         2：如何根据硬件设计配置软件。         3：如何根据软件现象debug硬件连接问题。         4：一个连接PCIe外设的demo. 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 2 2    PCIe硬件设计说明... 2 2.1  S32G PCIe能力... 2 2.2  S32G PCIe原理图设计... 4 2.3  S32G PCIe设计说明... 8 2.4  S32G PCIe硬件bring up. 9 3    PCIe 软件说明... 9 3.1  软件配置说明... 9 3.2  PCIe uboot初始化流程... 12 3.3  PCIe Linux初始化流程... 19 4    硬件连接错误的软件表现示例... 21 4.1  时钟配置错误... 21 4.2  硬件连接错误... 23 5    RDB3连接PCIe设置Demo. 25 5.1  硬件说明... 25 5.2  Uboot配置... 26 5.3  内核打印... 27 5.4  内核sys文件夹... 36  

Some common issues of HSE-H based on S32G are summarized. Hope it can help you understand the known issues of HSE-H. The issue contents have been listed to facilitate finding the topic you care about. Please refer to the attachment for details. Thank you.

Background:  ➢ IP protection is important for most customers, Kinetis, LPC54 series and i.MX RT have necessary security features that help us to win customers and markets. ➢ LPC55 series is a new generation of IoT MCU which is used for consumer and industrial market. LPC55 non-S parts are adopted by most customers due to its low-cost and easy-to-use features, but its secure features are different with S parts and is significantly simplified. ➢ LPC55 is designed for secured IoT application, so it’s supposed to hide the SWD/ISP ports after development work is finished. If the SWD/ISP ports are secured, they couldn’t be used any more. While for LPC54 & Kinetis MCU, mass erase command can be used to recover the MCU after the MCU is secured. ➢ However, Customers need the feature to secure the debugging/ISP ports, but they also need to recover them in some cases: - Reprogramming to update firmware - Investigate and analyze failed parts returned from end market - Rescue the MCU if it’s locked and stuck ➢ According to customers’ requirements, NXP support team raised the proposal to implement a solution which can be used to secure and recover the SWD/ISP ports with an IAP backdoor method. Solution: By Operating PFR region, LPC55 could switch between secure and recovery mode.   lpc5506_debug_isp_test_20220714: demonstrate how to operate this region to lock Debug Port then how to recovery it. The user interaction could be raised by UART or button;         2.hmac_test_20220714: demonstrate one full security flow,      ➢ This is a complete solution to secure & recovery debugging/ISP ports on LPC55, and it uses host machine challenge mechanism to implement security features: ▪ Challenge Host machine against unknown host probe; ▪ Generates dynamic seeds, so that the final encrypt information will be dynamically changed; ▪ The image hash value is device related, that avoids same encrypt info for different image/product; ➢ Customer also could clip the solution to simplify application complexity: ▪ Use UUID for device information only, no seed is needed; ▪ Host machine can use fixed keys instead of image hash values to do info encryption; ▪ Host machine can use UUID lookup table to find out verification key; Every device is programmed with dedicated verification key during production.  Demonstration: The attached demos could run at LPC55S06 EVK, and could easily migrate to other LPC55 series.

FAST BOOT FOR lx2160 IN adas •Objective To speed ​​​​up bringup of LX2 chip-based systems •Pain Points to Address The bringup time is much longer than 3s, which is very sensitive in ADAS systems or time-sensitive systems. •Value Proposition / Key Features The guide can help customers shorten uboot time from 5s to less than 1.5s, saving more than 70% bootup time. •Deliverables Demo based on LX2160ARDB board. Reference codes and patches. Guide for Fast boot document. Fast boot 广泛用于嵌入式设备，现以lx2160ardb板为例进行相关探索。 启动流程： 优化思路： 1.适当提高FSPI时钟速率 diff --git a/lx2160asi/flexspi_divisor_32.rcw b/lx2160asi/flexspi_divisor_32.rcw index 422139c..0f8d5c9 100644 --- a/lx2160asi/flexspi_divisor_32.rcw +++ b/lx2160asi/flexspi_divisor_32.rcw @@ -7,8 +7,10 @@ * Modify FlexSPICR1 register, to increase FlexSPI clock closer to 50MHz, * with divisor value as 32. * => 750 * 2 / 32 ==> 46.875MHz + *write 0x1e00900,0x00000013 + * 0f -12 =125M */ .pbi -write 0x1e00900,0x00000013 +write 0x1e00900,0x0f .end ​ 2.关键路径优化 固化spd参数 固化ddrc参数 BL33 裁剪 详细patch和测试结果参考附件。

         随着近年来人们对日常出行品质的提高，电动自行车（包括共享类）市场得到了飞速发展，其功能日趋复杂智能。作为电控部分的“三大件”，电驱，主控和仪表也在不断升级迭代，其中电驱发展经历了最早期的直流有刷电机驱动到直流无刷方波驱动再到如今的 FOC 正弦波驱动，主控从以前附属在电驱或者仪表里的边缘化概念到如今独立出来的中心化，仪表则从普通的段式 LED 显示到如今尺寸越来越大功能越来越丰富的彩屏显示，而相对应的负责沟通互联“三大件”的通信总线也从传统的单总线到 TTL UART 到 RS485 再到如今逐渐展露头脚的 CAN 总线。对于电动自行车这种大众型消费市场来说，这些电控部分的升级换代给MCU 带来新的机遇的同时也对其性能，外设资源和价格带来了极大挑战。基于此， 针对三大件之一的仪表市场，NXP 开发了一套基于高性价比 LPC5506 系列 MCU 的 E-Bike 迈速表中低端显示屏方案。 系统框图： 主要特性： 4.5v~85v宽范围电压输入，支持24v，36v和48v锂电池组电源直接接入； 主控LPC5506支持CAN通信，8080 16bit/8bit LCD接口，且封装为LQFP 10*10mm，利于仪表小型化； 支持3.5寸320*480 16bit及以下尺寸的TFT LCD显示屏，预留I2C接口的电阻屏触摸控制芯片； 支持开源免费的ZLG AWTK GUI和LittleVgl GUI框架； 板载光敏传感器，可用于根据环境光自动调节LCD背光亮度； 板载六轴Motion Sensor（MPU6050），可用于转把方向检测，防盗检测和自行车摔倒检测等； 板载GPS和BLE模块，可用于定位，精确授时校准，行车轨迹离线存储或者与手机蓝牙通信； 板载4MB SPI Flash，用于图片和字体资源，GPS坐标轨迹存储和其他重要信息存储； 预留了USB Type-C电源供电端口和调试串口，方便工程师调试。 软件环境：        当前版本的软件代码工程有三份，一份为基于ZLG AWTK GUI的完整E-Bike迈速表工程，可显示车速仪表盘，里程，档位和电池电压等行车参数，也可以进入简单的功能设置界面浏览当前系统信息，且支持通过指定的CAN帧格式更新当前GUI界面的参数信息。一份为基于NXP GUIGuider图形化工具设计开发的LVGL版本E-Bike迈速表工程，分为3个子界面显示车速和骑行状态等详细信息。第三份为移植到本参考设计上的LVGL官方Demo例程，里面包含了配置好的EZH驱动库和LittleVgl基本的设备输入输出框架，用户可以基于此例程灵活开发定制自己的LVGL based其他GUI应用。        目前基于ZLG AWTK和LVGL GUI的E-Bike迈速表显示屏方案在经过优化之后对主控MCU的资源的占用以及GUI整体刷新性能如下表1，由于两个工程所使用的GUI素材和布局不一样，所以不要对两者的资源占用和性能参数做对比。他们都可以满足大部分客户的应用需求（>15fps）。如果将显示屏的分辨率降低到320*240及以下小尺寸的情况下，整个系统的资源占用会相应的减小，刷新性能也会得到更大的提升。 表1 方案资源占用及GUI刷新性能（分辨率320*480 16bit） Demo Code Flash RAM Refresh Rate AWTK GUI Version 202KB 61KB 22fps LVGL GUI Version 206KB 78KB 17fps 写在最后：        本参考设计的初衷是针对E-Bike中低端仪表显示屏市场提供一个高性价比的选择，同时也可以作为一个对于显示，CAN通信和小封装有类似需求的平台性的参考方案推广，比如电摩，带显示屏的便携式医疗设备和工业IoT设备等，希望此方案能给市场带来更好的用户体验和高性价比的选择。 注：由于代码工程超过25M，不能上传到该Community，如有需要请联系NXP销售或FAE索取。

本文说明在S32G2 RDB2板上实现LLCE to PFE Demo的搭建过程。本Demo目前包括：  CANtoEth：CAN0发送，用硬件回环到 CAN1接收，然后通过PFE_EMAC1， 再通过RGMII接口发出。  CANtoEth：CAN0发送，用硬件回环到 CAN1接收，然后通过PFE_EMAC1， 再通过SGMII接口发出。  EthtoCAN：PC通过PFE_EMAC1的 RGMII发出，接收到CAN1，再硬件 回环到CAN0  CANtoCAN Logging to Eth: CAN0发 送，用硬件回环到CAN1接收，然后 通过PFE_EMAC1，再通过SGMII接 口发出,同时LLCE内部硬件把CAN1 再发送到CAN15_TX，再用硬件回环 到CAN14_RX 软件版本为 RTD3.0.0+LLCE1.0.3+PFE0.9.6/0.9.5。

This doc explain how to install S32G design studio& RTD SDK. contributed by Tony.Zhang

This doc explain how to optimize the Linux boot time, Contents as follows: 目录 1 默认BSP28 Linux内核的启动时间分析和优化方向 ..... 2 2 UBoot的优化 .............................................................. 3 2.1 缩小Uboot的DTS尺寸 ............................................ 3 2.2 缩小Uboot的尺寸 .................................................... 4 2.3 去掉等待3S输入时间 .............................................. 4 2.4 配合内核修改的Uboot参数 ..................................... 4 2.5 关闭串口调试信息 .................................................. 5 2.6 MMC read的方法来读取内核和DTB ....................... 5 3 Kernal的优化 ............................................................. 5 3.1 DTB中去掉不用的驱动和代码 ................................. 5 3.2 内核中去掉不用的平台与驱动及相关代码 ............... 6 3.3 内核中去掉不用功能，缩小内核大小 ...................... 7 3.4 去掉initramfs支持 ................................................... 7 3.5 关闭调试信息 .......................................................... 7 3.6 提前eMMC驱动加载时间 ........................................ 7 3.7 将Kernel与DTB打包在一起..................................... 8 4 Rootfs+应用程序的优化 ............................................. 8 5 最终全部启动时间比较 ............................................. 12

This doc expain how to use eMMC from user space, contents as follows: 目录 1 eMMC的分区情况 ...................................................... 2 2 S32G+BSP29上默认的eMMC启动 ............................ 3 2.1 eMMC硬件设计 .................................................. 3 2.2 eMMC的镜像烧写办法与启动 ............................. 6 2.3 增加MMC内核测试工具 .................................... 10 3 eMMC GP功能的测试 .............................................. 10 3.1 eMMC GP功能的说明 ....................................... 10 3.2 eMMC GP功能的测试 ....................................... 11 4 eMMC RPMB功能的测试 ......................................... 13 4.1 eMMC RPMB功能的说明 ................................. 13 4.2 eMMC RPMB功能的测试 ................................. 15