diff --git a/applications/asset_tracker_v2/README.rst b/applications/asset_tracker_v2/README.rst index 663127f1d334..22df0ee4d631 100644 --- a/applications/asset_tracker_v2/README.rst +++ b/applications/asset_tracker_v2/README.rst @@ -1,13 +1,13 @@ .. _asset_tracker_v2: -nRF9160: Asset Tracker v2 -######################### +Asset Tracker v2 +################ .. contents:: :local: :depth: 2 -The Asset Tracker v2 is a real-time configurable ultra-low power capable application firmware for the nRF9160 :term:`System in Package (SiP)`. +The Asset Tracker v2 is a real-time configurable ultra-low power capable application firmware for the nRF91 Series :term:`System in Package (SiP)`. See the subpages for detailed documentation on the application and its internal modules: diff --git a/applications/asset_tracker_v2/doc/app_behavior.rst b/applications/asset_tracker_v2/doc/app_behavior.rst index f7944c035358..0203a309c932 100644 --- a/applications/asset_tracker_v2/doc/app_behavior.rst +++ b/applications/asset_tracker_v2/doc/app_behavior.rst @@ -12,7 +12,7 @@ This section describes the general functioning of the Asset Tracker v2 applicati Data types ********** -Data from multiple sensor sources are collected to construct information about the location, environment, and the health of the nRF9160-based device. +Data from multiple sensor sources are collected to construct information about the location, environment, and the health of nRF91 Series devices. The data types that are collected by the application are listed in the following table: .. _app_data_types: diff --git a/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst b/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst index 3b5ac636801c..b44d06a985ea 100644 --- a/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst +++ b/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst @@ -9,7 +9,7 @@ Application description The Asset Tracker v2 application is built on the following principles: -* Ultra-low power by design - The application highlights the power saving features of the nRF9160 SiP, which is critical for successfully developing small form-factor devices and products which need very long battery lifetime. +* Ultra-low power by design - The application highlights the power saving features of the nRF91 Series SiP, which is critical for successfully developing small form-factor devices and products which need very long battery lifetime. * Offline first - Highly-mobile cellular IoT products need to handle unreliable connections gracefully by implementing mechanisms to retry the failed sending of data. * Timestamping on the device - Sensor data is timestamped on the device using multiple time sources. When the device is offline (planned or unplanned), the timestamping does not rely on the cloud side. * Batching of data - Data is batched to reduce the number of messages transmitted, and to be able to retain collected data while the device is offline. @@ -57,7 +57,7 @@ To set up a cloud service to work with the application firmware, complete the st This value is printed on the development kit. * nRF Cloud - :ref:`Connecting your device to nRF Cloud `. - The default configuration of the firmware is to communicate with `nRF Cloud`_ using the factory-provisioned certificates on the Thingy:91 and nRF9160 DK. + The default configuration of the firmware is to communicate with `nRF Cloud`_ using the factory-provisioned certificates on nRF91 Series DKs and Thingy:91. This means that no additional configuration of the firmware is needed to connect to nRF Cloud. It is recommended to build and run the firmware on the device before completing the steps listed in :ref:`Connecting your device to nRF Cloud `. See :ref:`Building and running `. @@ -104,11 +104,15 @@ The application provides predefined configuration files for typical use cases. Following are the available configuration files: -* :file:`prj.conf` - Configuration file common for ``thingy91_nrf9160_ns`` and ``nrf9160dk_nrf9160_ns`` build targets. +* :file:`prj.conf` - Configuration file common for ``nrf9161dk_nrf9161_ns``, ``thingy91_nrf9160_ns``, and ``nrf9160dk_nrf9160_ns`` build targets. * :file:`prj_qemu_x86.conf` - Configuration file common for ``qemu_x86`` build target. * :file:`prj_native_posix.conf` - Configuration file common for ``native_posix`` build target. -* :file:`boards/thingy91_nrf9160_ns.conf` - Configuration file specific for Thingy:91. This file is automatically merged with the :file:`prj.conf` file when you build for the ``thingy91_nrf9160_ns`` build target. -* :file:`boards/nrf9160dk_nrf9160_ns.conf` - Configuration file specific for nRF9160 DK. This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9160dk_nrf9160_ns`` build target. +* :file:`boards/nrf9161dk_nrf9161_ns.conf` - Configuration file specific for nRF9161 DK. + This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9161dk_nrf9161_ns`` build target. +* :file:`boards/thingy91_nrf9160_ns.conf` - Configuration file specific for Thingy:91. + This file is automatically merged with the :file:`prj.conf` file when you build for the ``thingy91_nrf9160_ns`` build target. +* :file:`boards/nrf9160dk_nrf9160_ns.conf` - Configuration file specific for nRF9160 DK. + This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9160dk_nrf9160_ns`` build target. * :file:`boards//led_state_def.h` - Header file that describes the LED behavior of the CAF LEDs module. Overlay configurations files that enable specific features: @@ -126,7 +130,7 @@ Overlay configurations files that enable specific features: Custom DTC overlay file for enabling a specific feature: -* :file:`nrf9160dk_with_nrf7002ek.overlay` - Configuration file that enables Wi-Fi scanning with nRF7002 EK. +* :file:`nrf91xxdk_with_nrf7002ek` - Configuration file that enables Wi-Fi scanning with nRF7002 EK. Multiple overlay files can be included to enable multiple features at the same time. @@ -144,10 +148,14 @@ Optional library configurations You can add the following optional configurations to configure the heap or to provide additional information such as Access Point Name (APN) to the modem for registering with an LTE network: -* :kconfig:option:`CONFIG_HEAP_MEM_POOL_SIZE` - Configures the size of the heap that is used by the application when encoding and sending data to the cloud. More information can be found in :ref:`memory_allocation`. -* :kconfig:option:`CONFIG_PDN_DEFAULTS_OVERRIDE` - Used for manual configuration of the APN. Set the option to ``y`` to override the default PDP context configuration. -* :kconfig:option:`CONFIG_PDN_DEFAULT_APN` - Used for manual configuration of the APN. An example is ``apn.example.com``. -* :kconfig:option:`CONFIG_MODEM_ANTENNA_GNSS_EXTERNAL` - Selects an external GNSS antenna. For nRF9160 DK v0.15.0 and later, it is recommended to set this option to achieve the best external antenna performance. +* :kconfig:option:`CONFIG_HEAP_MEM_POOL_SIZE` - Configures the size of the heap that is used by the application when encoding and sending data to the cloud. + More information can be found in :ref:`memory_allocation`. +* :kconfig:option:`CONFIG_PDN_DEFAULTS_OVERRIDE` - Used for manual configuration of the APN. + Set the option to ``y`` to override the default PDP context configuration. +* :kconfig:option:`CONFIG_PDN_DEFAULT_APN` - Used for manual configuration of the APN. + An example is ``apn.example.com``. +* :kconfig:option:`CONFIG_MODEM_ANTENNA_GNSS_EXTERNAL` - Selects an external GNSS antenna. + For nRF9160 DK v0.15.0 and later, it is recommended to set this option to achieve the best external antenna performance. .. note:: This application supports the :ref:`ug_bootloader` (also called immutable bootloader), which has been enabled by default since the |NCS| v2.0.0 release. diff --git a/applications/asset_tracker_v2/doc/cloud_module.rst b/applications/asset_tracker_v2/doc/cloud_module.rst index def971231a0d..d1eed0b5b4d0 100644 --- a/applications/asset_tracker_v2/doc/cloud_module.rst +++ b/applications/asset_tracker_v2/doc/cloud_module.rst @@ -82,7 +82,7 @@ nRF Cloud A-GPS and P-GPS ========================= When the cloud module is configured to communicate with `AWS IoT Core`_, `Azure IoT Hub`_, or an `LwM2M`_ server, it supports processing of received A-GPS and P-GPS data using the :ref:`lib_nrf_cloud_agps` and :ref:`lib_nrf_cloud_pgps` libraries. -This enables the cloud service to fetch A-GPS and P-GPS data directly from `nRF Cloud`_ using REST calls and relay this data to the nRF9160 SiP using the pre-established cloud connection. +This enables the cloud service to fetch A-GPS and P-GPS data directly from `nRF Cloud`_ using REST calls and relay this data to an nRF91 Series SiP using the pre-established cloud connection. By reusing the pre-established connection, the application saves overhead related to maintaining multiple connections at the same time. When configuring the application to communicate with nRF Cloud, A-GPS and P-GPS data are received directly from the service, and not by proxy. For more information, see `nRF Cloud Location Services `_. @@ -95,7 +95,7 @@ This enables the cloud to issue FOTA updates and update the application and mode For additional documentation on the various FOTA implementations, refer to the respective client library documentation linked to in :ref:`Integration layers `. Full modem FOTA updates are only supported by nRF Cloud. -This application implements full modem FOTA only for the nRF9160 development kit version 0.14.0 and higher. +This application implements full modem FOTA only for the nRF9161 DK, and for nRF9160 DK version 0.14.0 and higher. To enable full modem FOTA, add the ``-DEXTRA_CONF_FILE=overlay-full_modem_fota.conf`` parameter to your build command. Also, specify your development kit version by appending it to the board name. @@ -133,7 +133,7 @@ CONFIG_CLOUD_THREAD_STACK_SIZE - Cloud module thread stack size CONFIG_CLOUD_CLIENT_ID_USE_CUSTOM - Configuration for enabling the use of a custom cloud client ID This option is used to enable the use of a custom client ID for connection to the respective cloud service. - By default, the cloud module uses the IMEI of the nRF9160-based device as the client ID. + By default, the cloud module uses the IMEI of the nRF91 Series device as the client ID. .. _CONFIG_CLOUD_CLIENT_ID: @@ -159,7 +159,7 @@ For more information on how to set up a connection and provision certificates to .. note:: There are no mandatory configuration settings for the :ref:`lib_nrf_cloud` library. - The nRF9160 DK and Thingy91 come preprovisioned with certificates required to establish a connection to nRF Cloud. + The nRF91 Series DKs and the Thingy:91 come with factory-provisioned certificates required to establish a connection to nRF Cloud. The default configuration of the :ref:`lib_nrf_cloud` library uses the security tag that the nRF Cloud certificates are stored to. Configurations for AWS IoT library diff --git a/applications/asset_tracker_v2/doc/data_module.rst b/applications/asset_tracker_v2/doc/data_module.rst index ccb1412e2b21..8a8dc6fc2c3b 100644 --- a/applications/asset_tracker_v2/doc/data_module.rst +++ b/applications/asset_tracker_v2/doc/data_module.rst @@ -72,7 +72,7 @@ Options that alter the default values of the application's real-time configurati CONFIG_DATA_DEVICE_MODE_ACTIVE This configuration sets the device in active mode. - Default mode for the nRF9160 DK. + Default mode for nRF91 Series devices. .. _CONFIG_DATA_DEVICE_MODE_PASSIVE: diff --git a/applications/asset_tracker_v2/doc/location_module.rst b/applications/asset_tracker_v2/doc/location_module.rst index c88e715bea25..e3609c0b4164 100644 --- a/applications/asset_tracker_v2/doc/location_module.rst +++ b/applications/asset_tracker_v2/doc/location_module.rst @@ -18,8 +18,7 @@ This section documents the various features implemented by the module. Location control ================ -The module uses the :ref:`lib_location` library to communicate with the nRF9160 modem and -control its GNSS and LTE neighbor cell measurement functionalities as well as with the nRF7002 Wi-Fi positioning functionality. +The module uses the :ref:`lib_location` library to communicate with the nRF91 Series modem and control its GNSS and LTE neighbor cell measurement functionalities as well as with the nRF7002 Wi-Fi positioning functionality. A location request starts when the module receives an ``APP_EVT_DATA_GET`` event and the ``APP_DATA_LOCATION`` type is listed in the event's ``data_list`` member containing the data types that shall be sampled. @@ -53,7 +52,7 @@ GNSS LNA configuration Different devices have different GNSS antenna and LNA setups depending on the antenna type (onboard or external). The application uses the :ref:`lib_modem_antenna` library for configuring the LNA. -The library has Kconfig options to control the LNA using either the COEX0 or MAGPIO interface of the nRF9160. +The library has Kconfig options to control the LNA using either the COEX0 or MAGPIO interface of the nRF91 Series device. See the library documentation for more details on how to configure the antenna and LNA. GPS assistance data @@ -66,17 +65,28 @@ Providing the requested A-GPS data typically reduces significantly the time it t Wi-Fi positioning ================= -Wi-Fi positioning is supported with an nRF7002 EK on the nRF9160 DK. -To enable Wi-Fi positioning and especially nRF7002 functionality, use a -special DTC overlay with the compiler option ``-DEXTRA_DTC_OVERLAY_FILE=nrf9160dk_with_nrf7002ek.overlay`` and a -configuration overlay ``-DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf``. +Wi-Fi positioning is supported with an nRF7002 EK on the nRF91 Series DK. +To enable Wi-Fi positioning and especially nRF7002 functionality, use a special DTC overlay with the compiler option ``-DEXTRA_DTC_OVERLAY_FILE=nrf91xxdk_with_nrf7002ek.overlay`` and a configuration overlay ``-DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf``. -To build for the nRF9160 DK with nRF7002 EK, use the ``nrf9160dk_nrf9160_ns`` build target with the ``SHIELD`` CMake option set to ``nrf7002ek`` and a scan-only overlay configuration. -The following is an example of the CLI command: +.. tabs:: -.. code-block:: console + .. group-tab:: nRF9161 DK - west build -p -b nrf9160dk_nrf9160_ns -- -DSHIELD=nrf7002ek -DEXTRA_DTC_OVERLAY_FILE=nrf9160dk_with_nrf7002ek.overlay -DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf + To build for the nRF9161 DK with nRF7002 EK, use the ``nrf9161dk_nrf9161_ns`` build target with the ``SHIELD`` CMake option set to ``nrf7002ek`` and a scan-only overlay configuration. + The following is an example of the CLI command: + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -- -DSHIELD=nrf7002ek -DEXTRA_DTC_OVERLAY_FILE=nrf91xxdk_with_nrf7002ek.overlay DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf + + .. group-tab:: nRF9160 DK + + To build for the nRF9160 DK with nRF7002 EK, use the ``nrf9160dk_nrf9160_ns`` build target with the ``SHIELD`` CMake option set to ``nrf7002ek`` and a scan-only overlay configuration. + The following is an example of the CLI command: + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DSHIELD=nrf7002ek -DEXTRA_DTC_OVERLAY_FILE=nrf91xxdk_with_nrf7002ek.overlay DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf Wi-Fi positioning has the following limitations: diff --git a/applications/asset_tracker_v2/doc/sensor_module.rst b/applications/asset_tracker_v2/doc/sensor_module.rst index b3165f578e22..09ab14c92732 100644 --- a/applications/asset_tracker_v2/doc/sensor_module.rst +++ b/applications/asset_tracker_v2/doc/sensor_module.rst @@ -45,7 +45,7 @@ When the module receives an :c:enum:`APP_EVT_DATA_GET` event and the :c:enum:`AP When data sampling has been carried out, the :c:enum:`SENSOR_EVT_ENVIRONMENTAL_DATA_READY` event is sent from the module with the sampled environmental sensor values. .. note:: - The nRF9160 DK does not have any external sensors and battery fuel gauge. + An nRF91 Series DK does not have any external sensors and battery fuel gauge. If the sensor module is queried for sensor data when building for the DK, the event :c:enum:`SENSOR_EVT_ENVIRONMENTAL_NOT_SUPPORTED` is sent out by the module upon data sampling. For battery fuel gauge data, :c:enum:`SENSOR_EVT_FUEL_GAUGE_NOT_SUPPORTED` is sent. diff --git a/applications/asset_tracker_v2/doc/ui_module.rst b/applications/asset_tracker_v2/doc/ui_module.rst index e60c45f4cc63..e087bbfe68f0 100644 --- a/applications/asset_tracker_v2/doc/ui_module.rst +++ b/applications/asset_tracker_v2/doc/ui_module.rst @@ -7,7 +7,7 @@ User Interface module :local: :depth: 2 -The User Interface module controls and monitors the UI elements on the nRF9160 DK and Thingy:91. +The User Interface module controls and monitors the UI elements on nRF91 Series development kits and Thingy:91. Features ******** @@ -22,13 +22,13 @@ The buttons used by the module and their functionality are listed in the followi .. _button_behavior: -+--------+-------------------------------------+------------------------------------------------------------------------------------------------------------------+ -| Button | Thingy:91 | nRF9160 DK | -+========+=====================================+==================================================================================================================+ -| 1 | Send a message to the cloud service | Send message to the cloud service. | -+--------+-------------------------------------+------------------------------------------------------------------------------------------------------------------+ -| 2 | | Send message to the cloud service. | -+--------+-------------------------------------+------------------------------------------------------------------------------------------------------------------+ ++--------+-------------------------------------+------------------------------------+ +| Button | Thingy:91 | nRF91 Series DK | ++========+=====================================+====================================+ +| 1 | Send a message to the cloud service | Send message to the cloud service. | ++--------+-------------------------------------+------------------------------------+ +| 2 | | Send message to the cloud service. | ++--------+-------------------------------------+------------------------------------+ .. _led_indication: @@ -39,7 +39,7 @@ The module supports multiple LED patterns to visualize the operating state of th The following table describes the supported LED states: +---------------------------+------------------------------+----------------------------+ -| State | Thingy:91 RGB LED | nRF9160 DK solid LEDs | +| State | Thingy:91 RGB LED | nRF91 Series DK solid LEDs | +===========================+==============================+============================+ | LTE connection search | Yellow, blinking | LED1 blinking | +---------------------------+------------------------------+----------------------------+ diff --git a/applications/asset_tracker_v2/doc/util_module.rst b/applications/asset_tracker_v2/doc/util_module.rst index 04b7e759ec8f..4832464ebf84 100644 --- a/applications/asset_tracker_v2/doc/util_module.rst +++ b/applications/asset_tracker_v2/doc/util_module.rst @@ -38,7 +38,7 @@ The module implements a watchdog library that monitors the system workqueue usin To configure the watchdog timeout that is used, set the :ref:`CONFIG_WATCHDOG_APPLICATION_TIMEOUT_SEC ` Kconfig option. The header file of the library is located at :file:`asset_tracker_v2/src/watchdog/watchdog_app.h`. -If the watchdog is not fed within the timeout indicated by :ref:`CONFIG_WATCHDOG_APPLICATION_TIMEOUT_SEC `, a watchdog timeout occurs, causing a reboot that is initiated by the watchdog peripheral hardware unit on the nRF9160 DK. +If the watchdog is not fed within the timeout indicated by :ref:`CONFIG_WATCHDOG_APPLICATION_TIMEOUT_SEC `, a watchdog timeout occurs, causing a reboot that is initiated by the watchdog peripheral hardware unit on the nRF91 Series DK. The watchdog library is set up to feed the :ref:`Zephyr Watchdog driver ` with the system workqueue constantly at a time interval that equals half of the value specified by :ref:`CONFIG_WATCHDOG_APPLICATION_TIMEOUT_SEC `. This means that if the watchdog timeout is set to 60 seconds, the system workqueue feeds the watchdog every 30 seconds. A reboot caused by a watchdog timeout occurs if the system workqueue is blocked and it is unable to feed the watchdog. diff --git a/applications/serial_lte_modem/README.rst b/applications/serial_lte_modem/README.rst index caa118ffaafc..47c281a1a1b5 100644 --- a/applications/serial_lte_modem/README.rst +++ b/applications/serial_lte_modem/README.rst @@ -1,9 +1,9 @@ .. _serial_lte_modem: -nRF9160: Serial LTE modem -######################### +Serial LTE modem +################ -The Serial LTE Modem (SLM) application can be used to emulate a stand-alone LTE modem on the nRF9160. +The Serial LTE Modem (SLM) application can be used to emulate a stand-alone LTE modem on an nRF91 Series device. The application accepts both the modem-specific AT commands documented in the `nRF91 AT Commands Reference Guide `_ and proprietary AT commands documented in :ref:`SLM_AT_intro`. See the subpages for how to use the application, how to extend it, and information on the supported AT commands. diff --git a/applications/serial_lte_modem/doc/Generic_AT_commands.rst b/applications/serial_lte_modem/doc/Generic_AT_commands.rst index 5a4df6bc359d..088da99a01a9 100644 --- a/applications/serial_lte_modem/doc/Generic_AT_commands.rst +++ b/applications/serial_lte_modem/doc/Generic_AT_commands.rst @@ -119,14 +119,14 @@ The test command is not supported. Power saving #XSLEEP ==================== -The ``#XSLEEP`` command makes the nRF9160 System in Package (SiP) enter idle or sleep mode. +The ``#XSLEEP`` command makes the nRF91 Series System in Package (SiP) enter idle or sleep mode. -If you want to do power measurements on the nRF9160 development kit while running the SLM application, disable unused peripherals. +If you want to do power measurements on the nRF91 Series development kit while running the SLM application, disable unused peripherals. Set command ----------- -The set command makes the nRF9160 SiP enter either Idle or Sleep mode. +The set command makes the nRF91 Series SiP enter either Idle or Sleep mode. Syntax ~~~~~~ @@ -141,12 +141,12 @@ The ```` parameter accepts only the following integer values: * ``1`` - Enter Sleep. In this mode, both the SLM service and the LTE connection are terminated. - The nRF9160 SiP can be woken up using the :ref:`CONFIG_SLM_WAKEUP_PIN `. + The nRF91 Series SiP can be woken up using the :ref:`CONFIG_SLM_WAKEUP_PIN `. * ``2`` - Enter Idle. In this mode, both the SLM service and the LTE connection are maintained. - The nRF9160 SiP can be made to exit idle using the :ref:`CONFIG_SLM_WAKEUP_PIN `. + The nRF91 Series SiP can be made to exit idle using the :ref:`CONFIG_SLM_WAKEUP_PIN `. If the :ref:`CONFIG_SLM_INDICATE_PIN ` is defined, SLM toggle this GPIO when there is data for MCU. MCU could in turn make SLM to exit idle by :ref:`CONFIG_SLM_WAKEUP_PIN `. The data is buffered during the idle status and sent to MCU after exiting the idle status. @@ -220,12 +220,12 @@ Example Power off #XSHUTDOWN ==================== -The ``#XSHUTDOWN`` command makes the nRF9160 SiP enter System OFF mode, which is the deepest power saving mode. +The ``#XSHUTDOWN`` command makes the nRF91 Series SiP enter System OFF mode, which is the deepest power saving mode. Set command ----------- -The set command makes the nRF9160 SiP enter System OFF mode. +The set command makes the nRF91 Series SiP enter System OFF mode. Syntax ~~~~~~ @@ -236,7 +236,7 @@ Syntax .. note:: - In this case the nRF9160 SiP cannot be woken up using the :ref:`CONFIG_SLM_WAKEUP_PIN `.. + In this case the nRF91 Series SiP cannot be woken up using the :ref:`CONFIG_SLM_WAKEUP_PIN `.. Example ~~~~~~~~ @@ -260,12 +260,12 @@ The test command is not supported. Reset #XRESET ============= -The ``#XRESET`` command performs a soft reset of the nRF9160 SiP. +The ``#XRESET`` command performs a soft reset of the nRF91 Series SiP. Set command ----------- -The set command resets the nRF9160 SiP. +The set command resets the nRF91 Series SiP. Syntax ~~~~~~ diff --git a/applications/serial_lte_modem/doc/TCPUDP_AT_commands.rst b/applications/serial_lte_modem/doc/TCPUDP_AT_commands.rst index a0c58f0fd7d6..b0717e56a9ab 100644 --- a/applications/serial_lte_modem/doc/TCPUDP_AT_commands.rst +++ b/applications/serial_lte_modem/doc/TCPUDP_AT_commands.rst @@ -388,7 +388,7 @@ UDP server #XUDPSVR The ``#XUDPSVR`` command allows you to start and stop the UDP server. .. note:: - DTLS server functionality is not supported by the nRF9160. + DTLS server functionality is not supported by nRF91 Series devices. Set command ----------- diff --git a/applications/serial_lte_modem/doc/slm_description.rst b/applications/serial_lte_modem/doc/slm_description.rst index b3ddd972dca4..0c016c5ffe72 100644 --- a/applications/serial_lte_modem/doc/slm_description.rst +++ b/applications/serial_lte_modem/doc/slm_description.rst @@ -7,14 +7,14 @@ Application description :local: :depth: 3 -The Serial LTE Modem (SLM) application demonstrates how to use the nRF9160 as a stand-alone LTE modem that can be controlled by AT commands. +The Serial LTE Modem (SLM) application demonstrates how to use an nRF91 Series device as a stand-alone LTE modem that can be controlled by AT commands. Overview ******** -The nRF9160 SiP integrates both a full LTE modem and an application MCU, enabling you to run your LTE application directly on the nRF9160. +The nRF91 Series SiP integrates both a full LTE modem and an application MCU, enabling you to run your LTE application directly on the device. -However, if you want to run your application on a different chip and use the nRF9160 only as a modem, the serial LTE modem application provides you with an interface for controlling the LTE modem through AT commands. +However, if you want to run your application on a different chip and use the nRF91 Series device only as a modem, the serial LTE modem application provides you with an interface for controlling the LTE modem through AT commands. The application accepts both the modem-specific AT commands documented in the `nRF91 AT Commands Reference Guide `_ and the proprietary AT commands documented in the :ref:`SLM_AT_intro` page. @@ -61,12 +61,13 @@ CONFIG_SLM_NATIVE_TLS - Use Zephyr mbedTLS CONFIG_SLM_EXTERNAL_XTAL - Use external XTAL for UARTE This option configures the application to use an external XTAL for UARTE. - See the `nRF9160 Product Specification`_ (section 6.19 UARTE) for more information. + For the nRF9160 DK, see the `nRF9160 Product Specification`_ (section 6.19 UARTE) for more information. + For the nRF9161 DK, see the `nRF9161 Objective Product Specification`_ (section 6.19 UARTE) for more information. .. _CONFIG_SLM_START_SLEEP: CONFIG_SLM_START_SLEEP - Enter sleep on startup - This option makes nRF9160 enter deep sleep after startup. + This option makes an nRF91 Series device enter deep sleep after startup. It is not selected by default. .. _CONFIG_SLM_WAKEUP_PIN: @@ -75,6 +76,11 @@ CONFIG_SLM_WAKEUP_PIN - Interface GPIO to exit from sleep or idle This option specifies which interface GPIO to use for exiting sleep or idle mode. It is set by default as follows: + * On the nRF9161 DK: + + * **P0.8** (Button 1 on the nRF9161 DK) is used when UART_0 is used. + * **P0.31** is used when UART_1 is used. + * On the nRF9160 DK: * **P0.6** (Button 1 on the nRF9160 DK) is used when UART_0 is used. @@ -90,12 +96,19 @@ CONFIG_SLM_WAKEUP_PIN - Interface GPIO to exit from sleep or idle CONFIG_SLM_INDICATE_PIN - Interface GPIO to indicate data available or unsolicited event notifications This option specifies which interface GPIO to use for indicating data available or unsolicited event notifications from the modem. - On the nRF9160 DK, it is set by default as follows: + It is set by default as follows: + + * On the nRF9161 DK: + + * **P0.00** (LED 1 on the nRF9161 DK) is used when UART_0 is selected. + * **P0.30** is used when UART_2 is selected. + + * On the nRF9160 DK: - * **P0.2** (LED 1 on the nRF9160 DK) is used when UART_0 is selected. - * **P0.30** is used when UART_2 is selected. + * **P0.2** (LED 1 on the nRF9160 DK) is used when UART_0 is selected. + * **P0.30** is used when UART_2 is selected. - It is not defined when the target is Thingy:91. + * It is not defined when the target is Thingy:91. .. note:: This pin is used as output GPIO and configured as *Active Low*. @@ -240,6 +253,9 @@ The following configuration files are provided: * :file:`boards/nrf9160dk_nrf9160_ns.conf` - Configuration file specific for the nRF9160 DK. This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9160dk_nrf9160_ns`` build target. +* :file:`boards/nrf9161dk_nrf9161_ns.conf` - Configuration file specific for the nRF9161 DK. + This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9161dk_nrf9161_ns`` build target. + * :file:`boards/thingy91_nrf9160_ns.conf` - Configuration file specific for Thingy:91. This file is automatically merged with the :file:`prj.conf` file when you build for the ``thingy91_nrf9160_ns`` build target. @@ -251,10 +267,6 @@ When the DTS overlay filename matches the build target, the overlay is automatic See :ref:`app_build_system`: for more information on the |NCS| configuration system. -.. include:: /libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst - :start-after: modem_lib_sending_traces_UART_start - :end-before: modem_lib_sending_traces_UART_end - .. _slm_native_tls: Native TLS @@ -285,6 +297,10 @@ The configuration options that are required to enable the native TLS socket are * The DTLS server is currently not supported. * TLS session resumption is currently not supported. +.. include:: /libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst + :start-after: modem_lib_sending_traces_UART_start + :end-before: modem_lib_sending_traces_UART_end + .. _slm_building: Building and running @@ -294,22 +310,22 @@ Building and running .. include:: /includes/build_and_run_ns.txt -.. _slm_connecting_9160dk: +.. _slm_connecting_91dk: -Communicating with the modem on the nRF9160 DK -============================================== +Communicating with the modem on an nRF91 Series DK +================================================== -In this scenario, the nRF9160 DK running the Serial LTE Modem application serves as the host. +In this scenario, an nRF91 Series DK running the Serial LTE Modem application serves as the host. You can use either a PC or an external MCU as a client. -.. _slm_connecting_9160dk_pc: +.. _slm_connecting_91dk_pc: Connecting with a PC -------------------- -To connect to the nRF9160 DK with a PC +To connect to an nRF91 Series DK with a PC -.. slm_connecting_9160dk_pc_instr_start +.. slm_connecting_91dk_pc_instr_start 1. Verify that ``UART_0`` is selected in the application. It is defined in the default configuration. @@ -343,9 +359,9 @@ To connect to the nRF9160 DK with a PC When using PuTTY, you must set the :ref:`CONFIG_SLM_CR_TERMINATION ` SLM configuration option instead. See :ref:`application configuration ` for more details. -.. slm_connecting_9160dk_pc_instr_end +.. slm_connecting_91dk_pc_instr_end -.. _slm_connecting_9160dk_mcu: +.. _slm_connecting_91dk_mcu: Connecting with an external MCU ------------------------------- @@ -354,60 +370,105 @@ Connecting with an external MCU This section does not apply to Thingy:91 as it does not have UART2. -If you run your user application on an external MCU (for example, an nRF52 Series development kit), you can control the modem on nRF9160 directly from the application. +If you run your user application on an external MCU (for example, an nRF52 Series development kit), you can control the modem on an nRF91 Series device directly from the application. See the :ref:`slm_shell_sample` for a sample implementation of such an application. To connect with an external MCU using UART_2, change the configuration files for the default board as follows: -* In the :file:`nrf9160dk_nrf9160_ns.conf` file:: +.. tabs:: + + .. group-tab:: nRF9161 DK + + * In the :file:`nrf9161dk_nrf9161_ns.conf` file:: + + # Use UART_0 (when working with PC terminal) + # unmask the following config + #CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2 + #CONFIG_UART_0_NRF_HW_ASYNC=y + #CONFIG_SLM_WAKEUP_PIN=8 + #CONFIG_SLM_INDICATE_PIN=0 + + # Use UART_2 (when working with external MCU) + # unmask the following config + CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2 + CONFIG_UART_2_NRF_HW_ASYNC=y + CONFIG_SLM_WAKEUP_PIN=31 + CONFIG_SLM_INDICATE_PIN=30 + + * In the :file:`nrf9161dk_nrf9161_ns.overlay` file:: + + / { + chosen { + ncs,slm-uart = &uart2; + } + }; + + &uart0 { + status = "disabled"; + }; + + &uart2 { + compatible = "nordic,nrf-uarte"; + current-speed = <115200>; + status = "okay"; + hw-flow-control; + + pinctrl-0 = <&uart2_default_alt>; + pinctrl-1 = <&uart2_sleep_alt>; + pinctrl-names = "default", "sleep"; + }; + + + .. group-tab:: nRF9160 DK - # Use UART_0 (when working with PC terminal) - # unmask the following config - #CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2 - #CONFIG_UART_0_NRF_HW_ASYNC=y - #CONFIG_SLM_WAKEUP_PIN=6 - #CONFIG_SLM_INDICATE_PIN=2 + * In the :file:`nrf9160dk_nrf9160_ns.conf` file:: - # Use UART_2 (when working with external MCU) - # unmask the following config - CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2 - CONFIG_UART_2_NRF_HW_ASYNC=y - CONFIG_SLM_WAKEUP_PIN=31 - CONFIG_SLM_INDICATE_PIN=30 + # Use UART_0 (when working with PC terminal) + # unmask the following config + #CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2 + #CONFIG_UART_0_NRF_HW_ASYNC=y + #CONFIG_SLM_WAKEUP_PIN=6 + #CONFIG_SLM_INDICATE_PIN=2 + # Use UART_2 (when working with external MCU) + # unmask the following config + CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2 + CONFIG_UART_2_NRF_HW_ASYNC=y + CONFIG_SLM_WAKEUP_PIN=31 + CONFIG_SLM_INDICATE_PIN=30 -* In the :file:`nrf9160dk_nrf9160_ns.overlay` file:: - / { - chosen { - ncs,slm-uart = &uart2; - } - }; + * In the :file:`nrf9160dk_nrf9160_ns.overlay` file:: - &uart0 { - status = "disabled"; - }; + / { + chosen { + ncs,slm-uart = &uart2; + } + }; - &uart2 { - compatible = "nordic,nrf-uarte"; - current-speed = <115200>; - status = "okay"; - hw-flow-control; + &uart0 { + status = "disabled"; + }; - pinctrl-0 = <&uart2_default_alt>; - pinctrl-1 = <&uart2_sleep_alt>; - pinctrl-names = "default", "sleep"; - }; + &uart2 { + compatible = "nordic,nrf-uarte"; + current-speed = <115200>; + status = "okay"; + hw-flow-control; + pinctrl-0 = <&uart2_default_alt>; + pinctrl-1 = <&uart2_sleep_alt>; + pinctrl-names = "default", "sleep"; + }; -The following table shows how to connect an nRF52 Series development kit to the nRF9160 DK to be able to communicate through UART: +The following table shows how to connect an nRF52 Series development kit to an nRF91 Series development kit to be able to communicate through UART: .. list-table:: :align: center :header-rows: 1 * - nRF52 Series DK - - nRF9160 DK + - nRF91 Series DK * - UART TX P0.6 - UART RX P0.11 * - UART RX P0.8 @@ -424,7 +485,7 @@ The following table shows how to connect an nRF52 Series development kit to the Use the following UART devices: * nRF52840 or nRF52832 - UART0 -* nRF9160 - UART2 +* nRF9160 or nRF9161 - UART2 Use the following UART configuration: @@ -434,9 +495,9 @@ Use the following UART configuration: * Operation mode: IRQ .. note:: - The GPIO output level on the nRF9160 side must be 3 V. + The GPIO output level on the nRF91 Series device side must be 3 V. You can set the VDD voltage with the **VDD IO** switch (**SW9**). - See the `VDD supply rail section in the nRF9160 DK User Guide`_ for more information. + See the `VDD supply rail section in the nRF9160 DK User Guide`_ for more information related to nRF9160 DK. .. _slm_connecting_thingy91: @@ -458,8 +519,8 @@ By enabling the option ``CONFIG_BRIDGE_BLE_ENABLE`` , you can also use SLM over Then follow the instructions below: .. include:: slm_description.rst - :start-after: .. slm_connecting_9160dk_pc_instr_start - :end-before: .. slm_connecting_9160dk_pc_instr_end + :start-after: .. slm_connecting_91dk_pc_instr_start + :end-before: .. slm_connecting_91dk_pc_instr_end You can also test the i2c sensor on Thingy:91 using :ref:`SLM_AT_TWI`. See :ref:`slm_testing_twi` for more details. @@ -476,7 +537,7 @@ If you have an nRF52 Series DK running a client application, you can also use th 1. |connect_kit| #. :ref:`Connect to the kit with LTE Link Monitor `. - If you want to use a different terminal emulator, see `slm_connecting_9160dk_pc`_. + If you want to use a different terminal emulator, see ref:`slm_connecting_91dk_pc`. #. Reset the kit. #. Observe that the development kit sends a ``Ready\r\n`` message on UART. #. Enter ``AT+CFUN=1`` to turn on the modem and connect to the network. diff --git a/applications/serial_lte_modem/doc/slm_testing.rst b/applications/serial_lte_modem/doc/slm_testing.rst index ac6d241fe8ca..42bdc01fb20d 100644 --- a/applications/serial_lte_modem/doc/slm_testing.rst +++ b/applications/serial_lte_modem/doc/slm_testing.rst @@ -578,11 +578,11 @@ You must register the same PSK and PSK identity on the server side. TCP server ========== -.. |global_private_address| replace:: the nRF9160 DK must have a global private address. - The radio network must be configured to route incoming IP packets to the nRF9160 DK. +.. |global_private_address| replace:: the nRF91 Series DK must have a global private address. + The radio network must be configured to route incoming IP packets to the nRF91 Series DK. .. |global_private_address_check| replace:: To check if the setup is correct, use the ``AT+CGDCONT?`` command to check if the local IP address allocated by the network is a reserved private address of class A, B, or C (see `Private addresses`_). - If it is not, ping your nRF9160 DK from the destination server. + If it is not, ping your nRF91 Series DK from the destination server. To act as a TCP server, |global_private_address| @@ -911,7 +911,7 @@ To act as a UDP server, |global_private_address| OK Note that you will get an error message if a UDP packet is lost. - For example, this error indicates that a packet is lost in the downlink to the nRF9160 DK: + For example, this error indicates that a packet is lost in the downlink to the nRF91 Series DK: .. parsed-literal:: :class: highlight diff --git a/doc/nrf/libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst b/doc/nrf/libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst index c172c79d182d..df08a6c210b1 100644 --- a/doc/nrf/libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst +++ b/doc/nrf/libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.rst @@ -91,10 +91,10 @@ If the modem buffer is full, the modem drops modem traces until the buffer has s .. modem_lib_sending_traces_UART_start -Sending traces over UART on the nRF9160 DK -========================================== +Sending traces over UART on an nRF91 Series DK +============================================== -To send modem traces over UART on the nRF9160 DK, configuration must be added for the UART device in the devicetree and Kconfig. +To send modem traces over UART on an nRF91 Series DK, configuration must be added for the UART device in the devicetree and Kconfig. This is done by adding the :ref:`modem trace UART snippet ` when building and programming. .. modem_lib_sending_traces_UART_end diff --git a/doc/nrf/links.txt b/doc/nrf/links.txt index 9513a3f2c354..e8d459e7c93e 100644 --- a/doc/nrf/links.txt +++ b/doc/nrf/links.txt @@ -388,6 +388,8 @@ .. _`nRF9160 Certifications`: https://www.nordicsemi.com/Products/Low-power-Cellular-IoT/nRF9160-Certifications .. _`Energy efficiency`: https://www.nordicsemi.com/Products/Low-power-cellular-IoT/What-is-cellular-IoT#energy_efficiency +.. _`nRF9161 Objective Product Specification`: https://www.nordicsemi.com/-/media/Software-and-other-downloads/SiP/nRF91x1-SiP/nRF9161_OPS_v0.7.pdf + .. _`nRF52840 DK Downloads`: https://www.nordicsemi.com/Products/Development-hardware/nRF52840-DK/Download#infotabs .. _`nRF52840 DK product page`: https://www.nordicsemi.com/Products/Development-hardware/nRF52840-DK/ diff --git a/doc/nrf/releases_and_maturity/known_issues.rst b/doc/nrf/releases_and_maturity/known_issues.rst index 3411144e14c4..999b67971323 100644 --- a/doc/nrf/releases_and_maturity/known_issues.rst +++ b/doc/nrf/releases_and_maturity/known_issues.rst @@ -1173,8 +1173,8 @@ Applications The issues in this section are related to :ref:`applications`. -nRF9160: Asset Tracker v2 -========================= +Asset Tracker v2 +================ The issues in this section are related to the :ref:`asset_tracker_v2` application. @@ -1302,8 +1302,8 @@ IRIS-2676: Missing support for FOTA on nRF Cloud * 156d4cf3a568869adca445d43a786d819ae10250 * f520159f0415f011ae66efb816384a8f7bade83d -nRF9160: Serial LTE Modem -========================= +Serial LTE Modem +================ The issues in this section are related to the :ref:`serial_lte_modem` application. diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst b/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst index b3927116d743..13bb8bdd1b11 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst @@ -171,8 +171,10 @@ Applications This section provides detailed lists of changes by :ref:`application `. -nRF9160: Asset Tracker v2 -------------------------- +Asset Tracker v2 +---------------- + +* Added support for the nRF9161 development kit. * Updated: @@ -183,11 +185,12 @@ nRF9160: Asset Tracker v2 * Possibility for the cloud integration to request the location back to the device for Wi-Fi or cellular positioning. * Fixed an issue with movement timeout handling in passive mode. -nRF9160: Serial LTE modem -------------------------- +Serial LTE modem +---------------- * Added: + * Support for the nRF9161 development kit. * ``#XMODEMRESET`` AT command to reset the modem while keeping the application running. It is expected to be used during modem firmware update, which now only requires a reset of the modem. * DTLS connection identifier support to the ``#XSSOCKETOPT`` and ``#XUDPCLI`` AT commands. diff --git a/samples/cellular/https_client/README.rst b/samples/cellular/https_client/README.rst index 35d6c31b8de7..3f91f9ef5e27 100644 --- a/samples/cellular/https_client/README.rst +++ b/samples/cellular/https_client/README.rst @@ -13,7 +13,7 @@ It shows how to set up a TLS session towards an HTTPS server and how to send an Requirements ************ -The sample supports the following development kit: +The sample supports the following development kits: .. table-from-sample-yaml:: @@ -78,7 +78,7 @@ Testing After programming the sample to your development kit, test it by performing the following steps: -1. Connect the USB cable and power on or reset your nRF9160 DK. +1. Connect the USB cable and power on or reset your DK. #. Open a terminal emulator and observe that the sample starts, provisions certificates, connects to the LTE network and to example.com, and then sends an HTTP HEAD request. #. Observe that the HTTP HEAD request returns ``HTTP/1.1 200 OK``. diff --git a/samples/cellular/modem_shell/README.rst b/samples/cellular/modem_shell/README.rst index 0c3833e86c9b..ccbd81fbf72b 100644 --- a/samples/cellular/modem_shell/README.rst +++ b/samples/cellular/modem_shell/README.rst @@ -467,10 +467,10 @@ You can use the modem trace commands to control the trace functionality in the m See :ref:`modem_trace_module` for more information on how to configure modem tracing and the built-in trace backends available. You need a trace backend that can store modem traces if you want to upload modem traces to the cloud. -The flash backend can store modem traces to the external flash on the nRF9160 DK and can be retrieved for uploading. +The flash backend can store modem traces to the external flash on the nRF91 Series DK and can be retrieved for uploading. To enable modem traces with a flash backend, use the :file:`overlay-modem-trace-flash.conf` configuration file. -This also requires a device tree overlay for the external flash (:file:`nrf9160dk_ext_flash.overlay`). +This also requires a devicetree overlay for the external flash (:file:`nrf9160dk_ext_flash.overlay` for the nRF9160 DK or :file:`nrf9161dk_ext_flash.overlay` for the nRF9161 DK, depending on the DK you are using). Send to Memfault ---------------- @@ -502,7 +502,7 @@ See the following figure, which shows how to download the modem trace data in th .. note:: The conversion of modem trace file to a Wireshark-compatible format is available in the Cellular Monitor tool of the nRF Connect for Desktop. -To build the MoSh sample with the nRF9160 DK and modem traces with a flash backend, see :ref:`modem_shell_trace_support`. +To build the MoSh sample with the nRF91 Series DK and modem traces with a flash backend, see :ref:`modem_shell_trace_support`. Examples -------- @@ -940,9 +940,9 @@ LED indications The LEDs have the following functions: -LED 1 (nRF9160 DK)/Purple LED (Thingy:91): +LED 1 (nRF91 Series DKs)/Purple LED (Thingy:91): Lit for five seconds when the current location has been successfully retrieved by using the ``location get`` command. -LED 3 (nRF9160 DK)/Blue LED (Thingy:91): +LED 3 (nRF91 Series DKs)/Blue LED (Thingy:91): Indicates the LTE registration status. Power measurements @@ -997,19 +997,30 @@ After programming the application and all prerequisites to your development kit, #. Type any of the commands listed in the Overview section to the terminal. When you type only the command, the terminal shows the usage, for example ``sock``. -Getting nRF9160 DK out-of-the-box and to nRF Cloud -================================================== +Getting nRF91 Series DK out-of-the-box and to nRF Cloud +======================================================= To program the certificates and connect to nRF Cloud, complete the following steps: 1. `Download nRF Connect for Desktop`_. -#. Update the modem firmware on the on-board modem of the nRF9160 DK to the latest version as instructed in :ref:`nrf9160_gs_updating_fw_modem`. -#. Build and program the MoSh to the nRF9160 DK using the default MoSh configuration (with REST as the transport): +#. Update the modem firmware on the on-board modem of an nRF91 Series DK to the latest version as instructed in :ref:`nrf9160_gs_updating_fw_modem`. +#. Build and program the MoSh to your nRF91 Series DK using the default MoSh configuration (with REST as the transport): - .. code-block:: console + .. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + $ west build -p -b nrf9161dk_nrf9161_ns -d build + $ west flash -d build + + .. group-tab:: nRF9160 DK + + .. code-block:: console - $ west build -p -b nrf9160dk_nrf9160_ns -d build - $ west flash -d build + $ west build -p -b nrf9160dk_nrf9160_ns -d build + $ west flash -d build #. Get certificates from nRF Cloud as explained in :ref:`downloading_cloud_certificate`. #. In the MoSH terminal, power off the modem and start the AT command mode: @@ -1098,9 +1109,19 @@ PPP support To build the MoSh sample with PPP/dial up support, use the ``-DDTC_OVERLAY_FILE=ppp.overlay`` and ``-DOVERLAY_CONFIG=overlay-ppp.conf`` options. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -- -DDTC_OVERLAY_FILE=ppp.overlay -DOVERLAY_CONFIG=overlay-ppp.conf + + .. group-tab:: nRF9160 DK + + .. code-block:: console - west build -p -b nrf9160dk_nrf9160_ns -- -DDTC_OVERLAY_FILE=ppp.overlay -DOVERLAY_CONFIG=overlay-ppp.conf + west build -p -b nrf9160dk_nrf9160_ns -- -DDTC_OVERLAY_FILE=ppp.overlay -DOVERLAY_CONFIG=overlay-ppp.conf After programming the development kit, test it in the Linux environment by performing the following steps: @@ -1123,7 +1144,7 @@ After programming the development kit, test it in the Linux environment by perfo mosh:~$ Higher baudrates than the default 115200 result in better performance with the usual use cases for PPP/dial up. - Set the nRF9160 DK side UART for PPP with a MoSh command, for example ``ppp uartconf -b 921600``. + Set the nRF91 Series DK side UART for PPP with a MoSh command, for example ``ppp uartconf -b 921600``. You also need to set the corresponding UART accordingly from PC side (in this example, within the ``pppd`` command). #. Enter command ``ppp uartconf`` that results in the following UART configuration: @@ -1161,9 +1182,20 @@ Application FOTA support To build the MoSh sample with application FOTA support, use the ``-DOVERLAY_CONFIG=overlay-app_fota.conf`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG=overlay-app_fota.conf + + + .. group-tab:: nRF9160 DK - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-app_fota.conf + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-app_fota.conf LwM2M carrier library support ============================= @@ -1171,9 +1203,19 @@ LwM2M carrier library support To build the MoSh sample with LwM2M carrier library support, use the ``-DOVERLAY_CONFIG=overlay-carrier.conf`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG=overlay-carrier.conf - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-carrier.conf + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-carrier.conf P-GPS support ============= @@ -1181,9 +1223,19 @@ P-GPS support To build the MoSh sample with P-GPS support, use the ``-DOVERLAY_CONFIG=overlay-pgps.conf`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG=overlay-pgps.conf - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-pgps.conf + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-pgps.conf .. _cloud_build: @@ -1193,9 +1245,19 @@ Cloud over MQTT To build the MoSh sample with cloud connectivity over MQTT, use the ``-DOVERLAY_CONFIG=overlay-cloud_mqtt.conf`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_mqtt.conf + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_mqtt.conf + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_mqtt.conf Cloud over CoAP =============== @@ -1203,9 +1265,19 @@ Cloud over CoAP To build the MoSh sample with cloud connectivity over CoAP, use the ``-DOVERLAY_CONFIG=overlay-cloud_coap.conf`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_coap.conf + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_coap.conf + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG=overlay-cloud_coap.conf Location service handled in application ======================================= @@ -1215,33 +1287,62 @@ To build the sample with location cloud services handled in the MoSh, use the ``-DOVERLAY_CONFIG="overlay-cloud_mqtt.conf"`` and ``-DCONFIG_LOCATION_SERVICE_EXTERNAL=y`` options. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y To add P-GPS on top of that, use the ``-DOVERLAY_CONFIG="overlay-cloud_mqtt.conf;overlay-pgps.conf"``, ``-DCONFIG_LOCATION_SERVICE_EXTERNAL=y`` and ``-DCONFIG_NRF_CLOUD_PGPS_TRANSPORT_NONE=y`` options. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK - west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf;overlay-pgps.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y -DCONFIG_NRF_CLOUD_PGPS_TRANSPORT_NONE=y + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf;overlay-pgps.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y -DCONFIG_NRF_CLOUD_PGPS_TRANSPORT_NONE=y + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -d build -- -DOVERLAY_CONFIG="overlay-cloud_mqtt.conf;overlay-pgps.conf" -DCONFIG_LOCATION_SERVICE_EXTERNAL=y -DCONFIG_NRF_CLOUD_PGPS_TRANSPORT_NONE=y Remote control using nRF Cloud over MQTT ======================================== To enable the remote control feature, you need to build the sample with cloud connectivity, see :ref:`cloud_build`. -Zephyr native TCP/IP stack usage over nRF9160 LTE connection -============================================================ +Zephyr native TCP/IP stack usage over nRF91 Series DK LTE connection +==================================================================== To build the MoSh sample with the nRF91 device driver that is not offloading the TCP/IP stack to modem, use the ``-DOVERLAY_CONFIG=overlay-non-offloading.conf`` option. -When running this configuration, the configured MoSh commands, for example iperf3, are using Zephyr native TCP/IP stack over nRF9160 LTE connection in default PDN context. - +When running this configuration, the configured MoSh commands, for example iperf3, are using Zephyr native TCP/IP stack over nRF91 Series DK LTE connection in default PDN context. For example: -.. code-block:: console +.. tabs:: - west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-non-offloading.conf + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -- -DOVERLAY_CONFIG=overlay-non-offloading.conf + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-non-offloading.conf BT shell support ================ @@ -1304,17 +1405,29 @@ DK #2, where MoSh is used in observer (scanning) role: Scan successfully stopped mosh:~$ +.. note:: + The MoSh sample with Zephyr BT shell command is not supported by the nRF9161 DK. + SEGGER RTT support ================== To build the MoSh sample with SEGGER's Real Time Transfer (RTT) support, use the ``-DOVERLAY_CONFIG=overlay-rtt.conf`` option. When running this configuration, RTT is used as the shell backend instead of UART. - For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console - west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-rtt.conf + west build -p -b nrf9161dk_nrf9161_ns -- -DOVERLAY_CONFIG=overlay-rtt.conf + + .. group-tab:: nRF9160 DK + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-rtt.conf LwM2M support ============= @@ -1336,15 +1449,33 @@ You can build the MoSh sample with different LwM2M configurations: To build the sample with LwM2M support, use the following command: -.. code-block:: console +.. tabs:: - west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-lwm2m.conf -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" + .. group-tab:: nRF9161 DK -To also enable P-GPS, use the following command: + .. code-block:: console -.. code-block:: console + west build -p -b nrf9161dk_nrf9161_ns -- -DOVERLAY_CONFIG=overlay-lwm2m.conf -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" + + + To also enable P-GPS, use the following command: + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG="overlay-lwm2m.conf;overlay-lwm2m_pgps.conf;overlay-pgps.conf" -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" + + + .. group-tab:: nRF9160 DK - west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG="overlay-lwm2m.conf;overlay-lwm2m_pgps.conf;overlay-pgps.conf" -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG=overlay-lwm2m.conf -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" + + To also enable P-GPS, use the following command: + + .. code-block:: console + + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG="overlay-lwm2m.conf;overlay-lwm2m_pgps.conf;overlay-pgps.conf" -DCONFIG_MOSH_LWM2M_PSK=\"000102030405060708090a0b0c0d0e0f\" Use the following command to establish connection to the LwM2M server: @@ -1366,16 +1497,26 @@ When connected, the ``location`` and ``gnss`` commands use the LwM2M cloud conne .. _modem_shell_trace_support: -nRF9160 DK and modem trace support -================================== +nRF91 Series DK and modem trace support +======================================= -To build the MoSh sample with nRF9160 DK and modem traces with flash backend, use the ``-DDTC_OVERLAY_FILE=nrf9160dk_ext_flash.overlay`` and ``-DOVERLAY_CONFIG="overlay-modem-trace-flash.conf;overlay-memfault.conf"`` options. +To build the MoSh sample with an nRF91 Series DK and modem traces with flash backend, use the devicetree overlay for external flash corresponding to your device and the ``-DOVERLAY_CONFIG="overlay-modem-trace-flash.conf;overlay-memfault.conf"`` option. For example: -.. code-block:: console +.. tabs:: + + .. group-tab:: nRF9161 DK + + .. code-block:: console + + west build -p -b nrf9161dk_nrf9161_ns -- -DOVERLAY_CONFIG="overlay-modem-trace-flash.conf;overlay-memfault.conf" -DDTC_OVERLAY_FILE=nrf9161dk_ext_flash.overlay + + .. group-tab:: nRF9160 DK + + .. code-block:: console - west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG="overlay-modem-trace-flash.conf;overlay-memfault.conf" -DDTC_OVERLAY_FILE=nrf9160dk_ext_flash.overlay + west build -p -b nrf9160dk_nrf9160_ns -- -DOVERLAY_CONFIG="overlay-modem-trace-flash.conf;overlay-memfault.conf" -DDTC_OVERLAY_FILE=nrf9160dk_ext_flash.overlay References ********** diff --git a/samples/debug/memfault/README.rst b/samples/debug/memfault/README.rst index f7331cca8c88..4cb604311812 100644 --- a/samples/debug/memfault/README.rst +++ b/samples/debug/memfault/README.rst @@ -8,7 +8,7 @@ Memfault :depth: 2 The Memfault sample shows how to use the `Memfault SDK`_ in an |NCS| application to collect coredumps and metrics. -The sample connects to an LTE network using the nRF9160 DK or Thingy:91, or to Wi-Fi using the nRF7002 DK, and sends the collected data to Memfault's cloud using HTTPS. +The sample connects to an LTE network using an nRF91 Series DK or Thingy:91, or to Wi-Fi using the nRF7002 DK, and sends the collected data to Memfault's cloud using HTTPS. To get started with Memfault integration in |NCS|, see :ref:`ug_memfault`. @@ -52,7 +52,6 @@ This metric is defined in :file:`samples/debug/memfault/config/memfault_metrics_ * ``Switch1ToggleCount`` - The number of times **Switch 1** has been toggled on an nRF9160 DK. - Error Tracking with trace events ================================ @@ -61,7 +60,6 @@ The trace reason is called ``Switch2Toggled``, and is collected every time **Swi In addition to detection of the event, the trace includes the current switch state. See `Memfault: Error Tracking with Trace Events`_ for information on how to configure and use trace events. - Coredumps ========= @@ -122,7 +120,7 @@ Check and configure the following options in Memfault SDK that are used by the s * :kconfig:option:`CONFIG_MEMFAULT_HTTP_PERIODIC_UPLOAD_USE_DEDICATED_WORKQUEUE` * :kconfig:option:`CONFIG_MEMFAULT_COREDUMP_COLLECT_BSS_REGIONS` -If :kconfig:option:`CONFIG_MEMFAULT_ROOT_CERT_STORAGE_NRF9160_MODEM` is enabled, TLS certificates used for HTTP uploads are provisioned to the nRF9160 modem when :c:func:`memfault_zephyr_port_install_root_certs` is called. +If :kconfig:option:`CONFIG_MEMFAULT_ROOT_CERT_STORAGE_NRF9160_MODEM` is enabled, TLS certificates used for HTTP uploads are provisioned to the cellular modem when :c:func:`memfault_zephyr_port_install_root_certs` is called. Check and configure the following options for Memfault that are specific to |NCS|: diff --git a/samples/net/aws_iot/README.rst b/samples/net/aws_iot/README.rst index 15da389f50c1..ab369b82461f 100644 --- a/samples/net/aws_iot/README.rst +++ b/samples/net/aws_iot/README.rst @@ -89,7 +89,7 @@ The corresponding options that must be set for each of these values are: * :kconfig:option:`CONFIG_AWS_IOT_SEC_TAG` * :kconfig:option:`CONFIG_AWS_IOT_CLIENT_ID_STATIC` -Set these options in the project configuration file located at :file:`samples/nrf9160/aws_iot/prj.conf`. +Set these options in the project configuration file located at :file:`samples/net/aws_iot/prj.conf`. For documentation related to FOTA DFU, see :ref:`lib_aws_fota`. .. note:: @@ -105,7 +105,7 @@ General options --------------- The following lists the application-specific configurations used in the sample. -They are located in :file:`samples/nrf9160/aws_iot/Kconfig`. +They are located in :file:`samples/net/aws_iot/Kconfig`. .. _CONFIG_AWS_IOT_SAMPLE_APP_VERSION: