NXP Designs Knowledge Base

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

NXP Designs Knowledge Base

Discussions

Sort by:
  Overview Due to the flexibility and low operating cost of vending machine, it’s popular with consumers and merchants. The vending machine industry has great potential and wide market space with the introduction of mobile technology, will become a new channel for fast consumer retail. This solution with a i.MX 8M Mini apply a advanced process technology mode, that delivers much lower leakage than standard technology. Some of the features of this application are: Easy touch keypad and display for transaction status. Diversified payment methods: coin, bill and mobile payments. Compatible with Apple pay, Alipay, wechat pay and more. Block Diagram Products Category MPU Product URL i.MX 8M Mini - Arm® Cortex®-A53, Cortex-M4, Audio, Voice, Video  Product Description The i.MX 8M Mini is NXP’s first embedded multicore applications processor built using advanced 14LPC FinFET process technology, providing more speed and improved power efficiency.   Category Wi-Fi Product URL 88W8987: 2.4/5 GHz Dual-Band 1x1 Wi-Fi® 5 (802.11ac) + Bluetooth® 5 Solution  Product Description The 88W8987 is a highly integrated WLAN (2.4/5 GHz) and Bluetooth single-chip solution, specifically designed to support the speed, reliability, and quality requirements of next generation Very High Throughput (VHT) products.   Category RTC Product URL PCF85063A: Tiny Real-Time Clock/calendar with alarm function and I2C-bus  Product Description The PCF85063ATL is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption. An offset register allows fine-tuning of the clock.   Category Temperature Sensor Product URL PCF85063A: Tiny Real-Time Clock/calendar with alarm function and I2C-bus  Product Description The PCF85063ATL is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption.   Category Power Management Product URL PCA9450: Power Manage IC (PMIC) for i.MX 8M Mini/Nano/Plus  Product Description The PCA9450 is a single chip Power Management IC (PMIC) specifically designed to support i.MX 8M family processor in both 1 cell Li-Ion and Li-polymer battery portable application and 5 V adapter nonportable applications.   Category Motor Driver Product URL MC34931: MC34931/S H-Bridge, Brushed DC Motor Driver, 5-36 V, 5 A, 11 kHz/20 kHz  Product Description The NXP® MC34931 is a monolithic, thermally efficient 36 V/ 5 A H-Bridge DC motor driver.
View full article
Demo This demo shows an infotainment and ADAS system based on NXP Ethernet components and is divided in three main parts: Infotainment, Network and ADAS. In the infotainment part, a “Head Unit” ECU plays locally an MPEG movie and also streams it over Ethernet to the second “Rear Seat Unit” ECU. Both ECUs also execute in the backroad the NXP AVB SW stack. This enables the two ECUs to be perfectly synchronized with each other. Therefore the two ECUs can playback the very same video (and audio) frame at the same time on their local displays. In the network part the new Automotive Ethernet Switch (SJA1105EL) and PHYs (TJA1100HN) implement the Ethernet connectivity of the system. The switch executes the AVB “gPTP” synchronization SW that enables the infotainment application described above to operate. In the ADAS part a surround view camera captures a video stream and streams it to a “Cluster” ECU also connected via the automotive Ethernet network. The camera is based on the NXP “MPC5604E ” Salsa processor and on a competitor’s BroadR-Reach PHY. This also shows the interoperability of the TJA1100HN PHY with competitor’s products. Features: All displays are implemented with NXP i.MX6 processor, and a full implementation of the NXP Ethernet AVB Stack running on Linux. The camera is based on an NXP Salsa processor (MPC5304EKIT) . The Switch board that connects all displays and the camera uses the NXP SJA1105EL Automotive Ethernet switch and the TJA1100HN BroadR-Reach Ethernet PHY ______________________________________________________________________________________________________________ Featured NXP Products: Product Link IEEE 100BASE-T1 compliant Automotive Ethernet PHY Transceiver TJA1100HN | Automotive Ethernet PHY Transceiver | NXP  i.MX 6 Series i.MX 6 Series Applications Processors | Multicore Arm Cortex-A7/A9/M4 | NXP  Audio Video Bridging Software https://www.nxp.com/design/design-services/audio-video-bridging-software:AVB-SOFTWARE?&fsrch=1&sr=4&pageNum=1 Development Kit Enabling Video Over Ethernet with NXP® MPC5604E MCU NXP® MPC5604EKIT:Development Kit | NXP  ___________________________________________________________________________________________________________
View full article
  Overview   Libraries strive to provide great service and to ensure easy access to media products. With thousands of visitors choosing from copious books, CDs, videos, and computer games, storing and controlling inventory poses huge challenges. To reduce the waiting time for visitors and to relieve staff, most libraries that use RFID rely on RFID-powered self-service media checkout stations. This approach reduces labor, ensures that books are returned to shelves quickly, shortens wait times and encourages more people to visit the library. Taking inventory with the aid of RFID takes only a fraction of the time required with traditional systems. With RFID labels easily applied to all types of media, library staff can use handheld RFID readers to quickly, conveniently and reliably locate misplaced books or other items. New systems such as Smart Shelves enable real-time location of all media within the library. Features   Faster check-out and 24/7 self return service Fast and automated sorting of returned books Improved inventory management Identification of misplaced books Reliable theft protection with Electronic Article Surveillance (EAS) Unique serialized identification No line-of-sight requirement Easily applicable to all media types Reliable, fast and convenient identification   Video     Recommended Products   Category Name ICODE ICODE SLIX SL2S2002; SL2S2102 | NXP  Standard: ISO 18000-3M1 User Memory (bit): 896 EAS protection: 32-bit password AFI protection: 32-bit password Longest read range of any standards-based passive HF RFID technology ICODE SLIX2 NFC Forum Type 5 Tag with originality signature SL2S2602 | NXP  Standard: ISO 18000-3M1 User Memory (bit): 2528 EAS protection: 32-bit password AFI protection: 32-bit password Longest read range of any standards-based passive HF RFID technology Persistent quiet and Originality signature enabled   Related Information   For publishers and retailers: How NFC will merge physical with online book sales ICODE Family data protection for Libraries
