Template: Application

Note

• Provide a concise name to the application, which corresponds to the folder name. If the application targets a specific device, add it in the title before the application name (for example, “nRF5340:”). Do not include the word “application” in the title.

• Place the documentation inside the applications folder and use the file name README.rst.

• Use the provided stock phrases and includes when possible.

• Sections with * are optional and can be left out. All other sections are required. There could be more sections, which can be added after discussion with the tech writer team. However, it should have the mandatory sections from the template in the recommended format at the very least.

The XYZ application demonstrates some functionality for the Nordic XX hardware.

Tip

Explain what this application demonstrates in one or two sentences maximum (full sentences, not sentence fragments). This introduction must be concise and clear, highlighting the features of the application.

Application overview

You can use this application as a USB composite device.

The application adds the functionality of a USB mass storage device, which contains several utility files such as a :ref:RST link file. In addition, it uses the :ref:RST link to provide an option for adding some functionality.

Tip

Continue the explanation on what this application is about. What does it show, and why should users try it? What is the practical use? What libraries are used? (provide links to the used libraries)

Note

If the application uses a third-party integration, provide an explanation of how the integration works with the application. Provide a link to the integration user guide for the user to get more information.

Some title*

Note

Add optional subsections for technical details. Provide suitable titles (sentence style capitalization, thus only the first word capitalized). If there is nothing important to point out, do not include any subsections.

Requirements

Note

• Supported kits are listed in a table, which is composed of rows from the doc/nrf/includes/sample_board_rows.txt file. Select the required rows in the :rows: configuration, or use the .. table-from-sample-yaml:: directive to include all board targets specified in the sample.yaml file.

• If only one kit is supported, replace the introduction text with “The application supports the following development kit:”.

• If several kits are required to test the application, state it after the table (for example, “You can use one or more of the development kits listed above and mix different development kits.”).

• Mention additional requirements after the table.

• If TFM is included in the application, add .. include:: /includes/tfm.txt to include the standard text that states this.

The application supports the following development kits:

Hardware platforms	PCA	Board name	Board target
nRF52 DK	PCA10040	nrf52dk	nrf52dk/nrf52832
nRF52840 DK	PCA10056	nrf52840dk	nrf52840dk/nrf52840

The application also requires …

User interface*

Note

Add button and LED assignments here, with other information related to the user interface (for example, supported commands).

Button 1:

Does something.

Button 2:

Toggles something.

LED 1:

On when connected.

LED 2:

Indicates something.

Configuration*

Note

Always include this section if the user can configure the application. Start with the stock phrase that is included with |config|.

See Configuring and building for information about how to permanently or temporarily change the configuration.

Setup*

Note

Add information about the initial setup here, for example, that the user must install or enable some library before they can compile this application, or set up and select a specific backend. Most applications do not need this section.

Some title*

Note

If required, add subsections for additional configuration scenarios that require a different building procedure.

Configuration options*

Note

• List only important configuration options of the application in this section. Make sure all other configuration options are listed in the section at the bottom of the page.

• The syntax below allows application configuration options to link to the option descriptions in the same way as the library configuration options link to the corresponding Kconfig descriptions (:kconfig:option:`CONFIG_APPLICATION`, which results in CONFIG_APPLICATION).

• For each configuration option, list the symbol name and the string describing it.

• For the nRF Connect for VS Code extension instructions, list the configuration options as they are stated on the Generate Configuration screen.

Check and configure the following Kconfig options:

CONFIG_APPLICATION

The application configuration specifies …

Additional configuration*

Note

• Add this section to describe and link to any library configuration options that might be important to run this application. You can link to options with :kconfig:option:`CONFIG_XXX`.

• You need not list all possible configuration options, but only the ones that are relevant.

Check and configure the following library options that are used by the application:

• CONFIG_PDN_DEFAULT_APN - Used for manual configuration of the Access Point Name (APN).

• CONFIG_MODEM_ANTENNA_GNSS_EXTERNAL - Selects an external GNSS antenna.

Configuration files*

Note

Add this section if the application provides predefined configuration files.

The application provides predefined configuration files for typical use cases. You can find the configuration files in the XXX directory.

The following files are available:

• filename.conf - Specific scenario. This configuration file …

Building and running

Note

• Include the standard text for building - either .. include:: /includes/application_build_and_run.txt or .. include:: /includes/application_build_and_run_ns.txt for the board targets that use Cortex-M Security Extensions.

• The main supported IDE for nRF Connect SDK is Visual Studio Code, with the nRF Connect for VS Code extension installed. Therefore, build instructions for the nRF Connect for VS Code extension are required. Build instructions for the command line are optional.

• See the link to the nRF Connect for Visual Studio Code documentation site for basic instructions on building with the extension.

• If the application uses a non-standard setup, point it out and link to more information, if possible.

This application can be found under applications/XXX in the nRF Connect SDK folder structure.

To build the application, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

Some title*

Note

If required, add subsections for additional build instructions. Use these subsections sparingly and only if the content does not fit into other sections (mainly Configuration*). If the additional build instructions are valid for other applications as well, consider adding them to the Configuring and building section instead and linking to them.

Testing

After programming the application to your development kit, complete the following steps to test it:

1. Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.

2. Connect to the kit with a terminal emulator (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

3. Reset the development kit.

4. And so on …

Note

• Use the shortcuts provided in doc/nrf/shortcuts.txt to keep the wording consistent.

• If there are different ways of testing, introduce them in this section (for example, “After programming the application to your development kit, you can test it either by …”) and add subsections for the different scenarios.

Application output*

Note

Add the full output of the application in this section or include parts of the output in the testing steps in the previous section.

The application shows the following output:

[00:00:02.029,174] <inf> zigbee_app_utils: Zigbee stack initialized

References*

Note

Provide a link to other relevant documentation for the user to get more information.

Tip

Do not include links to documents that are common to all or many of our applications. For example, Installation section.

Related projects and applications*

Note

Add links to projects and/or applications that demonstrate or implement some or all of the features of this application. For example, the Thingy:53: Matter weather station application is part of the Matter project, and so on.

Related samples*

Note

Add links to the samples that show aspects of the application. A sample showcases one feature or component. An application uses several features or components. Include links to samples that showcase features included in the application.

Dependencies*

Note

• List all relevant dependencies, for example, libraries, other tool or service (third-party) references, certification requirements (if applicable).

• Standard libraries (for example, types.h, errno.h, or printk.h) need not be listed.

• Delete the parts that are not relevant.

• Drivers can be listed under libraries.

• If possible, link to the respective dependency. If there is no documentation for the dependency, include the path.

• Add the appropriate secure firmware component that the application supports.

This application uses the following nRF Connect SDK libraries:

• Application Event Manager

• AWS IoT

It uses the following sdk-nrfxlib library:

• Modem library

It uses the following Zephyr libraries:

• Logging

• Kernel Services:

  • include/kernel.h

In addition, it uses the following secure firmware component:

• Trusted Firmware-M

The application also uses drivers from nrfx.

Internal modules*

Note

Add this section if there are internal modules that must be documented. If there are complex modules that cannot fit on one page, add them on separate pages.

API documentation*

Note

Add the following section if the application uses API documentation. Add subsections if the application uses different components with their own APIs.

| Header file: :file:`*provide_the_path*`
| Source files: :file:`*provide_the_path*`

.. doxygengroup:: *doxygen_group_name*