fix: update from upstream

See https://github.com/nrfconnect/sdk-nrf/tree/46023f9cd9c4d5e3e2e2c81ed96cb88555740c08/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:
 

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:

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 <nrf9160_gs_connecting_dk_to_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 <nrf9160_gs_connecting_dk_to_cloud>`.
   See :ref:`Building and running <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/<BOARD>/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.

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 <nRF Cloud Location Services documentation_>`_.
@@ -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 <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

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:
 

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:
 

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.

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              |
 +---------------------------+------------------------------+----------------------------+

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 <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 <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 <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 <watchdog_api>` with the system workqueue constantly at a time interval that equals half of the value specified by :ref:`CONFIG_WATCHDOG_APPLICATION_TIMEOUT_SEC <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.

src/cloud/cloud_codec/aws_iot/aws_iot_codec.c

@@ -62,7 +62,7 @@ int cloud_codec_encode_cloud_location(
 	struct cloud_codec_data *output,
 	struct cloud_data_cloud_location *cloud_location)
 {
-	int err;
+	int err = -ENODATA;
 	char *buffer;
 
 	__ASSERT_NO_MSG(output != NULL);

src/cloud/cloud_codec/azure_iot_hub/azure_iot_hub_codec.c

@@ -33,7 +33,7 @@ int cloud_codec_encode_cloud_location(
 	struct cloud_codec_data *output,
 	struct cloud_data_cloud_location *cloud_location)
 {
-	int err;
+	int err = -ENODATA;
 	char *buffer;
 
 	__ASSERT_NO_MSG(output != NULL);