MCUXpresso Config Tools Knowledge Base

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

MCUXpresso Config Tools Knowledge Base

Labels

Discussions

Sort by:
MCUXpresso Config Tools provide a USB configuration component that allows configuring USB settings in a graphical environment and generates a configuration and sample C code according to the configuration.  This tutorial shows how to create the configuration and sample code for the mouse and keyboard HID USB class for the RT1050 EVKB board and build it using the MCUXpresso IDE.  Note: The i.MX RT1050 EVKB board is used; however, the instructions are applicable in a similar way on other NXP EVK boards.   Prerequisites EVKB-IMXRT1050 board  MCUXpresso IDE (v.11.x)  The SDK package for the board (EVKB-IMRT1050)  must be imported and ready to use into MCUXpresso IDE (in the installed SDKs)  Steps 1. Launch MCUXpresso IDE and click Create a new C/C++ project…:  2. Select the EVKBIMXRT1050 board in the MIMXRT1050 processor folder, click  Next:  3. Specify the project name (for example, Test_USB). In the Middleware section, select USB > USB Device. Then click Finish: 4. Unfold the drop-down menu (down arrow) of the Config tools icon (X) and launch the Peripherals tool: 5. In the Peripherals view of the Peripherals tool, click the USB1 peripheral checkbox, ignore the error for now: 6. When the Add configuration component instance dialog appears, select the USB configuration component, click  OK: 6. The USB configuration component instance is added. As it requires the component for MPU initialization, click the + icon to add it.  Confirm the selection of the MPU utility component in the dialog that appeared. Keep the MPU component in the default setting and close its editor tab. 7. In the USB component settings editor, select the HID Keyboard (bare metal) in the preset drop-down list:   The keyboard interfaces are now added to the Supported interfaces list and pre-configured. 8. To add the mouse interface, click the + in the Supported interfaces section. Select the newly added item and change the Class item to HID.   9. Check that the Use case Preset for the interface #1 is set to 'Mouse':   10. The Problems view shows an error as the clock function is inactive by default. To enable it, right-click on the error and select “Enable USBPHY1 PLL clock”: Note:  Optionally, it's possible to click the Show the problem… and adjust it in the Clocks tool. 11. Click the Update Code button in the main toolbar, a pop-up appears: In the pop-up, confirm the code update by clicking the OK button: Build the application using the Build Command in the Quickstart Panel.   13. Now connect the board to the computer via the USB debug connection. Note: The EVKB-IMXRT1050 board provides multiple USB connectors. For flashing the application, it is it’s necessary to use the debug connection.  Also ensure that the board power is configured properly. There are several other configuration jumpers on the board. So in case the application cannot be flashed or debugged,  follow the user guide of the board. 14. To launch the application in the debugger, click the Debug text located in the bottom-left corner of the IDE.   This launches the debugging and the connected board should be detected. Confirm the selection of the debug probe.   Once the connection is successful, launch the application by clicking the Run button. If the application connects successfully, connect an additional USB cable from the application USB connector to your PC. The generated source code files contain a sample code that moves a mouse cursor in a loop and sends Home and End keys. After the cable is connected and the application runs, the movement of the mouse cursor and the text cursor moves left to right are visible.      
View full article
We are pleased to announce that MCUXpresso Config Tools v16.1 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details on the release (features, known issues...) • Fixed missing information about the toolchain project in the Overview dialog shown for the first time. – The Update code dialog opened from the Overview dialog shows the *.cgen.yml file. • Incorrect detection of the selected toolchain file after the command-line execution is fixed. The problem occurs for the folders with multiple different toolchain project files. • Creating a configuration from the toolchain project that does not contain the tool configuration in the MEX file or in the tools source file is allowed. • Open-CMSIS generator support – The usage of the path information from *.cbuild-gen-idx.yml for generation of the *.cgen.yml file is supported. • Clocks – Disabling enabled clock outputs that have settings with shared bit-fields after reopening the configuration is fixed. – Clock slices with multiple outputs are supported. • TEE – An incorrect number of the MPU region attributes shown for the configuration of RT1180 is fixed. – An incorrect domain visibility and tab names when DAC is disabled on RT1180 is fixed.
View full article
We are pleased to announce that MCUXpresso Config Tools v16.0 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details on the release (features, known issues...) The product is based on Eclipse 2023-12 - A new command-line argument ( -UpdateCode) has been added. It performs the same action as the Update Code button in the user interface. It must be used with -HeadlessTool. - The command-line argument -CreateFromProject is improved, it no longer requires the -HeadlessTool argument and opens the toolchain project in the UI. - The command-line arguments -CreateFromProject and -ImportProject are improved. They no longer allow setting the toolchain project file path (for example, *.cbuild-gen-idx.yml, *.uvprojx, *.ewp, CMakeLists.txt) directly. TEE – The query for pins labels and routed signals is updated to work on the new NPI. – Global tool options now support enum, boolean, and string with the ability to define the regex validator. – Access templates are now greyed out when the global ones are used. – The legacy source names option is disabled when ROM output is selected. – MPU tabs are now sorted by top domain index and then alphabetically. – The correct representation of TRDC domains is implemented by removing mix domains. – Peripheral areas are now correctly stored within the correct tab. – The side-channel attack warning is added to the RAM security settings. – The Trigger tab for configuration of the ITRC register RW fields is added. PLU – Minor bug fixes Peripherals – Support for unique identification of configuration components is finished. – Support for settings with indentation, but no label content is added. Pins – Simultaneous routing detection (routing of one signal may result in multiple signals being routed based on the same register settings) is added. In that case, such signals are offered to be added into the configuration. – Support of internal pins that are not available on the package is added. Clocks – Creation of the clock model has been accelerated. Open-CMSIS generator – The open-CMSIS solution is supported as a new toolchain. – The generation of the .cgen.yml file is supported. – The generation of new source files inside the project output folder is supported. – The location of the MEX file inside the project output folder is supported.
View full article
We are pleased to announce that MCUXpresso Config Tools v15.1 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details on the release (features, known issues...) Config Tools v15.1 • On MacOS aarch64, the missing Overview is fixed. • TEE – Pin tables now only contain items for specific configuration (mask/security/interrupts).   Community MCUXpresso Config Tools      
View full article
We are pleased to announce that MCUXpresso Config Tools v15.0 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details on the release (features, known issues...) Config Tools v15.0 • The product is based on Eclipse 2023-06. • Support for SDK 2.15 in the Project cloner and Detect toolchain project is added. TEE – Setting a security level for a special three-state model is improved. – Validation for the uniqueness of DID, match and mask input for XRDC2 is added. – Default global access templates are now created if needed by checkers and missing within MEX. PLU – An error is now reported when a Verilog code contains a signal that was not declared. – A capability to select one input for some logic gates for which it does not make sense is removed. – A button to erase the whole diagram is added. – Support to keep intermediate files generated by an external program for debugging purposes is added. – The behavior of selecting the LUT type Custom to keep the previous logic table and added buttons to set it to zeros or ones is changed. – The status bar to the schematic view is added. Peripherals – A bug with the documentation view in a version integrated to the MCUXpresso IDE is fixed. – The mechanism that handles opening views that were opened in the previous session to work with identification of the configuration instead of its location on disk is updated. – A new optional experimental loading mechanism for components is prepared. This mechanism will be used by default in the next release. Pins – Validation to ensure that elements can be configured by the selected core is added.– Rows are sorted in the Peripheral Signals routing dialog. – The connected pins column in External User Signals always shows the pin's full name. – The missing scroll bar in the External User Signals view is fixed.   Clocks – Support for multicore code generation is added. – Global configuration elements now support tree structure and can be categorized. – Fractional PLL now supports a custom range and negative numerator. – Scrolling in the clock diagram by pressing the mouse wheel (drag and drop) is supported.   DCD – An issue with the code generation that stopped working after drag and drop of a group is fixed.   MCUXpresso IDE integration – Support for multiple MEX files within one project (toolbar Project combo + autoload MEX on IDE startup) is improved.   Community MCUXpresso Config Tools  
View full article
We are pleased to announce that MCUXpresso Config Tools v14.0 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details on the release (features, known issues...) Config Tools v14.0 The product is based on Eclipse 2022-12 Open JDK 17 is updated. Batch processing on command line is supported. Support for SDK 2.14 in Project cloner and Detect toolchain project is added. Link to a toolchain project on a location different than .mex file is added. The command for discarding changes and reloading .mex (MCUXpresso IDE) is added. Quick fix for errors allows setting the "Called by the default initialization function" flag when it would fix an error. Search functionality to Code Preview is added. TEE MCXN-947 combination of AHBSC with TRDC (MBC) is supported. Export TEE registers via wizard or command line is available. Boot ROM hiding feature is supported. Tier mode for TRDC is supported. Domain ambivalence for RDC masters is added. Master-specific memory alias Validation for A28 bit of MPU region address is added. Memory map filters are aligned with Arm terminology. Status bar is united with other tools. PLU Tools used for Verilog synthesis and model optimization are replaced. Linux, Mac, and Apple silicon platforms are supported. Newer versions of Verilog standard are supported. Creation of flip-flop circuits outside Direct mode is supported. Support for special comment that contains mapping information is added. Support for Verilog code resynthesis is added in the new command-line option. Buttons in Schematic view are reordered to groups of related buttons on each row. Information from Verilog synthesis and model optimization tools is added to the error dialog. Peripherals Migration of Peripherals tool components to the latest supported version on current MCU in command line is supported. User information on the dependency of the tool on another tool disabled in the configuration is improved. Migration report generation is supported. The generated report may contain instructions on how to handle incompatible changes between versions of the configured SDK component. Opening links to websites in the Documentation view in an external browser is supported. Pins Labels defined for Expansion header pins can be set as identifiers of the routed pin. Expansion headers can be locked for editing. Expansion headers and boards are added to the HTML and CSV reports. Columns from Routing Details can be added to the External User Signals view. New External User Signals can be created for all routed pins that are missing in the signals table. Clocks Support for the same frequencies settings from different source for internal clocks is added. Community MCUXpresso Config Tools
View full article
This article was written for MCUXpresso Config tools v12 and older. Newer MCUXpresso Config tools can map Arduino expansion boards into compatible expansion headers automatically, without the need for any virtual adapter and even with possibility to utilize all the spare pins!   This tutorial shows how to apply and use the appropriate Arduino virtual adapter file (virtual adapters are attached) to utilize Arduino compatibility across different expansion headers. Benefit Virtual adapter board files allow users of the Pins tool from the MCUXpresso Config tools suite to use the expansion board file intended for a standard Arduino expansion header with other NXP expansion headers that are compatible with the Arduino standard but not mechanically identical (for example, they use two rows of pins).   Arduino-compatible expansion headers Freedom Header (Kinetis FRDM boards) LPCXpresso V3 (LPC boards) LPCXpresso V3 Mirrored Normally, such expansion headers are treated as different in the Pins tool, but the virtual adapter file transforms the current board header into the standard Arduino header so the user can apply the expansion boards referencing the standard Arduino header. For details on the expansion board, see Creating expansion board definition file for Arduino Multifunction shield.   Step 1: Open the Expansion Header view   Open the Expansion Header view if it is not open. In the standalone MCUXpresso Config tools, select the command Views > Expansion header  In the MCUXpresso IDE, select the command Window > Show view > Expansion Header    Step 2: Apply the Arduino virtual adapter file   The application of the virtual adapter file is the same as the application of the expansion board definition file. Use the attached virtual adapter files. Press the “Apply expansion board” button Locate the virtual adapter file and confirm Select if you want to create the functional group (recommended) Choose which names you would like to use in your source code Apply the expansion board   Step 3: Switch to the newly created header   Choose the Arduino adapter header option and select the newly created “Arduino adapter” header. Using the “+” button, select and apply an expansion board intended for the standard single-row Arduino header, and it will be connected to appropriate pins automatically.    
View full article
We are pleased to announce that MCUXpresso Config Tools v13.1 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Config Tools v13.1 Pins tool Fix incomplete routing of deinit functions Update of data for Config Tools v13 and v13.1 General Update of MC56F80xxx support to the latest processor data Fix of missing MIMXRT1170-EVKB board configuration Pins tool Bug fix of incorrect labels of PMOD expansion header in Pins tool Peripherals tool Register init. components Bug fix of PLU Register init. component on LPC550x/S0x processors Bug fix of Peripherals tool FlexIO RIC SDK init. components Support of fcb Peripherals tool component for RT104x and RT116x processors Memory validation tool Update of DDR tool data for i.MX8M and i.MX93 processors Update of Memory validation tool data for Layerscape and i.MX RT processors Community MCUXpresso Config Tools  
View full article
We are pleased to announce that MCUXpresso Config Tools v13 are now available.
View full article
We are pleased to announce that MCUXpresso Config Tools v12.1 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Revision History 12.1 PLU tool Integrated into the Mcuxpresso Config tools Reworked to cooperate with Peripherals tool PLU register init component Pins tool Deinit function now sets also the routing and direction to it's default state. It also tries to route the original peripheral signal to it's default pin Support of RT1041xxxB/RT1042xxxxB   Community MCUXpresso Config Tools   TIP: Check new Expansion Boards in MCUXpresso Config Tools training id:mcuxpresso-config
View full article
We are pleased to announce that MCUXpresso Config Tools v12.1 are now available. Downloads It’s a part of MCUXpresso IDE https://www.nxp.com/mcuxpresso/ide/download In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to MCUXpresso Config Tools documentation for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Revision History 12.1 PLU tool Integrated into the Mcuxpresso Config tools Reworked to cooperate with Peripherals tool PLU register init component Pins tool Deinit function now sets also the routing and direction to it's default state. It also tries to route the original peripheral signal to it's default pin Support of RT1041xxxB/RT1042xxxxB   Community MCUXpresso Config Tools id:mcuxpresso-config
View full article
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
View full article
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
View full article
Measuring temperature using digital sensor DS18B20 and Arduino Multifunction Shield on FRDM K64F  This tutorial describes a simple application for measuring temperature using the digital sensor DS18B20 and the Arduino Multifunction Shield connected to FRDM K64F. You can use new feature Expansion Boards (expansion shields) included in the Pins tool v9. This feature enables quick integration of shields in an application without the need to study manuals. In this paper, you can find the environment setup, 1-wire protocol basics, and the steps of preparing a code with MCUXpresso tools (Peripherals and Pins tool). Setup environment Install MCUXpresso IDE v11.3.0 or later and SDK FRDM-K64F 2.8.2 or later. Use the FRDM K64F EVK board https://www.nxp.com/webapp/Download?colCode=FRDMK64FUG. Connect the Arduino Multifunction shield (Expansion Board) to the FRDM K64F EVK board and DS18B20 to the Arduino shield. Connect the EVK board to the PC via a USB cable. Figure 1 FRDM K64F EVK board with Arduino Multi-Function shield Have the expansion board definition file arduino_multifunction_ds18b20.xml. For detailed instructions on how to create the expansion board see the following article: Creating expansion board definition file for Arduino Multifunction shield DS18B20 Programmable Resolution 1-Wire Digital Thermometer See the documentation https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf This tutorial uses powering with an external supply. Figure 2 Powering the DS18B20 with an External Supply   See the timing diagrams for communication with the DS18B20, needed for writing 1-Wire communication protocol. Figure 3 Initialization Timing Figure 4 Read/Write Time Slot Timing Diagram The application only uses the following 1-wire protocol commands: ‘CCh’ skip ROM command - only one slave on the bus supported ’44h’ convert temperature ‘BEh’ read DS18B20 registers (temperature) Create the application in MCUXpresso IDE Begin with the hello_word example from SDK, rename the project to frdmk64_termometer. Steps to configure timer in the Peripherals tool: Go to the Peripherals tool and add/configure the PIT component. Resolve the new Error in Problems view by adding the SDK component to the project. Figure 5 PIT component in the Peripherals tool Steps to apply the expansion board and configure pin in Pins tool: Apply the expansion board (arduino_multifunction_ds18b20.xml) from menu Pins -> Apply Expansion Board menu    Figure 6 Apply expansion board dialog The Expansion Board Routing dialog is automatically opened after step 1. It provides the possibility to route signals to processor pins that are connected to the expansion board. By default, all pins are routed automatically, see below. Keep only pin A4 routed which is needed for our thermometer application. Unroute the unneeded pins by clicking the Route column or later in the Routing Details view, then click Apply.   Figure 7 Expansion board routing dialog  The action results in the following setting. When selecting Expansion board in the Labels combo, you see the labels as they are marked on the Arduino shield.  Figure 8 Expansion header view In the Routing Details view, set the electrical properties of the pin (Direction, Pull select, Pull enable). Figure 9 Electrical properties in the Routing Details view Click Update Code to update the project with the code generated by the tools. Write the thermometer application and 1-wire protocol (thermometer.c)   Rename the source file hello_world.c to thermometer.c and follow the steps below. Find the completed thermometer.c in the project.  Use the PIT timer to create methods delayMS() and delayUS() for delays of μs and ms. See the PIT interrupt handler PIT_CHANNEL_0_IRQHANDLER() function.   Write methods GPIO_low() and GPIO_high() to set the ARDUINO_A4_PIN to logical 0 and 1. These methods are based on the code which is in the screenshot below. Figure 10 Generated code for ARDUINO_A4_PIN Write methods for reading/writing bytes to the 1-wire bus. Figure 11 Methods for reading/writing bytes Write methods to request the temperature conversion and read the temperature, see dsRequestConvertTemp() and dsReadTemp(). Finally, use the methods in main().   Build the project and start debugging. Figure 12 Output from the application
View full article
  The Expansion headers feature in MCUXpresso Config Tools simplifies the usage of the Pins tool in several ways. It is easier to find appropriate pins on the board and configure them for usage in a user application. The pins can also be automatically routed by applying the expansion board file. This document describes how to add or modify the expansion headers if you are designing or using your own PCB board leveraging standard expansion headers such as those compatible with Arduino.  1. Introduction   1.1 Expansion header   An expansion header is a collection of expansion connectors placed on the development board. The pins from the connectors lead out the processor pins outside and can be identified by a label on the board. There can be multiple expansion headers on a single board.   Figure 1. Example of three expansion headers on- LPC55S69-EVK board  1.2 Expansion board   An expansion board is a circuit board that can be applied to the Expansion header, extending features of the development board. Expansion boards (sometimes called Shields) can contain special additional components such as wireless modules, sensors, and so on. The connected pins may have different names on the expansion board.    If an expansion header is defined in the configuration, then the pins tool can provide instant routing of the processor signals appropriate for the expansion board applied to this header.   Figure 2. Expansion board example - Tester click[https://www.mikroe.com/tester-click]  1.3 Expansion Headers in Pins tool  The Expansion Header view can be found in the Pins tool. The view shows the header connectors and pins in graphical form, with the layout corresponding to the layout of the real board. Figure 3. Expansion Header view  The Expansion Header view can simplify work with the pins connected to an expansion header. By moving the cursor on a connector pin, you can see the details on the pin's connection and routing. You can also route processor pins signals by left-clicking on the connector pin or by right-clicking to invoke the context menu.  The default new configurations created by MCUXpresso config tools for common evaluation boards already contain pre-populated expansion header(s) matching the expansion headers on the board that can be used out-of-box.  2. Adding Custom Expansion header   When the expansion header is not present in the configuration, or you would like to add an additional expansion header.  Open or create the configuration where you would like to add an expansion header in the Pins tool. Open the Expansion Header view if it is not open. In the standalone MCUXpresso Config tools, select the command Views > Expansion header  In the MCUXpressso IDE, select command Window > Show view > Expansion Header  Click the Add button in the Expansion Header view toolbar.      Figure 4. expansion header Add button  The Expansion Header dialog appears Set the header name, type, and connector names to match your hardware design.        Figure 5.  Add New Expansion Header dialog           NOTE: The number of connectors and arrangement is determined by the header type.      Figure 6. Example of the header types (orange: Lpc-style arduino; red: Pmod; green: Micro Bus) The values can be changed in the future in Edit Header   The created header initially contains only the disconnected pin that must be defined before it can be used in the configuration. For more information, see subchapter Connecting pins.  Note: The customized headers and their connections are saved to the configuration MEX file and in the YAML block within the generated source files, so they are not lost when you distribute the configuration to someone else.   Figure 7. Custom header in the source code   2.1 Connecting pins  The newly created custom expansion header does not contain any connected pins.    There are two ways to connect or disconnect a pin:   Dialog in the Expansion Header view Click the Connect command in the context menu of the connector pin.     Figure 8. Connect command in the context menu The Connector Pin dialog is shown   Figure 9. Connect dialog for the 3-d pin on connector “mA”, set name “mPin” and connected to processor pin on coordinates 26  You can set the name (for example, the label of the pin on the header); otherwise, the connector pin coordinates will be used instead.  If the pin is connected to the processor, check the checkbox connected with the processor pin. In this case, check the connected pin checkbox from the list. If the connector pin is used but is not connected to the processor, you can select external signal types, which will be used for validating features of the matching signals when the expansion board is applied to the header. You can also disconnect the pin by unchecking all the checked items.  It is also possible to connect Connector pins via the Pins view, see below.   3. Connections in the Pins view   The connections of each expansion header/board are also shown as a separate column in the Pins view.    The fields at processor pin rows that are filled contain a reference to the connector, the pin number and may contain a label specific for the expansion header. For example, P19[4] (A1) connects the processor pin to connector P19, pin number 4, and the label on the expansion header is A1.     Figure 10. Expansion headers/boards in the Pins view   Steps to connect connector pins in this view:  Find the cell, where the row is the processor pin you would like to connect, and the column is the expansion header to connect to.  The connection is made by setting cell value in the connector pin coordinates format “connector name”[“number of the pin”]. If you want to add an optional name, you append the name in parentheses.  Note: The external signal types of the connector pin cannot be set here.  The value is checked for the correct format, which  is described within the tooltip shown for the cell    Figure 11. Validation tooltip with advice for the header "My custom header"  Disconnecting can be done by deleting the cell value    3.1. Applying/Removing expansion board   If you have an expansion board definition file, you can apply it to the selected expansion header. After the application, the pins tool suggests routing for all used signals and it is possible to see the usage and corresponding board signals for the expansion board.   The expansion board is distributed as a simple .xml file. The type of expansion header must match the expansion header definition, other headers cannot be used. For details on the expansion board definition file, see the following article: Creating expansion board definition file for Arduino Multifunction shield To apply an expansion board, use the following steps:  In the expansion header view, select the plus button in the right part of the Expansion Header view toolbar.  Figure 12. Expansion board add button    You can also use the path Main menu Pins > Apply expansion board, where you can choose the expansion header.      Figure 13. Apply MikroE Tester click board for a micro bus header type  After clicking OK, the Expansion Board Routing dialog appears   Figure 14. Expansion board routing open after applying the expansion board  In the dialog box, you can choose which pins function group the routing will be applied to. The routing dialog contains routing tables, where processor pins are pre-autorouted based on the limitations of the expansion board. The routing is validated in real time and can be changed by clicking a cell in the Route column.   You can also decide if and what pin name will be used for the generation of the defined constants in the code for referencing from the application.    Figure 15. Generated #define for board MIKROE and pins AN, CS  The same dialog appears after clicking the edit expansion board in the Expansion header view, but the option to create a new functional group will not be enabled.  Figure 16 Expansion board edit button   NOTE: Removing expansion board does not remove configured routing. It only changes the identifier defines if they are derived from the board.   Figure 17. Source code change after removing  the expansion board      
View full article
1. Introduction  This tutorial contains the following goals: 1) How to use the main features of the eDMA component 2.4.0 (periodic trigger, peripheral request, linking, scatter-gather) in the Peripherals Configuration Tool. 2) How to set up periodic ADC autonomous (without CPU) queued measurement controlled by DMA. 2. Prerequisites  The application is developed in MCUXpresso IDE 11.5.0 which can be downloaded from https://www.nxp.com/mcuxpresso/ide website. It integrates MCUXpresso Config Tools Version 11 that is used for application design and configuration. The FRDM-K66F - Freedom Development Platform for Kinetis K66 SDK  version 2.11.0 can be downloaded from the https://mcuxpresso.nxp.com/ website or using the MCUXpresso IDE. 3. Application description  3.1. Description  The main goal of this application is to show the configuration of the DMA peripheral which can be used for the ADC channel to be measured and for collecting the results into the resulting output array. It demonstrates an approach for periodic measurement of multiple ADC channels without CPU intervention. It can be used on any MCU with a simple ADC peripheral (without a possibility to queue measured channels). 3.2. Application details  The application starts with the initialization of pins, clocks, and peripherals configured by the MCUXpresso Config Tool. After the initial state is printed to the console, it starts the PIT (periodic interrupt timer). The PIT channel named Trigger causes periodic transfer on the DMA channel named ADC, which configures the ADC peripheral’s channel to be measured. When the timer counting is completed, the ADC measures the analog signal of the DAC peripheral that has been already initialized. The interrupt routine of the PIT Trigger channel includes the actual DAC data reading sequence that will be printed at the end of the console. After the end of the measurement loop, there is the ADC peripheral’s DMA request which initiates the DMA channel named OUTPUT to read the measured ADC data. The DMA channel OUTPUT links the DMA channel named DAC, which increases the buffer read index of the DAC peripheral and generates the next analog signal to be measured by the ADC. The sample number corresponds to the number of major loops of the DMA channel OUTPUT. The major count completion interrupt of the DMA channel OUTPUT stops the measurement trigger (PIT) and enables the DMA request of the DMA channel named PROCESS. The DMA channel PROCESS processes the whole dataset by sorting it into individual data buffers using the scatter-gather function. The major count completion interrupt of the DMA channel PROCESS sets the flag for printing the results and starts the delay timer (PIT second channel named Delay) that delays individual measurements. The post-delay interrupt routine stops the PIT Delay channel and restarts the PIT Trigger channel, which initiates the whole cycle again. Figure 1. Application diagram  4. MCUXpresso Config Tool configuration  The project includes the initial configuration of the following peripherals by the Peripherals Tool: DAC (Digital to Analog Converter) ADC (Analog to Digital Converter) PIT (Periodic Interrupt Timer) eDMA (Enhanced Direct Memory Access) 4.1. DAC peripheral  The DAC peripheral is used for creating simulated data to be measured by the ADC. DAC peripheral setup: Mode – Buffered DAC reference voltage – DACREF_2 – the same voltage reference as for ADC, so that both peripherals are in the same voltage ranges. Enable DAC – true Enable DAC buffer - true Trigger mode – Software trigger (configured by DMA write to register C0, corresponds to the dac_trigger[] configuration) Work mode – Swing mode (demonstration choice) Data buffer values – 10 demonstrations of values from 100 to 1000 with step 100 Buffer read index - 0 The DAC buffer works in swing mode, so it moves the buffer read index from the first item to the last, then back to the first, and so on. After the one loop is measured by the ADC nearly the same values are printed out to the console log, due to the same voltage reference selected in both the DAC and the ADC. The DAC interrupt is not used. Figure 2. DAC Configuration  4.2. ADC peripheral  The ADC peripheral is used for measuring an analog signal (in this case, generated by the DAC peripheral) and converting it into a digital signal. ADC peripheral setup: Reference voltage source – VrefH/VrefL Input clock source – Bus clock divided by 2. Asynchronous clock output – false Divide input clock source – by 8 (to achieve better accuracy) Sample resolution mode – Single-end 12-bit (the same as DAC resolution) Perform auto-calibration – true (to achieve better accuracy) Use hardware trigger – false DMA requests – true The ADC channel selection is configured by the DMA. The adc_trigger[] array includes configurations of the SC1A register, which selects and triggers the ADC channel measurement. The clock frequency for the ADC measurement is set to 3.75 MHz. The conversion time is calculated in the following way: Conversion time = SFC adder + AverageNum * (BCT + LST adder + HSC adder) Where: SFC adder (Single or First Continuous time adder): 5 ADCK + 5 bus clock cycles AverageNum (Average Number factor): 8 BCT (Base Conversion Time: for 12-bit single-ended): 20 ADCK LST adder (Long Sample Time adder): 0 ADCK HSC adder (High-Speed Conversion time adder): 0 ADCK ADCK (ADC clock cycle period): (16/60000000) s The resulting conversion time is calculated as follows:  Conversion time = (5 ADCK + 5 bus clock cycles) + 8 * (20 ADCK + 0 ADCK + 0 ADCK) = 165 * 16/60000000 + 5/60000000 = 44.083 us Figure 3. ADC configuration  4.3. PIT peripheral  The PIT peripheral is used for setting time delays. PIT peripheral setup: Run PIT in debug mode – true (application is demonstrated in debug mode) Clock source frequency – 60 MHz PIT Channel 0 is configured to set the delay between each ADC measurement. It periodically triggers a DMA transfer of DMA channel 0 which writes to the ADC register SC1A. Setup PIT channel 0: Channel ID – Trigger (optional identifier) Channel number – 0 (corresponds to the DMA channel number) Channel period – 60 us (the period must be higher than the calculated ADC conversion time 44.083 us and DAC value stabilization) Interrupt – true Interrupt request – Enabled in the initialization Figure 4. PIT configuration channel 0 named Trigger PIT Channel 1 is configured to set a delay for printing results. It starts at the end of the measurement loop. PIT channel 1 setup: Channel ID – Delay (optional identifier) Channel number – 1 Channel period – 10 s (period of the whole measurement loop) Interrupt – true Interrupt request – Enabled in the initialization Figure 5. DMA channel OUTPUT TCD configuration 4.4. eDMA peripheral  The eDMA peripheral component initializes the DMA and DMAMUX (DMA request multiplexer) peripherals. The DMA controller enables moving data from one memory-mapped location to another without CPU involvement. Note: The error interrupt vector and channel error event for all DMA channels are enabled. It can improve the debugging process. The ISR is defined in the DMA_ERROR handler. eDMA peripheral setup: Priority arbitration mode – Round-robin (no specific channel priorities were set because channels are not used simultaneously) Debug mode enable – true (application is demonstrated in debug mode) Figure 6. General eDMA configuration overview The application example uses 4 DMA channels for control: ADC (always-on DMA request triggered by PIT) DAC (disabled DMA request) OUTPUT (ADC peripheral DMA request) PROCESS (always-on DMA request) All used DMA channels are configured as Non-transactional (TCD structures) channel API mode, which allows you to configure all TCD (Transfer Control Descriptor) registers. 4.4.1. Channel ADC The eDMA channel ADC (Figure 7) is used for setting and triggering the ADC channel to measure the analog signal generated by the DAC peripheral. It demonstrates the use-case of a triggered always-on DMA request when the selected DMA channel (0) is triggered by the corresponding PIT channel (0). The peripheral request is enabled; therefore, the channel operates immediately after the PIT trigger timer starts and completes counting. eDMA channel ADC setup: Channel API mode - Non-transactional (TCD structures) Channel ID – ADC (optional channel prefix name) eDMA channel number – 0 eDMA request – AlwaysOn (any always-on request number) Periodic trigger enable – true (requires initialization of PIT channel 0) Reset channel – true Peripheral request enable – true Figure 7. DMA channel ADC configuration The Transfer Control Descriptor for the DMA channel ADC (Figure 😎 is configured as memory-to-peripheral transfer, which configures the ADC peripheral for measurement. eDMA channel ADC TCD named ADC_trigger setup: TCD ID – ADC_trigger Source address configuration Data size [Byte] – 4 (one minor loop transfers 4 bytes, which corresponds with the destination register size) Address expression – &adc_trigger[0] (contains 2 configurations of the ADC0::SC1A register, for demonstration purposes both selected the same ADC channel 23 (0x17) interconnected with the DAC output. The configurations can be different) External definition – extern uint32_t adc_trigger[]; Offset expression – sizeof(adc_trigger[0]) (SOFF = 4 bytes) Modulo – Disable modulo Destination address configuration Data size [Byte] – 4 (one minor loop transfers 4 bytes, which corresponds to the destination register size) Address expression – ((uint32_t)(&ADC0_PERIPHERAL->SC1[0])) or (uint32_t)ADC0_PERIPHERAL (it is the first register of the peripheral ADC) Offset expression – 0 (DOFF = 0 bytes, destination address is always the same – ADC0::SC1A) Modulo – Disable modulo Minor loop configuration Minor loop transfer [Byte] – 4 Minor loop offset – Disabled Minor loop link enable – false Bandwidth control – No eDMA engine stalls Major loop configuration Major loop count – 2 (MAJOR_LOOP_COUNT – 2 ADC configurations) Source last address adjustment – -8 (SLAST = (-1) * SOFF * MAJOR_LOOP_COUNT) Destination last address adjustment – 0 (DLAST = (-1) * DOFF * MAJOR_LOOP_COUNT) Major loop link enable – false Auto stop request – false (channel operation is triggered by the hardware – PIT trigger) Scatter-gather configuration Scatter-gather enable – false Constant TCDs - true Initialize TCD - ADC_trigger Figure 8. DMA channel ADC TCD configuration 4.4.2. Channel DAC The DMA channel DAC (Figure 9) is used for setting and triggering the DAC peripheral to generate an analog signal for the ADC measurement. It demonstrates the DMA channel (1) configuration without using a DMA request. A channel without a DMA request can be enabled with a software trigger or with channel linking functionality. In this case, the DMA channel DAC is linked from the DMA channel OUTPUT.  Figure 9. DMA channel DAC configuration eDMA channel DAC setup: Channel API mode - Non-transactional (TCD structures) Channel ID – DAC (optional channel prefix name) eDMA channel number – 1 eDMA request – DMAMUX disable (without DMA request) Periodic trigger enable – false Reset channel – true Peripheral request enable – false The TCD for the DMA channel DAC (Figure 10) is configured as a memory-to-peripheral transfer, which configures the DAC peripheral for generating the next analog signal. eDMA channel DAC TCD named DAC_trigger setup: TCD ID – DAC_trigger Source address configuration Data size [Byte] – 1 (one minor loop transfers 1 byte, which corresponds to the destination register size) Address expression – &dac_trigger[0] (contains the configuration of the DAC0::C0 register (0xF0) that triggers DAC by software) External definition – extern uint8_t dac_trigger[]; Offset expression – size of(dac_trigger[0]) (SOFF = 1 bytes) Modulo – Disable modulo Destination address configuration Data size [Byte] – 1 (one minor loop transfers 1 byte which corresponds with the destination register size) Address expression – ((uint32_t)(&DAC0_PERIPHERAL->C0)) Offset expression – 0 (DOFF = 0 bytes, the destination address is always the same – DAC0::C0) Modulo – Disable modulo Minor loop configuration Minor loop transfer [Byte] – 1 Minor loop offset – Disabled Minor loop link enable – false Bandwidth control – No eDMA engine stalls Major loop configuration Major loop count – 2 (MAJOR_LOOP_COUNT – 2 ADC configurations) Source last address adjustment – -1 (SLAST = (-1) * SOFF * MAJOR_LOOP_COUNT) Destination last address adjustment - 0 (DLAST = (-1) * DOFF * MAJOR_LOOP_COUNT) Major loop link enable – false Auto stop request – false (DMA request disabled) Scatter-gather configuration Scatter-gather enable – false Constant TCDs - true Initialize TCD - DAC_trigger Note: Instead of the DAC peripheral the DMA channel can send or receive settings to/from any other peripherals that trigger the ADC measurement (for example, a communication peripheral - UART). Figure 10.  DMA channel DAC TCD configuration 4.4.3. Channel OUTPUT The DMA channel OUTPUT (Figure 11) is used for reading the ADC peripheral results and storing them in memory. It demonstrates the DMA channel (2) configuration using the DMA peripheral request (ADC). The peripheral request is enabled; therefore, the channel operates immediately after the ADC measurement is done. eDMA channel OUTPUT setup: Channel API mode - Non-transactional (TCD structures) Channel ID – OUTPUT (optional channel prefix name) eDMA channel – 2 eDMA request – ADC0 Enable periodic trigger – false Enable channel reset - true Enable peripheral request – true Asynchronous peripheral request – true Figure 11. DMA channel OUTPUT configuration The TCD for the DMA channel OUTPUT (Figure 12) is configured as a peripheral-to-memory transfer which reads the measured values by the ADC peripheral. eDMA channel OUTPUT TCD named ADC_RESULTS setup: TCD ID – ADC_RESULTS Source address configuration Data size [Byte] – 4 (one minor loop transfers 4 bytes which corresponds to the destination register size) Address expression – (uint32_t)(&ADC0_PERIPHERAL->R[0]) (reads results from ADC0::RA register) Offset expression – 0 (SOFF = 0 bytes, the source address is always the same) Modulo – Disable modulo Destination address configuration Data size [Byte] – 4 (one minor loop transfers 1 byte which corresponds to the destination register size) Address expression – &adc_results[0] External definition – extern uint32_t adc_results[]; Offset expression – sizeof(adc_results[0]) (DOFF = 4 bytes) Modulo – Disable modulo Minor loop configuration Minor loop transfer [Byte] – 4 Minor loop offset – Disabled Minor loop link enable – true Linked minor loop channel – 1(DAC) (every minor loop eDMA channel DAC is linked which triggers the DAC and increases the buffer index that changes the DAC output value) Bandwidth control – No eDMA engine stalls Major loop configuration Major loop count – 20 (MAJOR_LOOP_COUNT – 20 measured samples) Source last address adjustment – -0 (SLAST = (-1) * SOFF * MAJOR_LOOP_COUNT) Destination last address adjustment - -80 (DLAST = (-1) * DOFF * MAJOR_LOOP_COUNT) Major loop link enable – true Linked major loop channel – 1(DAC) (last minor loop increases the DAC buffer index for the next measurement cycle) Auto stop request – false Scatter-gather configuration Enable scatter-gather – false Interrupt configuration Interrupt sources – Major count completion (After the measurement cycle, the interrupt DMA_OUTPUT is invoked. The ISR clears the status flags of the DMA channel OUTPUT channel, stops the PIT trigger timer, and enables the peripheral request of the DMA channel PROCESS. This way, it initiates the next operation.) Constant TCDs - true Initialize TCD – ADC_RESULTS - Enable channel interrupt – true - Interrupt request – Enabled in initialization - Enable custom handler name - true - Interrupt handler name – DMA_OUTPUT Figure 12. DMA channel OUTPUT TCD configuration 4.4.4. Channel PROCESS The DMA channel PROCESS (Figure 13) is used for processing the results and storing them in memory. It demonstrates the DMA channel (3) configuration using a DMA always-on request. The peripheral request is disabled; therefore, the channel operates after the request is enabled by the software. In the example application, the DMA request is enabled in the interrupt routine of the DMA channel OUTPUT which is invoked after all major loops transfers are completed (measurement finished). After this DMA transfer, there are two arrays of results, one for each ADC configuration, see configuration array adc_trigger[]. eDMA channel PROCESS setup: Channel API mode - Non-transactional (TCD structures) Channel ID – PROCESS (optional channel prefix name) eDMA channel – 3 eDMA request – AlwaysOn (any always-on request number) Periodic trigger enable – false Reset channel – true Peripheral request enable – false Figure 13. DMA channel PROCESS configuration The DMA channel PROCESS contains pre-configured TCDs as memory-to-memory transfers that process the measured data using scatter-gather functionality. In the example application, the data from one source data-array adc_results[] is scattered into two destination data-arrays, data0[], and data1[]. The DMA channel ADC contains two ADC configurations to be measured. The values measured by the first ADC channel configuration are stored into the data0, and after that, the second ADC channel configuration data into the data1. eDMA channel TCD Data0 setup: TCD ID – Data0 Source address configuration Data size [Byte] – 4 (sample size) Address expression – &adc_results[0] (first sample) Offset expression – 2*sizeof(adc_results[0]) (SOFF = 8 bytes, read every second sample) Modulo – Disable modulo Destination address configuration Data size [Byte] – 4 Address expression – &data0[0] External definition – extern uint32_t data0[]; Offset expression – sizeof(data0[0]) (DOFF = 4 bytes) Modulo – Disable modulo Minor loop configuration Minor loop transfer [Byte] – 4 Minor loop offset – Disabled Minor loop link enable – false Bandwidth control – No eDMA engine stalls Major loop configuration Major loop counts – 10 (MAJOR_LOOP_COUNT – 10 samples) Source last address adjustment – -80 (SLAST = (-1) * SOFF * MAJOR_LOOP_COUNT) Destination last address adjustment – Disabled due to scatter-gather mode Major loop link enable – false Auto stop request – false (always-on request still enabled) Scatter-gather configuration Enable scatter-gather – true Scatter-gather TCD address – Data1 Setup eDMA channel TCD Data1: TCD ID – Data1 Source address configuration Data size [Byte] – 4 (sample size) Address expression – &adc_results[1] (second sample) Offset expression – 2*sizeof(adc_results[0]) (SOFF = 8 bytes, read every second sample) Modulo – Disable modulo Destination address configuration Data size [Byte] – 4 Address expression – &data1[0] External definition – extern uint32_t data1[]; Offset expression – sizeof(data1[0]) (DOFF = 4 bytes) Modulo – Disable modulo Minor loop configuration Minor loop transfer [Byte] – 4 Minor loop offset – Disabled Minor loop link enable – false Bandwidth control – No eDMA engine stalls Major loop configuration Major loop counts – 10 (MAJOR_LOOP_COUNT – 10 samples) Source last address adjustment – -80 (SLAST = (-1) * SOFF * MAJOR_LOOP_COUNT) Destination last address adjustment – Disabled due to scatter-gather mode Major loop link enable – false Auto stop request – true  (stops always-on request) Scatter-gather configuration Enable scatter-gather – true Scatter-gather TCD address – Data0 Interrupt configuration Interrupt sources – Major count completion (After the last major loop of the TCD Data1, the interrupt DMA_PROCESS is invoked. The ISR clears the status flags of the DMA channel PROCESS channel, sets the print flag, and starts the PIT delay timer. The results are printed in the console.) Constant TCDs - true Initialize TCD – Data0 Enable channel interrupt – true - Interrupt request – Enabled in initialization - Enable custom handler name - true - Interrupt handler name – DMA_DATA_PROCESSED Figure 14. DMA channel PROCESS TCD configuration Data0 Figure 15. DMA channel PROCESS TCD configuration Data1 5. Application design  Global variables and definitions: Definitions: • SAMPLE_COUNT - number of the measured values from one measurement loop – one swing through DAC buffer (10 values) to top and back => 2 * 10 • DATA_COUNT - number of the data in each separated output array • ADC_CONFIGURATIONS - number of values (channel settings) for ADC0_SC1A register • DAC_TRIGGER_CONFIGURATIONS - number of values (SW trigger) for DAC0_C0 register Main global variables: • dac_output - Result buffer with DAC output, the array of DAC values filled from the actual pointed buffer index – used for printing purposes/* Result buffer with ADC measurement output - interleaved channels measured data, one by one */ AT_NONCACHEABLE_SECTION_INIT(uint32_t adc_results[SAMPLE_COUNT]) = {0}; /* Process data buffers – output separated measured data from the two selected ADC channels into these two arrays */ AT_NONCACHEABLE_SECTION_INIT(uint32_t data0[DATA_COUNT]) = {0}; AT_NONCACHEABLE_SECTION_INIT(uint32_t data1[DATA_COUNT]) = {0}; /* ADC channel selection: twice channel 23 configuration – 0x17; here you can specify your own channels numbers when you transform the tutorial to real application */ AT_NONCACHEABLE_SECTION_INIT(uint32_t adc_trigger[ADC_CONFIGURATIONS]) = {0x17, 0x17}; /* Set DAC software trigger configuration – 0xF0 */ AT_NONCACHEABLE_SECTION_INIT(uint8_t dac_trigger[DAC_TRIGGER_CONFIGURATIONS]) = {0xF0}; Functions and interrupt handler's description: int main(void) { /* Initialization of MCU (pins, clocks and peripherals) */ . . . /* Start the DMA trigger */ PIT_StartTimer(PIT_PERIPHERAL, PIT_TRIGGER); /* Inside infinite loop */ if(printFlag){ printBuffers(); } } /* PIT0_IRQn interrupt handler */ void PIT_TRIGGER_IRQHANDLER(void) { /* After each ADC trigger */ /* Fill dac_output array by the actual value */ } /* PIT1_IRQn interrupt handler */ void PIT_DELAY_IRQHANDLER(void) { /* At the end of the measurement loop after printing out */ /* Stop delay timer */ PIT_StopTimer(PIT_PERIPHERAL, PIT_DELAY); /* Start triggering in the next measurement loop */ PIT_StartTimer(PIT_PERIPHERAL, PIT_TRIGGER); } /* DMA2_DMA18_IRQn interrupt handler */ void DMA_OUTPUT(void) { /* After all measurement results in actual loop is transferred by DMA to adc_results[] */ /* Stop DMA trigger */ PIT_StopTimer(PIT_PERIPHERAL, PIT_TRIGGER); /* Enable data process DMA channel request */ EDMA_EnableChannelRequest(DMA_DMA_BASEADDR, DMA_PROCESS_DMA_CHANNEL); } /* DMA3_DMA19_IRQn interrupt handler */ void DMA_DATA_PROCESSED(void) { /* After finishing separation DMA transfers from adc_results[] to the data0[] and data1[] */ /* Start delay next measurement and results printing */ PIT_StartTimer(PIT_PERIPHERAL, PIT_DELAY); } /* DMA_Error_IRQn interrupt handler */ void DMA_ERROR(void) { /* Just for sure */ } void printBuffers() { /* Printed out the DAC values with ADC measured values for comparison */ } 6. Conclusion The tutorial shows: 1) How to use the main abilities of the DMA component 2.4.0 (periodic trigger, peripheral request, linking, scatter-gather). 2) How to set up periodic ADC autonomous (without CPU) queued measurement controlled by DMA.        
View full article
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
View full article
If you are using LPCSxx microcontrollers and the TEE tool for configuration of resources isolation, you may encounter a tool warning or the chip’s behaviour differs from the expectations. This article may help you in configuring the Private Peripheral Bus (PPB) area properly. The 0xE000_0000 – 0xFFFF_FFFF area has specific behaviour in the TrustZone. The area’s security can be configured in the SAU, however, multiple regions are either exempt from security checking, or are fixed as Secure. Especially: 0xE000_0000 - 0xE000_2FFF – exempt from security violation checks 0xE000_E000 - 0xE000_EFFF – exempt from security violation checks 0xE002_E000 - 0xE002_EFFF – exempt from security violation checks 0xE004_0000 - 0xE004_1FFF – exempt from security violation checks 0xE00F_F000 - 0xE00F_FFFF – exempt from security violation checks 0xE000_0000 - 0xEFFF_FFFF – exempt from security violation checks for instruction fetch 0xF000_0000 – 0xFFFF_FFFF – fixed as Secure Therefore if you configure any address range mentioned above as a Non-Secure region in the SAU, the TEE tool generates a warning.
View full article
This paper describes using a simple audio DAC (Digital to Analog Converter) with the LPC54114 board. As the processor offers hardware I2S interface, TDA1543, a widely available low-cost 16-bit I2S DAC, is used. This tutorial describes the steps of connecting it and preparing a code for using TDA1543 in your application with leveraging MCUXpresso tools and SDK. Prerequisites MCUXpresso IDE 11.3 MCUXpresso SDK for LPCXpresso54114 version 2.9.x (use https://mcuxpresso.nxp.com) For testing on hardware: LPCXpresso54114 board, TDA1543, and related parts (see below) Hardware TDA1543 is a 16-bit DAC with stereo output. It is available in an 8-pin DIP package with 3 digital input signals. It can operate with a minimum of external parts. The following diagram shows a simple testing circuit used for this project to get an analog audio line output. This schematic can be easily wired using a breadboard. Figure 1. Schematic of an elementary audio output DAC using TDA1543 Connection and pin configuration The DAC uses the standard I2S interface which is a serial bus that consists of 3 signals: Clocks (in the nomenclature of our MCU it is the SCK signal), WS (Word select – indicating left or right channel), and DATA (serial data synchronized by the clock signal). MCUXpresso Config Tools provide the Pins tool that can be leveraged for finding appropriate pins for the connection and routing them. Steps: 1. Create a project for the LPCXpresso54114 board. If you need, you can find detailed instructions in this video. (https://www.nxp.com/design/training/basic-application-development-using-mcuxpresso-ide-and-mcuxpresso-config-tools:TIP-BASIC-APP-DEV-MCUXPRESSO-IDE-TOOLS) Hint: Ensure you select the appropriate board:  2. Open the Pins tool. You can use the tools' Menu button in the Project panel:          NOTE: Ensure you have selected the appropriate project when multiple projects are in the workspace. 3. Open the Peripheral signals view and unfold Flexcom7          NOTE: LPC 54114 MCU provides 8 instances of the Flexcomm communication peripheral that can be flexibly set for UART, SPI, I2C, but only Flexcomm6 and Flexcomm7 provide I2S interface. This tutorial uses Flexcomm7.          NOTE: I2S signals are marked red. FlexComm5 (and lower) do not offer I2S signals. 4. Check the RXD_SDA_MOSI_DATA pin. In the dialog for routing, select which pin you would like to route the signal to. This tutorial uses pin 27 Tip: Find which expansion header connector and pin the processor pin is connected to in the tooltip of each pin:   5. Repeat steps 3 and 4 for SCK and WS signals. SCK – pin 26 (connected to J1[14])  WS – pin 28 (connected to J1[12] and J9[6]) 6. In the Routing details view, set the mode of all signals to Inactive (it disables internal pull-up). Configuring I 2 S in the Peripherals tool Using the Peripherals tool, generate the initialization code for the Flexcomm I 2 S SDK driver that is used for communication with TDA1543. Steps 7. In the Peripherals tool, open the Peripherals view and check Flexcomm7 8. Select the I 2 S configuration component (category Peripheral driver). 9. The Problems view shows an error.  The FLEXCOMM driver is not present in the project. Right-click the error and select the action Add SDK component "FLEXCOMM Driver" into the project In the shown SDK Component Management dialog box, confirm the addition of the files by clicking the Yes button. 10. In the added configuration component, set up the following items: The Custom name checkbox is checked,  the Name: ‘CODEC’ Mode: Transfer (Note: Transfer mode is easy to use and provides asynchronous operation) Sample rate: 24000 Hz Transfer Configuration / Transfer functions setting / Buffer size in bytes: 32           11. The Bit clock source frequency shows an error as the clocks of Flexcom7 are not enabled (inactive).           Right-click the “bulb” icon offering possible fixes for the problem. Select the error message FXCOM7 clock is inactive and select the action Show problem in BOARD_BootClockHSRUN, which is the name of the functional group in the Clocks tool. It opens the Clocks tool and highlights the FXCOMCLK7 clock output related to                             Flexcomm7:     Configuring clocks For correct communication, enable and configure clocks for the Flexcomm7 interface. Steps 12. In the Path Details view (for FXCOM7 clock), set the FXCOM7 clock select to FRG clock, the output of…             NOTE: FRG is a Fractional Rate Generator allowing to provide non-integer ratios for clock frequencies. 13. Set the FRG clock select to FRO 12.               The clock path and frequencies are automatically updated. 14. Switch back to the Peripherals tool using the icon in the toolbar.   15. The bit clock source frequency is now 12000000 Hz and it shows a warning because it does not match a value suitable for producing the required bit clock. The nearest bit clock source frequencies show potential suitable values. Copy the first one            (11520000) to the clipboard and switch back to the Clocks tool. 16. Paste the value into the FXCOM7 clock value column and add ‘Hz’ units; otherwise, it is treated as currently used MHz.    17. An error is reported. The Clocks tool cannot satisfy the requirement, so change the accuracy to a higher value. Set it to 0.5 (which corresponds to 0.5 %): Now the requirement is satisfied (producing 11.54 instead of 11.52 MHz): Code 18. Update the generated code into the project by using the Update Code button.  Confirm the update by clicking OK in the shown dialog. 19. Add the code into the main module (stored in the Sources folder of the MCUXpresso IDE project): /* TODO: insert other definitions and declarations here. */ #define BUF_SIZE 32 // Example wave data for transfer, odd numbers are left channel, even numbers are right channel const uint16_t wave[32] = {                      0,2000,4000,6000,8000,10000,12000,14000,                      16000,18000,20000,22000,24000,26000,28000,30000, }; // I2S callback function volatile void CodecTx(I2S_Type *base, i2s_handle_t *handle, status_t completionStatus, void *userData) {     /* Enqueue the same original s_Buffer all over again */     //i2s_transfer_t *transfer = (i2s_transfer_t *)userData;     I2S_TxTransferNonBlocking(base, handle, CODEC_Tx_Transfer); } Add the following code after the existing hello world PRINTF:         PRINTF("Hello World\n");         // prepare data into the buffer         memcpy(CODEC_Tx_Buffer, wave, 32);        // Start transfer        I2S_TxTransferNonBlocking(CODEC_PERIPHERAL, &CODEC_Tx_handle, CODEC_Tx_Transfer); Testing on hardware You can test the application on the LPC54114 evaluation board with a connected DAC chip. Figure 2. DAC circuit wired with the evaluation board The output checked using the sound-card input of a PC has the following result. It corresponds to the expectations: Figure 3. Waveform measured at the output of the circuit  
View full article
  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.    
View full article