MCUXpresso配置工具知识库

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

MCUXpresso Config Tools Knowledge Base

标签

讨论

排序依据:
Creating expansion board definition file for Arduino Multifunction shield  An expansion board definition file for the Arduino Multifunction shield can be applied in Pins Tool to expansion headers available on the NXP board. This tutorial describes the steps of creating an XML expansion board file using the shield documentation and the expansion headers feature in the Pins tool. For details on the expansion headers feature, see the following article: Adding Expansion Headers to a custom board You can apply the Arduino Multifunction shield on several NXP boards. This tutorial uses the FRDM K64F EVK board.   Prerequisites: Use a  shield description/specification, for example, https://www.biomaker.org/multifunction-shields. You can use HAILANGNIAO Multi-Function shield V2. Use the XSD schema file https://mcuxpresso.nxp.com/XSD/expansion_board_1.0.xsd for the definition file validation. Use the definition of signal types - mapping of signals from the expansion board to the processor. You can find it in the Config Tools data directory: c:\ProgramData\NXP\mcu_data_{config_tools_version}\expansion_headers\signal_types\common_signal_types.xml. Use the definition of expansion header where the board can be applied: c:\ProgramData\NXP\mcu_data_{config_tools_version}\expansion_headers\frdm_arduino.xml. Get familiarized with devices that are on the shield or can be connected to the shield. Install MCUXpresso IDE v11.3.0 or later and SDK FRDM-K64F 2.8.2 or later. Create a Project for FRDM-K64F. Open Expansion Header view (Windows -> Show View -> Expansion Header). Figure 1 FRDM K64F EVK board Figure 2 Expansion Header view in the Pins tool Expansion board template  Edit the following template according to the steps below. <?xml version="1.0" encoding= "UTF-8" ?> <expansion_board id="board_id" name="board_name" xsi:schemaLocation="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0 http://mcuxpresso.nxp.com/XSD/expansion_board_1.0.xsd" xmlns="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header_connection ref="expansion_header_def_id"> <connectors> <connector ref="C1"> <pins> <pin ref="1" name="pin name" signal_type="digital_in" description="pin description"/> </pins> </connector> </connectors> </header_connection> <code_identifiers prefix="ARDUINO_"/> </expansion_board> Expansion board id and name  Edit the id and name of the expansion board. <?xml version="1.0" encoding= "UTF-8" ?> <expansion_board id="arduino_multifunction_ds18b20_board" name="Arduino Multi DS18B20 board" xsi:schemaLocation="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0 http://mcuxpresso.nxp.com/XSD/expansion_board_1.0.xsd" xmlns="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Expansion board - header connection The element header_connection determines the id of an expansion header where the board can be applied to. Get the type of expansion header in the FRDM-K64F board. Figure 3 Edit expansion header dialog Edit the header_connection in the expansion board XML. <?xml version="1.0" encoding= "UTF-8" ?> <expansion_board id="arduino_multifunction_ds18b20_board" name="Arduino Multi DS18B20 board" xsi:schemaLocation="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0 http://mcuxpresso.nxp.com/XSD/expansion_board_1.0.xsd" xmlns="http://mcuxpresso.nxp.com/XSD/expansion_board_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header_connection ref="frdm_arduino">​ NOTE Some other NXP boards can provide a  single row Arduino expansion header, for example, MIMXRT1060-EVK. For these boards,  create the definition file based on the single_row_arduino expansion header. The definition file varies only in pin references. Expansion board pins The tutorial describes how to add a pin element within the connector elements in three examples. See the marked pins on the shield below. Figure 4 Arduino Multi-Function shield Pin 5V (Power supply +5V) Get the needed pin element attributes values Find the board pin in the expansion header view. The pin tooltip shows connector J3 pin 10. The connector tooltip shows the definition id for J3, which is C1. Figure 5 Connector pin and connector tooltips in the Expansion header view Pin 5V is an external pin from the processor point of view (not connected to the processor). In the common_signal_types.xml, find a suitable signal type. Add the element pin with reference 10, name on the shield 5V, signal type power_supply_5V, and the description in the connector C1. <connector ref="C1"> <pins> <pin ref="10" name="5V" signal_type="power_supply_5V" description="Power supply +5V"/>​ Pin 13 (LED - D1) Get the needed pin element attributes values Find the board pin in the expansion header view. The pin tooltip shows connector J2 pin 12. The connector tooltip shows the definition id for J2, which is C2. Figure 6 Connector pin and connector tooltips in the Expansion header view Pin 13 is connected to LED D1 on the shield. It is digital input from the shield point of view, it is output from the processor point of view. In the common_signal_types.xml, find a suitable signal type. Add the element pin with reference 12, name on the shield 13, signal type digital_in, and the description in the connector C2. <connector ref="C2"> <pins> <pin ref="12" name="13" signal_type="digital_in" description="LED - D1"/>​ Pin A4 (Thermometer DS18B20 or LM35 - U5) Pin A4 is connected to the header U5 on the shield where two different external thermometers can be applied. The definition file you create is the variant for DS18B20. See the documentation for DS18B20: https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf  Get the needed pin element attributes values Find the board pin in the expansion header view. The pin tooltip shows connector J4 pin 10. The connector tooltip shows the definition id for J4, which is C4. Figure 7 Connector pin and connector tooltips in the Expansion header view Pin A4 is connected to DS18B20 DQ pin which is Data Input/Output. In the common_signal_types.xml, find a suitable signal type.   Add the element pin with reference 10, name on the shield A4, signal type digital, and the description in the connector C4. <connector ref="C4"> <pins> <pin ref="10" name="A4" signal_type="digital" description="Thermometer DS18B20 or LM35 - U5"/>​   See the complete expansion board definition file arduino_multifunction_ds18b20.xml and arduino_single_multifunction_ds18b20.xml in the CreateExpansionBoardFile.zip. For information on the usage of this created board file see the following article: Measuring temperature using digital sensor DS18B20 and Arduino Multifunction Shield on FRDM K64F
查看全文
LPC55Sxx: Securing Digital IO Pins  This tutorial explains why you must secure digital IO pins and how to utilize MCUXpresso Config Tools. Risk of Secure information leakage  GPIO (General Purpose Input Output) is the most common digital peripheral in a microcontroller. GPIO of LPC MCU is very flexible and powerful.  Below you can see a simple block diagram of  GPIO (Figure 1).  GPIO can read a pin state regardless of the pin function configured. For example, if this pin is configured as UART, then the pin state can be read via a  GPIO read.[1] Figure 1 GPIO [1]  Due to the architecture of GPIO, all digital IO pins states are readable through the GPIO module from the GPIO read path. It does not depend on what function is chosen for this pin as aforementioned. As a result, there is a possibility of information leakage from a Secure resource (S).   For example, when you configure a UART as a Secure peripheral, it means that only the Secure world can access this UART.  However, in this case, the Non-Secure world can monitor the UART pin states through the GPIO read path as shown in Figure 1. Hence, the Non-Secure world can get all the Secure information from the UART.[1]  To prevent the leakage of information from the Secure world by GPIO, the Secure GPIO Mask is implemented on LPC55Sxx devices with TrustZone®.  This mask disallows the use of GPIO for a pin in both the Secure and the Non-Secure world. LPC55Sxx devices with TrustZone® implement a new NXP peripheral named Secure GPIO that can operate GPIO in the Secure world. Figure 2 Secure GPIO and Secure GPIO Mask [1]  Securing digital IO pins in MCUXpresso Config Tools  MCUXpresso Config Tools contain everything you need to create a Secure configuration. You can do a pins configuration in the Pins tool, configure peripherals in the Peripherals tool, enable clocks in the Clocks tool, and set up the Secure aspects in the Trusted Execution Environment (TEE) tool. Prerequisites  MCUXpresso IDE – v11.3.0 is used in this tutorial, LPCXpresso55S69 SDK – v2.9.0 is used in this tutorial, An application that uses TrustZone and Secure USART, LPCXpresso55S69 Development Board  Application setup  The project uses TrustZone.  FLEXCOMM0 is used as USART.  FLEXCOMM0 is configured as Secure in the TEE tool.  FLEXCOMM0 uses non-blocking transfer.  Reading digital IO state from the Non-Secure world  You can create a simple example to test that the Non-Secure world can access information from the Secure world by reading the state of a GPIO pin.  Assuming the Secure application uses FLEXCOMM0 to communicate and GPIO0.30 pin for TX signal, you can add a code to a Non-Secure application that can read the communication. To use GPIO macros from the example code, make sure the “board.h” header file of LPC55S69 board is added in the include section of the file. When you run the application, the Non-Secure world reads the state of the GPIO pin and changes the state of the blue LED accordingly. You can achieve it without any additional modification to a configuration generated by MCUXpresso Config Tools. There is no need to configure the pin to GPIO. It demonstrates that the state can be read from the Non-Secure world and communication is not Secure. Securing the pin in the TEE tool  Open MCUXpresso Config Tools for the Secure project.  In the example, pin 94 is used as TX pin of FLEXCOMM0 (See Figure 3) as shown in the picture of Pins view from the Pins tool below. The pin is shared with the GPIO0.30 signal. Figure 3 Digital IO pin configured in the Pins tool  Open the TEE tool to configure pin masking  (See Figure 4). Figure 4 Open the Pins tab in the TEE tool  When FLEXCOMM0 is Secure, the TEE tool reports a warning on the GPIO0.30 pin as there is a risk of Secure information leakage.   Change the value of the Reading GPIO state column from Allow to Deny.  To update project files with files generated from the MCUXpresso Config Tools, click the Update Code button. Initialization code generated for a trust zone configuration now masks the read of pin 94 using GPIO.  Verify that the pin cannot be read from the Non-Secure world  You can run the same example to verify that reading a state of the pin, that is routed to the FLEXCOMM0 TX signal, from the Non-Secure world always returns the same value. Running the application, you can see that the blue LED is not changing color based on the communication of the FLEXCOMM peripheral.    [1] 2020. AN12326: Secure GPIO And Usage. 1st ed. [ebook] NXP B.V. 2019, pp.3-4. Available at: <https://www.nxp.com/doc/AN12326> [Accessed 15 December 2020]. 
查看全文
  A Digital Rights Management (DRM) use case   In the Creating Secure and Non-Secure projects tutorial, you have attempted to access a Secure (S) FlexComm0 (USART) peripheral from a Non-Secure (NS) code and failed with the SecureFault exception. This was expected, as TrustZone® for ARM®v8-M protects Secure resources from Non-Secure access.   Now imagine a use case where the platform manages (protects) access to all its peripherals and firmware logic and requires all 3 rd party extensions, for example plugins or widgets, to be certified (approved) for use. The result of this approval process is some form of identification, a license key for instance, the untrusted code needs to supply to the trusted code to gain peripheral access and be able to communicate via USART. This kind of behavior can be achieved with the help of Non-Secure Callable (NSC) memory.   NSC is a type of Secure memory exclusively permitted to hold the Secure Gateway (SG) instruction that allows transition from NS to S state. When a Non-Secure program calls a function in the Secure side, the first instruction in the API must be an SG instruction. The Branch with exchange to Non-secure state (BXNS) will return execution to the Non-Secure side after the API call. While it’s possible for NSC memory to contain entire functions, its typical usage is holding tables of SG instructions with entry points, called veneers.   With GCC, ARMCC, ARMCLANG, IARCC, and LLVM compilers, you must specify the __attribute__((cmse_nonsecure_entry)) function attribute to declare an entry C/C++ function callable from NS state; SG and BXNS instructions are generated automatically. GNU linker puts the resulting code into the .gnu.sgstubs section aligned at 32 bytes.   With the solution outlined, you can reuse projects from the “TEE projects creation” tutorial to speed things up. To extend an existing project with NSC functions, the workflow is as follows: Secure state Configure project and  SAU/IDAU Implement NSC functions Generate NSC library Non-Secure state Configure project (import NSC library) Implement calls for Secure code     S project update   Start with the Secure project conveniently named “Secure”. Reserve some flash memory space for SG_veneer_table first. Navigate to Project > Properties > C/C ++ Build. Locate the MCU settings in SDK MCUs. Click Add Flash and add SG_veneer_table at 0x1000fe00, size 0x200 bytes. Click Apply.   To tell the MCU Linker to generate the NSC import library, navigate to Project > Properties > C/C ++ Build > Settings > MCU Linker > TrustZone. Select the Enable generation of Secure Gateway Import Library checkbox. Click Apply and Close.   Now setup the newly added flash memory region as NSC in the TEE tool. To switch to the TEE tool, click the Open MCUXpresso Configuration button in the Project Explorer, and select Open TEE.   The TEE tool is capable of importing project-wide memory regions from multiple projects at once. To import memory regions, click the Import button in the User Memory Regions view.   In the Select Project dialog, select both NonSecure and Secure projects and click OK.   Quick-fix the reported error Issue: SAU+IDAU: The following security requirements are not satisfied: NS_CALLABLE by right-clicking the cell and selecting the quick-fix from the context menu.   To save the changes, click Update Code.   MCUXpresso IDE v11.3.0 and earlier versions contain a bug that messes up linker script and puts SG veneers into PROGRAM_FLASH instead of SG_veneer_table when you’re modifying an existing project. To work around the problem, navigate To Project > Properties > C/C ++ Build > Settings > MCU Linker > Managed Linker Script. Deselect the Manage linker script checkbox and click Apply and Close.   Edit the script manually by opening the Debug/Secure_Debug.ld inside the IDE, find the .gnu.sgstubs section and direct it to SG_veneer_table instead of PROGRAM_FLASH.         NS project update   If you attempt to build the S project now, you’ll receive several linker errors telling you the NSC library could not be built as there are no NSC functions (yet) including the name of the said library: Secure_CMSE_lib.o. You’re going to use it to configure the Non-Secure project named “Non-Secure”. Navigate to Project > Properties > C/C ++ Build > Settings > MCU Linker > TrustZone. Click the Import button next to the Secure Gateway Import Library field, and select Workspace.   In the Input Secure Gateway Import Library dialog, select Secure_CMSE_lib.o and click OK.   You will see “${workspace_loc:/Secure/Debug/Secure_CMSE_lib.o}” in the Secure Gateway Import Library field of the MCU Linker Setting dialog.     NSC API   The source/Secure.c file already contains the sendSecureByte function implementation you need to make accessible through the NSC space. What’s missing is a few lines of code for its NSC equivalent and function prototype. Create source/nsc_api.h and source/nsc_api.c files in the Secure project workspace. The following code needs go into the newly created header file. #ifndef NSC_API_H_ #define NSC_API_H_ #include <stdint.h> void sendSecureByteNSC(uint8_t data); #endif /* NSC_API_H_ */ Add the following code into the source file. #include <arm_cmse.h> #include "fsl_debug_console.h" #include "nsc_api.h" #include "comm.h" void __attribute__((cmse_nonsecure_entry)) sendSecureByteNSC(uint8_t data) { if (cmse_nonsecure_caller()) { PRINTF("sendSecureByteNSC called from NS space\r\n"); } else { PRINTF("sendSecureByteNSC called from S space\r\n"); } sendSecureByte(data); } To rebuild the Secure project and generate the NSC import library click the Build ‘Debug’ for project ‘Secure’ button in the Toolbar.   Next in line is the Non-Secure project. The NSC library is already set to be imported. Copy Secure/source/nsc_api.h to the NonSecure/source folder. Call the sendSecureByteNSC function instead of USART_WriteByte from source/NonSecure.c. #include "nsc_api.h" …                   USART_WriteByte((USART_Type *)FLEXCOMM0, 'n'); sendSecureByteNSC('n'); Rebuild the Non-Secure project and debug both. Select the Secure project in the workspace and select Debug either from the Quickstart panel or the project context menu. Once the code is running, each press of the WAKEUP (S2) button on the LPCXpresso55S69 board will display the “sendSecureByteNSC called from NS space” message in the IDE console and send a single character via USART instead of failing with the SecureFault exception.    