View full article
  Overview Industrial control is a key element in any factory automation process. It may vary from a simple panel-mounted controller to large interconnected and interactive distributed control systems. This small form factor board target applications that require low power, low costs, and high performance. This solution is based on aLS1028A Industrial Application Processor. This processor includes two powerful 64-bit Arm®v8 cores that can support real-time processing for industrial control, as well as virtual machines for edge computing in the IoT.  NXP is your ideal partner for factory automation. From embedded hardware to software solutions, our industrial expertise and innovative spirit enable you to meet the highest expectations of industry 4.0 and industrial IoT markets. Use Cases Our portfolio enables the next generation of smart factories from edge to cloud. We enable industrial applications at all layers of factory automation. Our technology implements secure connections from manufacturing level up to the cloud. Some applications are: Manufacturing Logistics Operations Management Edge-Cloud Block Diagram Product Category MPU Product URL Layerscape® 1028A Industrial Applications Processor  Product Description The Layerscape LS1028A industrial applications processor includes a TSN-enabled Ethernet switch and Ethernet controllers to support converged IT and OT networks.   Category RTC Product URL PCF85063A: Tiny Real-Time Clock/calendar with alarm function and I2C-bus  Product Description The PCF85063ATL is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption. An offset register allows fine-tuning of the clock.   Category Power Management Product URL MC34VR500: Multi-Output DC/DC Regulator  Product Description The NXP® MC34VR500 power management solution for network processor systems is a high-efficiency, quad buck regulator with up to 4.5 A output and five user-programmable LDOs.   Category Transceiver Product URL TJA1101: 2nd generation Ethernet PHY Transceivers - IEEE 100BASE-T1 compliant  Product Description TJA1101 is a high-performance single port, IEEE 100BASE-T1 compliant Ethernet PHY Transceiver.   Category Display Port Product URL PTN3460/PTN3460I - Commercial and Industrial e(DP) to LVDS bridge IC  Product Description PTN3460 is an (embedded) DisplayPort to LVDS bridge device that enables connectivity between an (embedded) DisplayPort (eDP) source and LVDS display panel.  
