NXP Designs ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

NXP Designs Knowledge Base

ディスカッション

ソート順:
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 
記事全体を表示
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.
記事全体を表示
IEEE 1588协议简单理解        IEEE 1588 是一个精密时间协议 (PTP),用于同步计算机网络中的时钟。 在局域网中,它能将时钟精确度控制在亚微秒范围内,使其适于测量和控制系统。 IEEE 1588 标准为时钟分配定义了一个主从式架构,由一个或多个网段及一个或多个时钟组成。 ​       TSN 网络中时间同步协议使用 IEEE 802.1AS 协议,它基于 IEEE 1588 协议进行精简和修改,也称为 gPTP 协议。 ​       IEEE 1588 协议简称精确时钟协议 PTP(Precision Timing Protocol),它的全称是“网络测量和控制系统的精密时钟同步协议标准”(IEEE 1588 Precision Clock Synchronization Protocol)。其工作的基本原理,是通过主从节点之间进行同步数据帧的发送,记录数据帧的发送时间和接收时间信息进行,并且将该时间信息添加到该数据帧中。从节点获取这些时间信息,并计算从节点本地时钟与主时钟的时间偏差和网络节点之间的传输延时,对本地时钟进行纠正,使之与主节点时钟同步。一个 PTP 网络只能存在一个主时钟。 ​ PTP 协议主要分为两大部分来实现时钟同步功能: ​ 1、建立同步体系: ​       协议使用最佳主时钟算法(Best Master Clock Algorithm,BMCA),通过选取主时钟,建立主从拓扑关系,进而在整个 PTP 网络中建立起同步体系。 ​ 2、同步本地时钟: ​       协议使用本地时钟同步算法(Local Clock Synchronization Algorithm,LCS),通过 PTP 数据报文在网络主从节点之间的交换,计算各从节点本地时钟与主时钟间的时间偏差,调整本地时钟,使之与主时钟同步。 IEEE 1588v1 ​       整个 PTP 网络内的时钟可按照其上 PTP 通信端口的数目来划分成普通时钟(Ordinary Clock,OC)与边界时钟(Boundary Clock,BC):普通时钟只存在一个,而边界时钟则存在多个。一般在确定性不高的网络节点处使用边界时钟,例如交换机或者路由器一般用作边界时钟,如下图所示。在每个端口上,PTP 通信都是独立进行的。 1、边界时钟: ​      边界时钟上只允许存在一个从端口,与上级节点的主端口通信,将其本地时钟与级主端口进行同步。其余端口为主端口,与下游节点的从端口进行通信。边界时钟可以连接不同的网络协议。 ​ 2、同步体系建立流程: ​   (1)初始状态,各个节点端口会在指定的时间内侦听网络中的 Sync 数据帧; 若接收到 Sync 数据帧,节点端口将根据最佳主时钟算法决定端口状态。若没有收到 Sync 数据帧,该节点状态变更为 Pre_Master,并将自己假定为主时钟节点。此时节点端口状态表现为主时钟,但是并不发送 Sync 帧。 ​   (2)端口状态在一定时间内保持 Pre_Master: 若在端口指定时间内接收到 Sync 数据帧,则该端口状态由最佳主时钟算法决定。 若判定端口为主时钟,则将周期性地发送 Sync 帧;若判定为从时钟,则接受 Sync 帧,并计算偏差,纠正本地时钟。 ​ 若在该时间段内端口没有收到 Sync 数据帧,则将状态变更为主时钟,并且开始定时发送 Sync 数据帧。 ​   (3)主时钟和从时钟的状态随着时钟性能与运行状态的变化而变化。下图展示了 BMCA 中状态转移。 3、时间同步建立流程: ​ 如下图PTP同步原理         如图所示,Master为网路中的同步时钟源,可以认为其与UTC或者GPS时无限接近。Slave为网络中需要被同步设备。假设从Master到Slave的路径符合对称路径,那么路径上的延时我们设Delay,然后设备Master和设备Slave之间待同步的时间差值为Offset,即Slave比Master在同一时刻慢Offset。         Slave设备根据算出的Offset即可以进行本地时钟校准。但是1588V1协议依赖于链路的对称性,即Master到Slave与Slave到Master时延一致,这在实际网络状况下很难满足,故需要额外的不对称算法进行链路延时差计算和补偿校准。   IEEE 1588v2 ​IEEE1588V2在IEEE1588V1版本上做了改进和扩展。主要包括: ​ 1.新增点到点路径延时测量的独立消息模式。 端口 A 与端口 B 间的路径延迟时间 Delay 为: ​        在 PTPv1 中,平均路径延迟测量时通过 Sync 帧与 Delay_Req 帧配合使用的,但是在 PTPv2 中却不需要 Sync 帧的参与,仅通过 PDelay_Req 数据帧系列来进行测量。这是一个独立的延迟测量过程,不依赖 Sync 帧和同步体系建立的参与,使得测量精度有所提高,并且可以经过多次测量求得平均值得到更为准确的路径延迟。另一方面,如果网络中的同步体系发生改变,这时不需要重新计算该节点间的路径延迟,直接使用之前已测得的延迟数据,大大增强了协议执行的效率,使得协议更为方便灵活。在PTPv2 中,利用 PDelay_req 数据帧系列已成为主要的测量路径延迟方法。 ​ 2、新增透明时钟模型 ​        在 PTPv1 中,网络中间节点均采用边界时钟模型。与网络中唯一的主时钟,即一个普通时钟连接的边界时钟,其上唯一的从端口接收主节点发送的同步数据帧,与主时钟实现同步,其余的主端口和与之相连的其他边界时钟发送同步数据帧,最后同步到网络边缘的普通时钟,这样便实现了整个网络的时间同步。这种方法虽然可行,但是由于这种方式是逐级同步,所以距离主时钟越远的节点,同步精度越低。 ​        当网络中的一些节点不需要进行时钟同步或者不具备同步功能时,便可采用透明时钟模型。透明时钟不像 BC/OC 模式那样,需要每个节点都与主时钟进行同步,它的端口只对协议数据帧进行转发,并将计算出的数据帧滞留时间添加在校正域中。这种方式将 PTP 数据帧的处理变得更为简单,降低了网络中 PTP 协议的实施难度,同时提高了各从节点的同步精度。 ​ 透明时钟有模型两种:端对端透明时钟,和点对点透明时钟。 ​     (1)端对端(E2E)透明时钟 ​ E2E 透明时钟对网络中普通数据帧不做任何处理,仅进行转达让其正常通过。但是对于 PTP 事件数据帧,则将他们从接收端口到发送端口间的驻留延迟时间累加到数据帧中的修正域,用以弥补 PTP 数据帧在经过其自身所带来的延迟误差。 ​     (2)点对点(P2P)透明时钟 ​ 点对点(P2P)透明时钟只转发特定的 PTP 报文,包括 Sync 帧、Follo_Up 帧和Announce 帧等。并且会采用 Pdelay_Req 数据帧系列计算每个端口与所连接的端口间的路径延迟时间,再与端口间延迟时间合并添加到时间修正域,来补偿数据帧从源端口到点对点透明时钟出端口的时间延迟。 ​ 3、增加单步时钟模型 ​        单步时钟模型解决了 Follow_Up 帧与 Sync 帧匹配问题。PTP 协议基本的同步过程采用双步模式,即主时钟节点发送 Sync 帧,和带有 Sync 帧发送时间的Follow_Up帧。这种方式虽然能提高 Sync 帧时间戳标记的精度,提高同步效果,但是在网络负载较大的情况下,数据帧很有可能发生丢失或者阻塞,造成两种数据帧的匹配出现差错。 ​        在 PTP 数据帧中设置一个标志,来使用单步模式,将 Sync 帧的发送时间与数据帧中的时间标签的差值作为传输延迟,并将其累加到修正域中。这样主时钟便通过单独的 Sync 帧而不需要 Follow_Up 进行时间的同步校准工作。 ​        单步模式可以减少网络流量,提高网络负载较大时同步的可靠性。单步模式需要额外的辅助硬件,来帮助计算时间修正值并将其累加到校正域中,这对网络的实时性有比较高的要求。 BMCA ​        BMCA,即最佳主时钟算法,它选择网络中性能最佳的时钟作为主时钟,并以 此建立网络拓扑,生成同步体系,进而实现时钟同步功能。 ​        最佳主时钟的选取是通过Announce帧在网络中各节点的传输,比较各个节点上的时钟属性(比如是否将时钟指定为主或者从时钟),用于标识精度的时钟等级,以及用于标识时钟源类型的时钟类型(比如铷钟、铯钟等),还有表示时钟偏移、方差等的时钟特性、时钟地址以及时钟端口号等特征来选择最佳主时钟,当其他时钟特征都一样是,协议会将端口号最小的节点时钟作为主时钟。IEEE 1588协议会以主时钟节点作为根节点形成树形拓扑结构,并且为避免生成回路,那些竞争失败的节点端口,协议将他们定义为被动或者禁用状态。
記事全体を表示
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
記事全体を表示
This doc explain how to use S32G design studio and SDK, contributed by Gary.Yuan yuan.yuan@nxp.com.
記事全体を表示
第一章 简介 MCU 闪存加载器是一个可配置的闪存烧写实用程序,可通过 MCU 上的串行通讯进行操作。 它可以在整个产品生命周期(包括应用程序开发和最终产品制造等)中对 MCU 进行快速轻 松编程。 MCU 闪存加载器将以高度可配置的二进制或完整源代码形式提供。主机端命令行 和 GUI 工具可用于与闪存加载器进行通信。用户可以利用主机工具通过闪存加载器上传和/ 或下载应用程序代码。 第二章 闪存加载器协议 本节介绍主机和 MCU 闪存加载器之间数据包传输的通用协议。介绍包括不同事务的数据包 传输,例如无数据阶段的命令以及带传入或传出数据阶段的命令。 第三章 闪存加载器数据包类型 MCU 闪存加载器设备以从机模式工作。所有数据通信均由主机发起,该主机可以是 PC 主 机,也可以是嵌入式主机。 MCU 闪存加载器设备是接收命令或数据包的目标机。主机和目 标机之间的所有数据通信均采用分包形式。 第四章 MCU闪存加载器API 所有 MCU 闪存加载器命令 API 均遵循由成帧数据包打包的命令数据包格式,如前几小节所 述。 第五章 支持的外设 本小节介绍 MCU 闪存加载器支持的外设。 第六章 外部存储器的支持 本小节介绍 MCU 闪存加载器支持的外部存储器设备。要正确使用外部存储器设备,必须使 用相应的配置文件启用该设备。闪存加载器无法访问未启用的外部存储设备。 MCU 闪存加 载器使用存储器标识符启用特定的外部存储设备,如下所示。 第七章 安全实用程序 MCU 闪存加载器支持某些安全实用程序,用于轻松生成与安全性相关的块。请注意,必须 首先对闪存加载器本身进行签名才能正确启用安全实用程序。
記事全体を表示
KW36 - 32kHz RTC外部振荡器的微调调节 USL:https://community.nxp.com/docs/DOC-342672     引言 FRDM-KW36包含带有32 kHz晶体振荡器的RTC模块。RTC模块以极低功耗模式运行并为MCU提供32 kHz时钟源。该振荡器包括一组可编程调节的负载电容C LOAD ,改变这些负载电容的值可以调整振荡器提供的频率。 此可配置电容的范围为0 pF(禁用电容器组)至30 pF,步长为2 pF。 这些值是通过组合启用的电容器获得的。可用值为2 pF,4 pF,8 pF和16 pF。这四个数值可以任意组合。如果外部电容可用,建议禁用这些内部电容器(将RTC控制寄存器SFR中的SC2P,SC4P,SCS8和SC16位设置为0)。 要调整振荡器提供的频率,必须首先能够测量该频率。最好使用频率计数器测了频率,因为它提供了比示波器更精确的测量。另外还需要KW36通过IO输出振荡器频率。要输出振荡器频率,以任意一个低功耗蓝牙演示应用程序为例,执行以下操作: 调整频率示例 本示例将利用低功耗蓝牙演示应用程序的心率传感器演示(freertos版本),并假定开发人员具有从SDK到IDE导入或打开项目的知识。 从SDK中打开或克隆“心率传感器”项目。       在工作区的board文件夹中找到board.c和board.h文件。 如下图所示在board.h文件中声明一个void函数。该函数将是为了把RTC时钟多路复用到PTB3,以使其能够输出32kHz频率用于测量。 /* Function to mux PTB3 to RTC_CLKOUT */void BOARD_EnableRtcClkOut (void); 如下所示在board.c文件中添加BOARD_EnableRtcClkOut函数。    void BOARD_EnableRtcClkOut(void){/* Enable PORTB clock gating */CLOCK_EnableClock(kCLOCK_PortB);/* Mux the RTC_CLKOUT to PTB3 */PORT_SetPinMux(PORTB, 3u, kPORT_MuxAlt7);/* Select the 32kHz reference for RTC_CLKOUT signal */ SIM->SOPT1 |= SIM_SOPT1_OSC32KOUT(1); } 在hardware_init函数中(board.c文件),在调用BOARD_BootClockRUN函数之后立即调用BOARD_EnableRtcClkOut函数。       在工作区的board文件夹中找到clock_config.c文件。 在文件顶部添加以下定义。 #define RTC_OSC_CAP_LOAD_0 0x0U /*!< RTC oscillator, capacitance 0pF */#define RTC_OSC_CAP_LOAD_2 0x2000U /*!< RTC oscillator, capacitance 2pF */#define RTC_OSC_CAP_LOAD_4 0x1000U /*!< RTC oscillator, capacitance 4pF */#define RTC_OSC_CAP_LOAD_6 0x3000U /*!< RTC oscillator, capacitance 6pF */#define RTC_OSC_CAP_LOAD_8 0x800U /*!< RTC oscillator, capacitance 8pF */#define RTC_OSC_CAP_LOAD_10 0x2800U /*!< RTC oscillator, capacitance 10pF */#define RTC_OSC_CAP_LOAD_12 0x1800U /*!< RTC oscillator, capacitance 12pF */#define RTC_OSC_CAP_LOAD_14 0x3800U /*!< RTC oscillator, capacitance 14pF */#define RTC_OSC_CAP_LOAD_16 0x400U /*!< RTC oscillator, capacitance 16pF */#define RTC_OSC_CAP_LOAD_18 0x2400U /*!< RTC oscillator, capacitance 18pF */#define RTC_OSC_CAP_LOAD_20 0x1400U /*!< RTC oscillator, capacitance 20pF */#define RTC_OSC_CAP_LOAD_22 0x3400U /*!< RTC oscillator, capacitance 22pF */#define RTC_OSC_CAP_LOAD_24 0xC00U /*!< RTC oscillator, capacitance 24pF */#define RTC_OSC_CAP_LOAD_26 0x2C00U /*!< RTC oscillator, capacitance 26pF */#define RTC_OSC_CAP_LOAD_28 0x1C00U /*!< RTC oscillator, capacitance 28pF */#define RTC_OSC_CAP_LOAD_30 0x3C00U /*!< RTC oscillator, capacitance 30pF */ 在BOARD_BootClockRUN函数内(也在clock_config.c文件中)找到对函数CLOCK_CONFIG_EnableRtcOsc的调用,然后通过上述任意定义来设置函数入参。 最后,在项目源文件夹中的“app_preinclude.h”文件中禁用低功耗选项和LED Support: #define cPWR_UsePowerDownMode 0#define gLEDSupported_d 0     此时,可以用频率计数器测量PTB3输出的频率,并进行频率调整。每次对电路板进行编程时,都需要执行POR以获得正确的测量值。下表是从FRDM-KW36板rev B获得的,可用作调整频率的参考。 请注意,电容不仅由启用的内部电容组成,还包括封装、焊线、焊垫和 PCB 走线中的寄生电容。因此,尽管下面给出的参考测量值应接近实际值,但您还应该在电路板上进行测量,以确保频率是专门针对您的电路板和布局进行调整的。 启用的电容器 CLOAD 电容定义 频率 - 0pF RTC_OSC_CAP_LOAD_0 (bank disabled) 32772.980Hz SC2P 2pF RTC_OSC_CAP_LOAD_2 32771.330Hz SC4P 4pF RTC_OSC_CAP_LOAD_4 32770.050Hz SC2P, SC4P 6pF RTC_OSC_CAP_LOAD_6 32769.122Hz SC8P 8pF RTC_OSC_CAP_LOAD_8 32768.289Hz SC2P, SC8P 10pF RTC_OSC_CAP_LOAD_10 32767.701Hz SC4P, SC8P 12pF RTC_OSC_CAP_LOAD_12 32767.182Hz SC2P, SC4P, SC8P 14pF RTC_OSC_CAP_LOAD_14 32766.766Hz SC16P 16pF RTC_OSC_CAP_LOAD_16 32766.338Hz SC2P, SC16P 18pF RTC_OSC_CAP_LOAD_18 32766.038Hz SC4P, SC16P 20pF RTC_OSC_CAP_LOAD_20 32765.762Hz SC2P, SC4P, SC16P 22pF RTC_OSC_CAP_LOAD_22 32765.532Hz SC8P, SC16P 24pF RTC_OSC_CAP_LOAD_24 32765.297Hz SC2P, SC8P, SC16P 26pF RTC_OSC_CAP_LOAD_26 32765.117Hz SC4P, SC8P, SC16P 28pF RTC_OSC_CAP_LOAD_28 32764.940Hz SC2P, SC4P, SC8P, SC16P 30pF RTC_OSC_CAP_LOAD_30 32764.764Hz  
記事全体を表示