查看全文
Creating Secure and Non-Secure projects The LPC55S69 MCU series contains Arm TrustZone® and Trusted Execution Environment extension from NXP. It allows users to assign cores, memories, and peripherals to the Secure or the Non-Secure World and restrict access between them. Manufacturers can use it to secure critical functionality of a device. For example, the Secure code is provided on the device by the manufacturer and could not be modified by users. However, a user can create a Non-Secure application and download it to the device. A secure code can communicate over a channel which security cannot be exposed to the Non-Secure World. This example is shown in the tutorial. This tutorial demonstrates how to create Secure and Non-Secure projects and their basic configuration using MCUXpresso IDE and Config Tools. LPCXpresso55S69 Board is used for the demonstration of functionality. Project description Two projects, a Secure and a Non-Secure, are created. Both projects are used on a single core. USART is used for sending data and it is configured as a Secure peripheral. S1 (ISP) button is used for sending data from the Secure world. S2 (WAKEUP) button is used for sending data from the Non-Secure world, which is not allowed due to a security violation. Prerequisites MCUXpresso IDE 11.3.0 LPCXpresso55S69 SDK 2.9.0 LPCXpresso55S69 Board You are familiar with the security extension used on LPC55S69. You are familiar with MCUXpresso IDE and Config Tools – Getting started with TEE. Steps 1.  Create a Secure project Create a new project, select the security type (Secure), and set memory regions in New Project Wizard. You must do it as Secure and Non-Secure projects use different parts of memories. In addition, secure memories use aliases – the 28 th bit is set to 1.  To download the firmware to the secure flash, select the Secure flash driver „LPC55xx_S.cfx“. 2. Create a Non-Secure project Create a new project and set security and memories as follows. 3. Connect the projects It is not mandatory but it makes things easier. Reference the Secure project from the Non-Secure project. It makes importing memory regions into the TEE tool easier.  The current and the linked or linking projects are preselected in the import dialog. In the  Secure project set the Non-Secure project to be preprogrammed.  Both projects are automatically downloaded to the board prior to debugging the Secure project. 4. Disable generation of  a Secure gateway library This feature is not used in this tutorial, therefore it must be turned off to compile the project. Change it in project properties (right-click the project and select Properties). 5. Route Secure pins Open Pins tool. Route S1 pin to SECGPIO. For detecting button press, peripheral SPINT is used and it must be routed to the same pin. Flexcom, which is used as USART, is routed by default in a board configuration. Do not change anything there. 6. Setup Secure peripherals Flexcomm is used for USART communication. Open Peripherals tool. Add USART component in Peripherals tool. Use the default configuration. Problems related to clocks must be resolved in the Clocks tool by enabling peripheral clock. Right-click the problem in Problems view and select Show problem. It opens the Clocks tool and highlights the problematic clock path. Add PINT component. Uncheck the checkbox „Show only components in toolchain project“  as the PINT driver is not in the project yet. Otherwise, it is not listed in the dialog. Select SECPINT peripheral. Configure it to invoke a callback function upon falling edge is detected on S1. Add the  PINT driver to the project via quick-fix in the Problems view. 7. Setup security extension in TEE tool Import memory regions from both projects in the User Memory Regions tab. As nothing is configured for the security extension, there are errors and warnings in the Security Level column. In Security Access Configuration, Miscellaneous tab enable Secure check for AHB matrix and Non-Secure access to floating point extension (CP10 access). FPU is turned on by default. Enable SAU and set Non-Secure regions. Other memory is considered Secure. Set MPC to allow only Secure transactions for Secure memory regions. It resolves errors and warnings in User Memory regions. Set SECGPIO and SECPINT peripherals as Secure. Keep Flexcomm as Non-Secure for now for demonstration purposes. Set PINT interrupt security as Non-Secure. Sending data from the Non-Secure world is also triggered by button press so its interrupt security must be set accordingly. It is the last setting of the Secure project in Config Tools, at this stage update the code. 8. Update Secure project settings After updating the code, create a  TrustZone folder. By default, new folders are excluded from the build. Right-click the folder and uncheck Exclude resource from build in the folder properties. Add the path to the folder into Include paths in project settings. 9. Add missing drivers If you use this version of tools,  add the inputmux driver in the Secure project. It is required for code generated by the Pins tool. 10. Update the Secure source code Do the following updates in source/Secure.c file. Add TEE initialization function call. As security is the first thing that should be configured,  place it SystemInitHook function. This way it is called before entering the main function. The initialization function is implemented in resource_config.h which must be included.       /*! * @brief Application-specific implementation of the SystemInitHook() * weak function. */ void SystemInitHook(void) { BOARD_InitTEE(); }       Implement SECPINT callback function. After pressing S1,  some data is sent from the Secure world via USART. For simplicity, character ‚s‘ is sent from the Secure world and character ‚n‘  is sent from the Non-Secure world.       /* * @brief Send on byte over secure channel * @param data data to be sent */ void sendSecureByte(uint8_t data) { USART_WriteByte(FLEXCOMM0_PERIPHERAL, data); } /* * @brief S1 button interrupt callback * @param pintr pin interrupt type * @param pmatch_status match status */ void secureButtonCallback(pint_pin_int_t pintr ,uint32_t pmatch_status) { sendSecureByte('s'); }       When you do the initialization in the Secure world, the MCU can continue with executing instructions from the Non-Secure world. The switching consists of setting a Non-Secure stack, a vector table, and calling a reset handler. The Non-Secure flash was previously configured to start at address 0x10000.       /* Start address of Non-secure application */ #define NON_SECURE_START 0x10000 /* typedef for non-secure callback functions */ typedef void (*funcptr_ns)(void) __attribute__((cmse_nonsecure_call)); int main(void) { /* Init board hardware. */ BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL /* Init FSL debug console. */ BOARD_InitDebugConsole(); #endif PRINTF("Secure World\n"); /* Set non-secure main stack (MSP_NS) */ __TZ_set_MSP_NS(*((uint32_t *)(NON_SECURE_START))); /* Set non-secure vector table */ SCB_NS->VTOR = NON_SECURE_START; /* Get non-secure reset handler */ funcptr_ns ResetHandler_ns; ResetHandler_ns = (funcptr_ns)(*((uint32_t *)((NON_SECURE_START) + 4U))); /* Jump to normal world */ ResetHandler_ns(); /* Force the counter to be placed into memory. */ volatile static int i = 0 ; /* Enter an infinite loop, just incrementing a counter. */ while(1) { i++ ; /* 'Dummy' NOP to allow source level single stepping of tight while() loop */ __asm volatile ("nop"); } return 0 ; }       11. Route Non-Secure pins Configure the Non-Secure project properly. Route S2 pin to GPIO as input. Route  PINT for pin #64. Flexcomm is routed by default, remove this routing as it is already routed in the Secure project. 12. Setup Non-Secure peripherals Set up PINT to use callback on falling edge of the S2 button press.  Add the driver, for example, via quick fix. 13. Update the Non-Secure source code Keep the initialization of Pins and Peripherals and remove the other initialization as it was done in the Secure world. That also includes the overriding SystemInit function.       /* * @brief System initialization * * Intentionally empty. Required initialization was done in the Secure project. * */ void SystemInit(void) { } /* * @brief Application entry point. */ int main(void) { /* Init board hardware. */ BOARD_InitBootPins(); BOARD_InitBootPeripherals(); ...       Add the code for sending data from the Non-Secure world. To use the USART_WriteByte function and the imputmux driver, include fsl_usart.h.       /* * @brief S2 button interrupt callback * @param pintr pin interrupt type * @param pmatch_status match status */ void nonSecureButtonCallback(pint_pin_int_t pintr ,uint32_t pmatch_status) { USART_WriteByte((USART_Type *)FLEXCOMM0, 'n'); }       Now the projects are ready. When debug is executed for the Secure project, the Non-Secure project is also downloaded to the board. After pressing S1, 's' is sent from the Secure world. When S2 is pressed, 'n' is sent from the Non-Secure world because Flexcomm is configured as Non-Secure in the TEE tool. 14. Securing USART Open the TEE tool from the Secure project and set the Flexcomm slave as Secure. After this change, you can send data from the Secure world but an attempt to send data from the Non-Secure world results in bus fault.  
查看全文
This tutorial is how to start working with TEE
查看全文
The MCUXpresso Config Tools is an integrated suite of configuration tools that help guide users from first evaluation to production software development when designing with Arm ® Cortex ® -M-based devices from NXP, including its general purpose, crossover and wireless-enabled MCUs. These configuration tools allow developers to quickly build a custom SDK and leverage pins, clocks and peripherals to generate initialization C code for custom board support. The following tutorials help you design with the MCUXpresso software and tools. Pins Tool and Expansion Headers Apply Arduino virtual adapter into compatible header Measuring temperature using digital sensor DS18B20 and Arduino Multifunction Shield on FRDM K64F Creating expansion board definition file for Arduino Multifunction shield Adding Expansion Headers to a custom board Peripherals tool USB Audio Class Tutorial  Using TDA1543 I2S DAC with the LPC54114 board  Touch controlled led light on LPCXPRESSO845-BRK  eDMA component abilities shown on ADC measurement example Trusted Execution Environment (TEE) Getting started with TEE  Creating Secure and Non-Secure projects Calling Secure code from Non-Secure region LPC55Sxx: Securing Digital IO Pins
查看全文
The following article describes how the data files of the Pins Tool can be downloaded either for offline usage or processed further, for example in an automated build system or how to use it on a machine without network connection: https://mcuoneclipse.com/2016/07/29/nxp-pins-tool-understanding-data-for-offline-usage/   I hope you find this useful, Erich
查看全文
This post will include a history of releases for the MCUXpresso Config Tools.    Most Recent Release: MCUXpresso Config Tools v11 - Released on January 17, 2022   Download Links: MCUXpresso IDE with integrated Config Tools Standalone MCUXpresso Config Tool   Standalone MCUXpresso Config Tool vs MCUXpresso IDE integrated version The functionality of the MCUXpresso Config Tools is integrated directly within the MCUXpresso IDE as tool perspectives (Pins, Clock, Peripheral, etc).  The configuration tools/perspective will provide a seamless way to configure and modify projects developed within MCUXpresso IDE.  The MCUXpresso Config Tools are also provided as a standalone installation for use with other IDEs (IAR and Keil).  Additionally these tools can be used without an IDE for generating configuration files and generated source file for use without an IDE.   Receive email notification for new releases: If you would like to receive email notifications when a new version of the MCUXpresso Config Tools is released, consider adding an "Email Watch" to this post.   Previous Release History: MCUXpresso Config Tools v10 - Released on July 15, 2021 MCUXpresso Config Tools v9 - Released on January 15, 2021 MCUXpresso Config Tools v8 - Released on July 21, 2020 MCUXpresso Config Tools v7 - Released on Dec 19, 2019  MCUXpresso Config Tools v6 - Released on June 13, 2019 MCUXpresso Config Tools v5 - Released on January 10, 2019
查看全文
The MCUXpresso Config Tools is installed without the data for MCUs and boards, and the data are download on demand via internet. So this article describes how to use MCUXpresso Config Tools with offline Computer. There are two methods: - Copy and paste the data on computer; - Connect the internet when first using. About the detail steps, please have a look at attachment . Thanks for the suggestion from Petr Hradsky . Alice Yang
查看全文
The following article has quick steps and videos how to get started with Kinetis Expert SDK and Design Studio:   https://community.freescale.com/docs/DOC-329662   Enjoy!
查看全文
The following article describes how to configure code generation for the clock gates and how to perform a full initialization with the Pins Tool: https://mcuoneclipse.com/2016/07/19/nxp-pins-tool-clock-gates-and-controlling-the-bits/  
查看全文
This community and forum is for the growing set of Kinetis Expert System Conguration Tools. The tools are acessible online on Welcome to Kinetis Expert | Kinetis Expert and include right now the 'Build an SDK' and 'Power Estimation' tools: So if you have any questions or need any further advice and information about the Kinetis Expert System Configuration Tools, this is the community for it!
查看全文
This tip will show you how to use MCUXpresso Config Tools V4.1 generate codes for KV5x with 50MHz external reference clock. The fec_extal in datasheet shows that the maximum frequency of Input clock frequency (external clock mode) is 48MHz. It will lead code generation failed when you configure 50MHz as the external reference clock in latest MCUXpresso Config Tools V4.1. (Code generation in case of warnings shouldn't be blocked. It will be fixed for MCUXpresso Config Tools V5.) Some customer had met this issue when using TWR-KV58F220M board, this board connect a 50MHz_OSC to EXTAL0. My colleague have prepared a hot fix for this issue (for all MKV5x MCUs). After install the attached hot_fix_MCUXpresso_Config_Tools_V4_1_data_MKV58_MCUCM-3936, customer is able to overcome it.(Notice: The ProgramData folder was hidden by default.)
查看全文