View full article
Overview This full digital power AC to DC Switched-Mode Power Supply (SMPS) system includes both digital power control and digital power management. The control feedback or feed-forward loop that regulates the output of the power system is directly controlled by a 56800/E DSC The DSC provides the digital power management function for configuration, tracking, monitoring, protection, guiding supply sequence, and communication capabilities This reference design is a fully digitally controlled high-frequency Switched-Mode Power Supply based on an NXP® 56F8323 device The primary side is the AC-DC converter with power factor correction (PFC) and on the secondary side is a full bridge DC-DC converter Features General: 500-Watt fully digital switched-mode power supply controlled by A 56F8323 with power factor correction A 56F8323 for secondary with phase shifting technique General Benefits: Power applications become more flexible and universal High input power factor lowers power pollution to the power grid Intelligent mode management and fault supervision Operating status is monitored and controlled in real time Lower system and maintenance cost Performance: Input voltage: 85 ~ 265VAC Input frequency: 45 ~ 65HZ Rating output voltage:48VDC Rating output power: 500W Switch frequency: > 100K Power factor > 95% Efficiency > 90% Communications: RS232 port for communication with optoisolation Visual Interface: Multi-segment LED indicators (input voltage, input current, output voltage, and output current) Block Diagram Board Design Resources
View full article
Overview The NXP® Solar Panel Inverter reference design demonstrates the ability of the 16-bit digital signal controller MC56F8023 to control whole inverter functionality. The inverter converts the input voltage from the solar panel to isolated one-phase AC output voltage The application comprises all needed circuitry for power transfer, control and measurement The main power board provides standard 64-pin PCI Express® connector as the interface for the daughter card control board, providing the ability to control this inverter by other digital signal controllers Features DC input voltage from the solar panel in the nominal level of 36V Possible to use one 36V or two 18V solar panels in series connection Maximum power point tracking feature in the control software implemented Battery charger for the 3 x 12V lead-acid accumulators in series included Galvanic isolated output voltage 230V 50Hz up to 400W output power True sine shape output voltage RS-485 isolated interface for the external communication Internal low-power DC power supply maintains proper functionality without battery connection Overvoltage, overcurrent and overtemperature protection implemented Embedded software example for off-grid available Block Diagram Design Resources
View full article
Description Earlier this year NXP organized a promotional opportunity for amateur radio enthusiasts to use their creativity and build their own power amplifier designs. NXP received numerous creative submissions in this competitive Homebrew RF Design Challenge. We appreciate the dedication and enthusiasm from the community that made this contest a success. First place winner An MRF101AN broadband amplifier design with 1 W Input, 100 W Output 1.8-54 MHZ Amplifier deck. (For more information visit:NXP MRF-101 - RFPowerTools )  It is an amplifier with a bandwidth of 1.8MHz to 54MHz. Maximum output power of 100W up to 30MHz and 70W up to 50MHz. Maximum power supply 50V to 4A, with a Voltage Standing Wave Ratio of 1.5:1 maximum. The design dimensions of the PCB is 5x5 cm (2x2 in). and 310g weight including fan and heat sink. Second place winner A 600W broadband HF amplifier using affordable LDMOS devices (For more information visit: https://qrpblog.com/2019/10/a-600w-broadband-hf-amplifier-using-affordable-ldmos-devices/  ) This project is meant to demonstrate the capabilities of the MRF300 transistors as linear broadband devices in the 2-50MHz range and to be used by radio amateurs as a starting point for a medium-high power amplifier. This is also my entry to the NXP Homebrew RF Design Challenge 2019. To achieve the target of 600W output while also minimizing the level of even-number harmonics, a “push-pull” configuration of two transistors is used. Luckily, the manufacturer made it easy to design the PCB layout for such a thing by offering two versions (the MRF300AN & MRF300BN) that have mirrored pinout. The common TO-247 package is used, with the source connected to the tab. Each individual MRF300 LDMOS transistor is specified at 330W output over a 1.8-250MHz working frequency range, a maximum 28dB of gain and over 70% efficiency. The recommended supply range is 30-50Vdc. By studying the specifications, it looks like with correct broadband matching and some operational safety margin we can get close to 600W output at a voltage of around 45V across a resonably large bandwidth; the aim is to cover 1.8 to 54MHz. Main challenges when designing this amplifier are related to achieving good input and output matching over the entire frequency range as well as maintaining high and flat gain. Good linearity and a low level of harmonic products are mandatory. As the TO-247 is not a package specifically designed for high-power RF, there are some challenges with thermal design and PCB layout as well. Information taken from the essay by the winner. Third place winner A High Efficiency Switchmode RF Amplifier using a MRF101AN LDMOS Device for a CubeSat Plasma Thruster (For more information visit: Research - SuperLab@Stanford ) The Class E amplifier utilizes the active device as a switch, operating in only cutoff (off) and saturated (on) conditions. This minimizes the overlap of voltage and current, reducing losses in the active device. To further reduce loss the Class E amplifier utilizes an inductively tuned resonant network to achieve zero voltage switching, bringing the voltage across the switch to zero before turn on, eliminating energy stored in the output capacitance of the active device that would otherwise be dissipated. This is achieved with an inductively tuned series resonant output filter.  In the Class E amplifier losses are almost entirely determined by the current conducted by the active device so a high drain impedance is desired to maximize efficiency. The drain impedance is ultimately limited by the voltage rating of the switch. For our desired output power of 40W and the maximum voltage rating of 133V for the MRF101AN this impedance is still less than 50 ohms, so a L match circuit is used to match the drain impedance to 50 ohms. The load network in our design provides a drain impedance of 15.4+12.8j. As the MRF101AN will operate in saturation a high drive level is desired. To eliminate the need for a preamplifier and allow for digital control, we use a high speed gate drive chip typically used in switch-mode power supplies, LMG1020, to drive the MRF101AN instead of a RF preamplifier. A resonant network is used to provide voltage gain at the fundamental and third harmonic, providing a quasi-square wave on the gate which helps insure the device remains in saturation. Conclusion It was a close call and highly competitive! Each participant had their own creative, unique and impressive way of displaying the capabilities of these new parts. NXP is always up for new design challenges. Ready for the next challenge?
View full article
Overview   In the power supply and distribution system, TTU (Transformer Terminal Unit) is used to collect and control the information of the distribution transformer. It can monitor the operation condition of the distribution transformer in real time and transmit the collected information to the main station or other intelligent devices to provide the data needed for the operation control and management of the distribution system. NXP provides many solutions on electricity conversion, including AC to AC, AC to DC and DC to DC converters NXP has a broad portfolio of software and processors for Smart Grid market. Regarding software, NXP has original LSDK Linux with Docker supporting and Edgescale solution for edge computing; Regarding processors, NXP has scalable solution from 1xA53 to 16xA72.   Block Diagram Products Category MPU Product URL Layerscape® 1043A and 1023A Multicore Processors  Product Description The LS1043A processor was NXP's first quad-core, 64-bit Arm®-based processor for embedded networking.   Category Bluetooth Product URL QN9090/30(T): Bluetooth Low Energy MCU with Arm®Cortex®-M4 CPU, Energy efficiency, analog and digital peripherals and NFC Tag option  Product Description The QN9090 and QN9030 are the latest microcontrollers in the QN series of Bluetooth low energy devices that achieve ultra-low-power consumption and integrate an Arm®Cortex®-M4 CPU with a comprehensive mix of analog and digital peripherals.   Category Power Management Product URL MC34VR500: Multi-Output DC/DC Regulator  Product Description The NXP® MC34VR500 power management solution for network processor systems is a high-efficiency, quad buck regulator with up to 4.5 A output and five user-programmable LDOs.   Category Peripherals Product URL 1 PCF85063B: Tiny Real-Time Clock/calendar with alarm function and SPI‑bus  Product Description 1 The PCF85063BTL is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption. Product URL 2 SA56004X: SMBus-Compatible, 8-Pin, Remote/Local Digital Temperature Sensor  Product Description 2 The NXP Semiconductors SA56004X is an SMBus compatible, 11-bit remote/local digital temperature sensor with over-temperature alarms. Product URL 3 NTS0101: Dual supply translating transceiver; open drain; auto direction sensing  Product Description 3 The NTS0101 is a 1-bit, dual supply translating transceiver with auto direction sensing, that enables bidirectional voltage level translation.
View full article
Overview   NXP is a one-stop partner for the different technologies needed to power major home appliances. They need a robust, reliable and attractive user interface, a powerful motor control optimized for efficiency and low noise as well as secure and accurate environment sensing. NXP portfolio counts with multiple processing solutions ranging from MCUs to multicore MPUs enabling motor control, system control and advanced HMI. This solution is based on a Kinetis Ke1xF-168 MHz MCU. This 5 V solution with the high-performance Cortex-M4 core running up to 168 MHz, integrates CAN 2.0B compliant FlexCAN and provides a highly reliable serial communication interface for industry applications. Block Diagram Products Category MCU Product URL KE1xF: Kinetis KE1xF-168MHz, Performance with CAN 5V Microcontrollers based on Arm® Cortex®-M4  Product Description Kinetis KE1xF MCUs are the high end series MCUs in Kinetis E family, providing robust 5V solution with the high performance Arm® Cortex®-M4 core running at up to 168 MHz.   Category Power Management Product URL 1 TEA19363LT: GreenChip SMPS Primary Side Control IC with QR/DCM Operation and Active x-Capacitor Discharge  Product Description 1 The TEA19363LT is a member of the GreenChip family of controller ICs for switched mode power supplies. Product URL 2 MC33813: One Cylinder Small Engine Control IC  Product Description 2 The NXP® MC33813 is an engine control analog power IC delivering a cost-optimized solution for managing one and one-cylinder engine.   Category Driver Product URL PCA9959: 24-Channel SPI Serial Bus 63 mA/5.5 V Constant Current LED Driver  Product Description The PCA9959 is a daisy-chain SPI-compatible 4-wire serial bus controlled by a 24-channel constant preset current LED driver optimized for dimming and blinking 63 mA Red/green/blue/amber (RGBA) LEDs.   Category Sensor Product URL PCT2075: I2C-Bus Fm+, 1 Degree C Accuracy, Digital Temperature Sensor And Thermal Watchdog  Product Description The PCT2075 is a temperature-to-digital converter featuring ±1 °C accuracy over ‑25 °C to +100 °C range.
View full article
Overview   NXP smart amplifier is a high efficiency boosted Class-D audio amplifier with a sophisticated SpeakerBoost acoustic enhancement and Protection algorithm in on-Chip DSP with temperature and excursion protection. The internal adaptive DC-to-DC converter raises the power supply voltage, providing ample headroom for major improvements in sound quality. NXP portfolio counts with multicore solutions for multimedia and display applications with high-performance and low-power capabilities that are scalable, safe, and secure. This solution is based on an i.MX 8M Family MCU. This application processor provides industry-leading audio, voice and video processing. Block Diagram Products Category MPU Product URL i.MX 8M Family - Arm® Cortex®-A53, Cortex-M4, Audio, Voice, Video  Product Description The i.MX 8M family of applications processors based on Arm® Cortex®-A53 and Cortex-M4 cores provide industry-leading audio, voice and video processing for applications.   Category Wireless Product URL 1 QN9090/30(T): Bluetooth Low Energy MCU with Arm®Cortex®-M4 CPU, Energy efficiency, analog and digital peripherals and NFC Tag option  Product Description 1 The QN9090 and QN9030 are the latest microcontrollers in the QN series of Bluetooth low energy devices that achieve ultra-low-power consumption and integrate an Arm®Cortex®-M4 CPU with a comprehensive mix of analog and digital peripherals. Product URL 2 88W8987: 2.4/5 GHz Dual-Band 1x1 Wi-Fi® 5 (802.11ac) + Bluetooth® 5 Solution  Product Description 2 The 88W8987 is a highly integrated Wi-Fi (2.4/5 GHz) and Bluetooth single-chip solution specifically designed to support the speed, reliability and quality requirements of Very High Throughput (VHT) products. Product URL 3 NTAG I2C plus: NFC Forum Type 2 Tag with I2C interface  Product Description 3 The NTAG I2C plus combines a passive NFC interface with a contact I2C interface.   Category Power Management Product URL 1 TEA1833LTS: GreenChip SMPS Control IC  Product Description 1 The TEA1833LTS is a low-cost Switched Mode Power Supply (SMPS) controller IC intended for flyback topologies. Product URL 2 PCA9450: Power Manage IC (PMIC) for i.MX 8M Mini/Nano/Plus  Product Description 2 The PCA9450 is a single chip Power Management IC (PMIC) specifically designed to support i.MX 8M family processor in both 1 cell Li-Ion and Li-polymer battery portable application and 5 V adapter nonportable applications.   Category RF Amplifier Product URL BGS8324: WLAN LNA + switch  Product Description The BGS8324 is, also known as the WLAN3001H, a fully integrated Low-Noise Amplifier (LNA) and SP3T switch for Bluetooth path and transmit path.   Category Peripherals Product URL 1 PCT2075: I2C-Bus Fm+, 1 Degree C Accuracy, Digital Temperature Sensor And Thermal Watchdog  Product Description 1 The PCT2075 is a temperature-to-digital converter featuring ±1 °C accuracy over ‑25 °C to +100 °C range. Product URL 2 PCA9955BTW: 16-channel Fm+ I²C-bus 57 mA/20 V constant current LED driver  Product Description 2 The PCA9955B is an I2C-bus controlled 16-channel constant current LED driver optimized for dimming and blinking 57 mA Red/Green/Blue/Amber (RGBA) LEDs in amusement products.
View full article
Overview   NXP Home Appliances is dedicated to provide intelligent, reliable and appealing solutions to make everyday life a bit easier. Bringing solutions that listen, learn and adapt into the places we call home for more comfort, safety and convenience. Home appliances are part of our daily lives and have been evolving with us. NXP´s i.MX families, offer reliable and robust motor control with HMI capabilities. Our wireless MCUs add HAN, WiFi and NFC and along our security devices ensure high-quality wireless connectivity. We have a wide range of precise sensors and complete solutions to simply add voice control to any home appliance.   Use Cases Refrigerators Dishwasher Washing machines RF Cooking Dryers Voice-controlled appliances Thermostat   Block Diagram Major Home Appliance Small & Medium Appliance   Products   Category MCU/MPU Product URL 1 i.MX 8M Mini - Arm® Cortex®-A53, Cortex-M4, Audio, Voice, Video  Product Description 1 The i.MX 8M Mini is NXP’s first embedded multicore applications processor built using advanced 14LPC FinFET process technology, providing more speed and improved power efficiency. Product URL 2 i.MX 8M Nano - Arm® Cortex®-A53, Cortex-M7  Product Description 2 NXP's i.MX 8M Nano applications processor provides cost-effective integration and affordable performance for smart, connected, power-efficient devices requiring graphics, vision, voice control, intelligent sensing and general-purpose processing. Product URL 3 i.MX RT1060 Crossover MCU with Arm® Cortex®-M7 core  Product Description 3 The i.MX RT1060 is the latest addition to the industry's first crossover MCU series and expands the i.MX RT series to three scalable families. Product URL 4 i.MX RT1050 Crossover MCU with Arm® Cortex®-M7 core  Product Description 4 The i.MX RT1050 is the industry's first crossover MCU and combines the high-performance and high level of integration on an applications processors with the ease of use and real-time functionality of a microcontroller.   Category Wireless Product URL 1 NTAG® 5 link: NFC Forum-compliant I2C bridge for IoT on demand  Product Description 1 NXP’s NTAG 5 link lets designers of sensor-equipped systems add an NFC interface with a wired host interface that’s configurable as an I2C master/slave, a Pulse Width Modulator (PWM), or a General-Purpose I/O (GPIO). Product URL 2 88W8977: 2.4/5 GHz Dual-Band 1x1 Wi-Fi® 4 (802.11n) + Bluetooth® 5 Solution  Product Description 2 The 88W8977 System-on-Chip (SoC) is a highly integrated single-chip solution that incorporates both Wi-Fi (2.4/5 GHz) and Bluetooth technology. Product URL 3 88W8887: 1x1 Dual-band Wi-Fi®5 (802.11ac) and Bluetooth®4.2 Combo Solution  Product Description 3 The 88W8887 is a highly integrated connectivity solution enabling 1x1 802.11 ac Wi-Fi 5 and Bluetooth 5.0 in a single-chip.   Category Power Management Product URL 1 TEA19363LT: GreenChip SMPS Primary Side Control IC with QR/DCM Operation and Active x-Capacitor Discharge  Product Description 1 The TEA19363LT is a member of the GreenChip family of controller ICs for switched mode power supplies. Product URL 2 PCA9450: Power Manage IC (PMIC) for i.MX 8M Mini/Nano/Plus  Product Description 2 The PCA9450 is a single chip Power Management IC (PMIC) specifically designed to support i.MX 8M family processor in both 1 cell Li-Ion and Li-polymer battery portable application and 5 V adapter nonportable applications.   Category Peripherals Product URL 1 PCAL6408A: Low-voltage translating, 8-bit I²C-bus/SMBus I/O expander  Product Description 1 The PCAL6408A is an 8-bit general purpose I/O expander that provides remote I/O expansion for many microcontroller families via the I²C-bus interface. Product URL 2 PCA9955BTW: 16-channel Fm+ I²C-bus 57 mA/20 V constant current LED driver  Product Description 2 The PCA9955B is an I2C-bus controlled 16-channel constant current LED driver optimized for dimming and blinking 57 mA Red/Green/Blue/Amber (RGBA) LEDs in amusement products. Product URL 3 PCT2075: I2C-Bus Fm+, 1 Degree C Accuracy, Digital Temperature Sensor And Thermal Watchdog  Product Description 3 The PCT2075 is a temperature-to-digital converter featuring ±1 °C accuracy over ‑25 °C to +100 °C range.
View full article
  Overview The growth in automotive emerging markets has increased the need for simple and lower cost instrument cluster solutions. NXP® offers several cost-effective solutions based on its complete range of instrument cluster processors, from the 8-bit S08 family to industry-leading 16-bit S12 architecture, integrating required interface features that include the optimal set of on-chip features, package and memory options. To further help your instrument cluster designs, NXP offers an extensive suite of hardware and software development tools. i.MX8X have similar CPU performance with i.MX6 but 2 times GPU performance. NXP provide function safety ASIL-B cluster solution with hardware/software support. i.MX8X has embedded VPU which can support video stream decoding from IVI to cluster. And also full solution for AVB/TSN in car network.   Block Diagram Products Category MCU/MPU Product URL 1 i.MX 8X Family – Arm® Cortex®-A35, 3D Graphics, 4K Video, DSP, Error Correcting Code on DDR  Product Description 1 Extending the scalable range of the i.MX 8 series, the i.MX 8X family is comprised of common subsystems and architecture from the higher-end i.MX 8 family, establishing a range of cost-performance scaling with pin-compatible options and a high level of software reuse. Product URL 2 S32K144EVB: S32K144 Evaluation Board  Product Description 2 The S32K144EVB is a low-cost evaluation and development board for general purpose automotive applications.   Category Power Management Product URL  PF8100-PF8200: 12-channel Power Management Integrated Circuit (PMIC) for High-Performance Processing Applications  Product Description The PF8100/PF8200 PMIC family is designed for high-performance processing applications such as infotainment, telematics, clusters, vehicle networking, ADAS, vision and sensor fusion.   Category Transceiver Product URL 1 TJA1042: High-speed CAN transceiver with standby mode  Product Description 1 The TJA1042 high-speed CAN transceiver provides an interface between a Controller Area Network (CAN) protocol controller and the physical two-wire CAN bus. Product URL 2 TJA1101: 2nd generation Ethernet PHY Transceivers - IEEE 100BASE-T1 compliant  Product Description 2 TJA1101 is a high-performance single port, IEEE 100BASE-T1 compliant Ethernet PHY Transceiver.   Category Peripherals Product URL1 PCA9538: 8-bit I²C-bus and SMBus low power I/O port with interrupt and reset  Product Description 1 The PCA9538 is a 16-pin CMOS device that provides 8 bits of General Purpose parallel Input/Output (GPIO) expansion with interrupt and reset for I2C-bus/SMBus applications and was developed to enhance the NXP Semiconductors family of II2CC-bus I/O expanders. Product URL 2 PCA9955BTW: 16-channel Fm+ I²C-bus 57 mA/20 V constant current LED driver  Product Description 2 The PCA9955B is an I2C-bus controlled 16-channel constant current LED driver optimized for dimming and blinking 57 mA Red/Green/Blue/Amber (RGBA) LEDs in amusement products. Product URL 3 PCT2075: I2C-Bus Fm+, 1 Degree C Accuracy, Digital Temperature Sensor And Thermal Watchdog  Product Description 3 The PCT2075 is a temperature-to-digital converter featuring ±1 °C accuracy over ‑25 °C to +100 °C range. Product URL 4 PCA85073A: Automotive tiny Real-Time Clock/Calendar with alarm function and I2C-bus  Product Description 4 The PCA85073A is a CMOS1 Real-Time Clock (RTC) and calendar optimized for low power consumption.
View full article
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. 
View full article
本文说明在S32G上如何修改eMMC时钟,来避开200Mhz的或及倍频的频率EMI干扰检查点。 目录 1    背景说明和需要的资料... 2 1.1  背景说明... 2 1.2  需要的资料... 2 2    eMMC的硬件连接... 3 3    eMMC时钟初始化方法... 4 3.1  eMMC时钟源说明及修改目标... 4 3.2  M7+Bootloader方法(可选项) 6 3.3  ATF初始化方法... 7 4    修改eMMC时钟... 9 4.1  ATF的修改... 9 4.2  Uboot相关的修改... 9 4.3  非整除时钟的修改考虑... 10 5    测试结果... 11 update to V2,增加分数分频: 6    分数分频... 13 6.1  调试方法... 13 6.2  代码修改... 14 6.3   测试结果   15
View full article
Near Field Communication (NFC) is hot. It is available in hundreds of millions of smartphones, tablets, and other consumer electronics, and enters more and more the industrial space as well. This article shows how to implement the demos of our "Industrial NFC Demonstrator", first exhibited at embedded world 2017 in Nürnberg.           Parameterization & Diagnosis 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. See here a video from embedded world 2017 showing this demo.   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.   Device-to-device communication In this demo you see how NFC can establish a communication between 2 devices with up to 40 kbit/s. The angular position of the rotating disk is measured, communicated to the main board via NFC and displayed on an LED ring. The nice thing: The rotating disk is without battery. Energy harvesting via NFC provides supply power up to 15mW. This principle of using NFC as a cable replacement is especially interesting in cases where you want to communicate with fully sealed, isolated, moving or rotating units. The communication is bi-directional, and the data can be static (a button press, or configuration data) or dynamic (sensor measurements). The demo is based on the CLRC663 plus reader on the main unit and the NTAG I²C plus passive connected tag on the rotating disk. See here the video from embedded world 2017 demonstrating this application.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333917       Access control In the Physical Access Control demo, we show a simple implementation of a basic access control solution using a Type 4 tag and a CLRC663 plus based reader, based on the public NFC Reader Library. NXP recommends for a complete real-life access control solution to use MIFARE DESFire credentials as with the MIFARE DESFire EV2 card. Supporting software library is under NDA. In this video from embedded world 2017 you see access control in action.   Download the source code here: http://nxp.com/assets/downloads/data/en/software/RC663Demo_ReadNdefT4T_v1.2.zip           1-tap Bluetooth Pairing This demo shows how easy it is to pair wireless devices to your phone with NFC - using an example of the Kinetis KW41 Freedom board (BLE MCU), with an NTAG I²C plus kit for Arduino® pinout for the NFC function. This new NTAG I²C plus kit is suitable for any board featuring an Arduino-compatible header, including LPCXpresso, Kinetis and i.MX boards. It is the ideal tool to evaluate and design-in an NTAG I²C plus tag chip in an embedded electronic system. Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-335241     Automation with Hexiwear A nice example of how to build versatile applications, is shown in the automation demo with the Hexiwear IOT development platform. Based on Kinetis MCUs and hundreds of available click-boards (plug-ins with sensors, actuators, transceivers - and of course also NFC), you can quickly build a prototype of your application. Two NFC-based click-boards are available: 1) A reader board based on PN7120 2) A board with NTAG I²C plus The automation demo uses 3 different Hexiwear base boards, connected between them via Zigbee. The NFC unit identifies a technician's badge, and also the tools he uses for his job. The second unit drives the instrument panel, and the third one the big LED screen. A video from embedded world 2017 shows how this works.   Find more information on Hexiwear at www.hexiwear.com.   Our partners in the NFC industrial demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID and Arti Grafiche Julia: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Neosid: Small NFC/RFID transponders for tool identification and authentication   Find out more Discover NFC Everywhere: www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/nfc
View full article
LPC54114 Audio and Voice Recognition Kit The LPC54114 Audio and Voice Recognition Kit provides a complete hardware and software platform for developers to evaluate and prototype with the LPC54114 processor family. It has been developed by NXP® to provide all that you need to develop an always-on low power voice triggering product. Features: LPCXpresso54114 (OM13089) development board with: LPC54114 dual-core (M4F and dual M0) MCU running at up to 100 MHz in LQFP64 package. Hi-speed USB based debug probe with CMSIS-DAP and SEGGER J-Link OB protocol options. Connectivity for external debug probes. Micro USB connector for LPC54114 USB device operation. Tri-color LED. Target Reset, ISP and interrupt/user buttons. On-board 1.8 V / 3.3 V or external power supply options. 8 Mb Macronix MX25R SPI flash. FTDI UART connector and built-in UART to USB bridge options. Built-in MCU power consumption and supply voltage measurement for LPC54114 device. UART, I²C and SPI port bridging from LPC54114 target to USB via Link2 device. FTDI UART connector. Digital Mic/Audio codec/OLED display (“MAO”) shield with: Knowles SPH0641LM4H digital microphone. Cirrus Logic (Wolfson) WM8904 audio codec with stereo line in/out sockets. Monochrome OLED display (160 x160 pixels). Demos: Include USB/I2S audio demo, as well as voice recognition demos leveraging partner technology (Malaspina and Sensory) http://cache.nxp.com/documents/application_note/AN11855.zip Videos: These videos showcase the NXP’s LPC54114 MCU in a kit designed for customers to evaluate its capabilities for audio and voice processing _______________________________________________________________________________________________________ Featured NXP Products: Product Link LPC54000 Series LPC54000|Power Efficient 32-bit Microcontrollers (MCUs)|Cortex®-M4 Core | NXP  LPC54114 Audio and Voice Recognition Kit https://www.nxp.com/design/microcontrollers-developer-resources/lpcxpresso-boards/lpc54114-audio-and-voice-recognition-kit:OM13090?&fsrch=1&sr=1&pageNum=1 _______________________________________________________________________________________________________
View full article
Demo Owner: Mark Houston   Kinetis V series is a family of devices targeting motor and power control applications for the mass market with a strong focus on enablement. See two elements of that story: a product benchmark showing relative product performance and the Kinetis motor suite -- a tool that speeds your development time to market.       Features Motor speed capabilities Comparison to standard controllers Smooth transitions Featured NXP Products Kinetis V Kinetis V1 Kinetis V3 Kinetis V4 Development Tools Kinetis Motor Suite Design Resources Kinetis Motor Suite Fact Sheet
View full article
Demo         This was a super fun project to work on and is popular around the office and on the road.  Now I have two of these for a truly amazing barrage of Nerf darts!  It's also always a lot of fun to tear things down and the Nerf gun had some cool plastic work and the shooting mechanism is more simple than what I originally guess.  But I digress, this post is about how you can build one of these yourself.  Please leave any questions or comments in the section below and I will try to answer and make refinements to this guide as we go.   The shopping list (aka Bill of Materials or BOM)   If you shop around you might be able to find better prices or substitute parts.   Type Part Qty Price URL UBEC HKU5 1 $             5.33 http://www.hobbyking.com/hobbyking/store/__16663__HobbyKing_HKU5_5V_5A_UBEC.html LiPo TURNIGY 2200mAh 3S 20C 1 $             7.89 http://www.hobbyking.com/hobbyking/store/__8932__Turnigy_2200mAh_3S_20C_Lipo_Pack.html Servo S5030DX 1 $           28.63 http://www.hobbyking.com/hobbyking/store/__18862__Hobbyking_S5030DX_Digital_MG_Servo_X_Large_HV_164g_0_20s_30kg.html Servo HK15138 1 $             3.12 http://www.hobbyking.com/hobbyking/store/__16269__HK15138_Standard_Analog_Servo_38g_4_3kg_0_17s.html Relay PCB COM-11041 1 $             3.95 https://www.sparkfun.com/products/11041 Relay Components Various 1 $             3.00 https://www.sparkfun.com/wish_lists/36307 Nerf Gun Nerf Dart Tag Swarmfire Blaster 1 $           44.99 http://www.toysrus.com/product/index.jsp?productId=11267568 Controller FRDM-K64F 1 $           29.00 FRDM-K64F | mbed Servo Arm Double Servo Arm X-Long 1 $             3.20 http://www.hobbyking.com/hobbyking/store/__19468__CNC_Alloy_Double_Servo_Arm_X_Long_Futaba_.html Servo Arm Heavy Duty Alloy Arm 1 $             5.63 http://www.hobbyking.com/hobbyking/store/__18350__Heavy_Duty_Alloy_1in_Servo_Arm_Futaba_Red_.html Servo Linkage Alloy Pushrod with Ball-Link 65mm 1 $             2.10 http://www.hobbyking.com/hobbyking/store/__25834__Alloy_Pushrod_with_Ball_Link_65mm.html Lazy Susan Shepherd 6 in. Lazy-Susan Turntable 1 $             4.49 http://www.homedepot.com/p/Shepherd-6-in-Lazy-Susan-Turntable-9548/100180572#.UYk5UqLql8E Metal Rod 3/8 in. x 36 in. Zinc Threaded Rod 1 $             2.87 http://www.homedepot.com/p/3-8-in-x-36-in-Zinc-Threaded-Rod-17340/202183465#.UYk5pqLql8E Frame 1/2 MDF 2ftx4ft 1 $           10.45 http://www.homedepot.com/p/1-2-in-x-2-ft-x-4-ft-Medium-Density-Fiberboard-Handy-Panel-1508108/202089097?N=btn1#.UYk6CqLql8E   The build   Two main pieces to construct in this phase.  The base turret and the actual hacking of the Nerf gun.   All your base.. The base of the turret is pretty rudimentary, lot's of room for improvement here.  I used 1/2 MDF and some carpentry skills.  Here is some instruction on how to build a MDF box.  Atop the box is a lazy Susan (ball bearing ring) so that the top-plate can rotate smoothly.  We considered leaving this element out, but worried that it would put to much strain on the servo.   On the subject of servos, a few tidbits of wisdom for you as you build this thing.  First, the left/right servo needs to be dead center of the lazy susan, if your off too much things will start to bind which is not good for your servo.  Second, I used large higher torque servos which cost a bit more, they might be overkill, but it certainly performs well.   I did a quick dimensionally accurate rendering of the design in Sketchup. Files are here.   Hacking the Nerf   Now for the fun stuff.   There is no shortage of screws with this Nerf Gun.  So get out your Phillips screwdriver and go to town. There are two electrical systems in the Nerf that we are going to tap into.  One is the power switch and the other is the electrical trigger. This is the electrical trigger.  The trigger goes to our relay, which is either on or off.  We did try at first to use a 7.2V R/C car battery, but the Nerf draws too much power and didn't fire.  Going up to a 11.1V LiPo fixed that right up. This is the power switch. In Nerfinator 1.0 everything was hardwired together, which prevented us from completely pulling the Nerf from the base and made repairs difficult to say the least.  Nerfinator 2.0 we put this handy connector which allowed us to completely and easily remove the Nerf from the base.  Shipping this thing around the country will take a toll on it!  On that subject, Nerf 1.0, stopped cycling to the next position for us at the Austin Mini Maker Faire.  After a through inspection of the operational mechanics inside the Nerf (really cool BTW) it was a little bitty spring that was causing the piston not to fully retract.  We replaced the spring with 1/2 a ballpoint pin spring and to our surprise it all worked again. Electrical Connection Diagram   Added High-Level Block Diagram.  Need to add pinouts.  You'll have to read the code for now to figure it out.     Code   Mbed was the programming tool of choice for this build.   Receive Side (RX) - The receiver is the base side.  This one takes input from the remote and controls the servo movement. NerfGun_nRF24L01P_RX - a mercurial repository | mbed Transmit Side (TX) - The transmitter is the remote side.  This one senses the users movement (accelerometer) and sends that data to the base station. NerfGun_nRF24L01P_TX - a mercurial repository | mbed   Finishing Touches   In the first passes of this build we just used a bare development board as the remote control.  We found that when given the remote they would not orientate it properly, so 3D Printed Controller STL files   Development Team John McLellan - Amplification/Motivation Clark Jarvis - Software/Hardware Iain Galloway and Angus Galloway - Design and print of controller FRDM_case_sunday_PART_REV_001.STL.zip
View full article
UPDATE: I recommend trying the steps outlined in this NXP Community post first.     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.
View full article
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
View full article