diff --git a/.github/workflows/oss-history.yml b/.github/workflows/oss-history.yml index 1e7b18e5f41c..ee730c491068 100644 --- a/.github/workflows/oss-history.yml +++ b/.github/workflows/oss-history.yml @@ -14,7 +14,7 @@ jobs: - name: Install extra python dependencies run: | - pip3 install west + pip3 install --upgrade pip setuptools west pip3 install -r ncs/nrf/scripts/requirements-extra.txt - name: Set upsteam diff --git a/.github/workflows/validate-pip-requirements-fixed-file.yml b/.github/workflows/validate-pip-requirements-fixed-file.yml index cd6c02bd4a5d..97766189c414 100644 --- a/.github/workflows/validate-pip-requirements-fixed-file.yml +++ b/.github/workflows/validate-pip-requirements-fixed-file.yml @@ -60,7 +60,9 @@ jobs: mkvirtualenv pip-fixed-venv > /dev/null 2>&1 || true workon pip-fixed-venv > /dev/null 2>&1 - pip3 install pip-compile-cross-platform==1.4.2 --upgrade > /dev/null 2>&1 + pip3 install \ + --extra-index-url https://files.nordicsemi.com/artifactory/api/pypi/nordic-pypi/simple \ + pip-compile-cross-platform==1.4.2+nordic --upgrade > /dev/null 2>&1 pip-compile-cross-platform \ bootloader/mcuboot/scripts/requirements.txt \ nrf/scripts/requirements-ci.txt \ diff --git a/.github/workflows/west-commands.yml b/.github/workflows/west-commands.yml index 485a7deb8680..74f8bf38641e 100644 --- a/.github/workflows/west-commands.yml +++ b/.github/workflows/west-commands.yml @@ -49,6 +49,7 @@ jobs: - name: Install requirements shell: bash run: | + python3 -m pip install -U pip pip3 install -r nrf/scripts/requirements-west-ncs-sbom.txt pip3 install -r nrf/scripts/requirements-extra.txt - name: Test ncs-sbom with asset tracker sample diff --git a/CODEOWNERS b/CODEOWNERS index ad0feff96b4d..e01ffb8b1b48 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -98,6 +98,8 @@ /doc/nrf/drivers/sensor_sim.rst @nrfconnect/ncs-si-muffin-doc /doc/nrf/drivers/sensor_stub.rst @nrfconnect/ncs-si-muffin-doc /doc/nrf/drivers/uart_ipc.rst @nrfconnect/ncs-doc-leads +/doc/nrf/drivers/wifi/ @sachinthegreen @krish2718 +/doc/nrf/drivers/wifi.rst @nrfconnect/ncs-wifi-doc /doc/nrf/drivers/uart_nrf_sw_lpuart.rst @nrfconnect/ncs-doc-leads /doc/nrf/external_comp/avsystem.rst @nrfconnect/ncs-iot-oulu-tampere-doc /doc/nrf/external_comp/bt_fast_pair.rst @nrfconnect/ncs-si-bluebagel-doc @@ -266,6 +268,7 @@ /doc/nrf/templates/ @nrfconnect/ncs-doc-leads /doc/nrf/test_and_optimize/ @nrfconnect/ncs-doc-leads /doc/nrf/test_and_optimize/optimizing/power_nrf91.rst @nrfconnect/ncs-cia-doc +/doc/wifi/ @sachinthegreen @krish2718 /doc/**/*.svg @nrfconnect/ncs-doc-leads /doc/**/*.png @nrfconnect/ncs-doc-leads @@ -400,7 +403,7 @@ /samples/app_event_manager/ @nrfconnect/ncs-si-muffin @nrfconnect/ncs-si-bluebagel /samples/app_event_manager_profiler_tracer/ @nrfconnect/ncs-si-muffin @nrfconnect/ncs-si-bluebagel /samples/benchmarks/coremark/ @nrfconnect/ncs-si-bluebagel -/samples/bluetooth/broadcast_config_tool/ @nrfconnect/ncs-audio +/samples/bluetooth/nrf_auraconfig/ @nrfconnect/ncs-audio /samples/bluetooth/central_and_peripheral_hr/ @nrfconnect/ncs-si-muffin /samples/bluetooth/central_bas/ @nrfconnect/ncs-si-muffin /samples/bluetooth/central_hids/ @nrfconnect/ncs-si-bluebagel @@ -514,13 +517,14 @@ /samples/wifi/softap/ @D-Triveni @krish2718 /samples/wifi/monitor/ @D-Triveni /samples/wifi/promiscuous/ @D-Triveni +/samples/wifi/offloaded_raw_tx/ @kapbh @sachinthegreen /samples/zigbee/ @nrfconnect/ncs-zigbee /samples/app_event_manager/*.rst @nrfconnect/ncs-si-muffin-doc @nrfconnect/ncs-si-bluebagel-doc /samples/app_event_manager_profiler_tracer/*.rst @nrfconnect/ncs-si-muffin-doc /samples/benchmarks/coremark/*.rst @nrfconnect/ncs-si-bluebagel-doc /samples/bluetooth/**/*.rst @nrfconnect/ncs-dragoon-doc @nrfconnect/ncs-si-muffin-doc -/samples/bluetooth/broadcast_config_tool/*.rst @nrfconnect/ncs-audio-doc +/samples/bluetooth/nrf_auraconfig/*.rst @nrfconnect/ncs-audio-doc /samples/bluetooth/fast_pair/**/*.rst @nrfconnect/ncs-si-bluebagel-doc /samples/bluetooth/mesh/**/*.rst @nrfconnect/ncs-paladin-doc /samples/bootloader/*.rst @nrfconnect/ncs-pluto-doc @@ -593,12 +597,14 @@ /scripts/west_commands/genboard/ @gmarull /scripts/west_commands/sbom/ @nrfconnect/ncs-si-muffin /scripts/west_commands/thingy91x_dfu.py @nrfconnect/ncs-cia +/scripts/west_commands/ncs-provision.py @nrfconnect/ncs-pluto /scripts/bootloader/ @nrfconnect/ncs-pluto /scripts/ncs-docker-version.txt @nrfconnect/ncs-ci /scripts/print_docker_image.sh @nrfconnect/ncs-ci /scripts/print_toolchain_checksum.sh @nrfconnect/ncs-ci /scripts/sdp/ @nrfconnect/ncs-ll-ursus +/scripts/docker/*.rst @nrfconnect/ncs-doc-leads /scripts/hid_configurator/*.rst @nrfconnect/ncs-si-bluebagel-doc /scripts/memfault/*.rst @nrfconnect/ncs-cia-doc /scripts/nrf_provision/fast_pair/*.rst @nrfconnect/ncs-si-bluebagel-doc @@ -611,7 +617,7 @@ # Snippets /snippets/ci-shell/ @nrfconnect/ncs-protocols-serialization -/snippets/emulated*/ @nrfconnect/ncs-ll-ursus +/snippets/sdp/ @nrfconnect/ncs-ll-ursus /snippets/hw-flow-control/ @nrfconnect/ncs-low-level-test @miha-nordic /snippets/matter-diagnostic-logs/ @nrfconnect/ncs-matter /snippets/nordic-bt-rpc/ @ppryga-nordic @@ -708,6 +714,7 @@ /tests/bluetooth/tester/ @carlescufi @nrfconnect/ncs-paladin /tests/crypto/ @stephen-nordic @magnev /tests/drivers/gpio/egpio_basic_api/ @nrfconnect/ncs-ll-ursus +/tests/drivers/gpio/gpio_more_loops/ @nrfconnect/ncs-low-level-test /tests/drivers/flash/flash_rpc/ @nrfconnect/ncs-pluto /tests/drivers/flash_patch/ @nrfconnect/ncs-pluto /tests/drivers/fprotect/ @nrfconnect/ncs-pluto @@ -763,6 +770,7 @@ /tests/subsys/emds/ @balaklaka @nrfconnect/ncs-paladin /tests/subsys/event_manager_proxy/ @nrfconnect/ncs-si-muffin /tests/subsys/fw_info/ @nrfconnect/ncs-pluto +/tests/subsys/kmu/ @nrfconnect/ncs-pluto /tests/subsys/mpsl/ @nrfconnect/ncs-dragoon /tests/subsys/net/lib/aws_*/ @nrfconnect/ncs-cia /tests/subsys/net/lib/azure_iot_hub/ @nrfconnect/ncs-cia diff --git a/Jenkinsfile b/Jenkinsfile index cb83d266db04..7f33f08c2069 100644 --- a/Jenkinsfile +++ b/Jenkinsfile @@ -1,4 +1,4 @@ -@Library("CI_LIB") _ +@Library("CI_LIB@v2.8-branch") _ def pipeline = new ncs.sdk_nrf.Main() diff --git a/applications/asset_tracker_v2/Kconfig.sysbuild b/applications/asset_tracker_v2/Kconfig.sysbuild index 39426561f59b..458e26593c62 100644 --- a/applications/asset_tracker_v2/Kconfig.sysbuild +++ b/applications/asset_tracker_v2/Kconfig.sysbuild @@ -16,6 +16,10 @@ config SECURE_BOOT_APPCORE config WIFI_NRF70 default y if BOARD_THINGY91X_NRF9151_NS +choice WIFI_NRF70_OPER_MODES + default WIFI_NRF70_SCAN_ONLY if BOARD_THINGY91X_NRF9151_NS +endchoice + config PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY default y if BOARD_NRF9151DK_NRF9151_NS || BOARD_NRF9161DK_NRF9161_NS default y if BOARD_NRF9160DK_NRF9160_NS \ diff --git a/applications/asset_tracker_v2/overlay-memfault.conf b/applications/asset_tracker_v2/overlay-memfault.conf index 5d29bc52c6ef..961e725de2f4 100644 --- a/applications/asset_tracker_v2/overlay-memfault.conf +++ b/applications/asset_tracker_v2/overlay-memfault.conf @@ -29,3 +29,6 @@ CONFIG_DEBUG_MODULE=y # Increase the event storage size so that all metrics generated by the asset tracker application # are reliably sent to the memfault cloud. CONFIG_MEMFAULT_EVENT_STORAGE_SIZE=2048 + +# Memfault depends on POSIX, disable unneeded POSIX features +CONFIG_POSIX_FILE_SYSTEM=n diff --git a/applications/connectivity_bridge/prj.conf b/applications/connectivity_bridge/prj.conf index 239733fa0ba5..bef0d620ddef 100644 --- a/applications/connectivity_bridge/prj.conf +++ b/applications/connectivity_bridge/prj.conf @@ -57,7 +57,6 @@ CONFIG_BRIDGE_LOG_POWER_DOWN_EVENT=n # UART CONFIG_SERIAL=y -CONFIG_UART_NRFX_UARTE_LEGACY_SHIM=n CONFIG_UART_INTERRUPT_DRIVEN=y CONFIG_UART_0_INTERRUPT_DRIVEN=n CONFIG_UART_1_INTERRUPT_DRIVEN=n diff --git a/applications/connectivity_bridge/src/modules/Kconfig b/applications/connectivity_bridge/src/modules/Kconfig index c4075c277115..171c29a3eb1f 100644 --- a/applications/connectivity_bridge/src/modules/Kconfig +++ b/applications/connectivity_bridge/src/modules/Kconfig @@ -98,6 +98,7 @@ config BRIDGE_BUF_SIZE config BRIDGE_UART_BUF_COUNT int "UART buffer block count" + default 16 if BOARD_THINGY91X_NRF5340_CPUAPP default 3 range 3 255 help diff --git a/applications/machine_learning/Kconfig.sysbuild b/applications/machine_learning/Kconfig.sysbuild index e1e697dec790..29012163e19e 100644 --- a/applications/machine_learning/Kconfig.sysbuild +++ b/applications/machine_learning/Kconfig.sysbuild @@ -26,7 +26,7 @@ config PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY config ML_APP_INCLUDE_REMOTE_IMAGE bool "Include remote image build" - depends on SOC_NRF54H20_CPUAPP + depends on SOC_NRF54H20_CPUAPP || SOC_NRF54H20_ENGB_CPUAPP config ML_APP_REMOTE_BOARD string "The name of the board to be used by remote image" diff --git a/applications/machine_learning/app_desc.rst b/applications/machine_learning/app_desc.rst index 30512b2bda96..e3b87672e3a9 100644 --- a/applications/machine_learning/app_desc.rst +++ b/applications/machine_learning/app_desc.rst @@ -34,6 +34,9 @@ By default, the following sensors are used by the application: * nRF5340 DK - Simulated sensor (:ref:`sensor_sim`). The simulated sensor generates predefined waves as acceleration. This development kit does not have a built-in accelerometer. +* nRF54L15 DK - Simulated sensor (:ref:`sensor_sim`). + The simulated sensor generates predefined waves as acceleration. + This development kit does not have a built-in accelerometer. * nRF54H20 DK - The development kit does not have a built-in accelerometer. However, it supports the following configurations: @@ -52,6 +55,7 @@ By default, the following transports are used: * Thingy:53 uses :ref:`nus_service_readme`. * The nRF52840 DK uses :ref:`zephyr:uart_api`. * The nRF5340 DK uses :ref:`zephyr:uart_api`. +* The nRF54L15 DK uses :ref:`zephyr:uart_api`. * The nRF54H20 DK uses :ref:`nus_service_readme`. Machine learning model @@ -72,7 +76,7 @@ By default, the application uses pre-trained machine learning models deployed in * ``tap`` - The device is tapped while placed on a flat surface. Unknown gestures, such as shaking the device, are recognized as anomalies. -* Both the nRF52840 DK and the nRF5340 DK use the `nRF Connect SDK simulated sensor machine learning model`_. +* The nRF52840, nRF5340 and nRF54L15 DKs use the `nRF Connect SDK simulated sensor machine learning model`_. The model uses simulated sensor data to recognize the following simulated wave types: * ``sine`` @@ -232,6 +236,11 @@ By default, the following buttons are used by the application: * **Button 1** switches between data forwarding and running a machine learning model. * **Button 3** changes the signal generated by the simulated sensor. + .. group-tab:: nRF54L15 DK + + * **Button 0** switches between data forwarding and running a machine learning model. + * **Button 2** changes the signal generated by the simulated sensor. + .. group-tab:: nRF54H20 DK **Button 0** button switches between data forwarding and running the machine learning model. @@ -266,30 +275,51 @@ By default, the application uses the following LED effects: The LED effect is overridden on the next successful detection. * If the device forwards data, the LED color turns red and uses the following blinking patterns: - * LED blinks slowly if it is not connected. - * LED blinks with an average frequency if it is connected but is not actively forwarding data. - * LED blinks rapidly if it is connected and is actively forwarding data. + * Blinks slowly if it is not connected. + * Blinks with an average frequency if it is connected but is not actively forwarding data. + * Blinks rapidly if it is connected and is actively forwarding data. .. group-tab:: nRF52840 and nRF5340 DKs Both nRF5340 DK and nRF52840 DK use monochromatic LEDs to display the application state. - The **LED1** displays the application state, and the **LED2** displays the signal generated by the simulated sensor. + The **LED1** displays the application state and the **LED2** displays the signal generated by the simulated sensor. * If the device is returning the machine learning prediction results, the **LED1** blinks for a predefined number of times and then turns off for a period of time. Then the sequence is repeated. The machine learning result is represented by the number of blinks: - * ``sine`` - 1 blink - * ``triangle`` - 2 blinks - * ``square`` - 3 blinks - * ``idle`` - 4 blinks + * ``sine`` - one blink + * ``triangle`` - two blinks + * ``square`` - three blinks + * ``idle`` - four blinks If the machine learning model is running but has not detected anything yet or has detected an anomaly, the **LED1** is breathing. * If the device forwards data, the **LED1** has the following blinking patterns: - * LED blinks slowly if it is not connected. - * LED blinks with an average frequency if it is connected but is not actively forwarding data. - * LED blinks rapidly if it is connected and is actively forwarding data. + * Blinks slowly if it is not connected. + * Blinks with an average frequency if it is connected but is not actively forwarding data. + * Blinks rapidly if it is connected and is actively forwarding data. + + .. group-tab:: nRF54L15 DK + + The nRF54L15 DK uses monochromatic LEDs to display the application state. + The **LED1** displays the application state and the **LED3** displays the signal generated by the simulated sensor. + + * If the device is returning the machine learning prediction results, the **LED1** blinks for a predefined number of times and then turns off for a period of time. + Then the sequence is repeated. + The machine learning result is represented by the number of blinks: + + * ``sine`` - one blink + * ``triangle`` - two blinks + * ``square`` - three blinks + * ``idle`` - four blinks + + If the machine learning model is running but has not detected anything yet or has detected an anomaly, the **LED1** is breathing. + * If the device forwards data, the **LED1** has the following blinking patterns: + + * Blinks slowly if it is not connected. + * Blinks with an average frequency if it is connected but is not actively forwarding data. + * Blinks rapidly if it is connected and is actively forwarding data. .. group-tab:: nRF54H20 DK nRF54H20 DK uses monochromatic LEDs to display the application state. @@ -306,9 +336,9 @@ By default, the application uses the following LED effects: If the machine learning model is running, but it has not detected anything yet or the ``idle`` state is detected, **LED0**, **LED1**, and **LED2**, keep blinking. * If the device forwards data, **LED0**, **LED1** and **LED2** has the following blinking patterns: - * LED blinks slowly if it is not connected. - * LED blinks with an average frequency if it is connected, but is not actively forwarding data. - * LED blinks rapidly if it is connected and is actively forwarding data. + * Blinks slowly if it is not connected. + * Blinks with an average frequency if it is connected, but is not actively forwarding data. + * Blinks rapidly if it is connected and is actively forwarding data. .. _nrf_machine_learning_app_configuration: @@ -525,14 +555,14 @@ After programming the application, perform the following steps to test the nRF M 1. Turn on the development kit. The application starts in a mode that runs the machine learning model. - Initially, **LED2** displays the LED effect representing ``sine`` wave (1 blink), and **LED1** is breathing, because the signal was not yet recognized by the machine learning model. + Initially, **LED2** displays the LED effect representing ``sine`` wave (one blink), and **LED1** is breathing, because the signal was not yet recognized by the machine learning model. After a brief delay, the machine learning model recognizes the simulated signal. **LED1** and **LED2** display the same LED effect. #. Press **Button 3** to change the generated acceleration signal. Right after the signal change, the effects displayed by LEDs are different. - After a brief delay, the machine learning model recognizes the ``triangle`` wave, and the same effect (2 blinks) is displayed by both LEDs. + After a brief delay, the machine learning model recognizes the ``triangle`` wave, and the same effect (two blinks) is displayed by both LEDs. #. Press **Button 3** to again change the generated acceleration signal. - The ``square`` wave (3 blinks) is displayed only by the **LED2**. + The ``square`` wave (three blinks) is displayed only by the **LED2**. This signal is marked as an anomaly by the machine learning model, and **LED1** starts breathing. #. Press and hold **Button 1** for more than five seconds to switch to the data forwarding mode. After the mode is switched, **LED1** starts to blink rapidly. @@ -545,6 +575,33 @@ After programming the application, perform the following steps to test the nRF M Optionally, you can also connect to the device using `Edge Impulse's data forwarder`_ and forward data to `Edge Impulse studio`_ (after logging in). See `Forwarding data to Edge Impulse studio`_ for details. +Testing with the nRF54L15 DK +--------------------------------------- + +After programming the application, perform the following steps to test the nRF Machine Learning application on the DK: + +1. Turn on the development kit. + The application starts in a mode that runs the machine learning model. + Initially, **LED3** displays the LED effect representing ``sine`` wave (one blink), and **LED1** is breathing, because the signal was not yet recognized by the machine learning model. + After a brief delay, the machine learning model recognizes the simulated signal. + **LED1** and **LED3** display the same LED effect. +#. Press **Button 2** to change the generated acceleration signal. + Right after the signal change, the effects displayed by LEDs are different. + After a brief delay, the machine learning model recognizes the ``triangle`` wave, and the same effect (two blinks) is displayed by both LEDs. +#. Press **Button 2** to again change the generated acceleration signal. + The ``square`` wave (three blinks) is displayed only by the **LED3**. + This signal is marked as an anomaly by the machine learning model, and **LED1** starts breathing. +#. Press and hold **Button 0** for more than five seconds to switch to the data forwarding mode. + After the mode is switched, **LED1** starts to blink rapidly. +#. Connect to the development kit with a terminal emulator (for example, `nRF Connect Serial Terminal`_). + See :ref:`test_and_optimize` for the required settings. +#. Observe the sensor readouts represented as comma-separated values. + Every line represents a single sensor readout. +#. Turn off the terminal emulator to ensure that only one program has access to the data on UART. + +Optionally, you can also connect to the device using `Edge Impulse's data forwarder`_ and forward data to `Edge Impulse studio`_ (after logging in). +See `Forwarding data to Edge Impulse studio`_ for details. + Testing with the nRF54H20 DK ----------------------------- diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/app.overlay b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/app.overlay new file mode 100644 index 000000000000..18fed076ad41 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/app.overlay @@ -0,0 +1,87 @@ +/ { + chosen { + ncs,ml-app-ei-data-forwarder-uart = &uart20; + zephyr,console = &uart30; + + }; + + sensor_sim: sensor-sim { + compatible = "nordic,sensor-sim"; + acc-signal = "wave"; + }; + + /* Redefine pwmleds to fit CAF requirements. */ + /delete-node/ pwmleds; + + pwmleds1 { + compatible = "pwm-leds"; + status = "okay"; + + pwm_led1: led_pwm_1 { + status = "okay"; + pwms = <&pwm20 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>; + label = "State LED"; + }; + }; + + pwmleds3 { + compatible = "pwm-leds"; + status = "okay"; + + pwm_led3: led_pwm_3 { + status = "okay"; + pwms = <&pwm21 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>; + label = "Simulated signal LED"; + }; + }; +}; + +&uart30 { + status = "okay"; +}; + +&uart20 { + status = "okay"; +}; + +&pwm20 { + status = "okay"; + pinctrl-0 = <&pwm20_default_alt>; + pinctrl-1 = <&pwm20_sleep_alt>; + pinctrl-names = "default", "sleep"; +}; + +&pwm21 { + status = "okay"; + pinctrl-0 = <&pwm21_default_alt>; + pinctrl-1 = <&pwm21_sleep_alt>; + pinctrl-names = "default", "sleep"; +}; + +&pinctrl { + pwm20_default_alt: pwm20_default_alt { + group1 { + psels = ; + }; + }; + + pwm20_sleep_alt: pwm20_sleep_alt { + group1 { + psels = ; + low-power-enable; + }; + }; + + pwm21_default_alt: pwm21_default_alt { + group1 { + psels = ; + }; + }; + + pwm21_sleep_alt: pwm21_sleep_alt { + group1 { + psels = ; + low-power-enable; + }; + }; +}; diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/buttons_def.h b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/buttons_def.h new file mode 100644 index 000000000000..4d547949ecda --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/buttons_def.h @@ -0,0 +1,25 @@ +/* + * Copyright (c) 2024 Nordic Semiconductor ASA + * + * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause + */ + +#include + +/* This configuration file is included only once from buttons module and holds + * information about pins forming keyboard matrix. + */ + +/* This structure enforces the header file is included only once in the build. + * Violating this requirement triggers a multiple definition error at link time. + */ +const struct {} buttons_def_include_once; + +static const struct gpio_pin col[] = {}; + +static const struct gpio_pin row[] = { + { .port = 1, .pin = DT_GPIO_PIN(DT_NODELABEL(button0), gpios) }, + { .port = 1, .pin = DT_GPIO_PIN(DT_NODELABEL(button1), gpios) }, + { .port = 1, .pin = DT_GPIO_PIN(DT_NODELABEL(button2), gpios) }, + { .port = 0, .pin = DT_GPIO_PIN(DT_NODELABEL(button3), gpios) }, +}; diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/click_detector_def.h b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/click_detector_def.h new file mode 100644 index 000000000000..0eb4be60f836 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/click_detector_def.h @@ -0,0 +1,24 @@ +/* + * Copyright (c) 2024 Nordic Semiconductor ASA + * + * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause + */ + +#include +#include + +/* This configuration file is included only once from click_detector module + * and holds information about click detector configuration. + */ + +/* This structure enforces the header file is included only once in the build. + * Violating this requirement triggers a multiple definition error at link time. + */ +const struct {} click_detector_def_include_once; + +static const struct click_detector_config click_detector_config[] = { + { + .key_id = CONFIG_ML_APP_MODE_CONTROL_BUTTON_ID, + .consume_button_event = true, + }, +}; diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/led_state_def.h b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/led_state_def.h new file mode 100644 index 000000000000..05b1e065a898 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/led_state_def.h @@ -0,0 +1,62 @@ +/* + * Copyright (c) 2024 Nordic Semiconductor ASA + * + * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause + */ + +#include +#include "led_state.h" +#include "ei_data_forwarder_event.h" + +/* This configuration file is included only once from led_state module and holds + * information about LED effects associated with data forwarder states and machine + * learning results. + */ + +/* This structure enforces the header file is included only once in the build. + * Violating this requirement triggers a multiple definition error at link time. + */ +const struct {} led_state_def_include_once; + + +/* Map function to LED ID */ +static const uint8_t led_map[] = { + [LED_ID_ML_STATE] = 0, + [LED_ID_SENSOR_SIM] = 1 +}; + +static const struct led_effect ei_data_forwarder_led_effects[] = { + [EI_DATA_FORWARDER_STATE_DISCONNECTED] = + LED_EFFECT_LED_BLINK(2000, LED_COLOR(100, 100, 100)), + [EI_DATA_FORWARDER_STATE_CONNECTED] = + LED_EFFECT_LED_BLINK(500, LED_COLOR(100, 100, 100)), + [EI_DATA_FORWARDER_STATE_TRANSMITTING] = + LED_EFFECT_LED_BLINK(50, LED_COLOR(100, 100, 100)), +}; + +static const struct ml_result_led_effect ml_result_led_effects[] = { + { + .label = NULL, + .effect = LED_EFFECT_LED_BREATH(500, LED_COLOR(100, 100, 100)), + }, + { + .label = ANOMALY_LABEL, + .effect = LED_EFFECT_LED_BREATH(250, LED_COLOR(100, 100, 100)), + }, + { + .label = "sine", + .effect = LED_EFFECT_LED_CLOCK(1, LED_COLOR(100, 100, 100)), + }, + { + .label = "triangle", + .effect = LED_EFFECT_LED_CLOCK(2, LED_COLOR(100, 100, 100)), + }, + { + .label = "square", + .effect = LED_EFFECT_LED_CLOCK(3, LED_COLOR(100, 100, 100)), + }, + { + .label = "idle", + .effect = LED_EFFECT_LED_CLOCK(4, LED_COLOR(100, 100, 100)), + }, +}; diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/prj.conf b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/prj.conf new file mode 100644 index 000000000000..30c60521c478 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/prj.conf @@ -0,0 +1,106 @@ +# +# Copyright (c) 2024 Nordic Semiconductor ASA +# +# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause +# +################################################################################ +# Application configuration + +CONFIG_ML_APP_SENSOR_EVENT_DESCR="accel_sim_xyz" + +CONFIG_ML_APP_EI_DATA_FORWARDER=y +CONFIG_ML_APP_EI_DATA_FORWARDER_UART=y + +CONFIG_ML_APP_ML_RUNNER=y +CONFIG_ML_APP_ML_RUNNER_WINDOW_SHIFT=1 +CONFIG_ML_APP_ML_RUNNER_FRAME_SHIFT=0 + +CONFIG_ML_APP_SENSOR_SIM_CTRL=y +CONFIG_ML_APP_SENSOR_SIM_CTRL_TRIG_BUTTON=y +CONFIG_ML_APP_SENSOR_SIM_CTRL_TRIG_BUTTON_ID=0x0002 + +CONFIG_ML_APP_MODE=y +CONFIG_ML_APP_MODE_CONTROL_BUTTON_ID=0x0000 + +CONFIG_ML_APP_LED_STATE=y +CONFIG_ML_APP_LED_STATE_VALUE_THRESH=900 +CONFIG_ML_APP_LED_STATE_ANOMALY_THRESH=500 + +CONFIG_CAF=y + +CONFIG_CAF_POWER_MANAGER=y + +CONFIG_CAF_INIT_LOG_SENSOR_EVENTS=n + +CONFIG_CAF_SENSOR_MANAGER=y + +CONFIG_CAF_BUTTONS=y +CONFIG_CAF_BUTTONS_POLARITY_INVERSED=y + +CONFIG_CAF_CLICK_DETECTOR=y + +CONFIG_CAF_LEDS=y +CONFIG_CAF_LEDS_PWM=y + +################################################################################ +# EI wrapper configuration + +CONFIG_CPP=y +CONFIG_STD_CPP11=y +CONFIG_FP16=n + +# Use the NCS machine learning model for simulated acceleration signal +CONFIG_EDGE_IMPULSE=y +CONFIG_EDGE_IMPULSE_URI="https://developer.nordicsemi.com/nRF_Connect_SDK/EdgeImpulse/nrf_accel_sim-v35.zip; https://publicburan.blob.core.windows.net/nrf-connect-sdk-edgeimpulse/nrf_accel_sim-v35.zip" +CONFIG_EI_WRAPPER=y + +################################################################################ +# System configuration + +CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 +CONFIG_ISR_STACK_SIZE=1536 +CONFIG_MAIN_STACK_SIZE=768 +CONFIG_IDLE_STACK_SIZE=512 + +CONFIG_HEAP_MEM_POOL_SIZE=2048 + +CONFIG_SPEED_OPTIMIZATIONS=y +CONFIG_HW_STACK_PROTECTION=y + +CONFIG_BOOT_BANNER=n +CONFIG_NUM_COOP_PRIORITIES=10 +CONFIG_NUM_PREEMPT_PRIORITIES=11 + +CONFIG_APP_EVENT_MANAGER=y +CONFIG_REBOOT=y + +CONFIG_GPIO=y +CONFIG_PWM=y + +CONFIG_LED=y +CONFIG_LED_PWM=y + +# Using simulated sensor (the DK does not have built-in sensor) +CONFIG_SENSOR=y + +# UART can be used only by EI data forwarder +CONFIG_CONSOLE=n +CONFIG_UART_CONSOLE=n +CONFIG_LOG_BACKEND_UART=n +CONFIG_UART_ASYNC_API=y +CONFIG_NEWLIB_LIBC=y +CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y + +################################################################################ +# Debug configuration (logger using RTT) + +CONFIG_ASSERT=y +CONFIG_RESET_ON_FATAL_ERROR=n + +CONFIG_LOG=y +CONFIG_LOG_MODE_DEFERRED=y +CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=1024 +CONFIG_USE_SEGGER_RTT=y +CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=4096 +CONFIG_LOG_BACKEND_RTT=y +CONFIG_LOG_PRINTK=y diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_manager_def.h b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_manager_def.h new file mode 100644 index 000000000000..e70bc69c2f36 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_manager_def.h @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2024 Nordic Semiconductor ASA + * + * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause + */ + +#include + +/* This configuration file is included only once from sensor_manager module and holds + * information about the sampled sensors. + */ + +/* This structure enforces the header file is included only once in the build. + * Violating this requirement triggers a multiple definition error at link time. + */ +const struct {} sensor_manager_def_include_once; + + +static const struct caf_sampled_channel accel_chan[] = { + { + .chan = SENSOR_CHAN_ACCEL_X, + .data_cnt = 1, + }, + { + .chan = SENSOR_CHAN_ACCEL_Y, + .data_cnt = 1, + }, + { + .chan = SENSOR_CHAN_ACCEL_Z, + .data_cnt = 1, + }, +}; + +static const struct sm_sensor_config sensor_configs[] = { + { + .dev = DEVICE_DT_GET(DT_NODELABEL(sensor_sim)), + .event_descr = CONFIG_ML_APP_SENSOR_EVENT_DESCR, + .chans = accel_chan, + .chan_cnt = ARRAY_SIZE(accel_chan), + .sampling_period_ms = 20, + .active_events_limit = 3, + }, +}; diff --git a/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_sim_ctrl_def.h b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_sim_ctrl_def.h new file mode 100644 index 000000000000..ac965e490436 --- /dev/null +++ b/applications/machine_learning/configuration/nrf54l15dk_nrf54l15_cpuapp/sensor_sim_ctrl_def.h @@ -0,0 +1,67 @@ +/* + * Copyright (c) 2024 Nordic Semiconductor ASA + * + * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause + */ + +#include "sensor_sim_ctrl.h" + +/* This configuration file is included only once from sensor_sim_ctrl module and holds + * information about wave signals that should be generated by simulated sensor. + */ + +/* This structure enforces the header file is included only once in the build. + * Violating this requirement triggers a multiple definition error at link time. + */ +const struct {} sensor_sim_ctrl_def_include_once; + +static const struct sim_wave sim_waves[] = { + { + .label = "sine", + .wave_param = { + .type = WAVE_GEN_TYPE_SINE, + .period_ms = 2000, + .offset = 0.0, + .amplitude = 0.5, + .noise = 0.1, + } + }, + { + .label = "triangle", + .wave_param = { + .type = WAVE_GEN_TYPE_TRIANGLE, + .period_ms = 2000, + .offset = 0.0, + .amplitude = 0.5, + .noise = 0.1, + }, + }, + { + .label = "square", + .wave_param = { + .type = WAVE_GEN_TYPE_SQUARE, + .period_ms = 2000, + .offset = 0.0, + .amplitude = 0.5, + .noise = 0.1, + }, + }, + { + .label = "idle", + .wave_param = { + .type = WAVE_GEN_TYPE_NONE, + .period_ms = 0, + .offset = 0.0, + .amplitude = 0.0, + .noise = 0.1, + }, + }, +}; + +BUILD_ASSERT(ARRAY_SIZE(sim_waves) <= UCHAR_MAX); + +static const struct sim_signal_params sim_signal_params = { + .chan = SENSOR_CHAN_ACCEL_XYZ, + .waves = sim_waves, + .waves_cnt = ARRAY_SIZE(sim_waves), +}; diff --git a/applications/machine_learning/sysbuild.cmake b/applications/machine_learning/sysbuild.cmake index 6e92f204135e..dbe3aac7d458 100644 --- a/applications/machine_learning/sysbuild.cmake +++ b/applications/machine_learning/sysbuild.cmake @@ -31,8 +31,8 @@ if(SB_CONFIG_PARTITION_MANAGER) endif() # Add a dependency so that the remote image will be built first. -sysbuild_add_dependencies(CONFIGURE machine_learning ipc_radio remote) +sysbuild_add_dependencies(CONFIGURE ${DEFAULT_IMAGE} ipc_radio remote) # Add dependency so that the remote image is flashed first. -sysbuild_add_dependencies(FLASH machine_learning ipc_radio remote) +sysbuild_add_dependencies(FLASH ${DEFAULT_IMAGE} ipc_radio remote) endif() diff --git a/applications/matter_bridge/Kconfig b/applications/matter_bridge/Kconfig index dc4e3344840b..31117458c1c8 100644 --- a/applications/matter_bridge/Kconfig +++ b/applications/matter_bridge/Kconfig @@ -180,6 +180,12 @@ endchoice endif # NET_L2_OPENTHREAD +# Dummy Kconfig just to select experimental for some of the configurations. +config BRIDGE_EXPERIMENTAL + bool + default y if NET_L2_OPENTHREAD || BRIDGE_SMART_PLUG_SUPPORT + select EXPERIMENTAL + source "${ZEPHYR_CONNECTEDHOMEIP_MODULE_DIR}/config/nrfconnect/chip-module/Kconfig.features" source "${ZEPHYR_CONNECTEDHOMEIP_MODULE_DIR}/config/nrfconnect/chip-module/Kconfig.defaults" source "${ZEPHYR_NRF_MODULE_DIR}/samples/matter/common/src/bridge/Kconfig" diff --git a/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst b/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst index f297036046ac..674241e6f422 100644 --- a/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst +++ b/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst @@ -236,7 +236,6 @@ The following steps show how to add support for a new Bluetooth LE service calle mGattSubscribeParams.value = BT_GATT_CCC_NOTIFY; mGattSubscribeParams.notify = MyBtServiceDataProvider::GattNotifyCallback; mGattSubscribeParams.subscribe = nullptr; - mGattSubscribeParams.write = nullptr; return bt_gatt_subscribe(mDevice.mConn, &mGattSubscribeParams); } diff --git a/applications/matter_bridge/doc/matter_bridge_description.rst b/applications/matter_bridge/doc/matter_bridge_description.rst index f25c30d52783..8a2ffde836c7 100644 --- a/applications/matter_bridge/doc/matter_bridge_description.rst +++ b/applications/matter_bridge/doc/matter_bridge_description.rst @@ -576,7 +576,7 @@ The current maximum number of Bluetooth LE connections that can be selected usin .. parsed-literal:: :class: highlight - west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf700x_nrf54h20dk -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf" + west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf7002eb_interposer_p1 -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf" .. group-tab:: Matter bridge over Thread @@ -697,6 +697,17 @@ The application supports the following configurations: Enables the Matter Bridge to work with Wi-Fi on nRF5340 DK. +Factory data support +==================== + +.. include:: ../../../samples/matter/lock/README.rst + :start-after: matter_door_lock_sample_factory_data_start + :end-before: matter_door_lock_sample_factory_data_end + +.. include:: ../../../samples/matter/lock/README.rst + :start-after: matter_door_lock_sample_factory_data_nrf54h20_start + :end-before: matter_door_lock_sample_factory_data_nrf54h20_end + Building and running ******************** @@ -719,7 +730,7 @@ Once connected, run the following command to build the sample: .. code-block:: console - west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf700x_nrf54h20dk + west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf7002eb_interposer_p1 Selecting a configuration ========================= @@ -734,19 +745,10 @@ Configure the functionality of the Matter-Bridge device To enable the Matter smart plugin functionality, run the following command with *board_target* replaced with the board target name: -.. tabs:: - - .. group-tab:: nRF54 DKs - - .. code-block:: console - - west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf700x_nrf54h20dk -DCONFIG_BRIDGED_DEVICE_BT=y -Dmatter_bridge_SNIPPET=onoff_plug - - .. group-tab:: nRF70 DKs - - .. code-block:: console +.. parsed-literal:: + :class: highlight - west build -b nrf7002dk/nrf5340/cpuapp -p -- -DCONFIG_BRIDGED_DEVICE_BT=y -Dmatter_bridge_SNIPPET=onoff_plug + west build -b *board_target* -p -- -Dmatter_bridge_SNIPPET=onoff_plug .. _matter_bridge_testing: diff --git a/applications/matter_bridge/prj.conf b/applications/matter_bridge/prj.conf index 072ecc1b0656..aec56151592e 100644 --- a/applications/matter_bridge/prj.conf +++ b/applications/matter_bridge/prj.conf @@ -51,6 +51,3 @@ CONFIG_CHIP_FACTORY_DATA_BUILD=y # Enable LTO to decrease the flash usage. CONFIG_LTO=y CONFIG_ISR_TABLES_LOCAL_DECLARATION=y - -# DAC Migration -CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY=y diff --git a/applications/matter_bridge/prj_release.conf b/applications/matter_bridge/prj_release.conf index b34d244892a7..d02bcda268c0 100644 --- a/applications/matter_bridge/prj_release.conf +++ b/applications/matter_bridge/prj_release.conf @@ -55,6 +55,3 @@ CONFIG_CHIP_ENABLE_READ_CLIENT=y # Enable Watchdog CONFIG_NCS_SAMPLE_MATTER_WATCHDOG=y - -# DAC Migration -CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY=y diff --git a/applications/matter_bridge/sample.yaml b/applications/matter_bridge/sample.yaml index c2087b5c0fcb..2f1c205d5a5a 100644 --- a/applications/matter_bridge/sample.yaml +++ b/applications/matter_bridge/sample.yaml @@ -79,7 +79,7 @@ tests: sysbuild: true build_only: true extra_args: SB_CONFIG_WIFI_NRF70=y CONFIG_CHIP_WIFI=y - matter_bridge_SHIELD=nrf7002eb_interposer_p1 CONFIG_BRIDGED_DEVICE_BT=y + matter_bridge_SHIELD="nrf7002eb_interposer_p1;nrf7002eb" CONFIG_BRIDGED_DEVICE_BT=y integration_platforms: - nrf54h20dk/nrf54h20/cpuapp platform_allow: nrf54h20dk/nrf54h20/cpuapp @@ -88,7 +88,7 @@ tests: sysbuild: true build_only: true extra_args: FILE_SUFFIX=release SB_CONFIG_WIFI_NRF70=y CONFIG_CHIP_WIFI=y - matter_bridge_SHIELD=nrf7002eb_interposer_p1 CONFIG_BRIDGED_DEVICE_BT=y + matter_bridge_SHIELD="nrf7002eb_interposer_p1;nrf7002eb" CONFIG_BRIDGED_DEVICE_BT=y integration_platforms: - nrf54h20dk/nrf54h20/cpuapp platform_allow: nrf54h20dk/nrf54h20/cpuapp diff --git a/applications/matter_bridge/snippets/onoff_plug/bridge.zap b/applications/matter_bridge/snippets/onoff_plug/bridge.zap index a75f40c77605..af273fa7bd75 100644 --- a/applications/matter_bridge/snippets/onoff_plug/bridge.zap +++ b/applications/matter_bridge/snippets/onoff_plug/bridge.zap @@ -4872,7 +4872,7 @@ "storageOption": "RAM", "singleton": 0, "bounded": 0, - "defaultValue": "4", + "defaultValue": "6", "reportable": 1, "minInterval": 1, "maxInterval": 65534, @@ -5108,7 +5108,7 @@ "storageOption": "RAM", "singleton": 0, "bounded": 0, - "defaultValue": "4", + "defaultValue": "6", "reportable": 1, "minInterval": 1, "maxInterval": 65534, @@ -6230,4 +6230,4 @@ "parentEndpointIdentifier": null } ] -} \ No newline at end of file +} diff --git a/applications/matter_bridge/snippets/onoff_plug/zap-generated/endpoint_config.h b/applications/matter_bridge/snippets/onoff_plug/zap-generated/endpoint_config.h index 844ae37c177b..1a53226bb594 100644 --- a/applications/matter_bridge/snippets/onoff_plug/zap-generated/endpoint_config.h +++ b/applications/matter_bridge/snippets/onoff_plug/zap-generated/endpoint_config.h @@ -387,7 +387,7 @@ ZAP_ATTRIBUTE_MASK(MIN_MAX) | ZAP_ATTRIBUTE_MASK(WRITABLE) | \ ZAP_ATTRIBUTE_MASK(NULLABLE) }, /* StartUpOnOff */ \ { ZAP_SIMPLE_DEFAULT(0), 0x0000FFFC, 4, ZAP_TYPE(BITMAP32), 0 }, /* FeatureMap */ \ - { ZAP_SIMPLE_DEFAULT(4), 0x0000FFFD, 2, ZAP_TYPE(INT16U), 0 }, /* ClusterRevision */ \ + { ZAP_SIMPLE_DEFAULT(6), 0x0000FFFD, 2, ZAP_TYPE(INT16U), 0 }, /* ClusterRevision */ \ \ /* Endpoint: 3, Cluster: Descriptor (server) */ \ { ZAP_EMPTY_DEFAULT(), 0x00000000, 0, ZAP_TYPE(ARRAY), \ diff --git a/applications/matter_bridge/src/default_zap/bridge.zap b/applications/matter_bridge/src/default_zap/bridge.zap index 74b39e06c718..000200eb30d2 100644 --- a/applications/matter_bridge/src/default_zap/bridge.zap +++ b/applications/matter_bridge/src/default_zap/bridge.zap @@ -3838,7 +3838,7 @@ "storageOption": "RAM", "singleton": 0, "bounded": 0, - "defaultValue": "4", + "defaultValue": "6", "reportable": 1, "minInterval": 1, "maxInterval": 65534, @@ -4074,7 +4074,7 @@ "storageOption": "RAM", "singleton": 0, "bounded": 0, - "defaultValue": "4", + "defaultValue": "6", "reportable": 1, "minInterval": 1, "maxInterval": 65534, diff --git a/applications/matter_bridge/src/default_zap/zap-generated/endpoint_config.h b/applications/matter_bridge/src/default_zap/zap-generated/endpoint_config.h index e50ff93fc4d7..8d5e3473af31 100644 --- a/applications/matter_bridge/src/default_zap/zap-generated/endpoint_config.h +++ b/applications/matter_bridge/src/default_zap/zap-generated/endpoint_config.h @@ -337,7 +337,7 @@ ZAP_ATTRIBUTE_MASK(MIN_MAX) | ZAP_ATTRIBUTE_MASK(WRITABLE) | \ ZAP_ATTRIBUTE_MASK(NULLABLE) }, /* StartUpOnOff */ \ { ZAP_SIMPLE_DEFAULT(0), 0x0000FFFC, 4, ZAP_TYPE(BITMAP32), 0 }, /* FeatureMap */ \ - { ZAP_SIMPLE_DEFAULT(4), 0x0000FFFD, 2, ZAP_TYPE(INT16U), 0 }, /* ClusterRevision */ \ + { ZAP_SIMPLE_DEFAULT(6), 0x0000FFFD, 2, ZAP_TYPE(INT16U), 0 }, /* ClusterRevision */ \ \ /* Endpoint: 2, Cluster: Descriptor (server) */ \ { ZAP_EMPTY_DEFAULT(), 0x00000000, 0, ZAP_TYPE(ARRAY), \ diff --git a/applications/matter_weather_station/prj.conf b/applications/matter_weather_station/prj.conf index 8e7c76d5043d..7d4aeb40efdb 100644 --- a/applications/matter_weather_station/prj.conf +++ b/applications/matter_weather_station/prj.conf @@ -90,6 +90,3 @@ CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_TEST=y # Set the NVS sector count to match the settings partition size that is 64 kB for this application. CONFIG_SETTINGS_NVS_SECTOR_COUNT=16 - -# DAC Migration -CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY=y diff --git a/applications/matter_weather_station/prj_release.conf b/applications/matter_weather_station/prj_release.conf index e98884b0a596..3d2b4fe40ea1 100644 --- a/applications/matter_weather_station/prj_release.conf +++ b/applications/matter_weather_station/prj_release.conf @@ -84,6 +84,3 @@ CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_TEST=y # Set the NVS sector count to match the settings partition size that is 64 kB for this application. CONFIG_SETTINGS_NVS_SECTOR_COUNT=16 - -# DAC Migration -CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY=y diff --git a/applications/nrf5340_audio/sample.yaml b/applications/nrf5340_audio/sample.yaml index 3a01e1029ee1..2a678b0950be 100644 --- a/applications/nrf5340_audio/sample.yaml +++ b/applications/nrf5340_audio/sample.yaml @@ -22,3 +22,5 @@ tests: extra_args: FILE_SUFFIX=release CONFIG_AUDIO_DEV=2 CONFIG_TRANSPORT_BIS=y applications.nrf5340_audio.headset_unicast_sd_card: extra_args: FILE_SUFFIX=release CONFIG_AUDIO_DEV=1 CONFIG_SD_CARD_PLAYBACK=y + applications.nrf5340_audio.headset_dfu: + extra_args: FILE_SUFFIX=release CONFIG_AUDIO_DEV=1 FILE_SUFFIX=fota diff --git a/applications/nrf5340_audio/src/bluetooth/bt_content_control/media/bt_content_ctrl_media.c b/applications/nrf5340_audio/src/bluetooth/bt_content_control/media/bt_content_ctrl_media.c index de090822bf25..18e6e2cd0e19 100644 --- a/applications/nrf5340_audio/src/bluetooth/bt_content_control/media/bt_content_ctrl_media.c +++ b/applications/nrf5340_audio/src/bluetooth/bt_content_control/media/bt_content_ctrl_media.c @@ -137,11 +137,19 @@ static void mcc_discover_mcs_cb(struct bt_conn *conn, int err) */ static void mcc_send_command_cb(struct bt_conn *conn, int err, const struct mpl_cmd *cmd) { + int ret; + LOG_DBG("mcc_send_command_cb"); if (err) { - LOG_ERR("MCC: cmd send failed (%d) - opcode: %u, param: %d", err, cmd->opcode, - cmd->param); + struct bt_conn_info info; + + /* Check that we are actually in a connected state before printing an error */ + ret = bt_conn_get_info(conn, &info); + if (!ret && info.state == (BT_CONN_STATE_CONNECTED)) { + LOG_ERR("MCC: cmd send failed (%d) - opcode: %u, param: %d", err, + cmd->opcode, cmd->param); + } } } #endif /* defined(CONFIG_BT_MCC_SET_MEDIA_CONTROL_POINT) */ diff --git a/applications/nrf5340_audio/src/bluetooth/bt_management/dfu/bt_mgmt_dfu.c b/applications/nrf5340_audio/src/bluetooth/bt_management/dfu/bt_mgmt_dfu.c index 388c6db0ab4d..a6bece89c988 100644 --- a/applications/nrf5340_audio/src/bluetooth/bt_management/dfu/bt_mgmt_dfu.c +++ b/applications/nrf5340_audio/src/bluetooth/bt_management/dfu/bt_mgmt_dfu.c @@ -23,19 +23,21 @@ LOG_MODULE_REGISTER(bt_mgmt_dfu, CONFIG_BT_MGMT_DFU_LOG_LEVEL); #define DEVICE_NAME_DFU CONFIG_BT_DFU_DEVICE_NAME #define DEVICE_NAME_DFU_LEN (sizeof(DEVICE_NAME_DFU) - 1) -/* Advertising data for SMP_SVR UUID */ -static struct bt_le_adv_param adv_param; static const struct bt_data ad_peer[] = { BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)), BT_DATA_BYTES(BT_DATA_UUID128_ALL, 0x84, 0xaa, 0x60, 0x74, 0x52, 0x8a, 0x8b, 0x86, 0xd3, 0x4c, 0xb7, 0x1d, 0x1d, 0xdc, 0x53, 0x8d), }; +/* Set aside space for name to be in scan response */ +static struct bt_data sd_peer[1]; + static void smp_adv(void) { int ret; - ret = bt_le_adv_start(&adv_param, ad_peer, ARRAY_SIZE(ad_peer), NULL, 0); + ret = bt_le_adv_start(BT_LE_ADV_CONN, ad_peer, ARRAY_SIZE(ad_peer), sd_peer, + ARRAY_SIZE(sd_peer)); if (ret) { LOG_ERR("SMP_SVR Advertising failed to start (ret %d)", ret); return; @@ -63,26 +65,46 @@ static struct bt_conn_cb dfu_conn_callbacks = { static void dfu_set_bt_name(void) { - char name[CONFIG_BT_DEVICE_NAME_MAX] = {0}; + int ret; + static char name[CONFIG_BT_DEVICE_NAME_MAX]; strlcpy(name, CONFIG_BT_DEVICE_NAME, CONFIG_BT_DEVICE_NAME_MAX); - strlcat(name, "_", CONFIG_BT_DEVICE_NAME_MAX); + ret = strlcat(name, "_", CONFIG_BT_DEVICE_NAME_MAX); + if (ret >= CONFIG_BT_DEVICE_NAME_MAX) { + LOG_ERR("Failed to set full BT name, will truncate"); + } + #if (CONFIG_AUDIO_DEV == GATEWAY) - strlcat(name, GW_TAG, CONFIG_BT_DEVICE_NAME_MAX); + ret = strlcat(name, GW_TAG, CONFIG_BT_DEVICE_NAME_MAX); + if (ret >= CONFIG_BT_DEVICE_NAME_MAX) { + LOG_ERR("Failed to set full BT name, will truncate"); + } #else enum audio_channel channel; channel_assignment_get(&channel); if (channel == AUDIO_CH_L) { - strlcat(name, CH_L_TAG, CONFIG_BT_DEVICE_NAME_MAX); + ret = strlcat(name, CH_L_TAG, CONFIG_BT_DEVICE_NAME_MAX); + if (ret >= CONFIG_BT_DEVICE_NAME_MAX) { + LOG_ERR("Failed to set full BT name, will truncate"); + } } else { - strlcat(name, CH_R_TAG, CONFIG_BT_DEVICE_NAME_MAX); + ret = strlcat(name, CH_R_TAG, CONFIG_BT_DEVICE_NAME_MAX); + if (ret >= CONFIG_BT_DEVICE_NAME_MAX) { + LOG_ERR("Failed to set full BT name, will truncate"); + } } #endif - strlcat(name, "_DFU", CONFIG_BT_DEVICE_NAME_MAX); - bt_set_name(name); + ret = strlcat(name, "_DFU", CONFIG_BT_DEVICE_NAME_MAX); + if (ret >= CONFIG_BT_DEVICE_NAME_MAX) { + LOG_ERR("Failed to set full BT name, will truncate"); + } + + sd_peer[0].type = BT_DATA_NAME_COMPLETE; + sd_peer[0].data_len = strlen(name); + sd_peer[0].data = name; } void bt_mgmt_dfu_start(void) @@ -90,7 +112,6 @@ void bt_mgmt_dfu_start(void) LOG_INF("Entering SMP server mode"); bt_conn_cb_register(&dfu_conn_callbacks); - adv_param = *BT_LE_ADV_CONN_NAME; dfu_set_bt_name(); smp_adv(); diff --git a/applications/nrf5340_audio/src/bluetooth/bt_management/scanning/bt_mgmt_scan_for_conn.c b/applications/nrf5340_audio/src/bluetooth/bt_management/scanning/bt_mgmt_scan_for_conn.c index 1ef01ab4fc0c..425e0730859e 100644 --- a/applications/nrf5340_audio/src/bluetooth/bt_management/scanning/bt_mgmt_scan_for_conn.c +++ b/applications/nrf5340_audio/src/bluetooth/bt_management/scanning/bt_mgmt_scan_for_conn.c @@ -43,7 +43,7 @@ static void bond_connect(const struct bt_bond_info *bond_info, void *user_data) { int ret; const bt_addr_le_t *adv_addr = user_data; - struct bt_conn *conn; + struct bt_conn *conn = NULL; char addr_string[BT_ADDR_LE_STR_LEN]; if (!bt_addr_le_cmp(&bond_info->addr, adv_addr)) { @@ -137,7 +137,7 @@ static bool device_name_check(struct bt_data *data, void *user_data) { int ret; bt_addr_le_t *addr = user_data; - struct bt_conn *conn; + struct bt_conn *conn = NULL; char addr_string[BT_ADDR_LE_STR_LEN]; /* We only care about LTVs with name */ @@ -197,7 +197,7 @@ static bool csip_found(struct bt_data *data, void *user_data) { int ret; bt_addr_le_t *addr = user_data; - struct bt_conn *conn; + struct bt_conn *conn = NULL; char addr_string[BT_ADDR_LE_STR_LEN]; if (!bt_csip_set_coordinator_is_set_member(server_sirk, data)) { diff --git a/applications/nrf_desktop/CMakeLists.txt b/applications/nrf_desktop/CMakeLists.txt index 24a87d4fe9bb..ec87ef388447 100644 --- a/applications/nrf_desktop/CMakeLists.txt +++ b/applications/nrf_desktop/CMakeLists.txt @@ -8,6 +8,9 @@ cmake_minimum_required(VERSION 3.20.0) ################################################################################ +# The application uses the configuration/ scheme for configuration files. +set(APPLICATION_CONFIG_DIR "${CMAKE_CURRENT_LIST_DIR}/configuration/\${NORMALIZED_BOARD_TARGET}") + find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project("nRF52 Desktop" VERSION 0.1) diff --git a/applications/nrf_desktop/doc/dvfs.rst b/applications/nrf_desktop/doc/dvfs.rst new file mode 100644 index 000000000000..cd08f22d0e87 --- /dev/null +++ b/applications/nrf_desktop/doc/dvfs.rst @@ -0,0 +1,120 @@ +.. _nrf_desktop_dvfs: + +DVFS module +########### + +.. contents:: + :local: + :depth: 2 + +The nRF Desktop Dynamic Voltage and Frequency Scaling (DVFS) module is responsible for switching the frequency and voltage according to the application needs. +The module chooses the highest frequency required by the application states. +The module, requests this frequency as a minimal requirement to clock control driver which selects DVFS operating point accordingly. +DVFS improves balancing performance and power consumption, especially in battery-operated devices. + +In the nRF Desktop application, the DVFS module enables the system to use the lowest possible frequency and voltage when the application performs less compute-intensive activities, such as Bluetooth® LE advertising. +However, if performing more compute-intensive tasks, the nRF Desktop DVFS module will dynamically change to a higher frequency to increase performance. + +The nRF Desktop DVFS module requests clock frequency change using API of the clock control driver. +The driver is responsible for choosing the optimal clock frequency. +The driver submits a request to the sysctrl core through the nrfs DVFS service. +The sysctrl core controls both clock frequency and voltage and chooses corresponding voltage to requested frequency. + +.. note:: + In the current solution, it is assumed that no other module requests frequency changes. + The nRF Desktop DVFS module is the sole entity responsible for managing frequency and voltage adjustments. + Controlling clock from other sources would result in a module fatal error. + +Supported devices +***************** + +The module is only available for the nRF54H20 SoC. + +The nRF54H20 SoC has the following available operating points (called frequency in the documentation): + +* DVFS_FREQ_HIGH - High frequency - 320 MHz, 0.8 V +* DVFS_FREQ_MEDLOW - Medium-low frequency - 128 MHz, 0.6V +* DVFS_FREQ_LOW - Low frequency - 64 MHz, 0.5V + +The nRF Desktop DVFS module might request any clock frequency, but it would be rounded up by the driver to one of the values from available operating points. + +Module events +************* + +.. include:: event_propagation.rst + :start-after: table_dvfs_start + :end-before: table_dvfs_end + +.. note:: + |nrf_desktop_module_event_note| + +Configuration +************* + +The nRF Desktop DVFS module is enabled by default on supported board targets. +To disable it, set the :ref:`CONFIG_DESKTOP_DVFS ` Kconfig option to ``n``. + +Tracked application states +========================== + +The nRF Desktop DVFS module defines independent application states that have different requirements in terms of frequency. +The module listens for Event Manager events that are sent and turns the state on or off according to the event. +It support the following DVFS states: + +* ``DVFS_STATE_INITIALIZING`` - Application initialization is in progress +* ``DVFS_STATE_LLPM_CONNECTED`` - There is an ongoing connection that uses BLE Low Latency Packet Mode +* ``DVFS_STATE_USB_CONNECTED`` - USB is connected +* ``DVFS_STATE_CONFIG_CHANNEL`` - :ref:`nrf_desktop_config_channel` is active +* ``DVFS_STATE_SMP_TRANSFER`` - DFU image transfer over BLE SMP is active + For details about SMP DFU integration in nRF Desktop, see :ref:`nrf_desktop_dfu_mcumgr`. + +You can configure each DVFS state using the following Kconfig options: + +* ``CONFIG_DESKTOP_DVFS_STATE__ENABLE`` - Enables DVFS state handling. +* ``CONFIG_DESKTOP_DVFS_STATE__ACTIVE_FREQ`` - Choice of minimal active frequency requested by state . + The possible values are ``DESKTOP_DVFS_STATE__ACTIVE_FREQ_HIGH`` and ``DESKTOP_DVFS_STATE__ACTIVE_FREQ_MEDLOW``. +* ``CONFIG_DESKTOP_DVFS_STATE__TIMEOUT_MS`` - Specifies the timeout in milliseconds, defining the duration from receiving an on event to the moment the state stops requesting its active frequency. + When the timeout is reached, the state returns to a non-active state potentially enabling the system to use lower frequency. + If the timeout is set to ``0`` the will continue requesting its active frequency until it receives an off event. + Some of the tracked application states have associated events that inform when the state is turned on and off (for example, USB connection). + Other states have associated application events emitted periodically when active. + There is no event explicitly informing that state is no longer active (for example, config channel). + For such states, we need to define a timeout that is used to turn off the tracked state after associated application events are no longer emitted. + +Frequency change retry +====================== + +Each frequency change request is retried if it fails due to a known reason. +Failing frequency change requests can be caused by: + +* Another frequency change request being in progress on sysctrl - error ``-EBUSY``. + In that case, the module will retry the request after a timeout specified by the :ref:`CONFIG_DESKTOP_DVFS_RETRY_BUSY_TIMEOUT_MS ` Kconfig option. + The default timeout value is 1 ms. +* The nrfs DVFS service being not yet initialized - error ``-EAGAIN``. + In that case, the nRF Desktop DVFS module will retry the request after a timeout specified by the :ref:`CONFIG_DESKTOP_DVFS_RETRY_INIT_TIMEOUT_MS ` Kconfig option. + The default timeout value is 500 ms. +* Other errors are not retried. + If the DVFS frequency request returns an error different from ``-EBUSY`` or ``-EAGAIN``, the module will report a :c:enum:`MODULE_STATE_ERROR` and set the ``module_state`` to ``STATE_ERROR``. + +The module will retry the request up to the number of times specified by the :ref:`CONFIG_DESKTOP_DVFS_RETRY_COUNT ` Kconfig option. +The default value of retries is ``5``. +The error counter is only set to zero when the DVFS change request is correct. +nRF Desktop DVFS module will also report a :c:enum:`MODULE_STATE_ERROR` and set ``module_state`` to ``STATE_ERROR`` if the number of retries is exceeded. + +In ``STATE_ERROR``, the module will not change the frequency and voltage. +:c:enum:`MODULE_STATE_ERROR` reported by the nRF Desktop DVFS module would lead to fatal application error. + +Implementation details +********************** + +The nRF Desktop DVFS module has the following two state tracing entities: + +* ``module_state`` is used to track the state of the nRF Desktop DVFS module. + It indicates if the module is ready or if an error has occurred. + +* ``dfvs_requests_state_bitmask`` is used to track separately the state of each application DVFS state. + Each DVFS state is represented by a bit in the bitmask. + If the bit is set, the state is active. + The module listens for Event Manager events related to a given state and updates the state accordingly. + The module then checks which states are active and sets the highest frequency that is required by at least one state. + If no state is active, the module sets the lowest frequency :ref:`CONFIG_DESKTOP_DVFS_FREQ_LOW `. diff --git a/applications/nrf_desktop/doc/event_propagation.rst b/applications/nrf_desktop/doc/event_propagation.rst index 936023f891e5..04a2ec161930 100644 --- a/applications/nrf_desktop/doc/event_propagation.rst +++ b/applications/nrf_desktop/doc/event_propagation.rst @@ -366,6 +366,8 @@ nRF Desktop event propagation | | | | ``ble_peer_conn_params_event`` | :ref:`nrf_desktop_ble_conn_params` | | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_ble_latency` | +| | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_dvfs` | | | | +--------------------------------+---------------------------------------------+ | | | | ``ble_peer_event`` | :ref:`nrf_desktop_ble_peer_event_sinks` | | | | +--------------------------------+---------------------------------------------+ @@ -624,6 +626,8 @@ nRF Desktop event propagation +-----------------------------------------------+----------------------------+ +----------------------------+---------------------------------------------+ | | | | ``ble_smp_transfer_event`` | :ref:`nrf_desktop_ble_latency` | | | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_dvfs` | +| | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_dfu_mcumgr` | | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_smp` | @@ -634,6 +638,33 @@ nRF Desktop event propagation .. table_dfu_mcumgr_end +.. table_dvfs_start + ++-----------------------------------------------+--------------------------------+-------------+------------------------+---------------------------------------------+ +| Source Module | Input Event | This Module | Output Event | Sink Module | ++===============================================+================================+=============+========================+=============================================+ +| :ref:`nrf_desktop_config_event_sources` | ``config_event`` | ``dvfs`` | | | ++-----------------------------------------------+--------------------------------+ | | | +| :ref:`nrf_desktop_ble_state` | ``ble_peer_conn_params_event`` | | | | ++-----------------------------------------------+--------------------------------+ | | | +| :ref:`nrf_desktop_ble_adv` | ``ble_peer_event`` | | | | ++-----------------------------------------------+ | | | | +| :ref:`nrf_desktop_ble_state` | | | | | ++-----------------------------------------------+--------------------------------+ | | | +| :ref:`nrf_desktop_dfu_mcumgr` | ``ble_smp_transfer_event`` | | | | ++-----------------------------------------------+ | | | | +| :ref:`nrf_desktop_smp` | | | | | ++-----------------------------------------------+--------------------------------+ | | | +| :ref:`nrf_desktop_module_state_event_sources` | ``module_state_event`` | | | | ++-----------------------------------------------+--------------------------------+ | | | +| :ref:`nrf_desktop_usb_state` | ``usb_state_event`` | | | | ++-----------------------------------------------+--------------------------------+ +------------------------+---------------------------------------------+ +| | | | ``module_state_event`` | :ref:`nrf_desktop_module_state_event_sinks` | ++-----------------------------------------------+--------------------------------+-------------+------------------------+---------------------------------------------+ + +.. table_dvfs_end + + .. table_factory_reset_start +-----------------------------------------------+------------------------+-------------------+------------------+---------------------------------------+ @@ -768,6 +799,10 @@ nRF Desktop event propagation +-----------------------------------------------+ | | | | | :ref:`nrf_desktop_usb_state` | | | | | +-----------------------------------------------+-----------------------------------+ | | | +| :ref:`nrf_desktop_hids` | ``hid_report_subscriber_event`` | | | | ++-----------------------------------------------+ | | | | +| :ref:`nrf_desktop_usb_state` | | | | | ++-----------------------------------------------+-----------------------------------+ | | | | :ref:`nrf_desktop_hids` | ``hid_report_subscription_event`` | | | | +-----------------------------------------------+ | | | | | :ref:`nrf_desktop_usb_state` | | | | | @@ -901,7 +936,9 @@ nRF Desktop event propagation | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_motion` | | | | +-----------------------------------+---------------------------------------------+ -| | | | ``hid_report_subscriber_event`` | :ref:`nrf_desktop_hid_state` | +| | | | ``hid_report_subscriber_event`` | :ref:`nrf_desktop_hid_forward` | +| | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_hid_state` | | | | +-----------------------------------+---------------------------------------------+ | | | | ``hid_report_subscription_event`` | :ref:`nrf_desktop_hid_forward` | | | | | +---------------------------------------------+ @@ -1223,6 +1260,8 @@ nRF Desktop event propagation +-----------------------------------------------+----------------------------+ +----------------------------+---------------------------------------------+ | | | | ``ble_smp_transfer_event`` | :ref:`nrf_desktop_ble_latency` | | | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_dvfs` | +| | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_dfu_mcumgr` | | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_smp` | @@ -1285,7 +1324,9 @@ nRF Desktop event propagation | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_motion` | | | | +-----------------------------------+---------------------------------------------+ -| | | | ``hid_report_subscriber_event`` | :ref:`nrf_desktop_hid_state` | +| | | | ``hid_report_subscriber_event`` | :ref:`nrf_desktop_hid_forward` | +| | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_hid_state` | | | | +-----------------------------------+---------------------------------------------+ | | | | ``hid_report_subscription_event`` | :ref:`nrf_desktop_hid_forward` | | | | | +---------------------------------------------+ @@ -1299,6 +1340,8 @@ nRF Desktop event propagation | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_ble_conn_params` | | | | | +---------------------------------------------+ +| | | | | :ref:`nrf_desktop_dvfs` | +| | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_motion` | | | | | +---------------------------------------------+ | | | | | :ref:`nrf_desktop_usb_state_pm` | diff --git a/applications/nrf_desktop/doc/event_rel_modules.rst b/applications/nrf_desktop/doc/event_rel_modules.rst index 9d429d3cde98..a3552760dccc 100644 --- a/applications/nrf_desktop/doc/event_rel_modules.rst +++ b/applications/nrf_desktop/doc/event_rel_modules.rst @@ -33,6 +33,7 @@ Sink modules for ble_peer_event * :ref:`nrf_desktop_ble_scan` * :ref:`nrf_desktop_ble_state_pm` * :ref:`nrf_desktop_dfu` +* :ref:`nrf_desktop_dvfs` * :ref:`nrf_desktop_hid_forward` * :ref:`nrf_desktop_led_state` * :ref:`nrf_desktop_ble_state` @@ -63,6 +64,7 @@ Sink modules for config_event * :ref:`nrf_desktop_ble_latency` * :ref:`nrf_desktop_ble_qos` * :ref:`nrf_desktop_dfu` +* :ref:`nrf_desktop_dvfs` * :ref:`nrf_desktop_factory_reset` * :ref:`nrf_desktop_hid_forward` * :ref:`nrf_desktop_info` @@ -121,6 +123,7 @@ Source modules for module_state_event * :ref:`nrf_desktop_cpu_meas` * :ref:`nrf_desktop_dfu` * :ref:`nrf_desktop_dfu_mcumgr` +* :ref:`nrf_desktop_dvfs` * :ref:`nrf_desktop_failsafe` * :ref:`nrf_desktop_fast_pair_app` * :ref:`nrf_desktop_fn_keys` @@ -170,6 +173,7 @@ Sink modules for module_state_event * :ref:`nrf_desktop_cpu_meas` * :ref:`nrf_desktop_dfu` * :ref:`nrf_desktop_dfu_mcumgr` +* :ref:`nrf_desktop_dvfs` * :ref:`nrf_desktop_factory_reset` * :ref:`nrf_desktop_fast_pair_app` * :ref:`nrf_desktop_fn_keys` diff --git a/applications/nrf_desktop/doc/hid_forward.rst b/applications/nrf_desktop/doc/hid_forward.rst index 65a24bfd7fbc..908631c9a262 100644 --- a/applications/nrf_desktop/doc/hid_forward.rst +++ b/applications/nrf_desktop/doc/hid_forward.rst @@ -32,16 +32,23 @@ Complete the following steps to configure the module: Make sure that both :ref:`CONFIG_DESKTOP_ROLE_HID_DONGLE ` and :ref:`CONFIG_DESKTOP_BT_CENTRAL ` are enabled. The HID forward application module is enabled by the :ref:`CONFIG_DESKTOP_HID_FORWARD_ENABLE ` option which is implied by the :ref:`CONFIG_DESKTOP_BT_CENTRAL ` option together with other application modules. These modules are required for HID dongle that forwards the data from HID peripherals connected over Bluetooth. -#. The :ref:`CONFIG_DESKTOP_HID_FORWARD_ENABLE ` option selects :kconfig:option:`CONFIG_BT_HOGP` to automatically enable the :ref:`hogp_readme`. - An nRF Desktop dongle does not generate its own HID input reports. - The dongle uses |hid_forward| to forward the HID reports. - The reports are received by the HID service client from the peripherals connected over Bluetooth. - .. note:: + * The :ref:`CONFIG_DESKTOP_HID_FORWARD_ENABLE ` option selects :kconfig:option:`CONFIG_BT_HOGP` to automatically enable the :ref:`hogp_readme`. + An nRF Desktop dongle does not generate its own HID input reports. + The dongle uses |hid_forward| to forward the HID reports. + The reports are received by the HID service client from the peripherals connected over Bluetooth. + + .. note:: The maximum number of supported HID reports (:kconfig:option:`CONFIG_BT_HOGP_REPORTS_MAX`) is set by default for the nRF Desktop dongle, which supports two peripherals with an average of six HID reports each. Make sure to align this configuration value for other use cases, for example, if the dongle supports more peripherals. -#. nRF Desktop dongle can forward either mouse or keyboard boot reports. + * The :ref:`CONFIG_DESKTOP_HID_FORWARD_ENABLE ` option selects :ref:`CONFIG_DESKTOP_HID_REPORTQ ` to automatically enable the HID report queue utility. + The HID report queue utility is used to locally enqueue reports at the source to prevent HID report drops. + If needed, you can update the maximum number of enqueued HID reports (:ref:`CONFIG_DESKTOP_HID_REPORTQ_MAX_ENQUEUED_REPORTS `). + See :ref:`nrf_desktop_hid_reportq` documentation for details. + +#. Check the chosen HID boot protocol. + The nRF Desktop dongle can forward either mouse or keyboard boot reports. The forwarded boot report type is specified using the following Kconfig options: * :ref:`CONFIG_DESKTOP_HID_BOOT_INTERFACE_KEYBOARD ` - This option enables forwarding keyboard boot reports. @@ -50,8 +57,10 @@ Complete the following steps to configure the module: Those options affect :ref:`nrf_desktop_usb_state` that subscribes for HID boot reports. The Dongle forwards HID reports from both mouse and keyboard, and so either option works if you want to have the Dongle work as boot mouse or boot keyboard. For more information about the configuration of the HID boot protocol, see the boot protocol configuration section in the :ref:`nrf_desktop_usb_state` documentation. - -You can set the queued HID input reports limit using the :ref:`CONFIG_DESKTOP_HID_FORWARD_MAX_ENQUEUED_REPORTS ` Kconfig option. +#. Make sure that the value of :ref:`CONFIG_DESKTOP_HID_FORWARD_SUBSCRIBER_COUNT ` Kconfig option matches number of USB HID class instances configured in :ref:`nrf_desktop_usb_state`. + nRF Desktop dongle can use one or more instances of the USB HID class. + By default, the module uses a dedicated HID subscriber (USB HID class instance) for every BLE bonded HID peripheral. + For more details about interactions with USB, see the `Interaction with the USB`_ section. Implementation details ********************** @@ -63,7 +72,10 @@ Interaction with the USB The :ref:`nrf_desktop_usb_state` can be configured to have one or more instances of the HID-class USB device. If there is more than one instance of the HID-class USB device, this number must match the maximum number of bonded Bluetooth peripheral devices. -Each instance of HID-class USB device subscribes to HID reports forwarded by the |hid_forward|. +Each USB HID class instance subscribes to HID reports forwarded by the |hid_forward|. +Each USB HID class instance is assigned a separate :ref:`nrf_desktop_hid_reportq` instance when the related HID subscriber connects. +The assigned HID report queue instance is freed when the related HID subscriber disconnects. +Subscriber state changes are tracked relying on :c:struct:`hid_report_subscriber_event`. The |hid_forward| has an array of subscribers, one for each HID-class USB device. The possible cases that impact how the host to which the nRF desktop dongle is connected interprets the reports are as follows: @@ -93,33 +105,27 @@ Forwarding HID input reports After :ref:`nrf_desktop_ble_discovery` successfully discovers a connected peripheral, the |hid_forward| automatically subscribes for every HID input report provided by the peripheral. The subscriber can use either the HID boot protocol or the HID report protocol, but both protocols cannot be used at the same time. -In the current implementation, the :ref:`nrf_desktop_usb_state` supports either the HID boot keyboard or the HID boot mouse reports, because the HID boot protocol code is set using a single Kconfig option that is common for all of the instances of the USB HID. +In the current implementation, the :ref:`nrf_desktop_usb_state` supports either the HID boot keyboard or the HID boot mouse reports, because the application does not support assigning HID boot protocol code separately for each USB HID instance. The :c:func:`hogp_read` callback is called when HID input report is received from the connected peripheral. -The received HID input report data is converted to ``hid_report_event``. +The received HID input report data is passed to the HID report queue and converted to a :c:struct:`hid_report_event`. -``hid_report_event`` is submitted and then the HID-class USB device configured by :ref:`nrf_desktop_usb_state` forwards it to the host. -When a HID report is sent to the host by the HID-class USB device, the |hid_forward| receives a ``hid_report_sent_event`` with the identifier of this device. +The :c:struct:`hid_report_event` is submitted by the HID report queue and the HID-class USB device configured by :ref:`nrf_desktop_usb_state` forwards it to the host. +When a HID report is sent to the host by the HID-class USB instance, the |hid_forward| receives a :c:struct:`hid_report_sent_event` with the identifier of the instance. +The |hid_forward| notifies the HID report queue to ensure proper HID report flow. Enqueuing incoming HID input reports ------------------------------------ -The |hid_forward| forwards only one HID input report to the HID-class USB device at a time. -Another HID input report may be received from a peripheral connected over Bluetooth before the previous one was sent. -In that case, ``hid_report_event`` is enqueued and submitted later. -Up to the number of reports specified in :ref:`CONFIG_DESKTOP_HID_FORWARD_MAX_ENQUEUED_REPORTS ` Kconfig option can be enqueued at a time for each report type and for each HID subscriber (HID-class USB device). -If there is not enough space to enqueue a new event, the module drops the oldest enqueued event (of the same type) that was enqueued for a given HID subscriber. - -Upon receiving the ``hid_report_sent_event``, the |hid_forward| submits the ``hid_report_event`` enqueued for the peripheral that is associated with the HID-class USB device. -The enqueued report to be sent is chosen by the |hid_forward| in the round-robin fashion. -The report of the next type will be sent if available. -If not available, the next report type will be checked until a report is found or there is no report in any of the queues. -If there is no ``hid_report_event`` in the queue, the module waits for receiving data from peripherals. +USB HID class instances limit the maximum number of HID input reports that can be handled simultaneously. +The number of HID input reports received from HID peripherals connected over Bluetooth LE may exceed the limit. +If needed, the |hid_forward| relies on the HID report queue to locally enqueue HID input reports before providing them to the USB HID subscriber. +All HID input reports received from a HID peripheral go through the HID report queue utility associated with a given USB HID instance. Forwarding HID output reports ============================= -When the |hid_forward| receives a ``hid_report_event`` that contains an output report from a :ref:`nrf_desktop_usb_state`, it tries to forward the output report. +When the |hid_forward| receives a :c:struct:`hid_report_event` that contains an output report from a :ref:`nrf_desktop_usb_state`, it tries to forward the output report. The HID output report is forwarded to all of the Bluetooth connected peripherals that forward the HID data to the HID subscriber that is source of the HID output report. The HID output report is never forwarded to peripheral that does not support it. diff --git a/applications/nrf_desktop/doc/hid_reportq.rst b/applications/nrf_desktop/doc/hid_reportq.rst new file mode 100644 index 000000000000..712365a84956 --- /dev/null +++ b/applications/nrf_desktop/doc/hid_reportq.rst @@ -0,0 +1,84 @@ +.. _nrf_desktop_hid_reportq: + +HID report queue utility +######################## + +.. contents:: + :local: + :depth: 2 + +A HID subscriber (for example, a USB HID class instance handled by :ref:`nrf_desktop_usb_state`) limits the maximum number of HID input reports that can be handled simultaneously. +Enqueuing HID input reports locally at the source is necessary to prevent HID report drops when receiving more HID reports than can be handled by the subscriber. +The HID report queue utility can be used by an application module to simplify enqueuing HID input reports received from connected HID peripherals before providing them to HID subscriber. + +Configuration +************* + +Make sure that heap size (:kconfig:option:`CONFIG_HEAP_MEM_POOL_SIZE`) is large enough to handle the worst possible use case. +Data structures used to enqueue HID reports are dynamically allocated using the :c:func:`k_malloc` function. +When no longer needed, the structures are freed using the :c:func:`k_free` function. + +Use the :ref:`CONFIG_DESKTOP_HID_REPORTQ ` Kconfig option to enable the utility. +You can use the utility only on HID dongles (:ref:`CONFIG_DESKTOP_ROLE_HID_DONGLE `). + +You can configure the following properties: + +* Maximum number of enqueued HID reports (:ref:`CONFIG_DESKTOP_HID_REPORTQ_MAX_ENQUEUED_REPORTS `) +* Number of supported HID report queues (:ref:`CONFIG_DESKTOP_HID_REPORTQ_QUEUE_COUNT `) + +See Kconfig help for more details. + +Using HID report queue +********************** + +You can use the utility in a HID dongle's application module that handles receiving HID input reports from HID peripherals. +The module uses the utility as a middleware between a connected HID peripheral and a HID subscriber. +The module passes the received HID input report to the HID report queue utility. +The HID report queue utility submits the :c:struct:`hid_report_event` to pass the HID input report to the HID subscriber. +The following sections describe how to integrate HID report queue APIs in an application module. + +The :ref:`nrf_desktop_hid_forward` is an example of an application module that uses the HID report queue utility. +Refer to the module's implementation (:file:`src/modules/hid_forward.c`) for an example of HID report queue integration. + +Allocation +========== + +A HID report queue instance must be allocated with the :c:func:`hid_reportq_alloc` function before it is used. +A separate HID report queue object needs to be allocated for each HID report subscriber. +During allocation, the caller specifies the HID subscriber identifier. +The :c:func:`hid_reportq_get_sub_id` function can be used to access the identifier later. +After the HID report queue object is no longer used, it should be freed using the :c:func:`hid_reportq_free` function. + +HID subscriptions +================= + +A HID report queue instance tracks HID input report subscriptions enabled by a HID subscriber. +You can use the :c:func:`hid_reportq_subscribe` and :c:func:`hid_reportq_unsubscribe` functions to update the state of enabled subscriptions. +The functions should be called while handling a :c:struct:`hid_report_subscription_event` in the module using the HID reportq utility. +You can use the :c:func:`hid_reportq_is_subscribed` function to check if the subscription is enabled for the specified HID input report. + +Enqueuing HID input reports +=========================== + +If an application module uses the HID report queue instance to locally enqueue HID input reports for a given HID subscriber, every HID report intended for the subscriber should go through the HID report queue. +The application module can call the :c:func:`hid_reportq_report_add` function for a received HID input report to pass the report to the HID report queue utility. +The function allocates a :c:struct:`hid_report_event` for the received HID input report. +If a HID subscriber can handle the :c:struct:`hid_report_event`, the event is instantly passed to the subscriber. +Otherwise, the event is enqueued and will be submitted later. + +When a HID subscriber (for example, a USB HID class instance) delivers a HID input report to the HID host (on :c:struct:`hid_report_sent_event`), the :c:func:`hid_reportq_report_sent` API needs to be called to notify the HID report queue. +This allows the queue to track the state of HID reports provided to the HID subscriber. +If the HID report queue contains an enqueued report, the queue object will instantly submit the subsequent :c:struct:`hid_report_event`. +The enqueued report to be sent is chosen in the round-robin fashion from HID report IDs with enabled subscription. +The report with the next report ID will be sent if available. +If not available, the next report IDs will be checked until a report is found or until the utility detects that there are no more enqueued reports. + +API documentation +***************** + +Application modules can use the following API of the HID report queue: + +| Header file: :file:`applications/nrf_desktop/src/util/hid_reportq.h` +| Source file: :file:`applications/nrf_desktop/src/util/hid_reportq.c` + +.. doxygengroup:: hid_reportq diff --git a/applications/nrf_desktop/fwupd.rst b/applications/nrf_desktop/fwupd.rst index b184b155042d..c4cf487dedaf 100644 --- a/applications/nrf_desktop/fwupd.rst +++ b/applications/nrf_desktop/fwupd.rst @@ -19,6 +19,11 @@ The fwupd project allows communication with multiple types of devices through va The communication protocols are implemented using plugins. The plugin associated with the DFU protocol realized through the :ref:`nrf_desktop_config_channel` is branded as ``nordic_hid``. +.. note:: + The format version of the :file:`dfu_application.zip` file generated by the build system was updated from ``0`` to ``1`` since the |NCS| v2.7.0 release. + The format version ``1`` is supported by the fwupd since the 1.9.25 release. + Older releases do not support the format version of ``1``. + Adding a new device ******************* diff --git a/applications/nrf_desktop/modules.rst b/applications/nrf_desktop/modules.rst index 69ff8302f840..3edae6a8e45c 100644 --- a/applications/nrf_desktop/modules.rst +++ b/applications/nrf_desktop/modules.rst @@ -43,12 +43,14 @@ These are valid for events that have many listeners or sources, and are gathered doc/dfu.rst doc/dfu_mcumgr.rst doc/dfu_lock.rst + doc/dvfs.rst doc/factory_reset.rst doc/failsafe.rst doc/fast_pair_app.rst doc/fn_keys.rst doc/bas.rst doc/hid_forward.rst + doc/hid_reportq.rst doc/hid_state.rst doc/hid_state_pm.rst doc/hids.rst diff --git a/applications/nrf_desktop/src/modules/Kconfig.dvfs b/applications/nrf_desktop/src/modules/Kconfig.dvfs index e702f9ff18cf..8d72a5967e3b 100644 --- a/applications/nrf_desktop/src/modules/Kconfig.dvfs +++ b/applications/nrf_desktop/src/modules/Kconfig.dvfs @@ -5,8 +5,9 @@ # menuconfig DESKTOP_DVFS - bool "DVFS module" - depends on SOC_NRF54H20_CPUAPP + bool "DVFS module [EXPERIMENTAL]" + depends on SOC_NRF54H20_CPUAPP || SOC_NRF54H20_ENGB_CPUAPP + select EXPERIMENTAL select NRFS_DVFS_SERVICE_ENABLED select CLOCK_CONTROL select CLOCK_CONTROL_NRF2 diff --git a/applications/nrf_desktop/src/modules/Kconfig.hid_forward b/applications/nrf_desktop/src/modules/Kconfig.hid_forward index 89e7fd313748..52b243b26825 100644 --- a/applications/nrf_desktop/src/modules/Kconfig.hid_forward +++ b/applications/nrf_desktop/src/modules/Kconfig.hid_forward @@ -18,6 +18,19 @@ config DESKTOP_HID_FORWARD_ENABLE if DESKTOP_HID_FORWARD_ENABLE +config DESKTOP_HID_FORWARD_SUBSCRIBER_COUNT + int "Number of HID subscribers" + range 1 255 + default DESKTOP_HID_DONGLE_BOND_COUNT + help + By default, the module uses a dedicated HID subscriber (USB HID class + instance) for every BLE bonded HID peripheral. Set this option to 1 to + forward all of the HID reports received from HID peripherals to one + subscriber (required if using a single USB HID instance). + + The configured number of HID subscribers must match number of USB HID + class instances. + config BT_HOGP_REPORTS_MAX default 12 help diff --git a/applications/nrf_desktop/src/modules/hid_forward.c b/applications/nrf_desktop/src/modules/hid_forward.c index ae69d587ac8f..250342ad141f 100644 --- a/applications/nrf_desktop/src/modules/hid_forward.c +++ b/applications/nrf_desktop/src/modules/hid_forward.c @@ -58,7 +58,7 @@ struct hids_peripheral { uint8_t sub_id; }; -static struct subscriber subscribers[CONFIG_DESKTOP_HID_DONGLE_BOND_COUNT]; +static struct subscriber subscribers[CONFIG_DESKTOP_HID_FORWARD_SUBSCRIBER_COUNT]; static bt_addr_le_t peripheral_address[CONFIG_BT_MAX_PAIRED]; static struct hids_peripheral peripherals[CONFIG_BT_MAX_CONN]; static uint8_t peripheral_cache[CONFIG_BT_MAX_CONN]; @@ -68,7 +68,7 @@ static bool suspended; static void hogp_out_rep_write_cb(struct bt_hogp *hogp, struct bt_hogp_rep_info *rep, uint8_t err); static int send_hid_out_report(struct bt_hogp *hogp, const uint8_t *data, size_t size); -#if CONFIG_DESKTOP_HID_DONGLE_BOND_COUNT > 1 +#if CONFIG_DESKTOP_HID_FORWARD_SUBSCRIBER_COUNT > 1 static void verify_data(const struct bt_bond_info *info, void *user_data) { for (size_t i = 0; i < ARRAY_SIZE(peripheral_address); i++) { @@ -116,7 +116,7 @@ static int verify_peripheral_address(void) SETTINGS_STATIC_HANDLER_DEFINE(hid_forward, MODULE_NAME, NULL, settings_set, verify_peripheral_address, NULL); -#endif /* CONFIG_DESKTOP_HID_DONGLE_BOND_COUNT > 1 */ +#endif /* CONFIG_DESKTOP_HID_FORWARD_SUBSCRIBER_COUNT > 1 */ static int store_peripheral_address(void) { diff --git a/applications/nrf_desktop/src/util/hid_reportq.h b/applications/nrf_desktop/src/util/hid_reportq.h index ae06603f2a90..23bb070deb65 100644 --- a/applications/nrf_desktop/src/util/hid_reportq.h +++ b/applications/nrf_desktop/src/util/hid_reportq.h @@ -58,6 +58,12 @@ const void *hid_reportq_get_sub_id(struct hid_reportq *q); /** * @brief Add a HID report to the queue. * + * The function returns an error if HID report subscription is disabled for the added HID report. + * + * If number of enqueued reports with a given report ID exceeds limit defined by the configuration + * (@kconfig{CONFIG_DESKTOP_HID_REPORTQ_MAX_ENQUEUED_REPORTS}), the oldest enqueued HID report with + * the ID is dropped. + * * @param[in] q Pointer to the queue instance. * @param[in] src_id ID of HID report source. * @param[in] rep_id HID report ID. @@ -99,6 +105,9 @@ void hid_reportq_subscribe(struct hid_reportq *q, uint8_t rep_id); /** * @brief Unsubscribe from HID report with given ID. * + * Disabling subscription for a given HID report ID, drops all of the enqueued HID reports related + * to the ID. + * * @param[in] q Pointer to the queue instance. * @param[in] rep_id HID report ID. */ diff --git a/applications/nrf_desktop/sysbuild/CMakeLists.txt b/applications/nrf_desktop/sysbuild/CMakeLists.txt index 119d1ea1350b..04f7dc8905d4 100644 --- a/applications/nrf_desktop/sysbuild/CMakeLists.txt +++ b/applications/nrf_desktop/sysbuild/CMakeLists.txt @@ -7,11 +7,9 @@ # The application uses the configuration/ scheme for configuration files. set(SB_APPLICATION_CONFIG_DIR "${CMAKE_CURRENT_LIST_DIR}/../configuration/\${NORMALIZED_BOARD_TARGET}") -# Redirect images' configuration directories to use those in the board configuration directory -set(nrf_desktop_APPLICATION_CONFIG_DIR - "${CMAKE_CURRENT_LIST_DIR}/../configuration/\${NORMALIZED_BOARD_TARGET}" - CACHE INTERNAL "Application configuration dir controlled by sysbuild" -) +# The main application configuration directory is defined by the main application's +# `CMakeLists.txt` file (this allows to avoid dependency on main application name). +# Redirect other images' configuration directories to redefine configuration. set(mcuboot_APPLICATION_CONFIG_DIR "${CMAKE_CURRENT_LIST_DIR}/../configuration/\${NORMALIZED_BOARD_TARGET}/images/mcuboot" CACHE INTERNAL "Application configuration dir controlled by sysbuild" diff --git a/applications/sdp/gpio/CMakeLists.txt b/applications/sdp/gpio/CMakeLists.txt index ae182d38491a..af892a1058ec 100644 --- a/applications/sdp/gpio/CMakeLists.txt +++ b/applications/sdp/gpio/CMakeLists.txt @@ -7,12 +7,16 @@ cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) -project(emulated_gpio) +project(sdp_gpio) sdp_assembly_generate("${CMAKE_SOURCE_DIR}/src/hrt/hrt.c") +sdp_assembly_check("${CMAKE_SOURCE_DIR}/src/hrt/hrt.c") +sdp_assembly_prepare_install("${CMAKE_SOURCE_DIR}/src/hrt/hrt.c") target_sources(app PRIVATE src/main.c) target_sources(app PRIVATE src/hrt/hrt.s) target_sources_ifdef(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICMSG app PRIVATE src/backend/backend_icmsg.c) target_sources_ifdef(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICBMSG app PRIVATE src/backend/backend_icmsg.c) target_sources_ifdef(CONFIG_GPIO_NRFE_EGPIO_BACKEND_MBOX app PRIVATE src/backend/backend_mbox.c) + +add_dependencies(app asm_check) diff --git a/applications/sdp/gpio/sample.yaml b/applications/sdp/gpio/sample.yaml index cec7ec721708..15f653d3e7b1 100644 --- a/applications/sdp/gpio/sample.yaml +++ b/applications/sdp/gpio/sample.yaml @@ -1,11 +1,11 @@ sample: - name: eGPIO application - description: SW-defined GPIO application + name: SDP GPIO application + description: SDP GPIO application common: integration_platforms: - nrf54l15dk/nrf54l15/cpuflpr tests: - applications.sdp.egpio_mbox: + applications.sdp.gpio.mbox: build_only: true sysbuild: true platform_allow: nrf54l15dk/nrf54l15/cpuflpr @@ -15,7 +15,7 @@ tests: extra_configs: - CONFIG_GPIO_NRFE_EGPIO_BACKEND_MBOX=y - applications.sdp.egpio_icmsg: + applications.sdp.gpio.icmsg: build_only: true sysbuild: true platform_allow: nrf54l15dk/nrf54l15/cpuflpr @@ -27,7 +27,7 @@ tests: - CONFIG_IPC_SERVICE=y - CONFIG_IPC_SERVICE_BACKEND_ICMSG=y - applications.sdp.egpio_icbmsg: + applications.sdp.gpio.icbmsg: sysbuild: true build_only: true platform_allow: nrf54l15dk/nrf54l15/cpuflpr diff --git a/applications/sdp/gpio/src/backend/backend.h b/applications/sdp/gpio/src/backend/backend.h index 11bf13693232..bc3ee7a9ebc4 100644 --- a/applications/sdp/gpio/src/backend/backend.h +++ b/applications/sdp/gpio/src/backend/backend.h @@ -9,9 +9,9 @@ #include -#if !defined(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICMSG) && \ - !defined(CONFIG_GPIO_NRFE_EGPIO_BACKEND_MBOX) && \ - !defined(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICBMSG) +#if !IS_ENABLED(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICMSG) && \ + !IS_ENABLED(CONFIG_GPIO_NRFE_EGPIO_BACKEND_MBOX) && \ + !IS_ENABLED(CONFIG_GPIO_NRFE_EGPIO_BACKEND_ICBMSG) #error "Define communication backend type" #endif diff --git a/applications/sdp/gpio/src/backend/backend_mbox.c b/applications/sdp/gpio/src/backend/backend_mbox.c index ff8ccae4e4b2..def1431b9c4e 100644 --- a/applications/sdp/gpio/src/backend/backend_mbox.c +++ b/applications/sdp/gpio/src/backend/backend_mbox.c @@ -34,8 +34,9 @@ static void mbox_callback(const struct device *instance, uint32_t channel, void nrfe_gpio_mbox_data_t *rx_data = (nrfe_gpio_mbox_data_t *)user_data; /* Try and get lock for the shared data structure */ - if (atomic_flag_test_and_set(&rx_data->lock.locked)) { - /* Return in case lock is not acquired (used by other core)*/ + if (!atomic_cas(&rx_data->lock.locked, DATA_LOCK_STATE_WITH_DATA, DATA_LOCK_STATE_BUSY)) { + /* Return in case buffer is without data */ + atomic_set(&rx_data->lock.locked, DATA_LOCK_STATE_READY); return; } @@ -49,7 +50,7 @@ static void mbox_callback(const struct device *instance, uint32_t channel, void rx_data->lock.data_size = 0; /* We are finished with the shared data structure, so we can release the lock */ - atomic_flag_clear(&rx_data->lock.locked); + atomic_set(&rx_data->lock.locked, DATA_LOCK_STATE_READY); } /** @@ -88,8 +89,8 @@ int backend_init(backend_callback_t callback) } /* clear the buffer locks and their size holders */ - atomic_flag_clear(&rx_data->lock.locked); rx_data->lock.data_size = 0; + atomic_set(&rx_data->lock.locked, DATA_LOCK_STATE_READY); return 0; } diff --git a/applications/serial_lte_modem/overlay-native_tls.conf b/applications/serial_lte_modem/overlay-native_tls.conf index 2b00c7d02509..47842f5b1ae9 100644 --- a/applications/serial_lte_modem/overlay-native_tls.conf +++ b/applications/serial_lte_modem/overlay-native_tls.conf @@ -38,6 +38,8 @@ CONFIG_MBEDTLS_DTLS=y CONFIG_MBEDTLS_SSL_DTLS_CONNECTION_ID=y CONFIG_NET_SOCKETS_ENABLE_DTLS=y CONFIG_NET_IPV4=y +# Maximum timeout for TCP, TLS and DTLS connections +CONFIG_NET_SOCKETS_CONNECT_TIMEOUT=30000 # Enable AES CONFIG_MBEDTLS_AES_C=y CONFIG_MBEDTLS_CCM_C=y diff --git a/applications/serial_lte_modem/src/main.c b/applications/serial_lte_modem/src/main.c index b31b1b5a7117..1fb06d7db12a 100644 --- a/applications/serial_lte_modem/src/main.c +++ b/applications/serial_lte_modem/src/main.c @@ -428,6 +428,8 @@ int lte_auto_connect(void) { int err = 0; #if defined(CONFIG_SLM_AUTO_CONNECT) + int ret; + int n; int stat; struct network_config { /* Refer to AT command manual of %XSYSTEMMODE for system mode settings */ @@ -447,8 +449,8 @@ int lte_auto_connect(void) #include "slm_auto_connect.h" }; - err = slm_util_at_scanf("AT+CEREG?", "+CEREG: %d", &stat); - if (err != 1 || (stat == 1 || stat == 5)) { + ret = slm_util_at_scanf("AT+CEREG?", "+CEREG: %d,%d", &n, &stat); + if (ret != 2 || (stat == 1 || stat == 5)) { return 0; } diff --git a/boards/nordic/nrf52820dongle/Kconfig b/boards/nordic/nrf52820dongle/Kconfig deleted file mode 100644 index 4679fcb33c4c..000000000000 --- a/boards/nordic/nrf52820dongle/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -# -# Copyright (c) 2020 Nordic Semiconductor ASA -# -# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -# - -if BOARD_NRF52820DONGLE_NRF52820 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_NRF52820DONGLE_NRF52820 diff --git a/boards/nordic/nrf52820dongle/nrf52820dongle_nrf52820.dts b/boards/nordic/nrf52820dongle/nrf52820dongle_nrf52820.dts index e9353fd7e74f..0caafb2acd41 100644 --- a/boards/nordic/nrf52820dongle/nrf52820dongle_nrf52820.dts +++ b/boards/nordic/nrf52820dongle/nrf52820dongle_nrf52820.dts @@ -63,6 +63,10 @@ }; }; +®1 { + regulator-initial-mode = ; +}; + &uicr { gpio-as-nreset; }; diff --git a/boards/nordic/nrf52833dongle/Kconfig b/boards/nordic/nrf52833dongle/Kconfig deleted file mode 100644 index cba440d67d36..000000000000 --- a/boards/nordic/nrf52833dongle/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -# -# Copyright (c) 2020 Nordic Semiconductor ASA -# -# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -# - -if BOARD_NRF52833DONGLE_NRF52833 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_NRF52833DONGLE_NRF52833 diff --git a/boards/nordic/nrf52833dongle/nrf52833dongle_nrf52833.dts b/boards/nordic/nrf52833dongle/nrf52833dongle_nrf52833.dts index 10b5fca3b2c8..47c6b1fb85f2 100644 --- a/boards/nordic/nrf52833dongle/nrf52833dongle_nrf52833.dts +++ b/boards/nordic/nrf52833dongle/nrf52833dongle_nrf52833.dts @@ -63,6 +63,10 @@ }; }; +®1 { + regulator-initial-mode = ; +}; + &uicr { nfct-pins-as-gpios; gpio-as-nreset; diff --git a/boards/nordic/nrf52840gmouse/Kconfig b/boards/nordic/nrf52840gmouse/Kconfig deleted file mode 100644 index b3e016f313e4..000000000000 --- a/boards/nordic/nrf52840gmouse/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -# -# Copyright (c) 2018 Nordic Semiconductor -# -# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -# - -if BOARD_NRF52840GMOUSE_NRF52840 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_NRF52840GMOUSE_NRF52840 diff --git a/boards/nordic/nrf52840gmouse/nrf52840gmouse_nrf52840.dts b/boards/nordic/nrf52840gmouse/nrf52840gmouse_nrf52840.dts index 3aefa94f9a3b..930338135008 100644 --- a/boards/nordic/nrf52840gmouse/nrf52840gmouse_nrf52840.dts +++ b/boards/nordic/nrf52840gmouse/nrf52840gmouse_nrf52840.dts @@ -37,6 +37,10 @@ status = "okay"; }; +®1 { + regulator-initial-mode = ; +}; + &adc { status = "okay"; }; diff --git a/boards/nordic/nrf52dmouse/Kconfig b/boards/nordic/nrf52dmouse/Kconfig deleted file mode 100644 index 74e9135f18ee..000000000000 --- a/boards/nordic/nrf52dmouse/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -# -# Copyright (c) 2019 Nordic Semiconductor -# -# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -# - -if BOARD_NRF52DMOUSE_NRF52832 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_NRF52DMOUSE_NRF52832 diff --git a/boards/nordic/nrf52dmouse/nrf52dmouse_nrf52832.dts b/boards/nordic/nrf52dmouse/nrf52dmouse_nrf52832.dts index 0464c35af681..9800b7997301 100644 --- a/boards/nordic/nrf52dmouse/nrf52dmouse_nrf52832.dts +++ b/boards/nordic/nrf52dmouse/nrf52dmouse_nrf52832.dts @@ -25,6 +25,10 @@ }; }; +® { + regulator-initial-mode = ; +}; + &adc { status = "okay"; }; diff --git a/boards/nordic/nrf52kbd/Kconfig b/boards/nordic/nrf52kbd/Kconfig deleted file mode 100644 index 0a0d64b7ac45..000000000000 --- a/boards/nordic/nrf52kbd/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -# -# Copyright (c) 2019 Nordic Semiconductor -# -# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -# - -if BOARD_NRF52KBD_NRF52832 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_NRF52KBD_NRF52832 diff --git a/boards/nordic/nrf52kbd/nrf52kbd_nrf52832.dts b/boards/nordic/nrf52kbd/nrf52kbd_nrf52832.dts index 9fac378fa972..43ff80ceee64 100644 --- a/boards/nordic/nrf52kbd/nrf52kbd_nrf52832.dts +++ b/boards/nordic/nrf52kbd/nrf52kbd_nrf52832.dts @@ -25,6 +25,10 @@ }; }; +® { + regulator-initial-mode = ; +}; + &adc { status = "okay"; }; diff --git a/boards/nordic/thingy91/Kconfig b/boards/nordic/thingy91/Kconfig index 35bdd0ecdaff..516893391927 100644 --- a/boards/nordic/thingy91/Kconfig +++ b/boards/nordic/thingy91/Kconfig @@ -4,15 +4,6 @@ # # SPDX-License-Identifier: LicenseRef-Nordic-5-Clause -if BOARD_THINGY91_NRF52840 - -config BOARD_ENABLE_DCDC - bool "Enable DCDC mode" - select SOC_DCDC_NRF52X - default y - -endif # BOARD_THINGY91_NRF52840 - if BOARD_THINGY91_NRF9160 || BOARD_THINGY91_NRF9160_NS config BOARD_INIT_PRIORITY diff --git a/boards/nordic/thingy91/thingy91_nrf52840.dts b/boards/nordic/thingy91/thingy91_nrf52840.dts index 33b3b9319c20..46378bf23353 100644 --- a/boards/nordic/thingy91/thingy91_nrf52840.dts +++ b/boards/nordic/thingy91/thingy91_nrf52840.dts @@ -33,6 +33,10 @@ }; }; +®1 { + regulator-initial-mode = ; +}; + &adc { status = "okay"; }; diff --git a/cmake/sdp.cmake b/cmake/sdp.cmake index 599ed872d300..bbe5100533da 100644 --- a/cmake/sdp.cmake +++ b/cmake/sdp.cmake @@ -49,3 +49,41 @@ function(sdp_assembly_generate hrt_srcs) add_dependencies(asm_gen syscall_list_h_target) endfunction() + +function(sdp_assembly_check hrt_srcs) + set(asm_check_msg "Checking if ASM files for Hard Real Time have changed.") + + if(TARGET asm_check) + message(FATAL_ERROR "sdp_assembly_check() already called, please note that + sdp_assembly_check() must be called only once with a list of all source files." + ) + endif() + + string(REPLACE ";" "$" hrt_srcs_semi "${hrt_srcs}") + + add_custom_target(asm_check + COMMAND ${CMAKE_COMMAND} -D hrt_srcs="${hrt_srcs_semi}" -P ${ZEPHYR_NRF_MODULE_DIR}/cmake/sdp_asm_check.cmake + COMMENT ${asm_check_msg} + ) + + add_dependencies(asm_check asm_gen) + +endfunction() + +function(sdp_assembly_prepare_install hrt_srcs) + set(asm_install_msg "Updating ASM files for Hard Real Time.") + + if(TARGET asm_install) + message(FATAL_ERROR "sdp_assembly_prepare_install() already called, please note that + sdp_assembly_prepare_install() must be called only once with a list of all source files." + ) + endif() + + string(REPLACE ";" "$" hrt_srcs_semi "${hrt_srcs}") + + add_custom_target(asm_install + COMMAND ${CMAKE_COMMAND} -D hrt_srcs="${hrt_srcs_semi}" -P ${ZEPHYR_NRF_MODULE_DIR}/cmake/sdp_asm_install.cmake + COMMENT ${asm_install_msg} + ) + +endfunction() diff --git a/cmake/sdp_asm_check.cmake b/cmake/sdp_asm_check.cmake new file mode 100644 index 000000000000..8af14542546a --- /dev/null +++ b/cmake/sdp_asm_check.cmake @@ -0,0 +1,30 @@ +# +# Copyright (c) 2024 Nordic Semiconductor ASA +# +# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause +# + +function(asm_check) + + foreach(hrt_src ${hrt_srcs}) + get_filename_component(asm_filename ${hrt_src} NAME_WE) # filename without extension + get_filename_component(src_dir ${hrt_src} DIRECTORY) + + execute_process(COMMAND ${CMAKE_COMMAND} -E compare_files --ignore-eol + ${src_dir}/${asm_filename}.s ${asm_filename}-temp.s + RESULT_VARIABLE compare_result) + + if( compare_result EQUAL 0) + message("File ${asm_filename}.s has not changed.") + elseif( compare_result EQUAL 1) + message(WARNING "${asm_filename}.s ASM file content has changed.\ + If you want to include the new ASM in build, \ + please run `ninja asm_install` in FLPR build directory and build again") + else() + message("Something went wrong when comparing ${asm_filename}.s and ${asm_filename}-temp.s") + endif() + endforeach() + +endfunction(asm_check) + +asm_check() diff --git a/cmake/sdp_asm_install.cmake b/cmake/sdp_asm_install.cmake new file mode 100644 index 000000000000..42d823db4dab --- /dev/null +++ b/cmake/sdp_asm_install.cmake @@ -0,0 +1,25 @@ +# +# Copyright (c) 2024 Nordic Semiconductor ASA +# +# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause +# + +function(asm_install) + + foreach(hrt_src ${hrt_srcs}) + get_filename_component(asm_filename ${hrt_src} NAME_WE) # filename without extension + get_filename_component(src_dir ${hrt_src} DIRECTORY) + + file(RENAME ${asm_filename}-temp.s ${src_dir}/${asm_filename}.s RESULT rename_result) + + if (rename_result EQUAL 0) + message("Updated ${asm_filename}.s ASM file.") + else() + message(WARNING "${asm_filename}.s cannot be updated, new ASM does not exist. Please run ninja asm_gen to create one.") + endif() + + endforeach() + +endfunction(asm_install) + +asm_install() diff --git a/cmake/sysbuild/debug_keys.cmake b/cmake/sysbuild/debug_keys.cmake index af94348d00ef..bcf9def42dde 100644 --- a/cmake/sysbuild/debug_keys.cmake +++ b/cmake/sysbuild/debug_keys.cmake @@ -47,12 +47,14 @@ if(NOT SB_CONFIG_SECURE_BOOT_SIGNING_CUSTOM AND "${SB_CONFIG_SECURE_BOOT_SIGNING ) set(SIGN_KEY_FILE_DEPENDS debug_sign_key_target) else() - if(IS_ABSOLUTE ${SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE}) - set(SIGNATURE_PRIVATE_KEY_FILE ${SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE}) + string(CONFIGURE "${SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE}" keyfile) + if(IS_ABSOLUTE ${keyfile}) + set(SIGNATURE_PRIVATE_KEY_FILE ${keyfile}) else() # Resolve path relative to the application configuration directory. - set(SIGNATURE_PRIVATE_KEY_FILE ${APPLICATION_CONFIG_DIR}/${SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE}) + set(SIGNATURE_PRIVATE_KEY_FILE ${APPLICATION_CONFIG_DIR}/${keyfile}) endif() + set(keyfile) if(NOT EXISTS ${SIGNATURE_PRIVATE_KEY_FILE}) message(FATAL_ERROR "Config points to non-existing PEM file '${SIGNATURE_PRIVATE_KEY_FILE}'") diff --git a/cmake/sysbuild/image_signing.cmake b/cmake/sysbuild/image_signing.cmake index 7710e6df9a0e..9ab1e3085712 100644 --- a/cmake/sysbuild/image_signing.cmake +++ b/cmake/sysbuild/image_signing.cmake @@ -19,6 +19,8 @@ endfunction() function(zephyr_mcuboot_tasks) set(keyfile "${CONFIG_MCUBOOT_SIGNATURE_KEY_FILE}") set(keyfile_enc "${CONFIG_MCUBOOT_ENCRYPTION_KEY_FILE}") + string(CONFIGURE "${keyfile}" keyfile) + string(CONFIGURE "${keyfile_enc}" keyfile_enc) if(NOT "${CONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE}") # Check for misconfiguration. diff --git a/cmake/sysbuild/nrf700x.cmake b/cmake/sysbuild/nrf700x.cmake index 740e7d9349c0..35faa4d617b9 100644 --- a/cmake/sysbuild/nrf700x.cmake +++ b/cmake/sysbuild/nrf700x.cmake @@ -16,6 +16,8 @@ function(setup_nrf700x_xip_data) set(NRF70_PATCH ${NRF70_FW_BINS}/radio_test/nrf70.bin) elseif(SB_CONFIG_WIFI_NRF70_SCAN_ONLY) set(NRF70_PATCH ${NRF70_FW_BINS}/scan_only/nrf70.bin) + elseif(SB_CONFIG_WIFI_NRF70_OFFLOADED_RAW_TX) + set(NRF70_PATCH ${NRF70_FW_BINS}/offloaded_raw_tx/nrf70.bin) elseif(SB_CONFIG_WIFI_NRF70_SYSTEM_WITH_RAW_MODES) set(NRF70_PATCH ${NRF70_FW_BINS}/system_with_raw/nrf70.bin) else() diff --git a/cmake/sysbuild/sdp.cmake b/cmake/sysbuild/sdp.cmake index c9b8ce1bb5da..509348c02fe2 100644 --- a/cmake/sysbuild/sdp.cmake +++ b/cmake/sysbuild/sdp.cmake @@ -15,7 +15,7 @@ function(egpio_update_kconfig) if(DEFINED SB_CONFIG_SOC_NRF54L15) sysbuild_cache_set(VAR flpr_egpio_EXTRA_DTC_OVERLAY_FILE APPEND REMOVE_DUPLICATES "./boards/nrf54l15dk_nrf54l15_cpuflpr_mbox.overlay") endif() - sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "emulated-gpio-mbox") + sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "sdp-gpio-mbox") message(STATUS "eGPIO: Using MBOX backend") elseif(SB_CONFIG_EGPIO_BACKEND_ICMSG) foreach(image ${PRE_CMAKE_IMAGES}) @@ -26,7 +26,7 @@ function(egpio_update_kconfig) if(DEFINED SB_CONFIG_SOC_NRF54L15) sysbuild_cache_set(VAR flpr_egpio_EXTRA_DTC_OVERLAY_FILE APPEND REMOVE_DUPLICATES "./boards/nrf54l15dk_nrf54l15_cpuflpr_icmsg.overlay") endif() - sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "emulated-gpio-icmsg") + sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "sdp-gpio-icmsg") message(STATUS "eGPIO: Using ICMSG backend") elseif(SB_CONFIG_EGPIO_BACKEND_ICBMSG) foreach(image ${PRE_CMAKE_IMAGES}) @@ -38,7 +38,7 @@ function(egpio_update_kconfig) if(DEFINED SB_CONFIG_SOC_NRF54L15) sysbuild_cache_set(VAR flpr_egpio_EXTRA_DTC_OVERLAY_FILE APPEND REMOVE_DUPLICATES "./boards/nrf54l15dk_nrf54l15_cpuflpr_icbmsg.overlay") endif() - sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "emulated-gpio-icbmsg") + sysbuild_cache_set(VAR ${DEFAULT_IMAGE}_SNIPPET APPEND REMOVE_DUPLICATES "sdp-gpio-icbmsg") message(STATUS "eGPIO: Using ICBMSG backend") endif() endfunction() diff --git a/cmake/sysbuild/sign.cmake b/cmake/sysbuild/sign.cmake index 3881744c56d0..bc504b1bcb33 100644 --- a/cmake/sysbuild/sign.cmake +++ b/cmake/sysbuild/sign.cmake @@ -30,8 +30,8 @@ function(b0_gen_keys) -out ${SIGNATURE_PUBLIC_KEY_FILE} ) elseif(SB_CONFIG_SECURE_BOOT_SIGNING_CUSTOM) - set(SIGNATURE_PUBLIC_KEY_FILE ${SB_CONFIG_SECURE_BOOT_SIGNING_PUBLIC_KEY}) - set(SIGNATURE_PUBLIC_KEY_FILE ${SB_CONFIG_SECURE_BOOT_SIGNING_PUBLIC_KEY} PARENT_SCOPE) + string(CONFIGURE "${SB_CONFIG_SECURE_BOOT_SIGNING_PUBLIC_KEY}" SIGNATURE_PUBLIC_KEY_FILE) + set(SIGNATURE_PUBLIC_KEY_FILE ${SIGNATURE_PUBLIC_KEY_FILE} PARENT_SCOPE) if(NOT EXISTS ${SIGNATURE_PUBLIC_KEY_FILE} OR IS_DIRECTORY ${SIGNATURE_PUBLIC_KEY_FILE}) message(WARNING "Invalid public key file: ${SIGNATURE_PUBLIC_KEY_FILE}") @@ -165,6 +165,7 @@ function(b0_sign_image slot) ) elseif(SB_CONFIG_SECURE_BOOT_SIGNING_CUSTOM) set(custom_sign_cmd "${SB_CONFIG_SECURE_BOOT_SIGNING_COMMAND}") + string(CONFIGURE "${custom_sign_cmd}" custom_sign_cmd) if (("${custom_sign_cmd}" STREQUAL "") OR (NOT EXISTS ${SIGNATURE_PUBLIC_KEY_FILE})) message(FATAL_ERROR "You must specify a signing command and valid public key file for custom signing.") diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt index fb5723c7ba8d..f99a96c245e2 100644 --- a/doc/CMakeLists.txt +++ b/doc/CMakeLists.txt @@ -335,6 +335,11 @@ add_docset(matter "1.3.0") add_docset(nrfxlib ${NRF_VERSION}) add_doxygen_docset(nrfxlib ${ZEPHYR_NRFXLIB_MODULE_DIR} ${NRF_VERSION}) +#------------------------------------------------------------------------------- +# docset: wifi + +add_doxygen_docset(wifi ${ZEPHYR_HAL_NORDIC_MODULE_DIR} "" STANDALONE) + #------------------------------------------------------------------------------- # docset: internal @@ -405,6 +410,7 @@ add_dependencies(build-all tfm-all matter-all kconfig-all + wifi ) if (EXISTS "${ZEPHYR_DOC_INTERNAL_MODULE_DIR}" ) add_dependencies(build-all internal-all) diff --git a/doc/_utils/redirects.py b/doc/_utils/redirects.py index 01292ab4c982..7bd6adc0cce3 100644 --- a/doc/_utils/redirects.py +++ b/doc/_utils/redirects.py @@ -416,6 +416,7 @@ ("applications/nrf5340_audio/README", "applications/nrf5340_audio/index"), # nRF5340 Audio applications (landing) ("samples/samples_bl", "samples/bl"), # Bluetooth samples (landing) ("samples/bluetooth/connection_event_trigger/README", "samples/bluetooth/event_trigger/README"), + ("samples/bluetooth/broadcast_config_tool/README", "samples/bluetooth/nrf_auraconfig/README"), ("samples/samples_nrf9160", "samples/cellular"), # Cellular samples (landing) ("samples/samples_crypto", "samples/crypto"), # Cryptography samples (landing) ("samples/samples_edge", "samples/edge"), # Edge Impulse samples (landing) diff --git a/doc/nrf/app_dev/board_support/board_names.rst b/doc/nrf/app_dev/board_support/board_names.rst index b3efa6d2d16a..c616791e3a5c 100644 --- a/doc/nrf/app_dev/board_support/board_names.rst +++ b/doc/nrf/app_dev/board_support/board_names.rst @@ -11,10 +11,10 @@ Board names The following tables list all boards and corresponding board targets for Nordic Semiconductor's hardware platforms. The board targets follow Zephyr's :ref:`zephyr:board_terminology` scheme and are used mostly when :ref:`building`. -For example, the board target ``nrf54l15pdk@0.2.1/nrf54l15/cpuapp`` can be read as made of the following elements: +For example, the board target ``nrf54l15dk/nrf54l15/cpuapp`` can be read as made of the following elements: +-------------+----------------+-------------------------+---------------------------------+--------------------------------------------------+ -| nrf54l15pdk | @0.2.1 | /nrf54l15 | /cpuapp | | +| nrf54l15dk | | /nrf54l15 | /cpuapp | | +=============+================+=========================+=================================+==================================================+ | Board name | Board revision | Board qualifier for SoC | Board qualifier for CPU cluster | Board qualifier for variant (empty in this case) | +-------------+----------------+-------------------------+---------------------------------+--------------------------------------------------+ diff --git a/doc/nrf/app_dev/bootloaders_dfu/index.rst b/doc/nrf/app_dev/bootloaders_dfu/index.rst index 2b9b73b4f266..4b63da0d780a 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/index.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/index.rst @@ -53,3 +53,4 @@ To learn more, refer to the following documentation pages: qspi_xip_split_image dfu_tools_mcumgr_cli mcuboot_image_compression + sysbuild_image_ids diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_image_compression.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_image_compression.rst index 4a87348d34a2..1d71b1b1834f 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_image_compression.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_image_compression.rst @@ -55,17 +55,17 @@ The following shows an example static Partition Manager layout for image compres .. group-tab:: nRF52840 - .. literalinclude:: ../../../../tests/subsys/nrf_compress/decompression/mcuboot_update/pm_static_nrf52840dk_nrf52840.yml + .. literalinclude:: ../../../../samples/nrf_compress/mcuboot_update/pm_static_nrf52840dk_nrf52840.yml :language: yaml .. group-tab:: nRF5340 - .. literalinclude:: ../../../../tests/subsys/nrf_compress/decompression/mcuboot_update/pm_static_nrf5340dk_nrf5340_cpuapp.yml + .. literalinclude:: ../../../../samples/nrf_compress/mcuboot_update/pm_static_nrf5340dk_nrf5340_cpuapp.yml :language: yaml .. group-tab:: nRF54L15 - .. literalinclude:: ../../../../tests/subsys/nrf_compress/decompression/mcuboot_update/pm_static_nrf54l15dk_nrf54l15_cpuapp.yml + .. literalinclude:: ../../../../samples/nrf_compress/mcuboot_update/pm_static_nrf54l15dk_nrf54l15_cpuapp.yml :language: yaml Required sysbuild configuration options diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst index b4271548dadf..11abb17cc51f 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst @@ -11,6 +11,48 @@ Partitioning device memory is a crucial aspect of managing how a device's storag By default, the Partition Manager in the system dynamically generates a partition map, which is suitable for most applications that do not use Device Firmware Upgrades (DFU). For scenarios involving DFU, read the following sections. +.. _bootloader_partitioning_partitions_file: + +Partition map file +****************** + +After you enable the Partition Manager, it will :ref:`start generating ` the :file:`partitions.yml` file in the build folder directory. +In this file, you will see detailed information about the memory layout used for the build. + +The :file:`partitions.yml` file is present also if the Partition Manager generates the partition map dynamically. +You can use this file as a base for your static partition map. + +.. _bootloader_partitioning_partitions_file_report: + +Partition reports +================= + +After building the application, you can print a report of how the partitioning has been handled for a bootloader, or combination of bootloaders, by using partition memory reports. + +Depending on your development environment, you can use one of the following options: + +.. tabs:: + + .. group-tab:: nRF Connect for VS Code + + Use the extension's `Memory report`_ feature, which shows the size and percentage of memory that each symbol uses on your device for RAM, ROM, and partitions. + Click the :guilabel:`Memory report` button in the :guilabel:`Actions View` to generate the report. + The partition map is available in the :guilabel:`Partitions` tab. + + Alternatively, you can also use the `Memory Explorer `_ feature of the extension's nRF Debug to check memory sections for the partitions. + This feature requires `enabling debugging in the build configuration `_ and providing the partition addresses manually. + + .. group-tab:: Command line + + Use the Partition Manager's :ref:`pm_partition_reports` feature. + Run the following command: + + .. code-block:: console + + west build -t partition_manager_report + + This command generates an output in ASCII with the addresses and sizes of each partition. + .. _ug_bootloader_flash_static_requirement: Static partition requirement for DFU @@ -22,13 +64,6 @@ This is important also when you use a precompiled HEX file as a child image (sub In such cases, the newly generated application images may no longer use a partition map that is compatible with the partition map used by the bootloader. As a result, the newly built application image may not be bootable by the bootloader. -.. note:: - For detailed information about the memory layout used for the build, see the partition configuration in the :file:`partitions.yml` file, located in the build folder directory, or run ``ninja partition_manager_report``. - You must enable the Partition Manager to make the :file:`partitions.yml` file and the ``partition_manager_report`` target available. - - The :file:`partitions.yml` file is present also if the Partition Manager generates the partition map dynamically. - You can use this file as a base for your static partition map. - The memory partitions that must be defined in the static partition map depend on the selected bootloader chain. For details, see :ref:`ug_bootloader_flash`. @@ -39,7 +74,7 @@ Flash memory partitions Each bootloader handles flash memory partitioning differently. -After building the application, you can print a report of how the flash partitioning has been handled for a bootloader, or combination of bootloaders, by using :ref:`pm_partition_reports`. +After building the application, you can print a report of how the flash partitioning has been handled for a bootloader, or combination of bootloaders, by using :ref:`bootloader_partitioning_partitions_file_report`. .. _ug_bootloader_flash_b0: @@ -64,7 +99,7 @@ This is particularly useful in memory-constrained devices to avoid providing spa See the *Image Slots* section in the :doc:`MCUboot documentation ` for more information. The |NCS| variant of MCUboot uses the :ref:`partition_manager` to configure the flash memory partitions for these image slots. -In the default configuration, defined in :file:`bootloader/mcuboot/boot/zephyr/pm.yml`, the partition manager dynamically sets up the partitions as required for MCUboot. +In the default configuration, defined in :file:`bootloader/mcuboot/boot/zephyr/pm.yml`, the Partition Manager dynamically sets up the partitions as required for MCUboot. For example, the partition layout for :file:`zephyr/samples/hello_world` using MCUboot on the ``nrf52840dk`` board would look like the following: .. code-block:: console @@ -82,16 +117,11 @@ For example, the partition layout for :file:`zephyr/samples/hello_world` using M You can also store secondary slot images in external flash memory when using MCUboot. See :ref:`ug_bootloader_external_flash` for more information. - .. _ug_bootloader_external_flash: Using external flash memory partitions ************************************** -.. contents:: - :local: - :depth: 2 - When using MCUboot, you can store the storage partition for the secondary slot in the external flash memory, using a driver for the external flash memory that supports the following features: * Single-byte read and write. @@ -112,7 +142,7 @@ To enable external flash with MCUboot, complete the following steps: .. note:: - The :ref:`partition_manager` will only support run-time access to flash partitions defined in regions placed on external flash devices that have drivers compiled in. + The Partition Manager will only support run-time access to flash partitions defined in regions placed on external flash devices that have drivers compiled in. The Partition Manager cannot determine which partitions will be used at runtime, but only those that have drivers enabled, and those are included into the partition map. Lack of partition access will cause MCUboot to fail at runtime. For more details on configuring and enabling access to external flash devices, see :ref:`pm_external_flash`. @@ -126,6 +156,11 @@ See also :ref:`ug_multi_image_variables` for more details on how to pass configu Troubleshooting *************** +This section describes some of the issues you might come across when partitioning device memory. + +MCUboot failure +=============== + MCUboot could fail, reporting the following error: .. code-block:: console @@ -139,7 +174,7 @@ MCUboot could fail, reporting the following error: This error could be caused by the following issues: - * The external flash driver for the application image partitions used by MCUboot is not enabled or an incorrect Kconfig option has been given to the ``DEFAULT_DRIVER_KCONFIG`` of the partition manager external region definition. + * The external flash driver for the application image partitions used by MCUboot is not enabled or an incorrect Kconfig option has been given to the ``DEFAULT_DRIVER_KCONFIG`` of the Partition Manager external region definition. See :ref:`pm_external_flash` for details. * An out-of-tree external flash driver is not selecting :kconfig:option:`CONFIG_PM_EXTERNAL_FLASH_HAS_DRIVER`, resulting in partitions for images located in the external flash memory being not accessible. @@ -148,6 +183,9 @@ This error could be caused by the following issues: * Insufficient value set for the ``CONFIG_BOOT_MAX_IMG_SECTORS`` Kconfig option, as MCUboot typically increases slot sizes when external flash is enabled. See `MCUboot's Kconfig options used in Zephyr `_ for details. +Compilation failure +=================== + The compilation could fail, reporting a linker error similar to following: .. code-block:: console diff --git a/doc/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.rst b/doc/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.rst new file mode 100644 index 000000000000..3f1ca76b162d --- /dev/null +++ b/doc/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.rst @@ -0,0 +1,109 @@ +.. _sysbuild_assigned_images_ids: + +Sysbuild-assigned image IDs +########################### + +.. contents:: + :local: + :depth: 2 + +When using sysbuild in |NCS| with MCUboot, the build system automatically assigns image IDs based on your project configuration. + +Sysbuild has the following configuration options that display the image IDs assigned to each image. +A value of ``-1`` indicates that the image is not present: + +.. note:: + These options are also shared with MCUboot and the main application through Kconfig values, except for the ``SB_CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER`` option, which is exclusive to MCUboot. + ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ +| Kconfig option (sysbuild) | Kconfig option (application/MCUboot) | Description | Dependencies | ++=================================================+============================================================+==============================================+==============================================================================================================+ +| ``SB_CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER` | Image number for application update | -- | ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER` | Image number for network core update | nRF5340 device and ``SB_CONFIG_NETCORE_APP_UPDATE`` | ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_WIFI_PATCHES_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_WIFI_PATCHES_IMAGE_NUMBER` | Image number for Wi-Fi-patch update | nRF7x device used and ``SB_CONFIG_WIFI_PATCHES_EXT_FLASH_XIP`` or ``SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE`` | ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_QSPI_XIP_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_QSPI_XIP_IMAGE_NUMBER` | Image number for QSPI XIP split image update | nRF52840 or nRF5340 device and ``SB_CONFIG_QSPI_XIP_SPLIT_IMAGE`` | ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER` | Image number for MCUboot update | ``SB_CONFIG_SECURE_BOOT_APPCORE`` | +| | (only set for MCUboot image) | | | ++-------------------------------------------------+------------------------------------------------------------+----------------------------------------------+--------------------------------------------------------------------------------------------------------------+ + +The following configuration options specify the number of images and how these image numbers are configured: + ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Kconfig option (sysbuild) | Description | ++========================================================+======================================================================================================================================================+ +| ``SB_CONFIG_MCUBOOT_MIN_UPDATEABLE_IMAGES`` | Minimum number of MCUboot images | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_MIN_ADDITIONAL_UPDATEABLE_IMAGES`` | Minimum number of additional MCUboot images for MCUboot only (see :ref:`sysbuild_assigned_images_ids_mcuboot_only`) | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_MAX_UPDATEABLE_IMAGES`` | Maximum number of MCUboot images | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES`` | Number of MCUboot images to set in images | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_ADDITIONAL_UPDATEABLE_IMAGES`` | Number of additional MCUboot images to include in MCUboot (see :ref:`sysbuild_assigned_images_ids_mcuboot_only`) | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ +| ``SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES`` | If enabled, this option sets the number of MCUboot images for both MCUboot and the main application. | +| | If disabled, it sets the number only for the MCUboot image. | ++--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ + +See :ref:`configuring_kconfig` for information about how to configure these options. + +.. _sysbuild_assigned_images_ids_mcuboot_only: + +MCUboot-only images +******************* + +Some images are visible only to MCUboot, allowing it to manage them independently of the main application. +This setup supports features like shared secondary slots. +Currently, MCUboot uses this capability to update itself, which can be enabled with secure boot. +MCUboot then shares the main application's secondary slot for firmware updates. +However, it directly transfers the update to the designated MCUboot image slot, which is then booted by :ref:`bootloader`. + +The main application does not need to be aware of this process; it only needs to handle an MCUboot update as it would any normal application update and reboot to apply changes. +This functionality is possible because there are additional MCUboot-only images that are not accessible to the main application and are configured only within MCUboot. + +The total number of images configured in MCUboot is the sum of ``SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES`` and ``SB_CONFIG_MCUBOOT_ADDITIONAL_UPDATEABLE_IMAGES``. +If ``SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES`` is enabled, the main application sets only ``SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES``. +Otherwise, it is not set. + +Getting image IDs in an application +*********************************** + +When building with sysbuild, the image IDs are provided to the application through Kconfig values and can be used in the code as needed. +These image IDs are also used in |NCS| hooks for various tasks (such as :ref:`nRF5340 network core updates `), so no additional configuration is required. + +Image numbers +************* + +Image numbers are assigned in ascending order based on the following priority: + ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ +| Image | Value (if all enabled) | Kconfig option (sysbuild) | Kconfig option (application/MCUboot) | ++======================+================================+=================================================+============================================================+ +| Application | 0 | ``SB_CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER` | ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ +| Network core | 1 | ``SB_CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER` | ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ +| nRF7x Wi-Fi patch | 2 | ``SB_CONFIG_MCUBOOT_WIFI_PATCHES_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_WIFI_PATCHES_IMAGE_NUMBER` | ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ +| QSPI XIP split image | 3 | ``SB_CONFIG_MCUBOOT_QSPI_XIP_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_QSPI_XIP_IMAGE_NUMBER` | ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ +| MCUboot | 4 (only set for MCUboot image) | ``SB_CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER`` | :kconfig:option:`CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER` | ++----------------------+--------------------------------+-------------------------------------------------+------------------------------------------------------------+ + +MCUboot update package version +****************************** + +When MCUboot updates are enabled, the firmware embeds the |NSIB| version using the :kconfig:option:`CONFIG_FW_INFO_FIRMWARE_VERSION` Kconfig option. +However, during an update, MCUboot does not check this version; it only checks the MCUboot package version. + +You can set the MCUboot update package version in sysbuild with ``SB_CONFIG_SECURE_BOOT_MCUBOOT_VERSION``. +You must increase this version number when deploying an MCUboot update. +If the version in the update is lower than the current version, MCUboot will reject the update and not transfer it to the opposing secure boot firmware slot. + +Additionally, make sure to load the correct update image onto the device. +If MCUboot is currently running from the ``s0`` slot, then you must use the ``s1`` update, and if it is running from the ``s1`` slot, then you must use the ``s0`` update. +If you upload to the wrong slot image, MCUboot will reject the update. diff --git a/doc/nrf/app_dev/companion_components.rst b/doc/nrf/app_dev/companion_components.rst index a848fd89c7c4..09de6703cb5f 100644 --- a/doc/nrf/app_dev/companion_components.rst +++ b/doc/nrf/app_dev/companion_components.rst @@ -41,7 +41,7 @@ The following table lists the available companion components: - :ref:`mcuboot:mcuboot_ncs` * - `Trusted Firmware-M (TF-M) `_ - Platform security architecture reference implementation aligning with PSA Certified guidelines, enabling chips, Real Time Operating Systems and devices to become PSA Certified. - - :ref:`nRF91 Series devices `, :ref:`nRF54L15 PDK `, :ref:`nRF54H20 DK `, :ref:`nRF5340 DK `, :ref:`Thingy:53 ` + - :ref:`nRF91 Series devices `, :ref:`nRF54L15 DK `, :ref:`nRF54H20 DK `, :ref:`nRF5340 DK `, :ref:`Thingy:53 ` - :file:`ncs/modules/tee/tf-m` (external module), :file:`ncs/nrf/modules/trusted-firmware-m` (integration files) - :ref:`ug_tfm` * - :ref:`bootloader` @@ -59,3 +59,13 @@ The following table lists the available companion components: - :ref:`Sample requirements ` - :file:`samples/suit/recovery` - :ref:`Sample's building and running section ` + * - :ref:`Secure Domain Firmware ` + - Secure Domain Firmware exposes security services to the other cores through an IPC interface and is part of Platform Root of Trust (PRoT). + - :ref:`nRF54H20 DK ` + - :file:`nrf54h20_soc_binaries_v0.6.5.zip` (This component is not yet fully integrated in the |NCS| and is currently distributed as a bundle.) + - :ref:`ug_nrf54h20_SoC_binaries` + * - :ref:`System Controller Firmware ` + - System Controller Firmware performs system clock and power management operations delegated by Secure Domain and is part of Platform Root of Trust (PRoT). + - :ref:`nRF54H20 DK ` + - :file:`nrf54h20_soc_binaries_v0.6.5.zip` (This component is not yet fully integrated in the |NCS| and is currently distributed as a bundle.) + - :ref:`ug_nrf54h20_SoC_binaries` diff --git a/doc/nrf/app_dev/config_and_build/building.rst b/doc/nrf/app_dev/config_and_build/building.rst index 390e01521bb8..5993a55d1c19 100644 --- a/doc/nrf/app_dev/config_and_build/building.rst +++ b/doc/nrf/app_dev/config_and_build/building.rst @@ -16,12 +16,13 @@ Just as for creating the application, you can build the application using either .. group-tab:: nRF Connect for VS Code - For instructions about building with the |nRFVSC|, see `How to build an application`_ in the extension documentation. + To build with the |nRFVSC|, you first need to create a build configuration. + For instructions, see `How to build an application`_ in the extension documentation. By default, the extension runs both stages of the CMake build (:ref:`configuration phase and building phase `). If you want to only set up the build configuration without building it, make sure the :guilabel:`Build after generating configuration` is not selected. - To build with :ref:`configuration_system_overview_sysbuild`, select the :guilabel:`Use sysbuild` checkbox. + To build with :ref:`configuration_system_overview_sysbuild`, :ref:`keep the default setting selected ` or select the :guilabel:`Use sysbuild` radio button. If you want to build with custom options or scripts, read about `Binding custom tasks to actions`_ in the extension documentation. diff --git a/doc/nrf/app_dev/config_and_build/cmake/index.rst b/doc/nrf/app_dev/config_and_build/cmake/index.rst index 2a97747acb51..283e33edaef3 100644 --- a/doc/nrf/app_dev/config_and_build/cmake/index.rst +++ b/doc/nrf/app_dev/config_and_build/cmake/index.rst @@ -115,12 +115,14 @@ This is how you can specify them: See `How to build an application`_ in the |nRFVSC| documentation. You can specify the additional configuration variables when `setting up a build configuration `_: - * :makevar:`FILE_SUFFIX` (and :makevar:`CONF_FILE`) - Select the configuration in the :guilabel:`Configuration` menu. - * :makevar:`EXTRA_CONF_FILE` - Add the Kconfig fragment file in the :guilabel:`Kconfig fragments` menu. - * :makevar:`EXTRA_DTC_OVERLAY_FILE` - Add the devicetree overlays in the :guilabel:`Devicetree overlays` menu. + * :makevar:`FILE_SUFFIX` (and :makevar:`CONF_FILE`) - Select the configuration in the :guilabel:`Base configuration files` menu. + * :makevar:`EXTRA_CONF_FILE` - Add the Kconfig fragment file in the :guilabel:`Extra Kconfig fragments` menu. + * :makevar:`DTC_OVERLAY_FILE` - Select the configuration in the :guilabel:`Base devicetree overlays` menu. + * :makevar:`EXTRA_DTC_OVERLAY_FILE` - Add the devicetree overlays in the :guilabel:`Extra devicetree overlays` menu. + * :makevar:`SNIPPET` - Select the snippet from the list in the :guilabel:`Snippets` menu. * Other variables - Provide CMake arguments in the :guilabel:`Extra CMake arguments` field, preceded by ``--``. - For example, to build the :ref:`location_sample` sample for the nRF9161 DK with the nRF7002 EK Wi-Fi support, select ``nrf9161dk/nrf9161/ns`` in the :guilabel:`Board` menu, :file:`overlay-nrf7002ek-wifi-scan-only.conf` in the :guilabel:`Kconfig fragments` menu, and provide ``-- -DSHIELD=nrf7002ek`` in the :guilabel:`Extra CMake arguments` field. + For example, to build the :ref:`location_sample` sample for the nRF9161 DK with the nRF7002 EK Wi-Fi support, select ``nrf9161dk/nrf9161/ns`` in the :guilabel:`Board` menu, :file:`overlay-nrf7002ek-wifi-scan-only.conf` in the :guilabel:`Extra Kconfig fragments` menu, and provide ``-- -DSHIELD=nrf7002ek`` in the :guilabel:`Extra CMake arguments` field. .. group-tab:: Command line diff --git a/doc/nrf/app_dev/config_and_build/config_and_build_system.rst b/doc/nrf/app_dev/config_and_build/config_and_build_system.rst index 07735a06148a..49f17073175a 100644 --- a/doc/nrf/app_dev/config_and_build/config_and_build_system.rst +++ b/doc/nrf/app_dev/config_and_build/config_and_build_system.rst @@ -273,12 +273,13 @@ Sysbuild enabled by default :ref:`configuration_system_overview_sysbuild` in the |NCS| works differently than in Zephyr. -The |NCS| `modifies the default behavior `_ of ``west build``, so that the :ref:`standard building procedure ` will use sysbuild by default for :ref:`repository applications ` in the :ref:`SDK repositories `. +The |NCS| `modifies the default behavior `_ of ``west build``: the :ref:`standard building procedure ` in the |NCS| uses sysbuild by default for all types of applications in the :ref:`SDK repositories `. +This includes :ref:`repository applications ` and the out-of-tree applications (:ref:`workspace ` and :ref:`freestanding applications `). + For this reason, unlike in Zephyr, ``--sysbuild`` does not have to be explicitly mentioned in the command prompt when building a repository application. This setting only applies to repositories delivered with the |NCS|, to maintain compatibility with child/parent images. -This setting does not apply to out-of-tree applications, such as :ref:`workspace ` or :ref:`freestanding applications `. -In such cases, once you ported your application to sysbuild, it is up to you to either use the ``--sysbuild`` parameter on the command line every time you build or to :ref:`configure west to always use it `. +If you want to disable this feature, for example if you want to explicitly use the ``--sysbuild`` parameter on the command line every time you build, :ref:`configure west to disable this default setting `. Moreover, this |NCS| setting does not apply to the following areas: diff --git a/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_configuring_west.rst b/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_configuring_west.rst index f1522bbc1e8b..7f53dcd0a4f8 100644 --- a/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_configuring_west.rst +++ b/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_configuring_west.rst @@ -3,16 +3,23 @@ Configuring sysbuild usage in west ################################## -The |NCS| has :ref:`sysbuild enabled by default ` for for :ref:`repository applications ` in the :ref:`SDK repositories `. +The |NCS| has :ref:`sysbuild enabled by default ` for :ref:`all types of applications ` in the :ref:`SDK repositories `. -If you work with out-of-tree applications, such as :ref:`workspace ` or :ref:`freestanding applications `, you can configure your project to use sysbuild by default whenever invoking ``west build``. +You can configure your project to not sysbuild by default whenever invoking ``west build``. You can do this either per-workspace, using the local configuration option, or for all your workspaces, using the global configuration option: .. tabs:: .. group-tab:: Local sysbuild configuration - Use the following command to configure west to use sysbuild by default for building all projects in the current workspace (including any freestanding applications that are built against it): + Use the following command to configure west not to use sysbuild by default for building all projects in the current workspace: + + .. parsed-literal:: + :class: highlight + + west config --local build.sysbuild False + + Use the following command to configure west to use sysbuild by default: .. parsed-literal:: :class: highlight @@ -21,7 +28,14 @@ You can do this either per-workspace, using the local configuration option, or f .. group-tab:: Global sysbuild configuration - Use the following command to configure west to use sysbuild by default for building all projects in all workspaces: + Use the following command to configure west not to use sysbuild by default for building all projects in all workspaces: + + .. parsed-literal:: + :class: highlight + + west config --global build.sysbuild False + + Use the following command to configure west to use sysbuild by default: .. parsed-literal:: :class: highlight diff --git a/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst b/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst index 988b31bbb141..9026663733a9 100644 --- a/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst +++ b/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst @@ -40,7 +40,7 @@ You can build and program separate images or combined images using the |nRFVSC|. Program the sample or application --------------------------------- -Complete the following steps to program the sample or application onto Thingy:91: +Complete the following steps to program the sample or application onto nRF5340 DK: #. Connect the nRF5340 development kit to your PC using a USB cable. #. Make sure that the nRF5340 DK and the external debug probe are powered on. diff --git a/doc/nrf/app_dev/device_guides/nrf54l/building_nrf54l.rst b/doc/nrf/app_dev/device_guides/nrf54l/building_nrf54l.rst new file mode 100644 index 000000000000..13c8c60288e7 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/nrf54l/building_nrf54l.rst @@ -0,0 +1,138 @@ +.. _building_nrf54l: + +Building and programming with nRF54L15 DK +######################################### + +.. contents:: + :local: + :depth: 2 + +This guide provides instructions on how to build and program the nRF54L15 development kit. +Whether you are working with single or multi-image builds, the following sections will guide you through the necessary steps. + +Depending on the sample, you must program only the application core or both the Fast Lightweight Peripheral Processor (FLPR) and the application core. +Additionally, the process will differ based on whether you are working with a single-image or multi-image build. + +.. note:: + The following instructions do not include multi-image single-core builds scenario. + +Building for the application core only +************************************** + +Building for the application core only follows the default building process for the |NCS|. +For instructions, see how the :ref:`building` page. + +.. _building_nrf54l_app_flpr_core: + +Building for the application and FLPR core +****************************************** + +Building for both the application and the FLPR cores is different from the default |NCS| procedure. +Using the FLPR core also requires additional configuration to enable it. +This section outlines how to build and program for both the application and FLPR core, covering separate builds and sysbuild configurations. +The FLPR core supports two variants: + +* ``nrf54l15dk/nrf54l15/cpuflpr``, where FLPR runs from SRAM, which is the recommended method. + To build FLPR image with this variant, the application core image must include the ``nordic-flpr`` :ref:`snippet `. + +* ``nrf54l15dk/nrf54l15/cpuflpr/xip``, where FLPR runs from RRAM. + To build FLPR image with this variant, the application core image must include the ``nordic-flpr-xip`` snippet. + +Standard build +-------------- + +This subsection focuses on how to build an application using :ref:`sysbuild `. + +.. note:: + Currently, the documentation does not cover specific instructions for building an application image that uses sysbuild to incorporate the FLPR core as a sub-image. + The only documented scenario is for building FLPR as the main image and the application as a sub-image. + +Complete the following steps: + +.. tabs:: + + .. group-tab:: Using minimal sample for VPR bootstrapping + + This option automatically programs the FLPR core with :ref:`dedicated bootstrapping firmware `. + + To build and flash both images, run the following command that performs a :ref:`pristine build `: + + .. code-block:: console + + west build -p -b nrf54l15dk/nrf54l15/cpuflpr + west flash + + .. group-tab:: Using application that supports multi-image builds + + If your application involves creating custom images for both the application core and the FLPR core, make sure to disable the VPR bootstrapping sample. + You can do this by disabling the ``SB_CONFIG_VPR_LAUNCHER`` option when building for the FLPR target. + For more details, see :ref:`how to configure Kconfig `. + + To build and flash both images, run the following command that performs a :ref:`pristine build `: + + .. code-block:: console + + west build -p -b nrf54l15dk/nrf54l15/cpuflpr -- -DSB_CONFIG_VPR_LAUNCHER=n + west flash + +Separate images +--------------- + +You can build and program application sample and the FLPR sample as separate images using the |nRFVSC| or command line. +To use nRF Util, see `Programming application firmware on the nRF54L15 SoC`_. +Depending on the selected method, complete the following steps: + +.. tabs:: + + .. group-tab:: nRF Connect for VS Code + + .. note:: + + The |nRFVSC| currently offers experimental support for the nRF54L15's FLPR core. + Certain features, particularly debugging, may not function as expected. + + .. include:: /includes/vsc_build_and_run.txt + + 3. Build the application image by setting the following options: + + * Board target to ``nrf54l15dk/nrf54l15/cpuapp``. + * Choose either ``nordic-flpr`` or ``nordic-flpr-xip`` snippet depending on the FLPR image target. + * System build to :guilabel:`No sysbuild`. + + For more information, see :ref:`cmake_options`. + + #. Build the FLPR image by setting the following options: + + * Board target to ``nrf54l15dk/nrf54l15/cpuflpr`` (recommended) or ``nrf54l15dk/nrf54l15/cpuflpr/xip``. + * System build to :guilabel:`No sysbuild`. + + For more information, see :ref:`cmake_options`. + + .. group-tab:: Command line + + 1. |open_terminal_window_with_environment| + #. Build the application core image, and based on your build target include the appropriate snippet: + + .. code-block:: console + + west build -p -b nrf54l15dk/nrf54l15/cpuapp -S nordic-flpr --no-sysbuild + + #. Program the application core image by running the `west flash` command :ref:`without --erase `. + + .. code-block:: console + + west flash + + #. Build the FLPR core image: + + .. code-block:: console + + west build -p -b nrf54l15dk/nrf54l15/cpuflpr --no-sysbuild + + You can also customize the command for additional options, by adding :ref:`build parameters `. + + #. Once you have successfully built the FLPR core image, program it by running the `west flash` command :ref:`without --erase `. + + .. code-block:: console + + west flash diff --git a/doc/nrf/app_dev/device_guides/nrf54l/features.rst b/doc/nrf/app_dev/device_guides/nrf54l/features.rst index 7c98e9664bff..afc1f0237ab5 100644 --- a/doc/nrf/app_dev/device_guides/nrf54l/features.rst +++ b/doc/nrf/app_dev/device_guides/nrf54l/features.rst @@ -14,10 +14,29 @@ For additional information, see the following documentation: * Zephyr page on the :ref:`zephyr:nrf54l15dk_nrf54l15` * :ref:`installation` and :ref:`configuration_and_build` documentation to install the |NCS| and learn more about its development environment. +VPR core +******** + +The nRF54L15 DK has VPR core named *fast lightweight peripheral processor* (FLPR). +It is designed to support the RISC-V instruction set, and features key enhancements that enable efficient handling of basic and complex operations, as well as streamlined instruction processing. +It can be used as either a standalone processor or as a helper core. + +As a helper processor, FLPR specializes in managing tasks that require real-time attention or low power consumption, effectively boosting the performance of the main processor. +It is versatile, capable of operating independently or as an integrated peripheral, with accessible components for easy control and customization. + +Trusted Firmware-M (TF-M) +************************* + +Trusted Firmware-M provides a configurable set of software components to create a Trusted Execution Environment. +When you build your application with CMSE enabled, the TF-M is automatically included in the build. + +For more information about the TF-M, see :ref:`ug_tfm`. +See also :ref:`tfm_hello_world` for a sample that demonstrates how to add TF-M to an application. + Supported protocols ******************* -The nRF54L15 DK supports Bluetooth Low Energy (LE), proprietary protocols (including Enhanced ShockBurst), Matter, and Thread. +The nRF54L15 DK supports Bluetooth® Low Energy (LE) including Bluetooth Mesh, proprietary protocols (including Enhanced ShockBurst), Matter, and Thread. Amazon Sidewalk =============== @@ -42,6 +61,20 @@ In addition, you can run the :ref:`zephyr:bluetooth-samples` that are included f For available libraries, see :ref:`lib_bluetooth_services` (|NCS|) and :ref:`zephyr:bluetooth_api` (Zephyr). +Bluetooth Mesh +-------------- + +Bluetooth Mesh operates on Bluetooth Low Energy (LE), and is implemented according to Bluetooth Mesh Profile Specification v1.0.1 and Bluetooth Mesh Model Specification v1.0.1. +For the application core, the |NCS| provides several :ref:`bt_mesh_samples`. +In addition, you can find Bluetooth Mesh samples with :ref:`Bluetooth samples in Zephyr `. + +IEEE 802.15.4 +============= + +Implementation of the IEEE 802.15.4 MAC layer frame technology that enhances network efficiency and reliability through intelligent decoding of frame control fields, which manage types, addressing, and control flags. + +For the application core, the |NCS| provides a series of samples for the :ref:`Thread `, and :ref:`Matter ` protocols. + Enhanced ShockBurst =================== @@ -90,13 +123,15 @@ See the :ref:`nfc_samples` and :ref:`lib_nfc` for the samples and libraries that MCUboot bootloader support ************************** -The nRF54L15 DK supports MCUboot as its bootloader, in the experimental phase. -This means the following: +The nRF54L15 DK supports MCUboot as its bootloader. +The following features are supported: + + * Software and hardware-based :ref:`cryptography` + * Hardware key management + * Single image pair for dual-bank Device Firmware Update (DFU) targeted at the CPU application (the ``nrf54l15dk/nrf54l15/cpuapp`` board target) + * Configuring MCUboot as a first-stage bootloader - * Only software cryptography is supported. - * Single image pair is supported for dual-bank Device Firmware Update (DFU) targeted at the CPU application (the ``nrf54l15dk/nrf54l15/cpuapp`` board target). - * MCUboot can be configured as a first-stage bootloader (second-stage bootloader functionality is not yet available). - * Serial recovery mode is also not yet supported. +The second-stage bootloader functionality and the serial recovery mode are currently not supported. Supported DFU protocols ======================= diff --git a/doc/nrf/app_dev/device_guides/nrf54l/index.rst b/doc/nrf/app_dev/device_guides/nrf54l/index.rst index e6b774007b35..ab027622d118 100644 --- a/doc/nrf/app_dev/device_guides/nrf54l/index.rst +++ b/doc/nrf/app_dev/device_guides/nrf54l/index.rst @@ -21,8 +21,19 @@ Zephyr and the |NCS| provide support and contain board definitions for developin * - :ref:`zephyr:nrf54l15dk_nrf54l15` - PCA10156 - ``nrf54l15dk/nrf54l15/cpuapp`` - - :ref:`Getting started ` + - * `nRF54L15 Datasheet`_ + * :ref:`Getting started ` - `nRF54L15 System-on-Chip`_ + * - :ref:`nRF54L05 emulation on the nRF54L15 DK ` + - PCA10156 + - ``nrf54l15dk/nrf54l15/cpuapp`` + - -- + - -- + * - :ref:`nRF54L10 emulation on the nRF54L15 DK ` + - PCA10156 + - ``nrf54l15dk/nrf54l15/cpuapp`` + - -- + - -- Ensure to check the revision of your nRF54L15 device to see if it is supported: @@ -47,6 +58,9 @@ Ensure to check the revision of your nRF54L15 device to see if it is supported: :caption: Subpages: features + zms cryptography testing_dfu + vpr_flpr + building_nrf54l snippets diff --git a/doc/nrf/app_dev/device_guides/nrf54l/snippets.rst b/doc/nrf/app_dev/device_guides/nrf54l/snippets.rst index db2c1d8edd4a..59f0d54814e3 100644 --- a/doc/nrf/app_dev/device_guides/nrf54l/snippets.rst +++ b/doc/nrf/app_dev/device_guides/nrf54l/snippets.rst @@ -17,16 +17,19 @@ You can emulate the nRF54L05 and nRF54L10 targets on an nRF54L15 device using th - Compatible board targets * - :ref:`emulated-nrf54l05` - ``emulated-nrf54l05`` - - ``nrf54l15dk/nrf54l15/cpuapp``, ``nrf54l15dk/nrf54l15/cpuapp/ns`` + - ``nrf54l15dk/nrf54l15/cpuapp`` * - :ref:`emulated-nrf54l10` - ``emulated-nrf54l10`` - - ``nrf54l15dk/nrf54l15/cpuapp``, ``nrf54l15dk/nrf54l15/cpuapp/ns`` + - ``nrf54l15dk/nrf54l15/cpuapp`` .. important:: You cannot use these snippets with the FLPR core because all memory, including RAM and RRAM, is allocated to the application core. Currently, using the snippets is supported only on the :ref:`zephyr:nrf54l15dk_nrf54l15` board. +.. note:: + Trusted Firmware-M (TF-M) is not yet supported for nRF54L05 and nRF54L10 emulated targets. + .. _emulated-nrf54l05: nRF54L05 snippet diff --git a/doc/nrf/app_dev/device_guides/nrf54l/testing_dfu.rst b/doc/nrf/app_dev/device_guides/nrf54l/testing_dfu.rst index f7ac757be44e..7e6f14f94b1b 100644 --- a/doc/nrf/app_dev/device_guides/nrf54l/testing_dfu.rst +++ b/doc/nrf/app_dev/device_guides/nrf54l/testing_dfu.rst @@ -16,7 +16,7 @@ To compile the SMP server sample for testing secondary image slots on external S .. code-block:: console - west build -b nrf54l15dk/nrf54l15/cpuapp -d build/smp_svr_54l zephyr/samples/subsys/mgmt/mcumgr/smp_svr -T sample.mcumgr.smp_svr.bt.nrf54l15pdk.ext_flash + west build -b nrf54l15dk/nrf54l15/cpuapp -d build/smp_svr_54l zephyr/samples/subsys/mgmt/mcumgr/smp_svr -T sample.mcumgr.smp_svr.bt.nrf54l15dk.ext_flash .. group-tab:: DTS partitioning @@ -24,7 +24,7 @@ To compile the SMP server sample for testing secondary image slots on external S .. code-block:: console - west build -b nrf54l15dk/nrf54l15/cpuapp -d build/smp_svr_54l_d zephyr/samples/subsys/mgmt/mcumgr/smp_svr -T sample.mcumgr.smp_svr.bt.nrf54l15pdk.ext_flash.pure_dts + west build -b nrf54l15dk/nrf54l15/cpuapp -d build/smp_svr_54l_d zephyr/samples/subsys/mgmt/mcumgr/smp_svr -T sample.mcumgr.smp_svr.bt.nrf54l15dk.ext_flash.pure_dts This configuration sets up the secondary image slot on the serial flash memory installed on the nRF54L15 DK. It also enables the relevant SPI and the SPI NOR flash drivers. diff --git a/doc/nrf/app_dev/device_guides/nrf54l/vpr_flpr.rst b/doc/nrf/app_dev/device_guides/nrf54l/vpr_flpr.rst new file mode 100644 index 000000000000..4d46a21b6da1 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/nrf54l/vpr_flpr.rst @@ -0,0 +1,43 @@ +.. _vpr_flpr_nrf54l: + +Working with the FLPR core +########################## + +.. contents:: + :local: + :depth: 2 + +The nRF54L15 SoC has a dedicated VPR CPU (RISC-V architecture), named *fast lightweight peripheral processor* (FLPR). +The following peripherals are available for use with the FLPR core, and can be accessed through the appropriate Zephyr Device Driver API: + +* GPIO +* GPIOTE +* GRTC +* TWIM +* UARTE +* VPR + +.. _vpr_flpr_nrf54l15_initiating: + +Using FLPR with Zephyr multithreaded mode +***************************************** + +FLPR can function as a generic core, operating under the full Zephyr kernel. +In this configuration, building the FLPR target is similar to the application core. +However, the application core build must incorporate an overlay that enables the FLPR core. + +Bootstrapping the FLPR core +=========================== + +The |NCS| provides a FLPR snippet that adds an overlay required for bootstrapping the FLPR core. +Snippet's primary function is to enable the code that transfers the FLPR code to the designated region (if necessary) and to initiate the FLPR core. + +When building for the ``nrf54l15dk/nrf54l15/cpuflpr`` target, a minimal sample is automatically loaded onto the application core. +See more information on :ref:`building_nrf54l_app_flpr_core`. + +Memory allocation +***************** + +If a FLPR CPU is running, it can lead to increased latency when accessing ``RAM_01``. +Because of this, when FLPR is used in a project, you should utilize ``RAM_01`` to store only the FLPR code, FLPR data, and the application CPU's non-time-sensitive information. +Conversely, you should use ``RAM_00`` to store data with strict access time requirements such as DMA buffers, and the application CPU data used in low-latency ISRs. diff --git a/doc/nrf/app_dev/device_guides/nrf54l/zms.rst b/doc/nrf/app_dev/device_guides/nrf54l/zms.rst new file mode 100644 index 000000000000..701d1533cc3b --- /dev/null +++ b/doc/nrf/app_dev/device_guides/nrf54l/zms.rst @@ -0,0 +1,78 @@ +.. _memory_storage: + +Enabling Zephyr Memory Storage +############################## + +.. contents:: + :local: + :depth: 2 + +For nRF54L Series, you should use the :ref:`Zephyr Memory Storage (ZMS) `. +ZMS utilizes a flexible data management system that reduces write and erase cycles, extending the lifespan of non-volatile memory. + +.. note:: + + If you are using the :ref:`Non-Volatile Storage (NVS) `, ensure to switch to the ZMS solution. + +Enabling the ZMS module +*********************** + +You can enable the ZMS module for your application in two ways - directly through ZMS or through the :ref:`Settings subsystem `. +Additionally, you can optimize the application performance using caching mechanism: + +.. tabs:: + + .. group-tab:: Using storage directly through ZMS + + 1. Enable the :kconfig:option:`CONFIG_ZMS` Kconfig option in your project's configuration file. + #. Optionally, enable the lookup cache to increase the application performance: + + a. Enable the :kconfig:option:`CONFIG_ZMS_LOOKUP_CACHE` Kconfig option. + #. Set the lookup cache size in :kconfig:option:`CONFIG_ZMS_LOOKUP_CACHE_SIZE` depending on your application needs. + + .. group-tab:: Using storage through Settings subsystem + + 1. Enable the :kconfig:option:`CONFIG_ZMS` Kconfig option in your project's configuration file. + #. Enable ZMS within the Settings subsystem with the :kconfig:option:`CONFIG_SETTINGS_ZMS` Kconfig option. + #. Optionally, enable the lookup cache to increase the application performance: + + a. Enable the :kconfig:option:`CONFIG_ZMS_LOOKUP_CACHE` Kconfig option. + #. Set the lookup cache size in :kconfig:option:`CONFIG_ZMS_LOOKUP_CACHE_SIZE` depending on your application needs. + #. Ensure the lookup cache is configured to support the Setting subsystem by enabling the :kconfig:option:`CONFIG_ZMS_LOOKUP_CACHE_FOR_SETTINGS` Kconfig option. + + #. To further enhance the performance, enable the :kconfig:option:`CONFIG_SETTINGS_ZMS_NAME_CACHE` Kconfig option, and configure its size with :kconfig:option:`CONFIG_SETTINGS_ZMS_NAME_CACHE_SIZE` according to your application needs. + +Optimizing ZMS in your application +********************************** + +When integrating ZMS through the Settings subsystem in your application, you might need to optimize its performance. +The following sections include the best practices to enhance ZMS performance. + +Sector size and count +===================== + +To ensure optimal performance from ZMS, consider the following: + +* Storage partition sizing - The total storage partition size and the sector size should be carefully dimensioned to optimize ZMS performance. + For detailed instructions on managing free space effectively within ZMS, refer to the :ref:`ZMS ` documentation. + You should choose a storage partition capable of holding double the size of the key-value pairs expected to be written. + +* Entry management - In subsystems like Settings, all path-value pairs are split into two ZMS entries (ATEs). + You should include the extra header needed by these entries in your total storage space calculations. + +* Optimizing data storage - Storing small data directly in the ZMS entry headers can significantly enhance performance. + For instance, in the Settings subsystem, using a path name of 8 bytes or less can speed up read and write operations. + +Dimensioning cache +================== + +Proper cache sizing is critical for maintaining high performance and efficient memory usage in ZMS: + +* Cache size determination - Ideally, the cache size should match the number of different entries that could be written to the storage. + This ensures efficient data retrieval and storage operations. + +* Memory considerations - Each cache entry consumes an additional 8 bytes of RAM. + Therefore, you should choose the cache size to balance performance with memory usage effectively. + +* Settings subsystem specifics - When using ZMS through the Settings subsystem, remember that each entry translates into two ZMS entries. + Consequently, the optimal cache size should be twice the number of Settings entries to accommodate this division effectively. diff --git a/doc/nrf/app_dev/device_guides/nrf70/features.rst b/doc/nrf/app_dev/device_guides/nrf70/features.rst index 7a3083818b0a..756b0b0c1790 100644 --- a/doc/nrf/app_dev/device_guides/nrf70/features.rst +++ b/doc/nrf/app_dev/device_guides/nrf70/features.rst @@ -49,7 +49,45 @@ The nRF70 Series devices also support the following functionalities: * :ref:`ug_nrf70_developing_raw_ieee_80211_packet_transmission`: Allows the injection of raw IEEE 802.11 frames in Station and Monitor modes. * :ref:`Promiscuous reception `: Allows the reception of IEEE 802.11 packets from a connected BSSID when operating in Station mode. +* :ref:`Offloaded raw transmission `: Allows the offloading of raw IEEE 802.11 frame transmission to the nRF Wi-Fi driver. +* :ref:`Wi-Fi advanced security modes `: Allows the use of advanced security modes, certificate-based Wi-Fi security, and the Platform Security Architecture (PSA) security framework. Peer-to-peer support in the form of Wi-Fi Direct® will be available in the future. See the :ref:`ug_wifi` documentation for more information related to Wi-Fi modes of operation. + +.. _ug_nrf70_features_hostap: + +hostap +****** + +The nRF70 Series devices use the `WPA Supplicant`_ to implement full Wi-Fi functionality. +The WPA supplicant is part of the ``hostap`` project and is a widely used implementation of the IEEE 802.11i standard for wireless LAN security. +The WPA supplicant is a software component that implements the Wi-Fi Protected Access (WPAâ„¢), WPA2â„¢ and WPA3â„¢ security protocols. + +The nRF70 Series devices use `Zephyr hostap fork`_, a fork of the hostap project that is integrated with the Zephyr RTOS. +The WPA supplicant is integrated with the Zephyr RTOS and registers as a Wi-Fi network manager in the Zephyr networking stack. +See `Zephyr Wi-Fi NM API`_ for details. +The `Zephyr Wi-Fi management`_ layer in Zephyr uses the Wi-Fi network manager to manage the Wi-Fi interface. + +The nRF70 Series driver registers as a Wi-Fi device in the Zephyr networking stack and provides the Wi-Fi interface to the WPA supplicant. +The WPA supplicant then manages the Wi-Fi interface and provides the Wi-Fi functionality to the application. + +.. note:: + + The WPA supplicant is only used for System mode to offer full Wi-Fi functionality. + It is not used in other modes, for example, Scan-only mode. + +Supported hostap features in the |NCS| +====================================== + +The `Zephyr hostap fork`_ supports a wide range of Wi-Fi features and functionalities. +The nRF70 Series devices use the Zephyr hostap fork but only implement a subset of the features supported by the fork. + +The nRF70 Series devices support the following features: + +* Wi-Fi 6 support. +* Station mode. +* SoftAP mode - Based on ``wpa_supplicant``. +* WPA2-PSK and WPA3-SAE security modes. +* WPA2-EAP-TLS security mode. diff --git a/doc/nrf/app_dev/device_guides/nrf70/index.rst b/doc/nrf/app_dev/device_guides/nrf70/index.rst index 50a2ec8bb55e..d577c9f5ebc0 100644 --- a/doc/nrf/app_dev/device_guides/nrf70/index.rst +++ b/doc/nrf/app_dev/device_guides/nrf70/index.rst @@ -77,11 +77,13 @@ Zephyr and the |NCS| provide support for developing networking applications with - ``nrf54h20dk/nrf54h20/cpuapp`` - | `nRF54H20 Objective Product Specification 0.3.1`_ | :ref:`Getting started ` - * - :ref:`zephyr:nrf54l15pdk_nrf54l15` + * - :ref:`zephyr:nrf54l15dk_nrf54l15` - nRF7002 EB - PCA20053 - - ``nrf54l15pdk/nrf54l15/cpuapp`` - - :ref:`Getting started ` + - ``nrf54l15dk/nrf54l15/cpuapp`` + - | `Quick Start`_ + | :ref:`Developing with nRF54L Series ` + The following nRF70 Series shields are available and defined in the :file:`nrf/boards/shields` folder: @@ -110,7 +112,7 @@ The following nRF70 Series shields are available and defined in the :file:`nrf/b | `User Guide `_ * - nRF7002 :term:`Expansion Board (EB)` - PCA63561 - - ``nrf7002eb``, ``nrf700x_nrf54h20dk``, ``nrf700x_nrf54l15pdk`` + - ``nrf7002eb``, ``nrf7002eb_interposer_p1`` (nRF54 Series) - | :ref:`Development guide ` | `User Guide `_ @@ -130,3 +132,4 @@ The following subpages cover topics related to developing applications with the power_profiling nrf7002ek_dev_guide nrf7002eb_dev_guide + wifi_advanced_security_modes diff --git a/doc/nrf/app_dev/device_guides/nrf70/nrf7002eb_dev_guide.rst b/doc/nrf/app_dev/device_guides/nrf70/nrf7002eb_dev_guide.rst index b808e0fea55f..941888efd623 100644 --- a/doc/nrf/app_dev/device_guides/nrf70/nrf7002eb_dev_guide.rst +++ b/doc/nrf/app_dev/device_guides/nrf70/nrf7002eb_dev_guide.rst @@ -1,5 +1,5 @@ .. _ug_nrf7002eb_gs: -.. _ug_nrf7002eb_nrf54l15pdk_gs: +.. _ug_nrf7002eb_nrf54l15dk_gs: .. _ug_nrf7002eb_nrf54h20dk_gs: Developing with nRF7002 EB @@ -12,7 +12,7 @@ Developing with nRF7002 EB The nRF7002 :term:`Expansion Board (EB)` (PCA63561), part of the `nRF70 Series Family `_, can be used to provide Wi-Fi® connectivity to compatible development or evaluation boards through the nRF7002 Wi-Fi 6 companion IC. For example, you can use it with the :ref:`Nordic Thingy:53 `, an IoT prototyping platform from Nordic Semiconductor. -You can also use the nRF7002 EB to provide Wi-Fi connectivity to the :ref:`zephyr:nrf54h20dk_nrf54h20` and :ref:`zephyr:nrf54l15pdk_nrf54l15`. +You can also use the nRF7002 EB to provide Wi-Fi connectivity to the :ref:`zephyr:nrf54h20dk_nrf54h20` and :ref:`zephyr:nrf54l15dk_nrf54l15`. .. figure:: images/nRF7002eb.png :alt: nRF7002 EB @@ -29,10 +29,10 @@ The castellated holes on the side of the board allow the EB to be used as a brea This way, you can provide Wi-Fi capabilities to develop Wi-Fi applications with another System on Chip (SoC), MPU, or MCU host. For the pinout of the castellated holes, see `nRF7002 EB castellated edge holes`_ in the board's `Hardware User Guide `_. -Pin mapping for the nRF54H20 DK and the nRF54L15 PDK -**************************************************** +Pin mapping for the nRF54H20 DK and the nRF54L15 DK +*************************************************** -For nRF54H20 DK and nRF54L15 PDK, refer to the following tables for the pin mapping for these kits: +For nRF54H20 DK and nRF54L15 DK, refer to the following tables for the pin mapping for these kits: .. tabs:: @@ -65,10 +65,10 @@ For nRF54H20 DK and nRF54L15 PDK, refer to the following tables for the pin mapp .. note:: Connect ``VIO`` to 1.8 V and ``VBAT`` to 3.6 V and ``GND``. - .. group-tab:: nRF54L15 PDK + .. group-tab:: nRF54L15 DK +-----------------------------------+-------------------+-----------------------------------------------+ - | nRF70 Series pin name (EB name) | nRF54L15 PDK pins | Function | + | nRF70 Series pin name (EB name) | nRF54L15 DK pins | Function | +===================================+===================+===============================================+ | CLK (CLK) | P1.11 | SPI Clock | +-----------------------------------+-------------------+-----------------------------------------------+ @@ -116,19 +116,19 @@ Alternatively, add the shield in the project's :file:`CMakeLists.txt` file by us set(SHIELD nrf7002eb) -To build for the nRF7002 EB with nRF54H20 DK, use the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the CMake ``SHIELD`` variable set to ``nrf700x_nrf54h20dk``. -To build for a custom target, set ``-DSHIELD=nrf700x_nrf54h20dk`` when you invoke ``west build`` or ``cmake`` in your |NCS| application. -Alternatively, you can add the shield in the project's :file:`CMakeLists.txt` file by using the ``set(SHIELD nrf700x_nrf54h20dk)`` command. +To build for the nRF7002 EB with nRF54H20 DK, use the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the CMake ``SHIELD`` variable set to ``nrf7002eb_interposer_p1 nrf7002eb``. +To build for a custom target, set ``-DSHIELD=nrf7002eb_interposer_p1;nrf7002eb`` when you invoke ``west build`` or ``cmake`` in your |NCS| application. +Alternatively, you can add the shield in the project's :file:`CMakeLists.txt` file by using the ``set(SHIELD nrf7002eb_interposer_p1 nrf7002eb)`` command. -To build for the nRF7002 EB with the nRF54L15 PDK, use the ``nrf54l15pdk/nrf54l15/cpuapp`` board target with the CMake ``SHIELD`` variable set to ``nrf700x_nrf54l15pdk``. -To build for a custom target, set ``-DSHIELD=nrf700x_nrf54l15pdk`` when you invoke ``west build`` or ``cmake`` in your |NCS| application. -Alternatively, you can add the shield in the project's :file:`CMakeLists.txt` file by using the ``set(SHIELD nrf700x_nrf54l15pdk)`` command. +To build for the nRF7002 EB with the nRF54L15 DK, use the ``nrf54l15dk/nrf54l15/cpuapp`` board target with the CMake ``SHIELD`` variable set to ``nrf7002eb_interposer_p1 nrf7002eb``. +To build for a custom target, set ``-DSHIELD=nrf7002eb_interposer_p1;nrf7002eb`` when you invoke ``west build`` or ``cmake`` in your |NCS| application. +Alternatively, you can add the shield in the project's :file:`CMakeLists.txt` file by using the ``set(SHIELD nrf7002eb_interposer_p1 nrf7002eb)`` command. -Limitations when building with nRF54H20 DK and nRF54L15 PDK -*********************************************************** +Limitations when building with nRF54H20 DK and nRF54L15 DK +********************************************************** The Wi-Fi support is experimental and has the following limitations: * It only supports STA mode. * It is only suitable for low-throughput applications. -* For nRF54L15 PDK, WPA3 security mode is not supported. +* For nRF54L15 DK, WPA3 security mode is not supported. diff --git a/doc/nrf/app_dev/device_guides/nrf70/wifi_advanced_security_modes.rst b/doc/nrf/app_dev/device_guides/nrf70/wifi_advanced_security_modes.rst new file mode 100644 index 000000000000..aa220e1feeb0 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/nrf70/wifi_advanced_security_modes.rst @@ -0,0 +1,86 @@ +.. _ug_nrf70_wifi_advanced_security_modes: + +nRF70 Series advanced security modes +#################################### + +.. contents:: + :local: + :depth: 2 + +Enterprise security +******************* + +The nRF70 Series devices support Wi-Fi® enterprise security, which is a more secure form of Wi-Fi security compared to Wi-Fi personal security. +Wi-Fi enterprise security is used in corporate environments where the security requirements are more stringent. +It is based on the IEEE 802.1X standard, which defines the port-based network access control. + +The nRF70 Series devices support the following Wi-Fi enterprise security mode, ``WPA2-EAP-TLS``. +This mode uses the Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS) for authentication. +The client and the authentication server exchange certificates to authenticate each other. + + +Enterprise testing: X.509 certificate headers generation +======================================================== + +Wi-Fi enterprise security requires use of X.509 certificates. +Test certificates in PEM format are available at :zephyr_file:`samples/net/wifi/test_certs/` repository. +During the build process, the certificates are converted to a C header file that is included in the Wi-Fi shell module or the :ref:`Wi-Fi credentials ` library. + +To use custom certificates, use the following commands: + +.. code-block:: bash + + $ cp client.pem samples/net/wifi/test_certs/ + $ cp client-key.pem samples/net/wifi/test_certs/ + $ cp ca.pem samples/net/wifi/test_certs/ + $ cp client.pem samples/net/wifi/test_certs/client2.pem + $ cp client-key.pem samples/net/wifi/test_certs/client-key2.pem + $ cp ca.pem samples/net/wifi/test_certs/ca2.pem + + $ west build -p -b samples/net/wifi -- -DEXTRA_CONF_FILE=overlay-enterprise.conf + +.. note:: + The EAP phase2 certificates (suffixed with 2) are unused in ``WPA2-EAP-TLS`` but are mandatory for building the sample application. + The phase1 certificates are copied as phase2 certificates to avoid build errors as a temporary workaround. + +To establish a Wi-Fi connection, use the following command: + +.. code-block:: console + + uart:~$ wifi connect -s -k 7 -a anon -K + +.. code-block:: console + + uart:~$ wifi_cred add -s -k 7 -a anon -K + + +.. note:: + + The Wi-Fi credentials only support 16characters for the anonymous identity and the key passphrase. + +The server certificate is also provided in the same directory for testing purposes. +You can use any AAA server for testing purposes, such as FreeRADIUS or hostapd. + +.. note:: + + The certificates are for testing purposes only and should not be used for production. + +.. _ug_nrf70_developing_wifi_psa_support: + +Platform Security Architecture (PSA) crypto support +*************************************************** + +The nRF70 Series devices support the `Platform Security Architecture (PSA)`_ security framework. +This framework provides a set of APIs for cryptographic operations, which are used by the nRF70 Series. +This improves the security of the nRF70 device compared to the non-PSA mode. + +.. note:: + + Currently, the PSA crypto support is only applicable to the WPA2â„¢-personal security profile. + +Enable PSA support +================== + +To enable the nRF70 PSA crypto support in your applications, use the :kconfig:option:`CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ALT_NCS_PSA` Kconfig option. + +The Wi-Fi connection process is similar to the non-PSA mode, however, the only difference is that the cryptographic operations are performed using PSA crypto APIs. diff --git a/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst b/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst index 34c7c555373b..990ce9b4109d 100644 --- a/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst +++ b/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst @@ -159,8 +159,8 @@ The band lock mask allows you to set the bands on which you want the modem to op Each bit in the :kconfig:option:`CONFIG_LTE_LOCK_BAND_MASK` option represents one band. The maximum length of the string is 88 characters (bit string, 88 bits). -For Thingy:91, you can configure the modem to use specific LTE bands by using the band lock AT command. -The preprogrammed firmware configures the modem to use the bands currently certified on the Thingy:91 hardware. +For Thingy:91 and Thingy:91 X, you can configure the modem to use specific LTE bands by using the band lock AT command. +The preprogrammed firmware configures the modem to use the bands currently certified on the hardware. When building the firmware, you can configure which bands must be enabled. For more detailed information, see the `band lock section in the nRF9160 AT Commands Reference Guide`_ or the `band lock section in the nRF91x1 AT Commands Reference Guide`_, depending on the SiP you are using. @@ -262,7 +262,7 @@ Therefore, the performance is not ideal when there are obstructions overhead or Customers who are developing their own hardware with the nRF9160 are strongly recommended to use the `nRF9160 Antenna and RF Interface Guidelines`_ as a reference. See `GPS interface and antenna`_ for more details on GNSS interface and antenna. -Thingy:91 has a GNSS receiver, which allows the device to be located globally using GNSS signals if it is activated. +Thingy:91 and Thingy:91 X have a GNSS receiver, which allows the device to be located globally using GNSS signals if it is activated. In :ref:`asset_tracker_v2`, the GNSS receiver is activated by default. .. note:: diff --git a/doc/nrf/app_dev/device_guides/nrf91/nrf91_programming.rst b/doc/nrf/app_dev/device_guides/nrf91/nrf91_programming.rst index a0d459ee25df..a2254aac6734 100644 --- a/doc/nrf/app_dev/device_guides/nrf91/nrf91_programming.rst +++ b/doc/nrf/app_dev/device_guides/nrf91/nrf91_programming.rst @@ -58,7 +58,7 @@ You must use the build target ``thingy91/nrf9160/ns`` when building the applicat LTE/GNSS features can only be used with :ref:`Cortex-M Security Extensions enabled ` (``_ns`` build target). -The table below shows the different types of build files that are generated and the different scenarios in which they are used: +The following table shows the different types of build files that are generated and the different scenarios in which they are used: +-----------------------+----------------------------------------+----------------------------------------------------------------+ | File | File format | Programming scenario | @@ -91,7 +91,17 @@ It is recommended to use an external debug probe to program the Thingy:91. Complete the following steps to program firmware onto Thingy:91: -.. include:: /includes/thingy91_prog_extdebugprobe.txt +1. Set the Thingy:91 SWD selection switch (**SW2**) to **nRF91** or **nRF52** depending on whether you want to program the nRF9160 SiP or the nRF52840 SoC component. +#. Connect the Thingy:91 to the debug out port on a 10-pin external debug probe, for example, nRF9160 DK, using a 10-pin JTAG cable. + + .. note:: + + If you are using nRF9160 DK as the debug probe, make sure that **VDD_IO (SW11)** is set to 1.8 V. + +#. Connect the external debug probe to the PC using a USB cable. +#. Make sure that the Thingy:91 and the external debug probe are powered on. + +.. thingy91_building_pgmin_start .. tabs:: @@ -111,3 +121,54 @@ Complete the following steps to program firmware onto Thingy:91: west flash The device resets and runs the programmed sample or application. + +.. thingy91_building_pgmin_end + +.. _building_pgming_thingy91x: + +Programming onto Thingy:91 X +**************************** + +You can also program the Thingy:91 X with the images obtained by building the code in an |NCS| environment and the west tool. + +To set up your system to be able to build a compatible firmware image, follow the :ref:`installation` guide for the |NCS| and read the :ref:`configuration_and_build` documentation. +The build targets of interest for Thingy:91 X in the |NCS| are as follows: + ++----------------------------------+---------------------------------+ +| Component | Build target | ++==================================+=================================+ +| nRF9151 SiP | ``thingy91x/nrf9151`` | +| | ``thingy91x/nrf9151/ns`` | ++----------------------------------+---------------------------------+ +| nRF5340 SoC - Application core | ``thingy91x/nrf5340/cpuapp`` | +| | ``thingy91x/nrf5340/cpuapp/ns`` | ++----------------------------------+---------------------------------+ +| nRF5340 SoC - Network core | ``thingy91x/nrf5340/cpunet`` | ++----------------------------------+---------------------------------+ + +.. note:: + LTE/GNSS features can only be used with :ref:`Cortex-M Security Extensions enabled ` (nRF9151 ``ns`` build target). + +The following table shows the different types of build files that are generated and the different scenarios in which they are used: + ++-----------------------+----------------------------------------+----------------------------------------------------------------+ +| File | File format | Programming scenario | ++=======================+========================================+================================================================+ +|:file:`merged.hex` | Full image, HEX format | Using an external debug probe and nrfutil device. | ++-----------------------+----------------------------------------+----------------------------------------------------------------+ +|:file:`app_signed.hex` | MCUboot compatible image, HEX format | Using the built-in bootloader and nrfutil device. | ++-----------------------+----------------------------------------+----------------------------------------------------------------+ +|:file:`app_update.bin` | MCUboot compatible image, binary format|* Using the built-in bootloader and mcumgr command-line tool. | +| | |* For FOTA updates. | ++-----------------------+----------------------------------------+----------------------------------------------------------------+ + +Complete the following steps to program firmware onto Thingy:91 X: + +1. Set the Thingy:91 X SWD selection switch (**SW2**) to **nRF91** or **nRF53** depending on whether you want to program the nRF9151 SiP or the nRF5340 SoC component. +#. Connect the Thingy:91 X to the debug out port on a 10-pin external debug probe, for example, nRF9151 DK, using a 10-pin SWD cable. +#. Connect the external debug probe to the PC using a USB cable. +#. Make sure that the Thingy:91 X and the external debug probe are powered on. + +.. include:: nrf91_programming.rst + :start-after: thingy91_building_pgmin_start + :end-before: thingy91_building_pgmin_end diff --git a/doc/nrf/app_dev/device_guides/nrf91/nrf91_updating_fw_programmer.rst b/doc/nrf/app_dev/device_guides/nrf91/nrf91_updating_fw_programmer.rst index 2add5dc811b9..3165fd67bcaa 100644 --- a/doc/nrf/app_dev/device_guides/nrf91/nrf91_updating_fw_programmer.rst +++ b/doc/nrf/app_dev/device_guides/nrf91/nrf91_updating_fw_programmer.rst @@ -20,3 +20,4 @@ See the subpages for detailed documentation on how to update the application and nrf91_dk_updating_fw_programmer thingy91_updating_fw_programmer + thingy91x_updating_fw_programmer diff --git a/doc/nrf/app_dev/device_guides/nrf91/thingy91x_updating_fw_programmer.rst b/doc/nrf/app_dev/device_guides/nrf91/thingy91x_updating_fw_programmer.rst new file mode 100644 index 000000000000..a8bb42159e27 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/nrf91/thingy91x_updating_fw_programmer.rst @@ -0,0 +1,169 @@ +.. _programming_thingy91x: + +Updating the Thingy:91 X firmware using nRF Util +################################################ + +.. contents:: + :local: + :depth: 2 + +You can use the ``nrfutil device`` command for the following: + +* :ref:`Update the firmware on the nRF5340 SoC `. +* :ref:`Update the application firmware on the nRF9151 SiP `. +* :ref:`Update the modem firmware on the nRF9151 SiP `. + +You can perform these operations through USB using MCUboot, or through an external debug probe. +When developing with your Thingy:91 X, it is recommended to use an external debug probe. + +.. note:: + The external debug probe must support Arm Cortex-M33, such as the nRF9151 DK. + You need a 10-pin 2x5 socket-socket 1.27 mm IDC (:term:`Serial Wire Debug (SWD)`) JTAG cable to connect to the external debug probe. + +See `Installing nRF Util`_ and `Installing and upgrading nRF Util commands`_ for instructions on how to install the nrfutil device utility. + +.. _updating_firmware_nRF5340: + +Updating the firmware on the nRF5340 SoC +**************************************** + +This section describes how you can update the firmware of the nRF5340 SoC on the Nordic Thingy:91 X through USB or with an external debug probe. + +.. tabs:: + + .. group-tab:: Through USB and MCUboot + + To update the nRF5340 SoC firmware over USB, complete the following steps: + + 1. Install the ``nrfutil device`` command package by completing the steps in the `Installing and upgrading nRF Util commands`_ documentation. + #. Connect the Thingy:91 X to your computer with a USB-C cable. + #. Power on the device by switching **SW1** to the **ON** position. + #. Open a terminal window. + #. Enter the following command to list the connected devices and their traits:: + + nrfutil device list + + The Nordic Thingy\:91 X will be listed as a Thingy\:91 X UART product and have the following details: + + * A 21-character serial number, for example, ``THINGY91X_C2E0AC7F599``. + * ``mcuboot``, ``nordicUsb``, ``serialPorts``, and ``usb`` traits. + + + #. Enter the following command to update both the application and network core of the nRF5340 application core with a multi-image :file:`dfu_application.zip` file: + + .. code-block:: console + + nrfutil device program --firmware dfu_application.zip --serial-number --traits mcuboot --x-family nrf53 + + .. group-tab:: Through external debug probe + + To update the nRF5340 firmware using an external debug probe, complete the following steps: + + 1. Install the ``nrfutil device`` command package by completing the steps in the `Installing and upgrading nRF Util commands`_ documentation. + #. Connect the Thingy:91 X to your computer with a USB-C cable. + #. Connect the 10-pin :term:`Serial Wire Debug (SWD)` programming cable from the external debug probe to the programming connector (**P8**) on the Thingy:91 X. + #. Connect the external debug probe to your computer. + #. Power on the device by switching **SW1** to the **ON** position. + #. Set the programming target select switch **SW2** to **nRF53** on the Thingy:91 X. + #. Open a terminal window. + #. Enter the following command to list the connected devices and their traits:: + + nrfutil device list + + The external debug probe will be listed as a J-Link product with the ``jlink`` trait and will have a 9 or 10 digit J-Link serial number depending on the J-Link probe used. + + #. Enter the following command to program the application binary to the nRF5340 application core: + + .. code-block:: console + + nrfutil device program --firmware --serial-number --traits jlink --x-family nrf53 --core Application + + #. Enter the following command to program the application binary to the nRF5340 network core: + + .. code-block:: console + + nrfutil device program --firmware --serial-number --traits jlink --x-family nrf53 --core Network + +.. _update_nRF9151_application: + +Updating the application firmware on the nRF9151 SiP +**************************************************** + +This section describes how you can update the application firmware of the nRF9151 SiP on the Nordic Thingy:91 X through USB or with an external debug probe. + +.. tabs:: + + .. group-tab:: Through USB and MCUboot + + To update the nRF5340 SoC firmware over USB, complete the following steps: + + 1. Install the ``nrfutil device`` command package by completing the steps in the `Installing and upgrading nRF Util commands`_ documentation. + #. Connect the Thingy:91 X to your computer with a USB-C cable. + #. Power on the device by switching **SW1** to the **ON** position. + #. Open a terminal window. + #. Enter the following command to list the connected devices and their traits:: + + nrfutil device list + + The Nordic Thingy\:91 X will be listed as a Thingy\:91 X UART product and have the following details: + + * A 21-character serial number, for example, ``THINGY91X_C2E0AC7F599``. + * ``mcuboot``, ``nordicUsb``, ``serialPorts``, and ``usb`` traits. + + #. Enter the following command to program the application binary to the nRF9151 application core: + + .. code-block:: console + + nrfutil device program --firmware dfu_application.zip --serial-number --traits mcuboot --x-family nrf91 --core Application + + .. group-tab:: Through external debug probe + + To update the nRF5340 firmware using an external debug probe, complete the following steps: + + 1. Install the ``nrfutil device`` command package by completing the steps in the `Installing and upgrading nRF Util commands`_ documentation. + #. Connect the Thingy:91 X to your computer with a USB-C cable. + #. Connect the 10-pin :term:`Serial Wire Debug (SWD)` programming cable from the external debug probe to the programming connector (**P8**) on the Thingy:91 X. + #. Connect the external debug probe to your computer. + #. Power on the device by switching **SW1** to the **ON** position. + #. Set the programming target select switch **SW2** to **nRF91** on the Thingy:91 X. + #. Open a terminal window. + #. Enter the following command to list the connected devices and their traits:: + + nrfutil device list + + The external debug probe will be listed as a J-Link product with the ``jlink`` trait and will have a 9 or 10 digit J-Link serial number depending on the J-Link probe used. + + #. Enter the following command to program the application binary to the nRF9151 application core: + + .. code-block:: console + + nrfutil device program --firmware --serial-number --traits jlink --x-family nrf91 --core Application + +.. _update_modem_fw_nRF9151: + +Updating the modem firmware on the nRF9151 SiP +********************************************** + +.. note:: + Modem firmware update through USB and MCUboot is currently not supported. + +To update the nRF5340 firmware using an external debug probe, complete the following steps: + +1. Install the ``nrfutil device`` command package by completing the steps in the `Installing and upgrading nRF Util commands`_ documentation. +#. Connect the Thingy:91 X to your computer with a USB-C cable. +#. Connect the 10-pin :term:`Serial Wire Debug (SWD)` programming cable from the external debug probe to the programming connector (**P8**) on the Thingy:91 X. +#. Connect the external debug probe to your computer. +#. Power on the device by switching **SW1** to the **ON** position. +#. Set the programming target select switch **SW2** to **nRF91** on the Thingy:91 X. +#. Open a terminal window. +#. Enter the following command to list the connected devices and their traits:: + + nrfutil device list + + The external debug probe will be listed as a J-Link product with the ``jlink`` trait and will have a 9 or 10 digit J-Link serial number depending on the J-Link probe used. + +#. Enter the following command to program the modem firmware on the nRF9151 SiP: + + .. code-block:: console + + nrfutil device program --firmware --serial-number --traits jlink modem --x-family nrf91 diff --git a/doc/nrf/app_dev/device_guides/pmic/npm1300.rst b/doc/nrf/app_dev/device_guides/pmic/npm1300.rst index 0ce6837aae32..3c5236e33621 100644 --- a/doc/nrf/app_dev/device_guides/pmic/npm1300.rst +++ b/doc/nrf/app_dev/device_guides/pmic/npm1300.rst @@ -53,11 +53,10 @@ The following boards in the `Zephyr`_ open source project and in the |NCS| are c | ``nrf54h20dk_nrf54h20_cpuppr`` - | `Objective Product Specification `_ | :ref:`Getting started ` - * - :ref:`zephyr:nrf54l15pdk_nrf54l15` + * - :ref:`zephyr:nrf54l15dk_nrf54l15` - nPM1300 EK - PCA10156 - - | ``nrf54l15pdk/nrf54l15/cpuapp`` for the PDK revision v0.2.1, AB0-ES7 (Engineering A). - | ``nrf54l15pdk@0.3.0/nrf54l15/cpuapp`` for the PDK revisions v0.3.0 and v0.7.0 (Engineering A). + - | ``nrf54l15dk/nrf54l15/cpuapp`` - -- * - :ref:`zephyr:nrf5340dk_nrf5340` - nPM1300 EK diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_invocation_topology.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_invocation_topology.svg new file mode 100644 index 000000000000..6dd5a4a68eae --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_invocation_topology.svg @@ -0,0 +1,183 @@ + + + + + + + + + + + + + + + + + + + + + + Page-1 + + Sheet.1000 + + Nordic Blueslate.1001 + Secure Domain and SysCtl + + Secure Domain and SysCtl + + Sheet.7 + OEM-controlled SUIT manifest Dependency between manifests Nor... + + OEM-controlled SUIT manifest Dependency between manifests Nordic-controlled SUIT manifest + + Nordic Light Grey.19 + + + + Dynamic connector.25 + + + + Nordic Light Grey.1016 + + + + Nordic Light Grey.1014 + System controller + + System controller + + Nordic Light Grey.1015 + SDFW, SDFW_RECOVERY + + SDFW, SDFW_RECOVERY + + Dynamic connector.1017 + + + + Dynamic connector.33 + + + + Nordic Dark Grey + Empty invocation sequence. Manifest does not boot anything. + + Empty invocation sequence. Manifest does not boot anything. + + Dynamic connector.35 + + + + Nordic Light Grey.1010 + Nordic Top + + Nordic Top + + Nordic Sky + SecDom FW + + SecDom FW + + Dynamic connector.1000 + + + + Dynamic connector.1001 + + + + Nordic Blueslate + Radio domain + + Radio domain + + Nordic Middle Grey + Application domain + + Application domain + + Nordic Light Grey.1002 + Application Local A + + Application Local A + + Nordic Light Grey.1003 + Application Spare + + Application Spare + + Nordic Light Grey.1004 + Application Local B + + Application Local B + + Dynamic connector.1005 + + + + Dynamic connector.1006 + + + + Dynamic connector.1007 + + + + Nordic Light Grey.1008 + Radio Local B + + Radio Local B + + Dynamic connector.1009 + + + + Nordic Light Grey.36 + Radio Local A + + Radio Local A + + Dynamic connector.37 + + + + Nordic Light Grey + Root + + Root + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_recovery_invocation_topology.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_recovery_invocation_topology.svg new file mode 100644 index 000000000000..d174e221e253 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_recovery_invocation_topology.svg @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + + + + + + + Page-1 + + Nordic Blueslate.1001 + Secure Domain and SysCtl + + Secure Domain and SysCtl + + Sheet.1013 + OEM-controlled SUIT manifest Dependency between manifests Nor... + + OEM-controlled SUIT manifest Dependency between manifests Nordic-controlled SUIT manifest + + Nordic Light Grey.19 + + + + Dynamic connector.25 + + + + Nordic Light Grey.1016 + + + + Nordic Light Grey.1014 + System controller + + System controller + + Nordic Light Grey.1015 + SDFW, SDFW_RECOVERY + + SDFW, SDFW_RECOVERY + + Dynamic connector.1017 + + + + Dynamic connector.33 + + + + Nordic Dark Grey + Empty invocation sequence. Manifest does not boot anything. + + Empty invocation sequence. Manifest does not boot anything. + + Dynamic connector.35 + + + + Nordic Light Grey.1010 + Nordic Top + + Nordic Top + + Nordic Sky + SecDom FW + + SecDom FW + + Dynamic connector.1000 + + + + Dynamic connector.1001 + + + + Nordic Blueslate + Radio domain + + Radio domain + + Nordic Middle Grey + Application domain + + Application domain + + Nordic Light Grey.9 + Radio recovery + + Radio recovery + + Nordic Light Grey.1002 + Application Local A + + Application Local A + + Nordic Light Grey.1003 + Application Spare + + Application Spare + + Nordic Light Grey.1004 + Application Local B + + Application Local B + + Dynamic connector.9 + + + + Dynamic connector.1005 + + + + Dynamic connector.1006 + + + + Dynamic connector.1007 + + + + Nordic Light Grey.1008 + Radio Local B + + Radio Local B + + Dynamic connector.1009 + + + + Nordic Light Grey.36 + Radio Local A + + Radio Local A + + Dynamic connector.37 + + + + Nordic Light Grey + Application recovery + + Application recovery + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests.svg new file mode 100644 index 000000000000..e3c923dbf9e0 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests.svg @@ -0,0 +1,116 @@ + + + + + + + + Page-1 + + Sheet.1005 + + Nordic Blueslate + Application domain + + Application domain + + Nordic Blue + Root + + Root + + Nordic Blue.6 + Application recovery + + Application recovery + + Nordic Blue.7 + Application Local A + + Application Local A + + Nordic Blue.8 + Application Local B + + Application Local B + + Nordic Blue.9 + Application Spare + + Application Spare + + Nordic Blueslate.12 + Radio domain + + Radio domain + + Nordic Blue.13 + Radio recovery + + Radio recovery + + Nordic Blue.14 + Radio Local A + + Radio Local A + + Nordic Blue.15 + Radio Local B + + Radio Local B + + Nordic Blueslate.17 + Secure domain and SysCtl + + Secure domain and SysCtl + + Nordic Blue.18 + Nordic Top + + Nordic Top + + Nordic Blue.19 + System Controller + + System Controller + + Nordic Blue.20 + SDFW, SDFW_RECOVERY + + SDFW, SDFW_RECOVERY + + Sheet.1004 + + Nordic Blue.1001 + OEM - controlled SUIT manifest Nordic-controlled SUIT manifest + + OEM - controlled SUIT manifest Nordic-controlled SUIT manifest + + Nordic Sky.1001 + + + + Nordic Sky.1002 + + + + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests_minimal.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests_minimal.svg new file mode 100644 index 000000000000..0eef41b75f7c --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_manifests_minimal.svg @@ -0,0 +1,85 @@ + + + + + + + + Page-1 + + Nordic Blueslate + Application domain + + Application domain + + Nordic Blueslate.12 + Radio domain + + Radio domain + + Nordic Blueslate.17 + Secure domain and SysCtl + + Secure domain and SysCtl + + Nordic Sky + Root + + Root + + Nordic Sky.9 + Application Local A + + Application Local A + + Nordic Sky.10 + Radio Local A + + Radio Local A + + Nordic Lake + Nordic top + + Nordic top + + Nordic Lake.13 + System controller + + System controller + + Nordic Lake.14 + SDFW, SDFW_RECOVERY + + SDFW, SDFW_RECOVERY + + Nordic Blue.10 + OEM - controlled SUIT manifest Nordic-controlled SUIT manifest + + OEM - controlled SUIT manifest Nordic-controlled SUIT manifest + + Nordic Sky.1001 + + + + Nordic Sky.1002 + + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_non_recovery_elements.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_non_recovery_elements.svg new file mode 100644 index 000000000000..9709da657b9e --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_non_recovery_elements.svg @@ -0,0 +1,165 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + Sheet.1019 + + Nordic Blueslate + Radio domain + + Radio domain + + Nordic Middle Grey + Application domain + + Application domain + + Nordic Light Grey.9 + Radio Local A + + Radio Local A + + Dynamic connector + + + + Nordic Blueslate.1001 + Secure Domain and SysCtl + + Secure Domain and SysCtl + + Nordic Light Grey.1002 + Application Local A + + Application Local A + + Nordic Light Grey.1003 + Application Spare + + Application Spare + + Nordic Light Grey.1004 + Application Local B + + Application Local B + + Dynamic connector.9 + + + + Dynamic connector.1005 + + + + Dynamic connector.1006 + + + + Dynamic connector.1007 + + + + Nordic Light Grey.1008 + Radio Local B + + Radio Local B + + Dynamic connector.1009 + + + + Sheet.12 + OEM-controlled SUIT manifest Dependency between manifests Nor... + + OEM-controlled SUIT manifest Dependency between manifests Nordic-controlled SUIT manifest + + Nordic Light Grey.19 + + + + Dynamic connector.25 + + + + Nordic Light Grey.1011 + + + + Nordic Light Grey.1014 + System controller + + System controller + + Nordic Light Grey.1015 + SDFW, SDFW_RECOVERY + + SDFW, SDFW_RECOVERY + + Dynamic connector.1016 + + + + Dynamic connector.1017 + + + + Dynamic connector.1018 + + + + Nordic Light Grey.1010 + Nordic Top + + Nordic Top + + Nordic Light Grey + Root + + Root + + Nordic Lake + Application, SecDOM FW + + Application, SecDOM FW + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_recovery_elements.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_recovery_elements.svg new file mode 100644 index 000000000000..69ed60430ad5 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_update_topology_for_recovery_elements.svg @@ -0,0 +1,88 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + Sheet.1001 + + Nordic Blueslate + Radio domain + + Radio domain + + Nordic Middle Grey + Application domain + + Application domain + + Nordic Lake + Application, SecDOM FW + + Application, SecDOM FW + + Nordic Light Grey.9 + Radio recovery + + Radio recovery + + Dynamic connector.14 + + + + Nordic Light Grey + Application recovery + + Application recovery + + Dynamic connector + + + + Sheet.18 + OEM-controlled SUIT manifest Dependency between manifests + + OEM-controlled SUIT manifest Dependency between manifests + + Nordic Light Grey.19 + + + + Dynamic connector.25 + + + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_acme_manifests.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_acme_manifests.svg new file mode 100644 index 000000000000..6ef2f86c20ed --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_acme_manifests.svg @@ -0,0 +1,91 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + Nordic Lake + Light Bulb root + + Light Bulb root + + Nordic Lake.6 + Roller Shutter root + + Roller Shutter root + + Nordic Lake.7 + Light Bulb application (local) Class ID: uuid5(adme_vid, `nRF... + + Light Bulb application (local) Class ID: uuid5(adme_vid, `nRF54H20_light_bulb_app`) + + Nordic Lake.8 + Roller Shutter application (local) Class ID: uuid5(acme_vid, ... + + Roller Shutter application (local) Class ID: uuid5(acme_vid, `nRF54H20_roller_shutter_app`) + + Nordic Sky + Radio application (local) Class ID: uuid5(acme_vid, `nRF54H20... + + Radio application (local) Class ID: uuid5(acme_vid, `nRF54H20_radio`) + + Sheet.1000 + Shared + + Shared + + Dynamic connector.1002 + + + + Dynamic connector.1003 + + + + Dynamic connector.1004 + + + + Dynamic connector.1005 + + + + Dynamic connector.1006 + + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_manifest_properties.svg b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_manifest_properties.svg new file mode 100644 index 000000000000..e4a24517d84e --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/suit_manifest_properties.svg @@ -0,0 +1,85 @@ + + + + + + + + Page-1 + + Nordic Blue + Vendor ID: uuid5(uuid.NAMESPACE_DNS, `examplecorp.com`) 2bd8b... + + Vendor ID: uuid5(uuid.NAMESPACE_DNS, `examplecorp.com`) 2bd8bef4-43e6-5235-a2ec-918b7d4dd2d2 + + Nordic Blue.6 + Class ID: uuid5(Vendor_ID, `nrf54H20_light_bulb_app_A`) 4f488... + + Class ID: uuid5(Vendor_ID, `nrf54H20_light_bulb_app_A`) 4f488e49-91d4-5762-b6e9-9a15128c8e20 + + Nordic Blue.7 + Downgrade prevention policy downgrade_prevention_enabled + + Downgrade prevention policy downgrade_prevention_enabled + + Nordic Blue.8 + Independent updateability policy independent_update_denied + + Independent updateability policy independent_update_denied + + Nordic Blue.9 + Signature verification policy signature_check_enabled_on_upda... + + Signature verification policy signature_check_enabled_on_update_and_boot + + Nordic Blue.10 + Ability to operate on device resources Booting the App Core M... + + Ability to operate on device resources Booting the App Core Memory access based on App Domain UICR + + Nordic Blue.11 + Key ID range for signature verification MANIFEST_PUBKEY_APPLI... + + Key ID range for signature verification MANIFEST_PUBKEY_APPLICATION_GEN0-2 0x40022100 – 0x40022102 + + Nordic Light Grey.1001 + Values provisioned by the OEM in device manufacturing process... + + Values provisioned by the OEM in device manufacturing process Values which cannot be customized by the OEM + + Nordic Blueslate.1002 + + + + Nordic Blueslate.1003 + + + + diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_cpu.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_cpu.rst index 1c82309fa242..7b8b7de81587 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_cpu.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_cpu.rst @@ -128,6 +128,8 @@ This CPU is intended to implement software-defined peripherals. .. note:: FLPR firmware support is not available during the customer sampling. +.. _ug_nrf54h20_secure_domain: + Secure Domain ************* @@ -140,6 +142,8 @@ Since the nRF54H platform supports global resource sharing, where memory partiti The Secure Domain Firmware (SDFW) exposes security-related services to the Cores in the system located in local domains (like Application and Radio). +.. _ug_nrf54h20_sys_ctrl: + System Controller ***************** diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_memory.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_memory.rst index c2e3d43ae787..15d8017dbd02 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_memory.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_memory.rst @@ -42,18 +42,22 @@ Local RAM is present in each of local domains Application core RAM -------------------- -.. image:: images/nrf54h20_memory_map_app.svg - :width: 300 px - The application core contains 32 KB of local RAM. Accessing this memory from the application core CPU has minimal latency, but accessing it from any other core adds significant latency. Because of this property, the local RAM in the application domain should be used mainly to store data frequently accessed by the application core, or to store timing-critical parts of the code executed by the application core. -Address range - 0x22000000 - 0x22008000 +.. table:: Application core RAM layout in the nRF54H20 -Size - 32 KB + +-------------+-----------+---------+----------+-----------------------------+ + |Start Address|End Address|Size (KB)|Total (KB)|Content | + +=============+===========+=========+==========+=============================+ + |config |0x22008000 |config |32 |Application's Non-Secure data| + +-------------+-----------+---------+ +-----------------------------+ + |0x22000000 |config |config | |Application's Secure data | + +-------------+-----------+---------+----------+-----------------------------+ + +.. note:: + *Config* means that you can configure the address to meet the specific needs of the application. Access control Application domain local RAM is accessible by the application core. @@ -70,16 +74,22 @@ Access control Radio core RAM -------------- -The radio core contains 96 KB of local RAM. Any access to this memory has minimal latency if originated either from radio core CPU or from peripherals with EasyDMA located in the radio core. Any access from any other core has a significant latency. Because of this property, local RAM in the radio core should be used mainly to store data frequently accessed by the radio core CPU or the radio protocol frames to be accessed by CCM or RADIO peripherals, or to store timing critical parts of the code executed by the radio core CPU. -Address range - 0x23000000 - 0x23030000 +.. table:: Radio core RAM layout in the nRF54H20 -Size - 192 KB + +-------------+-----------+---------+----------+-----------------------------+ + |Start Address|End Address|Size (KB)|Total (KB)|Content | + +=============+===========+=========+==========+=============================+ + |config |0x23030000 |config |192 |Radio's Non-Secure data | + +-------------+-----------+---------+ +-----------------------------+ + |0x23000000 |config |config | |Radio's Secure data | + +-------------+-----------+---------+----------+-----------------------------+ + +.. note:: + *Config* means that you can configure the address to meet the specific needs of the application. Access control The radio core local RAM is accessible by the radio core. @@ -291,8 +301,6 @@ Each of the cores has full control on the data layout and management in the assi There is also a Device Firmware Upgrade partition used to store firmware images used during the upgrade procedure. If code and data for the application core do not fit in MRAM_10, it can be partially or fully placed in MRAM_11. -.. to review - Address range 0x0E100000 - 0x0E200000 diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_gs.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_gs.rst index d29da9935141..db574db312b4 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_gs.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_gs.rst @@ -20,9 +20,13 @@ Make sure you have all the required hardware and that your computer has one of t Hardware ======== -* nRF54H20 DK, version PCA10175 v0.8.0 (ES4) or later revisions. - This is the only version of the nRF54H20 DK compatible with the |NCS| v2.7.99-cs2. - Check the version number on your DK's sticker to verify its compatibility with the |NCS| version v2.7.99-cs2. +* nRF54H20 DK version PCA10175: + + * Engineering B - ranging from v0.8.0 to 0.8.2 + * Engineering C - v0.8.3 and later revisions + + Check the version number on your DK's sticker to verify its compatibility with the |NCS|. + * USB-C cable. Software @@ -81,10 +85,10 @@ To work with the nRF54H20 DK, follow the instructions in the next sections to in .. _ug_nrf54h20_install_toolchain: -Installing the |NCS| v2.7.99-cs2 and its toolchain -************************************************** +Installing the |NCS| and its toolchain +************************************** -You can install the |NCS| v2.7.99-cs2 and its toolchain by using Toolchain Manager. +You can install the |NCS| and its toolchain by using Toolchain Manager. Toolchain Manager is a tool available from `nRF Connect for Desktop`_, a cross-platform tool that provides different applications that simplify installing the |NCS|. Both the tool and the application are available for Windows, Linux, and MacOS. @@ -109,9 +113,9 @@ To install the toolchain and the SDK using the Toolchain Manager app, complete t The Toolchain Manager window #. Click :guilabel:`SETTINGS` in the navigation bar to specify where you want to install the |NCS|. - #. In :guilabel:`SDK ENVIRONMENTS`, click the :guilabel:`Install` button next to the |NCS| version 2.7.99-cs2. + #. In :guilabel:`SDK ENVIRONMENTS`, click the :guilabel:`Install` button next to the |NCS| version |release|. - The |NCS| version 2.7.99-cs2 is installed on your machine. + The |NCS| version |release| is installed on your machine. The :guilabel:`Install` button changes to :guilabel:`Open VS Code`. #. Set up the preferred building method: @@ -157,10 +161,11 @@ Both of these terminal emulators start the required :ref:`toolchain environment Installing nRF Util and its commands ************************************ -Using the nRF54H20 DK with the |NCS| v2.7.99-cs2 requires the following: +Using the nRF54H20 DK with the |NCS| version |release| requires the following: * nRF Util version 7.11.1 or above -* nRF Util ``device`` version 2.5.4 +* nRF Util ``device`` version 2.7.2 +* nrf-regtool version 7.0.0 1. Download the nrfutil executable file from the `nRF Util development tool`_ product page. #. Add nRF Util to the system path on Linux and MacOS, or environment variables on Windows, to run it from anywhere on the system. @@ -180,11 +185,15 @@ Using the nRF54H20 DK with the |NCS| v2.7.99-cs2 requires the following: nrfutil self-upgrade -#. Install the nRF Util ``device`` command version 2.5.4 as follows:: + For more information, consult the `nRF Util`_ documentation. + +#. Install the nRF Util ``device`` command version 2.7.2 as follows:: - nrfutil install device=2.5.4 --force + nrfutil install device=2.7.2 --force -For more information, consult the `nRF Util`_ documentation. +#. Install the nrf-regtool version 7.0.0 as follows:: + + pip install nrf-regtool==7.0.0 .. _ug_nrf54h20_gs_bringup: @@ -214,17 +223,22 @@ To prepare the nRF54H20 DK for first use, you must manually program the values o #. Move the BICR HEX file to a folder of your choice, then program the BICR by running nRF Util from that folder using the following command:: - nrfutil device program --options chip_erase_mode=ERASE_NONE --firmware build/zephyr/bicr.hex --core Application --serial-number + nrfutil device program --options chip_erase_mode=ERASE_NONE --firmware bicr.hex --core Application --serial-number .. rst-class:: numbered-step +.. _ug_nrf54h20_SoC_binaries: + Programming the nRF54H20 SoC binaries ===================================== -After programming the BICR, the nRF54H20 SoC requires the provisioning of the nRF54H20 SoC binaries, a bundle ( :file:`nrf54h20_soc_binaries_v0.6.5.zip`) containing the precompiled firmware for the Secure Domain and System Controller. +After programming the BICR, the nRF54H20 SoC requires the provisioning of the nRF54H20 SoC binaries, a bundle containing the precompiled firmware for the Secure Domain and System Controller. To program the nRF54H20 SoC binaries to the nRF54H20 DK, do the following: -1. Download the `nRF54H20 SoC binaries v0.6.5`_. +1. Download the nRF54H20 SoC binaries v0.7.0: + + * `nRF54H20 SoC Binaries v0.7.0 for EngC DKs`_, compatible with the nRF54H20 DK v0.8.3 and later revisions + * `nRF54H20 SoC Binaries v0.7.0 for EngB DKs`_, compatible with the nRF54H20 DKs ranging from v0.8.0 to v0.8.2. .. note:: On MacOS, ensure that the ZIP file is not unpacked automatically upon download. @@ -247,35 +261,11 @@ To correctly operate, its lifecycle state must be transitioned to Root of Trust To transition the LCS to ``RoT``, do the following: -1. Verify the current lifecycle state of the nRF54H20:: - - nrfutil device x-adac-discovery --serial-number - - The output will look similar to the following:: - - *serial_number* - adac_auth_version 1.0 - vendor_id Nordic VLSI ASA - soc_class 0x00005420 - soc_id [e6, 6f, 21, b6, dc, be, 11, ee, e5, 03, 6f, fe, 4d, 7b, 2e, 07] - hw_permissions_fixed [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] - hw_permissions_mask [01, 00, 00, 00, 87, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] - psa_lifecycle LIFECYCLE_EMPTY (0x1000) - sda_id 0x01 - secrom_revision 0xad3b3cd0 - sysrom_revision 0xebc8f190 - token_formats [TokenAdac] - cert_formats [CertAdac] - cryptosystems [Ed25519Sha512] - Additional TLVs: - TargetIdentity: [ff, ff, ff, ff, ff, ff, ff, ff] - -#. If the lifecycle state (``psa_lifecycle``) shown is ``RoT`` (``LIFECYCLE_ROT (0x2000)``), no LCS transition is required. - If the lifecycle state (``psa_lifecycle``) shown is not ``RoT`` (``LIFECYCLE_EMPTY (0x1000)`` means the LCS is set to ``EMPTY``), set it to Root of Trust using the following command:: +1. Set the LCS of the nRF54H20 SoC to Root of Trust using the following command:: nrfutil device x-adac-lcs-change --life-cycle rot --serial-number -#. Verify again the current lifecycle state of the nRF54H20:: +#. Verify the new lifecycle state of the nRF54H20:: nrfutil device x-adac-discovery --serial-number @@ -315,11 +305,17 @@ It uses the ``nrf54h20dk/nrf54h20/cpuapp`` board target. To build and program the sample to the nRF54H20 DK, complete the following steps: 1. Connect the nRF54H20 DK to your computer using the **DEBUGGER** port on the DK. -#. Open nRF Connect for Desktop, navigate to the Toolchain Manager, select the v2.7.99-cs2 toolchain, and click the :guilabel:`Open terminal` button. +#. Open nRF Connect for Desktop, navigate to the Toolchain Manager, select the version |release| toolchain, and click the :guilabel:`Open terminal` button. #. In the terminal window, navigate to the :file:`zephyr/samples/sysbuild/hello_world` folder containing the sample. -#. Build the sample for application and radio cores by running the following command:: +#. Build the sample for application and radio cores by running the following commands: + + * For Engineering C (DKs 0.8.3 and later revisions):: + + west build -p -b nrf54h20dk/nrf54h20/cpuapp -T sample.sysbuild.hello_world.nrf54h20dk_cpuapp_cpurad . + + * For Engineering B (DKs from v0.8.0 to 0.8.2):: - west build -p -b nrf54h20dk/nrf54h20/cpuapp -T sample.sysbuild.hello_world.nrf54h20dk_cpuapp_cpurad . + west build -p -b nrf54h20dk@0.8.0/nrf54h20/cpuapp -T sample.sysbuild.hello_world.nrf54h20dk_cpuapp_cpurad . You can now program the sample. If you have multiple Nordic Semiconductor devices, make sure that only the nRF54H20 DK you want to program is connected. diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_device_config.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_device_config.rst new file mode 100644 index 000000000000..55e3817a7105 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_device_config.rst @@ -0,0 +1,474 @@ +.. _ug_nrf54h20_suit_device_config: + +nRF54H20 SUIT device configuration +################################## + +.. contents:: + :local: + :depth: 2 + + +The SUIT manifest defines both the installation and invocation logic using SUIT commands, classed either as conditions or directives. +This allows you to shape the logic to meet the end product's requirements, even when using a generic Secure Domain Firmware (SDFW). + +In addition to the logic, certain properties of the SUIT subsystem must be exposed as configurable parameters: + +* The number of SUIT manifests supported by the end product. +* Update and boot policies for the manifests. +* Attributes of the manifests. + +The following sections define these properties for products based on the nRF54H20 SoC, and describe the default configuration. + +SUIT manifests supported by the nRF54H20 SoC +******************************************** + +In the most complex predicted case, there can be 11 manifests in total, assigned across the 3 domains. + +Application domain +================== + +In the application domain, the following five SUIT manifests are supported: + +* The root manifest +* Three local app manifests +* A recovery manifest + +Local manifests are manifests that operate on the same set of local resources. +In most cases, using a single manifest is expected to be sufficient. +However, this document describes what is supported for the most complex scenarios, such as an A/B approach where two executable images are managed alongside a separate manifest for non-executable resources (for example, images or other media). + +Radio domain +============ + +In the radio domain, the following three SUIT manifests are supported: + +* Two local radio manifests +* A recovery manifest + +Secure Domain and System Controller +=================================== + +The Secure Domain and the System Controller support the following manifests: + +* The Nordic top manifest +* A System Controller manifest +* A Secure Domain manifest + +The Secure Domain Manifest is responsible solely for the delivery and initiation of the update process for the Secure Domain Firmware and Secure Domain Recovery Firmware images. +In the following diagrams, the Secure Domain Manifest is labeled as ``SDFW`` or ``SDFW_RECOVERY``. + +.. figure:: images/nrf54h20_suit_manifests.svg + + SUIT manifests supported by the nRF54H20 SoC in the most complex predicted case + +This diagram illustrates the most complex predicted configuration. +You can choose a subset of the manifests supported by the nRF54H20. + +.. figure:: images/nrf54h20_suit_manifests_minimal.svg + + SUIT manifests enabled in nRF54H20, Application and Radio images, without recovery support + +This diagram illustrates the minimal predicted configuration that supports the application and radio domains. + +Properties associated to SUIT manifest +************************************** + +.. figure:: images/suit_manifest_properties.svg + + An example of property values of the SUIT Application Local Manifest + +This diagram presents a set of properties associated with the SUIT manifest type, along with *example* values. +These properties are not part of the manifest itself but are configuration parameters stored on the device, defining the boundaries for allowable manifest behavior. +The properties covered in this document include: + +* The property that enables the manifest +* The vendor ID (VID) +* The manifest class ID +* The downgrade prevention policy +* The independent updateability policy +* The key ID ranges for SUIT manifest verification and signature verification policy +* The property granting the ability to operate on device resources + +The properties of Nordic-controlled manifests are hard-coded into the SDFW and cannot be modified. +However, some properties of user-customizable manifests are configurable using the manifest provisioning information data structure. + +Vendor ID and manifest class ID +=============================== + +Vendor ID and manifest class ID allow users to specify the vendor (for example, ``Nordic``, or ``ACME Corp``) and the manifest class. +In other words, they define the intended usage of the manifest, such as the manifest controlling firmware images associated with the application domain. + +Since it is impractical to store and process long, variable-length strings, RFC4122 UUID version 5 (uuid5) is used instead. + +There is no strict requirement on how to generate these ID values, as long as they remain unique. +However, the recommended method for creating a VID is ``Vendor ID = UUID5(DNS_PREFIX, vendor domain name)``. +The following example shows how to generate a VID for ``nordicsemi.com`` using Python:: + + uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') + +This generates ``7617daa5-71fd-5a85-8f94-e28d735ce9f4``. + +The recommended method for creating a manifest class ID is ``Manifest Class ID = UUID5(Vendor ID, Class-Specific-Information)``. +The following example shows how to generate a manifest class ID using Python:: + + uuid5(nordic_vid, 'nRF54H20_sample_app') + +Assuming ``nordic_vid`` is equal to ``7617daa5-71fd-5a85-8f94-e28d735ce9f4``, it generates ``08c1b599-55e8-5fbc-9e76-7bc29ce1b04d``. + +How manifest class ID-based filtering works +------------------------------------------- + +The SDFW has access to a list of manifest class IDs supported by the device. +During the update candidate evaluation process, the SDFW compares the manifest class ID of each candidate manifest against this list. +If the manifest class ID of a candidate manifest is not recognized by the device, the update candidate is rejected. + +Expressing Class-specific information +------------------------------------- + +The following example illustrates this. +ACME Corp has two product types in its portfolio: roller shutter motors and light bulbs. +Both product types are powered by the nRF54H20 SoC and share the hardware design of the radio-related part, to the extent that they can share the same set of executable binary images for the radio domain. +At the same time, hardware differences between motors and light bulbs are significant and it makes sense to have a separated set of executable binary images for the application domain. + +This means that it is worth considering to assign the same manifest class ID for Radio Local Manifest for both products, for example:: + + uuid5(acme_vid, 'nRF54H20_radio') + +And two distinct manifest class ID values for Application Local Manifest, for example:: + + uuid5(acme_vid, 'nRF54H20_light_bulb_app') + + uuid5(acme_vid, 'nRF54H20_roller_shutter_app') + +.. figure:: images/suit_acme_manifests.svg + + Manifest hierarchies for ACME Corp devices. + +This approach allows ACME Corp to share the same radio domain update package (executable binaries and SUIT manifest) across both products. +Additionally, if an application domain update package intended for the light bulb is accidentally delivered to the roller shutter motor, the motor will reject it due to the unrecognized (unsupported) manifest class ID. + +Downgrade prevention policy +=========================== + +Product requirements can impose different downgrade prevention policies for different manifests. +The following values are supported: + +* ``downgrade_prevention_disabled`` +* ``downgrade_prevention_enabled`` + +How downgrade prevention works +------------------------------ + +The ``suit-manifest-sequence-number`` (an element of the SUIT manifest) is a monotonically increasing anti-rollback counter. +As part of the update candidate evaluation process, the ``suit-manifest-sequence-number`` of the candidate manifest is compared with the installed counterpart. +The result of this comparison, along with the associated downgrade prevention policy, determines whether a candidate is accepted or rejected. + +Assuming ``downgrade_prevention_enabled`` is enabled, a candidate manifest will be accepted only if its ``suit-manifest-sequence-number`` is equal or bigger than the ``suit-manifest-sequence-number`` of the installed manifest. + +Independent updateability policy +================================ + +This policy allows the expression of whether a candidate manifest of a specific manifest class ID can be updated independently of its parent. +In some cases, this can be the intended behavior, while in others, the opposite can be desired. + +The following policy values are supported: + +* ``independent_update_allowed`` +* ``independent_update_denied`` + +How independent updateability policy works +------------------------------------------ + +The system is designed to allow the expression of an update package as a candidate manifest along with its dependencies (candidate, child manifests). +In the simplest case, an update package composed of just one manifest (for example, a Local App Manifest), the policy ``independent_update_denied`` associated with the Local App Manifest would block the update. + +This be considered intended behavior because images for the Application Core (controlled by the Local App Manifest) can rely on functionality provided by images controlled by other manifests, such as the radio manifest. +In such a case, updating the app images individually could cause interoperability issues. +Blocking the independent update of the manifest implies that the update must go through the parent manifest. +If two manifests share the same parent, the installation sequence of the parent manifest can manage compatibility between the two manifests. + +Key ID ranges for SUIT manifest verification and signature verification policy +================================================================================== + +Signature verification helps ensure the following: + +* The signed material has not been altered. +* The material is signed by the proper signing authority. + +This is essential for detecting situations where a valid signing key, intended for one type of material (for example, Local App Manifest), is maliciously used to sign another type of material (for example, Local Radio Manifest). + +Nordic-related SUIT manifests are authenticated using the Edwards-curve Digital Signature Algorithm, specifically Ed25519. +Algorithms for verifying user-specific SUIT manifests are beyond the scope of this document. + +Signing Authorities +------------------- + +Each manifest type in SoC is associated with a range of Key IDs that are allowed to be used for signing and verifying the signature of a specific manifest. +The user does not have the ability to override these settings. +The range of Key IDs associated with distinct manifests is hard-coded in the SDFW. + +Provisioning of key material +---------------------------- + +The respective Nordic-related public keys for SUIT manifest verification are embedded in the SDFW. +You can provision these public keys as part of the device provisioning process. + +The key provisioning process for user-specific keys is beyond the scope of this document. + +Signature verification policy +----------------------------- + +The policy allows you to verify if a manifest must be verified before processing. +The following signature verification policy values are supported: + +* ``signature_check_disabled`` +* ``signature_check_enabled_on_update`` +* ``signature_check_enabled_on_update_and_boot`` + +.. note:: + + For SUIT manifests related to the application and radio domains, signature verification must be skipped, regardless of the configured signature verification policy, if the respective domain is in one of the following lifecycle states (LCS): + + * ``LCS_EMPTY`` + * ``LCS_ROT`` + * ``LCS_ROT_DEBUG`` + +Ability to operate on device resources +========================================== + +As the manifest operates on device resources, such as accessing memory (whether NVM, RAM, or both) and starting the processor, access rights are associated with the manifest class ID. +This ensures that if a manifest belonging to one local domain (for example, the application domain) attempts to declare components that span into areas belonging to another local domain (for example, the radio domain or, more critically, the Secure Domain), the system can detect and block this behavior. + +SUIT topologies +***************** + +The supported SUIT topologies are the following. + +Invocation path (normal booting) +================================ + +.. figure:: images/nrf54h20_invocation_topology.svg + + SUIT topology for nRF54H20 invocation path in the most complex predicted case + +In the event of a device cold boot, following the standard invocation procedure, the SDFW will first execute the validation, loading, and invocation sequences defined in the top manifest from Nordic Semiconductor. +Next, it will execute these sequences as specified in the root manifest. + +The invocation of Nordic-related SUIT elements is fully controlled by SUIT manifests signed by Nordic Semiconductor. +This approach ensures that entities other than Nordic cannot manipulate the order of execution of Nordic-controlled elements. + +Both the Nordic top and root manifests control the boot process of their respective dependency manifests. + +Update path +=========== + +Updating regular resources (such as SUIT manifests and images) alongside those responsible for device recovery in a single update increases the risk of placing the device in an unrecoverable state. +To minimize this risk, recovery-dedicated SUIT manifests cannot be updated together with other manifests. + +Update path for elements not dedicated to SUIT recovery: + +.. figure:: images/nrf54h20_update_topology_for_non_recovery_elements.svg + + SUIT topology for the nRF54H20 SoC update path in the most complex predicted case for elements not dedicated to SUIT recovery. + +Update path for elements dedicated to SUIT recovery: + +.. figure:: images/nrf54h20_update_topology_for_recovery_elements.svg + + SUIT topology for the nRF54H20 SoC update path for elements dedicated to SUIT recovery. + +Recovery path +============= + +Verification failures (for the SUIT manifest signature, SUIT manifest digest, and images) in the invocation path force the device to reboot into the recovery path. +The recovery path is essentially an invocation path with a specific purpose: to download missing elements (such as images and manifests) and provide them to the SDFW as update candidates. + +.. note:: + If the device is in a state requiring recovery and the application recovery manifest is not activated the SDFW will boot from the root manifest. + If the application recovery manifest is activated, but the application recovery manifest is damaged, the SDFW will NOT boot any local images. + +In the event of a device cold boot in the recovery path, the SDFW will first execute the respective validation, load, and invocation sequences from the nordic top manifest, followed by the sequences from the application recovery manifest. +Any potential failure of the nordic top manifest or its dependencies will NOT interrupt the boot process. + +The application recovery manifest has the ability to directly control local application images and manage the boot process using the respective dependency manifests (such as the application and radio local manifests, and the radio recovery manifest). +This gives the user flexibility in defining the device's behavior in recovery scenarios. +One possible scenario is reusing the regular radio image to download a damaged application image. + +.. figure:: images/nrf54h20_recovery_invocation_topology.svg + + SUIT topology for the nRF54H20 SoC recovery path in the most complex predicted case. + +Properties of user-controlled SUIT manifests configurable by the users +********************************************************************** + +A user-controlled SUIT manifest must be explicitly enabled or configured to be functional. + +The following tables contain *proposed* configuration parameter values selected to render R&D activities more convenient. + +Root manifest +============= + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Default value | Note | ++==================================+======================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Class ID | 3f6a3a4d-cdfa-58c5-acce-f9f584c41124 | RFC4122 uuid5(nordic_vid, 'nRF54H20_sample_root') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_allowed | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Application local manifest 1 +============================ + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Default value | Note | ++==================================+======================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Class ID | 08c1b599-55e8-5fbc-9e76-7bc29ce1b04d | RFC4122 uuid5(nordic_vid, 'nRF54H20_sample_app') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_denied | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Radio local manifest 1 +====================== + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Default value | Note | ++==================================+======================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Class ID | 816aa0a0-af11-5ef2-858a-feb668b2e9c9 | RFC4122 uuid5(nordic_vid, 'nRF54H20_sample_rad') | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_denied | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_disabled | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Properties of user-controlled SUIT manifests fixed in the SDFW implementation +***************************************************************************** + +Root manifest +============= + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Proposed value | Note | ++==================================+======================================+===========================================================+ +| Independent updateability policy | independent_update_allowed | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Signing Key ID Range | MANIFEST_PUBKEY_OEM_ROOT_GEN0-2 | 0x4000AA00 - 0x4000AA02 | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Does not operate on local resources | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Application recovery manifest +============================= + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Proposed value | Note | ++==================================+======================================+===========================================================+ +| Independent updateability policy | independent_update_allowed | | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Signing Key ID Range | MANIFEST_PUBKEY_APPLICATION_GEN0-2 | 0x40022100 - 0x40022102 | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Ability to boot the App Core, | +| | | Memory access based on App Domain UICR | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Application local manifest 1, 2, 3 +================================== + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Proposed value | Note | ++==================================+======================================+===========================================================+ +| Signing Key ID Range | MANIFEST_PUBKEY_APPLICATION_GEN0-2 | 0x40022100 - 0x40022102 | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Ability to boot the App Core, | +| | | Memory access based on App Domain UICR | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Radio Recovery Manifest, Radio Local manifest 1, 2 +================================================== + ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Property | Proposed value | Note | ++==================================+======================================+===========================================================+ +| Signing Key ID Range | MANIFEST_PUBKEY_RADIO_GEN0-2 | 0x40032100 - 0x40032102 | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Ability to boot the Radio Core, | +| | | Memory access based on radio domain UICR | ++----------------------------------+--------------------------------------+-----------------------------------------------------------+ + +Properties of Nordic-controlled SUIT manifests +********************************************** + +All values given in this section are hard-coded in the SDFW and cannot be altered by the user. +Support for all the manifests described in the following tables are enabled by default. + +Nordic top manifest +=================== + ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Property | Default value | Note | ++==================================+============================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Class ID | f03d385e-a731-5605-b15d-037f6da6097f | RFC4122 uuid5(nordic_vid, 'nRF54H20_nordic_top') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_enabled | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_allowed | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_enabled_on_update_and_boot | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Does not operate on local resources | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ + +System Controller manifest +========================== + ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Property | Default value | Note | ++==================================+============================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Class ID | c08a25d7-35e6-592c-b7ad-43acc8d1d1c8 | RFC4122 uuid5(nordic_vid, 'nRF54H20_sys') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_enabled | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_denied | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_enabled_on_update_and_boot | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Ability to boot the System Controller, | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ + +Secure Domain manifest +====================== + ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Property | Proposed value | Note | ++==================================+============================================+===========================================================+ +| Vendor ID | 7617daa5-71fd-5a85-8f94-e28d735ce9f4 | RFC4122 uuid5(uuid.NAMESPACE_DNS, 'nordicsemi.com') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Class ID | d96b40b7-092b-5cd1-a59f-9af80c337eba | RFC4122 uuid5(nordic_vid, 'nRF54H20_sec') | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Downgrade prevention policy | downgrade_prevention_enabled | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Independent updateability policy | independent_update_denied | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Signature verification policy | signature_check_enabled_on_update_and_boot | | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ +| Resource Access Rights | | Ability to trigger installation of SDFW, SDFW_UPDATE | ++----------------------------------+--------------------------------------------+-----------------------------------------------------------+ diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst index 1279eeec1f28..5601cb5e2ee1 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst @@ -24,6 +24,7 @@ For a list of available SUIT samples, see the :ref:`suit_samples` page. ug_nrf54h20_suit_intro.rst ug_nrf54h20_suit_manifest_overview.rst + ug_nrf54h20_suit_device_config.rst ug_nrf54h20_suit_customize_qsg.rst ug_nrf54h20_suit_customize_dfu.rst ug_nrf54h20_suit_fetch diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_external_memory.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_external_memory.rst index 76255941e5e0..0aabbe26a28a 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_external_memory.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_external_memory.rst @@ -137,16 +137,69 @@ Common steps for both push and fetch models In this example, the component index is ``3``. In the following steps, the companion image component is selected with ``suit-directive-set-component-index: 3``. - #. Modify the ``suit-install`` sequence in the application manifest file (:file:`app_envelope.yaml.jinja2`) to boot the companion image before accessing the candidate images stored in the external memory: + #. Append directives to the ``suit-shared-sequence`` sequence in the application manifest file (:file:`app_envelope.yaml.jinja2`) to set the expected digest of the companion application: + + .. code-block:: yaml + + suit-shared-sequence: + - suit-directive-set-component-index: 3 + - suit-directive-override-parameters: + suit-parameter-image-digest: + suit-digest-algorithm-id: cose-alg-sha-256 + suit-digest-bytes: + file: {{ flash_companion['binary'] }} + + #. Modify the ``suit-install`` sequence in the application manifest file (:file:`app_envelope.yaml.jinja2`) to load into RAM and boot the companion image before accessing the candidate images stored in the external memory: .. code-block:: yaml suit-install: + # Use CAND_IMG component to access flash companion binary, stored as one of the integrated payloads. + - suit-directive-set-component-index: 1 + - suit-directive-override-parameters: + suit-parameter-uri: "#{{ flash_companion['name'] }}" + suit-parameter-image-digest: + suit-digest-algorithm-id: cose-alg-sha-256 + suit-digest-bytes: + file: {{ flash_companion['binary'] }} + - suit-directive-fetch: + - suit-send-record-failure + # Verify integrity of the companion binary in the envelope. + - suit-condition-image-match: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure + # Copy companion into local RAM. - suit-directive-set-component-index: 3 + - suit-directive-override-parameters: + suit-parameter-source-component: 1 + - suit-directive-copy: + - suit-send-record-failure + # Verify integrity of the companion binary in the local RAM. + - suit-condition-image-match: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure + # Boot the companion application. - suit-directive-invoke: - - suit-send-record-failure + - suit-send-record-failure + + To further improve the update procedure robustness, you can copy all integrity checks from the ``suit-install`` to the ``suit-candidate-verification`` sequence. - The companion image can be optionally upgraded and have its integrity checked. + #. Append the flash companion binary as integrated payload inside SUIT envelope: + + .. code-block:: yaml + + SUIT_Envelope_Tagged: + suit-authentication-wrapper: { ... } + suit-manifest: { .. } + + suit-integrated-payloads: + "#{{ flash_companion['name'] }}": {{ flash_companion['binary'] }} + + The flash companion binary must be available before the driver of the external memory is booted, so it must be transferred as part of the update candidate envelope and fit within the DFU partition inside the internal MRAM memory. Steps specific for the push model ================================= @@ -157,7 +210,7 @@ Steps specific for the push model #. Modify the manifest files for all domains by completing the following steps: - a. Ensure that the URI used by the ``suit-payload-fetch`` sequence to fetch a given image matches the :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI` Kconfig option. + a. Ensure that the URI used by the ``suit-directive-fetch`` command to fetch a given image matches the :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI` Kconfig option. #. Ensure that the envelope integrates the specified image within the envelope integrated payloads section. This is ensured by default if you use the provided SUIT envelope templates. @@ -193,7 +246,79 @@ Steps specific for the fetch model - suit-directive-fetch: - suit-send-record-failure - This snippet assumes that ``CACHE_POOL`` is the third component on the manifest's components list (so its component index is 2) + This snippet assumes that ``CACHE_POOL`` is the third component on the manifest's components list (so its component index is ``2``) + +#. If your application uses the radio core, complete the following steps to modify the radio core manifest file :file:`rad_envelope.yaml.jinja2`: + + a. Modify the ``CACHE_POOL`` identifier in the SUIT manifest: + + .. code-block:: yaml + + suit-components: + ... + - - CACHE_POOL + - 1 + + The ``CACHE_POOL`` identifier must match the identifier of the cache partition defined in the DTS file. + + #. Add the ``suit-payload-fetch`` sequence: + + .. code-block:: yaml + + suit-payload-fetch: + - suit-directive-set-component-index: 2 + - suit-directive-override-parameters: + suit-parameter-uri: 'file://{{ radio['binary'] }}' + - suit-directive-fetch: + - suit-send-record-failure + + This snippet assumes that ``CACHE_POOL`` is the third component on the manifest's components list (so its component index is ``2``) + +#. Complete the following steps to modify the root manifest file :file:`root_with_binary_nordic_top_extflash.yaml.jinja2`: + + a. Add the ``suit-payload-fetch`` sequence: + + .. code-block:: yaml + + suit-payload-fetch: + - suit-directive-set-component-index: 0 + - suit-directive-override-parameters: + suit-parameter-uri: "#{{ application['name'] }}" + - suit-directive-fetch: + - suit-send-record-failure + - suit-condition-dependency-integrity: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure + - suit-directive-process-dependency: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure + + This snippet assumes that ``CAND_MFST`` is the first component on the manifest's components list (so its component index is ``0``). + + #. If your application uses the radio core, append the following to the ``suit-payload-fetch`` sequence: + + .. code-block:: yaml + + suit-payload-fetch: + - suit-directive-set-component-index: 0 + - suit-directive-override-parameters: + suit-parameter-uri: "#{{ radio['name'] }}" + - suit-directive-fetch: + - suit-send-record-failure + - suit-condition-dependency-integrity: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure + - suit-directive-process-dependency: + - suit-send-record-success + - suit-send-record-failure + - suit-send-sysinfo-success + - suit-send-sysinfo-failure Testing the application with external flash support =================================================== @@ -242,4 +367,5 @@ Limitations * The Secure Domain, System Controller and companion image update candidates must always be stored in the MRAM. Trying to store those candidates in external memory will result in a failure during the installation process. -* The companion image needs a dedicated area in the executable region of the MRAM that is assigned to the application domain. +* The companion image needs either a dedicated area in the executable region of the MRAM or it needs to fit within the local RAM that is assigned to the application domain. + The default flash companion application uses local RAM, so there is no need to reserve additional area in the main application memory map. diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_push.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_push.rst index 4ccbc9f4993a..8e136a3afa21 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_push.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_push.rst @@ -87,14 +87,14 @@ To reconfigure the sample to allow for pushing images into DFU cache partitions, * Optionally, modify :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_PARTITION` to select the partition where the image will be pushed (default is partition 1). * Optionally, modify the :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI` to modify the URI used as key for the given image in the DFU cache. -#. Ensure that the URI used by the ``suit-payload-fetch`` sequence to fetch a given image matches the :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI` Kconfig option. +#. Ensure that the URI used by the ``suit-directive-fetch`` command to fetch a given image matches the :kconfig:option:`CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI` Kconfig option. This is done by default when using the manifest templates provided by Nordic Semiconductor. For the application image URI, you can do that as follows (assuming the target name ``application`` for the image): .. code-block:: yaml - suit-directive-override-parameters: - suit-parameter-uri: '{{ application['config']['CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI'] }}' + suit-parameter-uri: "{{ application['config']['CONFIG_SUIT_DFU_CACHE_EXTRACT_IMAGE_URI'] }}" - suit-directive-fetch: - suit-send-record-failure diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_soc_binaries.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_soc_binaries.rst index 301c81cd8154..db02651e1602 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_soc_binaries.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_soc_binaries.rst @@ -3,6 +3,10 @@ Upgrade the nRF54h20 SOC binaries with SUIT ########################################### +.. contents:: + :local: + :depth: 2 + The nRF54H20 SoC includes the *nRF54h20 SOC binaries*, precompiled firmware components provided by Nordic Semiconductor that provide basic functionality and security features. To see which version of the nRF54h20 SOC binaries to use with the given version of the nRF Connect SDK, see :ref:`abi_compatibility`. diff --git a/doc/nrf/drivers/wifi.rst b/doc/nrf/drivers/wifi.rst new file mode 100644 index 000000000000..df32be17493f --- /dev/null +++ b/doc/nrf/drivers/wifi.rst @@ -0,0 +1,8 @@ +Wi-Fi drivers +############# + +.. toctree:: + :maxdepth: 2 + + wifi/nrf70_native + wifi/nrf70_portable diff --git a/doc/nrf/drivers/wifi/nrf70_native.rst b/doc/nrf/drivers/wifi/nrf70_native.rst new file mode 100644 index 000000000000..7c1b29d87d4e --- /dev/null +++ b/doc/nrf/drivers/wifi/nrf70_native.rst @@ -0,0 +1,120 @@ +.. _nrf70_wifi: + +nRF Wi-Fi driver +################ + +.. contents:: + :local: + :depth: 2 + +The nRF Wi-Fi driver implements the Wi-Fi® protocol for the nRF70 FullMAC Series of devices. +FullMAC devices implement the Wi-Fi protocol in the chipset. +The driver configures the chipset and transfers the frames to and from the device to the networking stack. + +The nRF70 Series device is a companion IC and can be used with any Nordic Semiconductor System-on-Chips (SoCs), such as the nRF53 and nRF91 Series SoCs. + +You can enable the driver by using the following Kconfig options: + + * When using :ref:`zephyr:sysbuild` to build your application, set the :kconfig:option:`SB_CONFIG_WIFI_NRF70` Kconfig option to ``y`` in your :file:`sysbuild.conf` file.` + * When not using :ref:`zephyr:sysbuild`, set the :kconfig:option:`CONFIG_WIFI_NRF70` Kconfig option to ``y`` in your application's :file:`prj.conf` file. + +Architecture +************* + +The following figure illustrates the architecture of the nRF Wi-Fi driver. + +.. figure:: /images/nrf700x_wifi_driver.svg + :alt: nRF Wi-Fi driver block diagram + :align: center + :figclass: align-center + + nRF Wi-Fi driver architecture overview + +Design overview +*************** + +The nRF Wi-Fi driver follows an OS-agnostic design, and the driver implementation is split into OS-agnostic and OS (Zephyr)-specific code. +The OS-agnostic code is located in the :file:`${ZEPHYR_BASE}/../modules/hal/nordic/drivers/nrf_wifi/` folder, and the Zephyr OS port is located in the :file:`${ZEPHYR_BASE}/drivers/wifi/nrfwifi/` folder. + +The driver supports two modes of operation: + +Wi-Fi mode +========== + +In this mode, the driver is designed to be used with the Zephyr networking stack. +It is implemented as a network interface driver. + +The driver supports the following IEEE 802.11 features: + +* Wi-Fi 6 (802.11ax) support +* WPA3â„¢/WPA2â„¢ personal security +* IEEE 802.11 Power Save modes +* Scan-only mode +* IEEE 802.11 :term:`Station mode (STA)` +* :term:`Software-enabled Access Point (SoftAP or SAP)` mode + +The Wi-Fi Direct® mode feature is in the driver code but is not yet supported. + +Except for scan-only mode, the driver uses the host access point daemon (hostapd) to implement AP Media Access Control (MAC) Sublayer Management Entity (AP MLME) and wpa_supplicant to implement 802.1X supplicant. + +Radio Test mode +=============== + +The nRF Wi-Fi driver supports Radio Test mode, which you can use to test the RF performance of the nRF70 Series device. +This is a build time option that you can enable using the :kconfig:option:`CONFIG_NRF70_RADIO_TEST` Kconfig option. + +For more details about using this driver in Radio Test mode, see :ref:`wifi_radio_test`. + +Driver to nRF70 Series device communication +******************************************* + +The driver communicates with the nRF70 Series device using the QSPI/SPI interface. +The driver uses the QSPI/SPI interface to send commands to the nRF70 Series device, and to transfer data to and from the device. +The nRF7002 DK uses QSPI, whereas the nRF7002 EK uses SPI. + +To connect the nRF7002 EK to the SoC, the ``nrf7002ek`` shield is required. + +Configuration +************* + +The nRF Wi-Fi driver has the following configuration options: + +Kconfig configuration +===================== + +.. options-from-kconfig:: /../../../../../zephyr/drivers/wifi/nrfwifi/Kconfig.nrfwifi + :show-type: + +Devicetree specification configuration +====================================== + +The maximum transmit power achieved on an nRF70 Series device-based product depends on the frequency band and operating channel. +This varies across different :term:`Printed Circuit Board (PCB)` designs. + +Multiple calibrations and checks are implemented to ensure consistency across channels and devices. +However, these values depend on PCB design, which may result in Error Vector Magnitude (EVM) and spectral mask failures. +To avoid this problem, you can specify the power ceiling at which the EVM and spectral mask are met for a given PCB design. +Additionally, build-time parameters are made available to drivers through the DTS overlay file. + +The following code snippet shows an example of the DTS overlay file. +Note that the numbers used in this following example do not represent any particular PCB design or package type. + +You must replace these values with measurements obtained from transmitter testing on your own PCB designs. +The values are represented in 1 dB increments. +To configure 15 dBm, use the value ``15``. + +.. code-block:: devicetree + + &nrf70 { + wifi-max-tx-pwr-2g-dsss = <21>; + wifi-max-tx-pwr-2g-mcs0 = <16>; + wifi-max-tx-pwr-2g-mcs7 = <16>; + wifi-max-tx-pwr-5g-low-mcs0 = <14>; + wifi-max-tx-pwr-5g-low-mcs7 = <14>; + wifi-max-tx-pwr-5g-mid-mcs0 = <14>; + wifi-max-tx-pwr-5g-mid-mcs7 = <14>; + wifi-max-tx-pwr-5g-high-mcs0 = <14>; + wifi-max-tx-pwr-5g-high-mcs7 = <14>; + }; + +See the DTS binding documentation for more information. diff --git a/doc/nrf/drivers/wifi/nrf70_portable.rst b/doc/nrf/drivers/wifi/nrf70_portable.rst new file mode 100644 index 000000000000..e9d7cd8146dc --- /dev/null +++ b/doc/nrf/drivers/wifi/nrf70_portable.rst @@ -0,0 +1,15 @@ +.. nrf70_portable_wifi: + +nRF Wi-Fi portable driver +######################### + +The nRF Wi-Fi portable driver implements OS-agnostic code for the nRF70 FullMAC Series of devices. +This code can be used to implement OS-native drivers for the nRF70 Series devices. + +The Zephyr native driver implementation is located in the :file:`${ZEPHYR_BASE}/drivers/wifi/nrfwifi/` folder. + +API documentation +***************** + +Once the nRF Wi-Fi driver is initialized, the application recognizes it as an Ethernet interface. +To use the Ethernet interface, the application can use the `Zephyr Network APIs`_. diff --git a/doc/nrf/external_comp/bt_fast_pair.rst b/doc/nrf/external_comp/bt_fast_pair.rst index 4138f4c37941..bda04d55bdeb 100644 --- a/doc/nrf/external_comp/bt_fast_pair.rst +++ b/doc/nrf/external_comp/bt_fast_pair.rst @@ -284,6 +284,7 @@ You can use the following API functions only in the *unready* state of the FMDN * The :c:func:`bt_fast_pair_fmdn_info_cb_register` function (optional) * The :c:func:`bt_fast_pair_fmdn_ring_cb_register` function (mandatory with the Kconfig configuration for at least one ringing component) * The :c:func:`bt_fast_pair_fmdn_read_mode_cb_register` function (optional) + * The :c:func:`bt_fast_pair_fmdn_motion_detector_cb_register` function (mandatory if the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MOTION_DETECTOR` Kconfig option is enabled) * The :c:func:`bt_fast_pair_fmdn_id_set` API function used for assigning Bluetooth identity to FMDN activities (like advertising and connections) * The :c:func:`bt_fast_pair_factory_reset` API function used for performing factory reset of all Fast Pair data @@ -768,6 +769,8 @@ The following sources of ringing activity are supported: * :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_FMDN_BT_GATT` - This ringing source originates from the Bluetooth Fast Pair service and its Beacon Actions characteristic that is defined in the FMDN Accessory specification. * :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_DULT_BT_GATT` - This ringing source originates from the Bluetooth Accessory Non-owner service and its characteristic that are defined in the DULT specification. This source is available only when the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT` Kconfig option is enabled. +* :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_DULT_MOTION_DETECTOR` - This ringing source originates from the DULT motion detector module. + This source is available only when the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MOTION_DETECTOR` Kconfig option is enabled. The following callbacks are defined in the :c:struct:`bt_fast_pair_fmdn_ring_cb` structure: @@ -780,6 +783,8 @@ The following callbacks are defined in the :c:struct:`bt_fast_pair_fmdn_ring_cb` * Ringing timeout in deciseconds. The timeout value of the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_RING_REQ_TIMEOUT_DULT_BT_GATT` Kconfig option is used for the :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_DULT_BT_GATT` DULT source. The default value of this Kconfig is in line with the `Fast Pair Unwanted Tracking Prevention Guidelines`_ documentation. + The timeout value of the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_RING_REQ_TIMEOUT_DULT_MOTION_DETECTOR` Kconfig option is used for the :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_DULT_MOTION_DETECTOR` DULT source. + There are no specific requirements for this Kconfig value in neither the FMDN nor the DULT specification. * Ringing volume level. The :c:member:`bt_fast_pair_fmdn_ring_cb.start_request` callback can be called again when the ringing action has already started. @@ -835,6 +840,38 @@ This update policy applies to all listed stop trigger types. To satisfy the requirements from the DULT specification when the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT` Kconfig option is enabled, the FMDN extension communicates with the DULT module to receive ringing requests from the DULT peers and to send updates regarding the ringing state. For more details on the ringing mechanism in the DULT module, see the :ref:`ug_dult_sound` documentation. +.. _ug_bt_fast_pair_gatt_service_fmdn_dult_motion_detector: + +Interacting with the motion detector from DULT +---------------------------------------------- + +The motion detector is an optional feature of the DULT subsystem that can be integrated into the FMDN extension. +For more details about the feature, see the `DULT motion detector`_ section of the DULT specification. +To activate the DULT motion detector functionality in the FMDN extension, enable the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MOTION_DETECTOR` Kconfig option. +The FMDN extension implementation acts as a thin wrapper for the DULT motion detector module callbacks. +It passes callbacks from the DULT motion detector module to the user application. + +To register the motion detector callbacks, use the :c:func:`bt_fast_pair_fmdn_motion_detector_cb_register` function. +You must register all motion detector callbacks defined in the :c:struct:`bt_fast_pair_fmdn_motion_detector_cb` structure: + +* The motion detector start request is indicated by the :c:member:`bt_fast_pair_fmdn_motion_detector_cb.start` callback. + After this callback is called, the motion detector events are polled periodically with the :c:member:`bt_fast_pair_fmdn_motion_detector_cb.period_expired` callback. + A typical action after the motion detector start request is to power up the accelerometer and start collecting motion data. +* The motion detector period expired event is indicated by the :c:member:`bt_fast_pair_fmdn_motion_detector_cb.period_expired` callback. + This callback is called at the end of each motion detector period. + The :c:member:`bt_fast_pair_fmdn_motion_detector_cb.start` callback indicates the beginning of the first motion detector period. + The next period is started as soon as the previous period expires. + You need to notify the DULT module if motion was detected in the previous period. + The return value of this callback is used to pass this information. + The motion must be considered as detected if it fulfills the requirements defined in the `DULT motion detector`_ section of the DULT documentation. +* The motion detector stop request is indicated by the :c:member:`bt_fast_pair_fmdn_motion_detector_cb.stop` callback. + It concludes the motion detector activity that was started by the :c:member:`bt_fast_pair_fmdn_motion_detector_cb.start` callback. + A typical action after the motion detector stop request is to power down the accelerometer. + +The motion detector is started by the DULT subsystem when the accessory is in the separated state for an amount of time controlled by the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN` and :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX` Kconfig options. +When the motion is detected during the motion detector active period, the :c:member:`bt_fast_pair_fmdn_ring_cb.start_request` callback is called to request the ringing action with the :c:enum:`BT_FAST_PAIR_FMDN_RING_SRC_DULT_MOTION_DETECTOR` parameter as the ringing source. +Emitted sounds help to alert the non-owner that they are carrying an accessory that does not belong to them and might be used by the original owner to track their location. + .. _ug_bt_fast_pair_gatt_service_fmdn_battery_dult: Battery information with DULT diff --git a/doc/nrf/external_comp/dult.rst b/doc/nrf/external_comp/dult.rst index f03b840df79d..98408648bb1e 100644 --- a/doc/nrf/external_comp/dult.rst +++ b/doc/nrf/external_comp/dult.rst @@ -46,6 +46,7 @@ The DULT integration in the |NCS| consists of the following steps: #. :ref:`Managing the near-owner state ` #. :ref:`Managing the identification process ` #. :ref:`Using the sound callbacks and managing the sound state ` +#. :ref:`Interacting with the motion detector ` #. :ref:`Managing the battery information ` These steps are described in the following sections. @@ -128,6 +129,7 @@ Use the following functions to register callbacks: * :c:func:`dult_id_read_state_cb_register` (mandatory) * :c:func:`dult_sound_cb_register` (mandatory) + * :c:func:`dult_motion_detector_cb_register` (mandatory if the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR` Kconfig option is enabled) Preset configuration ==================== @@ -213,6 +215,9 @@ There are following sound sources available: * Bluetooth GATT (:c:enum:`DULT_SOUND_SRC_BT_GATT`) - Sound source type originating from the Bluetooth ANOS. The non-owner device can trigger the sound callbacks by sending the relevant request message over the DULT GATT service. +* Motion detector (:c:enum:`DULT_SOUND_SRC_MOTION_DETECTOR`) - Sound source type originating from the motion detector. + The motion detector may trigger the sound callbacks if the accessory separated from the owner for an amount of time controlled by the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN` and :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX` Kconfig options is moving. + Used only when the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR` Kconfig option is enabled. * External (:c:enum:`DULT_SOUND_SRC_EXTERNAL`) - Sound source type originating from the location unknown to the DULT module. The accessory-locating network often provides a native mechanism for playing sounds. The :c:enum:`DULT_SOUND_SRC_EXTERNAL` sound source is used to notify the DULT module that externally defined sound action is in progress. @@ -221,12 +226,12 @@ To register the sound callbacks, use the :c:func:`dult_sound_cb_register` functi All sound callbacks defined in the :c:struct:`dult_sound_cb` structure are mandatory to register: * The sound start request is indicated by the :c:member:`dult_sound_cb.sound_start` callback. - The minimum duration for the DULT sound action is defined by the :c:macro:`DULT_SOUND_DURATION_MIN_MS`. - The upper layer determines the sound duration, and the duration must be greater than the value set in the :c:macro:`DULT_SOUND_DURATION_MIN_MS` macro. + The minimum duration for the DULT sound action originating from the Bluetooth ANOS is defined by the :c:macro:`DULT_SOUND_DURATION_BT_GATT_MIN_MS`. + The upper layer determines the sound duration, and for the sound action originating from the Bluetooth ANOS, the duration must exceed the value set in the :c:macro:`DULT_SOUND_DURATION_BT_GATT_MIN_MS` macro. + In case of the sound action originating from the motion detector, the minimum duration is not defined. * The sound stop request is indicated by the :c:member:`dult_sound_cb.sound_stop` callback. -All callbacks pass the sound source as a first parameter and only report the internal sound sources. -Currently, callbacks always use the :c:enum:`DULT_SOUND_SRC_BT_GATT` (internal) sound source. +All callbacks pass the sound source as a first parameter and only report the internal sound sources (:c:enum:`DULT_SOUND_SRC_BT_GATT` or :c:enum:`DULT_SOUND_SRC_MOTION_DETECTOR`). The :c:enum:`DULT_SOUND_SRC_EXTERNAL` never appears as the callback parameter as the external sound source cannot originate from the DULT module. You must treat all callbacks from the :c:struct:`dult_sound_cb` structure as requests. The internal sound state of the DULT subsystem is not automatically changed on any callback event. @@ -244,6 +249,41 @@ Asynchronous support is also necessary to report sound state changes that are tr .. rst-class:: numbered-step +.. _ug_dult_motion_detector: + +Interacting with the motion detector +************************************ + +DULT motion detector is an optional feature of the DULT subsystem. +For more details, see the `DULT motion detector`_ section of the DULT documentation. +To support the DULT motion detector feature in your project, enable the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR` Kconfig option. + +To integrate the motion detector feature, set the motion detector unwanted tracking accessory capability bit (:c:enum:`DULT_ACCESSORY_CAPABILITY_MOTION_DETECTOR_UT_BIT_POS`) in the accessory capabilities bitmask. +You must do this when registering the DULT user to indicate support for this feature. + +To register the motion detector callbacks, use the :c:func:`dult_motion_detector_cb_register` function. +You must register all motion detector callbacks defined in the :c:struct:`dult_motion_detector_cb` structure: + +* The motion detector start request is indicated by the :c:member:`dult_motion_detector_cb.start` callback. + After this callback is called, the motion detector events are polled periodically with the :c:member:`dult_motion_detector_cb.period_expired` callback. + A typical action after the motion detector start request is to power up the accelerometer and start collecting motion data. +* The motion detector period expired event is indicated by the :c:member:`dult_motion_detector_cb.period_expired` callback. + This callback is called at the end of each motion detector period. + The :c:member:`dult_motion_detector_cb.start` callback indicates the beginning of the first motion detector period. + The next period is started as soon as the previous period expires. + The user should notify the DULT module if motion was detected in the previous period. + The return value of this callback is used to pass this information. + The motion must be considered as detected if it fulfills the requirements defined in the `DULT motion detector`_ section of the DULT documentation. +* The motion detector stop request is indicated by the :c:member:`dult_motion_detector_cb.stop` callback. + It concludes the motion detector activity that was started by the :c:member:`dult_motion_detector_cb.start` callback. + A typical action after the motion detector stop request is to power down the accelerometer. + +The motion detector is started by the DULT subsystem when the accessory is in the separated state for an amount of time controlled by the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN` and :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX` Kconfig options. +When the motion is detected during the motion detector active period, the DULT subsystem calls the :c:member:`dult_sound_cb.sound_start` callback to request the sound action with the :c:enum:`DULT_SOUND_SRC_MOTION_DETECTOR` parameter as the sound source. +Emitted sounds help to alert the non-owner that they are carrying an accessory that does not belong to them and might be used by the original owner to track their location. + +.. rst-class:: numbered-step + .. _ug_dult_battery: Managing the battery information diff --git a/doc/nrf/external_comp/memfault.rst b/doc/nrf/external_comp/memfault.rst index 6730988603b8..868162d1f6ac 100644 --- a/doc/nrf/external_comp/memfault.rst +++ b/doc/nrf/external_comp/memfault.rst @@ -202,7 +202,7 @@ The following samples demonstrate the Memfault integration in |NCS|: * :ref:`peripheral_mds` - This sample has an implementation of the Memfault Diagnostic Service (MDS). It sends data to the Memfault cloud through a Bluetooth gateway. -* :ref:`memfault_sample` - This 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. +* :ref:`memfault_sample` - This sample connects to an LTE network using an nRF91 Series DK, Thingy:91, or Thingy:91 X, or to Wi-Fi® using the nRF7002 DK, and sends the collected data to Memfault's cloud using HTTPS. Library support *************** diff --git a/doc/nrf/external_comp/nrf_cloud.rst b/doc/nrf/external_comp/nrf_cloud.rst index 10563d273cdc..3eff5705196e 100644 --- a/doc/nrf/external_comp/nrf_cloud.rst +++ b/doc/nrf/external_comp/nrf_cloud.rst @@ -73,7 +73,7 @@ nRF Cloud supports a variety of device ID formats: Nordic development kits such as the nRF9160 DK have a sticker on the back indicating the device's IMEI and PIN. They are preprovisioned with just-in-time provisioning (JITP) certificates so they can be added easily to nRF Cloud using the device ID ``nrf-IMEI`` and PIN. -Device IDs that start with ``nrf-`` are checked against a database of genuine Nordic development kits and Thingy:91s. +Device IDs that start with ``nrf-`` are checked against a database of genuine Nordic development kits, Thingy:91, and Thingy:91 X. If the device ID (and the accompanying PIN or Hardware ID) is not found in the database, the device cannot connect. This means that customers using custom hardware cannot use the ``nrf-`` prefix for their device IDs. Choose your own PIN when creating creating JITP credentials for a custom device. diff --git a/doc/nrf/gsg_guides/nrf9160_gs.rst b/doc/nrf/gsg_guides/nrf9160_gs.rst index 7d56d1ac3a27..9b328854b479 100644 --- a/doc/nrf/gsg_guides/nrf9160_gs.rst +++ b/doc/nrf/gsg_guides/nrf9160_gs.rst @@ -7,7 +7,7 @@ Getting started with nRF9160 DK :local: :depth: 2 -This guide lets you evaluate the |NCS|'s support for nRF9160 DK :term:`Development Kit (DK)` without the need of installing the SDK. +This guide lets you evaluate the |NCS|'s support for nRF9160 :term:`Development Kit (DK)` without the need of installing the SDK. You will update the firmware (both the modem firmware and the application firmware) and the nRF Cloud certificates of the DK, and conduct some initial tests. If you want to go through a hands-on online training to familiarize yourself with cellular IoT technologies and development of cellular applications, enroll in the `Cellular IoT Fundamentals course`_ in the `Nordic Developer Academy`_. diff --git a/doc/nrf/includes/sample_board_rows.txt b/doc/nrf/includes/sample_board_rows.txt index 5b0c3bc1a28e..e189adb97c1d 100644 --- a/doc/nrf/includes/sample_board_rows.txt +++ b/doc/nrf/includes/sample_board_rows.txt @@ -237,3 +237,9 @@ .. nrf54l15dk_nrf54l15_cpuapp_ns | :ref:`nRF54L15 DK ` | PCA10156 | :ref:`nrf54l15dk ` | ``nrf54l15dk/nrf54l15/cpuapp/ns`` | + +.. nrf54l15dk_nrf54l15_cpuapp_and_cpuapp_ns + +| :ref:`nRF54L15 DK ` | PCA10156 | :ref:`nrf54l15dk ` | ``nrf54l15dk/nrf54l15/cpuapp`` | +| | | | | +| | | | ``nrf54l15dk/nrf54l15/cpuapp/ns`` | diff --git a/doc/nrf/includes/thingy91_prog_extdebugprobe.txt b/doc/nrf/includes/thingy91_prog_extdebugprobe.txt deleted file mode 100644 index 0d5f1fe9b89d..000000000000 --- a/doc/nrf/includes/thingy91_prog_extdebugprobe.txt +++ /dev/null @@ -1,9 +0,0 @@ -1. Set the Thingy:91 SWD selection switch (**SW2**) to **nRF91** or **nRF52** depending on whether you want to program the nRF9160 SiP or the nRF52840 SoC component. -#. Connect the Thingy:91 to the debug out port on a 10-pin external debug probe, for example, nRF9160 DK (Development Kit), using a 10-pin JTAG cable. - - .. note:: - - If you are using nRF9160 DK as the debug probe, make sure that **VDD_IO (SW11)** is set to 1.8 V on the nRF9160 DK. - -#. Connect the external debug probe to the PC using a USB cable. -#. Make sure that the Thingy:91 and the external debug probe are powered on. diff --git a/doc/nrf/includes/wifi_credentials_shell.txt b/doc/nrf/includes/wifi_credentials_shell.txt index 26f4b4e1c6a9..f4428895f040 100644 --- a/doc/nrf/includes/wifi_credentials_shell.txt +++ b/doc/nrf/includes/wifi_credentials_shell.txt @@ -9,9 +9,24 @@ Once you have flashed your device with this sample, connect to your device's UAR .. parsed-literal:: :class: highlight - wifi_cred add *NetworkSSID* *SecurityMode (OPEN, WPA2-PSK, WPA2-PSK-SHA256, WPA3-SAE)* *NetworkPassword* + wifi_cred add -s *NetworkSSID* -k *SecurityMode* -p *NetworkPassword* Where *NetworkSSID* is replaced with the SSID of the Wi-Fi access point you want your device to connect to, and *NetworkPassword* is its password. +*SecurityMode* is replaced by the number as listed here: + +* 0:None +* 1:WPA2-PSK +* 2:WPA2-PSK-256 +* 3:SAE-HNP +* 4:SAE-H2E +* 5:SAE-AUTO +* 6:WAPI +* 7:EAP-TLS +* 8:WEP +* 9:WPA-PSK +* 10:WPA-Auto-Personal +* 11:DPP + If you are not sure which security mode to use, enable the :kconfig:option:`CONFIG_NET_L2_WIFI_SHELL` Kconfig option and use the ``wifi scan`` command to display a list of all accessible networks along with their corresponding security modes. Then either reboot the device or use the ``wifi_cred auto_connect`` command to manually trigger a connection attempt. diff --git a/doc/nrf/index.rst b/doc/nrf/index.rst index b67c337c79d7..6431725f87d8 100644 --- a/doc/nrf/index.rst +++ b/doc/nrf/index.rst @@ -4,11 +4,6 @@ Introduction ############ -.. important:: - - |NCS| v2.8.0-preview1 is a development tag used for development purposes but is not recommended to use in a production environment. - This tag may be replaced by a release in the future. - The |NCS| is a modern, unified software development kit for building low-power wireless applications based on the Nordic Semiconductor nRF52, nRF53, nRF54, nRF70, and nRF91 Series wireless devices. It supports :ref:`Microsoft Windows, Linux, and macOS ` for development. diff --git a/doc/nrf/installation/install_ncs.rst b/doc/nrf/installation/install_ncs.rst index c5238fb4f1c6..147216de5c9a 100644 --- a/doc/nrf/installation/install_ncs.rst +++ b/doc/nrf/installation/install_ncs.rst @@ -102,10 +102,11 @@ Depending on your preferred development environment, complete the following step #. In the extension's :guilabel:`Welcome View`, click on :guilabel:`Manage toolchains`. The list of actions appears in the |VSC|'s quick pick. #. Click :guilabel:`Install Toolchain`. - The list of available toolchain versions appears in the |VSC|'s quick pick. + The list of available stable toolchain versions appears in the |VSC|'s quick pick. #. Select the toolchain version to install. The toolchain version should match the |NCS| version you are going to work with. If you have received a custom URL for installing the toolchain, you can provide it using the :guilabel:`Change Toolchain Index` button in the quick pick's header (wrench icon). + If you are working with a development tag, disable the filter in the quick pick's header to list all available toolchains. The toolchain installation starts in the background, as can be seen in the notification that appears. When you install the toolchain for the first time, the installed version is automatically selected for your project. @@ -207,7 +208,7 @@ For more information about the repository and development model, see the :ref:`d #. In the extension's :guilabel:`Welcome View`, click on :guilabel:`Manage SDKs`. The list of actions appears in the |VSC|'s quick pick. #. Click :guilabel:`Install SDK`. - The list of available SDK versions appears in the |VSC|'s quick pick. + The list of available stable SDK versions appears in the |VSC|'s quick pick. #. Select the SDK version to install. |install_latest_version| diff --git a/doc/nrf/libraries/bluetooth_services/services/fast_pair.rst b/doc/nrf/libraries/bluetooth_services/services/fast_pair.rst index 96c2d07ef898..a7c39d93d346 100644 --- a/doc/nrf/libraries/bluetooth_services/services/fast_pair.rst +++ b/doc/nrf/libraries/bluetooth_services/services/fast_pair.rst @@ -62,6 +62,7 @@ With the :kconfig:option:`CONFIG_BT_FAST_PAIR` Kconfig option enabled, the follo * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MODEL_NAME` - The option configures the model name parameter. * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_ACCESSORY_CATEGORY` - The option configures the accessory category parameter. * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_FIRMWARE_VERSION_MAJOR`, :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_FIRMWARE_VERSION_MINOR` and :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_FIRMWARE_VERSION_REVISION` - These options configure the firmware version parameter. + * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MOTION_DETECTOR` - The option enables the DULT motion detector functionality support in the FMDN extension (see :ref:`ug_bt_fast_pair_gatt_service_fmdn_dult_motion_detector`). * There are following advertising configuration options for the FMDN extension (see :ref:`ug_bt_fast_pair_advertising_fmdn`): @@ -90,6 +91,8 @@ With the :kconfig:option:`CONFIG_BT_FAST_PAIR` Kconfig option enabled, the follo * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_RING_VOLUME` - The option enables ringing volume support. * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_RING_REQ_TIMEOUT_DULT_BT_GATT` - The option configures the ringing timeout for connected peers that use DULT-based ringing mechanism. This option can only be used when the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT` is enabled. + * :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_RING_REQ_TIMEOUT_DULT_MOTION_DETECTOR` - The option configures the ringing timeout for ringing requests from the DULT motion detector. + This option can only be used when the :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT` is enabled. * There are following beacon clock service configuration options for the FMDN extension (see :ref:`ug_bt_fast_pair_prerequisite_ops_fmdn_clock_svc`): @@ -193,6 +196,10 @@ The FMDN extension implementation also acts as middleware between the user appli The DULT module integration is required for small and not easily discoverable accessories. The :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT` is enabled by default. +The :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_DULT_MOTION_DETECTOR` of the FMDN extension selects the :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR` Kconfig option to enable the motion detector feature of the DULT module. +With this option enabled, the FMDN extension passes the DULT motion detector callbacks from the DULT module to application. +To learn more about the DULT motion detector, see :ref:`ug_dult_motion_detector`. + The :kconfig:option:`CONFIG_BT_FAST_PAIR_FMDN_BATTERY_DULT` of the FMDN extension selects the :kconfig:option:`CONFIG_DULT_BATTERY` Kconfig option to enable the battery support in the DULT module. With this option enabled, the FMDN extension passes the battery information also to the DULT module. diff --git a/doc/nrf/libraries/modem/modem_antenna.rst b/doc/nrf/libraries/modem/modem_antenna.rst index 09e27694e1fa..e582aa96b8ca 100644 --- a/doc/nrf/libraries/modem/modem_antenna.rst +++ b/doc/nrf/libraries/modem/modem_antenna.rst @@ -7,7 +7,7 @@ Modem antenna :local: :depth: 2 -You can use this library to set the antenna configuration on an nRF91 Series DK or a Thingy:91. +You can use this library to set the antenna configuration on an nRF91 Series DK, a Thingy:91, or a Thingy:91 X. Overview ******** diff --git a/doc/nrf/libraries/networking/nrf_cloud.rst b/doc/nrf/libraries/networking/nrf_cloud.rst index a308c68daee3..f58228f4d79d 100644 --- a/doc/nrf/libraries/networking/nrf_cloud.rst +++ b/doc/nrf/libraries/networking/nrf_cloud.rst @@ -127,7 +127,7 @@ Configuration options for device ID * :kconfig:option:`CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI` - If you enable this option, the ID is automatically generated using a prefix and the modem's IMEI (````). This is the default. You can configure the prefix by using :kconfig:option:`CONFIG_NRF_CLOUD_CLIENT_ID_PREFIX`. - The default format of the prefix is ``nrf-`` and it is valid only for Nordic devices such as Thingy:91 or an nRF91 Series DK. + The default format of the prefix is ``nrf-`` and it is valid only for Nordic devices such as Thingy:91, Thingy:91 X, or an nRF91 Series DK. For custom hardware, use a prefix other than ``nrf-`` by modifying :kconfig:option:`CONFIG_NRF_CLOUD_CLIENT_ID_PREFIX`. * :kconfig:option:`CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID` - If you enable this option, the ID is automatically generated using the modem's 128-bit internal UUID, which results in a 36 character string of hexadecimal values in the 8-4-4-4-12 UUID format. diff --git a/doc/nrf/libraries/nfc/rpc/index.rst b/doc/nrf/libraries/nfc/rpc/index.rst new file mode 100644 index 000000000000..4c9bbef12ac0 --- /dev/null +++ b/doc/nrf/libraries/nfc/rpc/index.rst @@ -0,0 +1,95 @@ +.. _nfc_rpc: + +NFC Remote Procedure Call +######################### + +.. contents:: + :local: + :depth: 2 + +The :ref:`NFC ` Remote Procedure Call (RPC) solution is a set of libraries that allows using the NFC stack running entirely on a separate device or CPU. + +Overview +******** + +The solution allows calling the NFC API (both :ref:`Type 2 Tag ` and :ref:`Type 4 Tag `) on a different CPU or device. +This is accomplished by running the full NFC functionality on one device and serializing the API from another device. +Use this solution when you do not want your firmware to include the NFC stack, for example to offload the application CPU, save memory, or to be able to build your application in a different environment. + +Implementation +============== + +The NFC RPC solution consists of the following components: + + * NFC RPC Client and common software libraries. + These libraries serialize the NFC API and enable RPC communication, and need to be part of the user application. + * NFC RPC Server, common libraries, and the Type 4 Tag library, Type 2 Tag library, or both. + These libraries enable communication with NFC RPC Client, and need to run on a device or CPU that has an NFC radio hardware peripheral. + +You can add support for serializing NFC-related custom APIs by implementing your own client and server procedures. +You can use the following files as examples: + + * :file:`subsys/nfc/rpc/client/nfc_rpc_t2t_client.c` + * :file:`subsys/nfc/rpc/server/nfc_rpc_t2t_server.c` + +Requirements +************ + +These configuration options must be enabled to use the library: + + * :kconfig:option:`CONFIG_NFC_RPC` + * :kconfig:option:`CONFIG_NFC_RPC_CLIENT` - for the NFC RPC client + * :kconfig:option:`CONFIG_NFC_RPC_SERVER` - for the NFC RPC server + +These configuration options related to NFC Data Exchange Format must be enabled on the client for the Type 4 Tag: + + * :kconfig:option:`CONFIG_NFC_NDEF` + * :kconfig:option:`CONFIG_NFC_NDEF_MSG` + * :kconfig:option:`CONFIG_NFC_NDEF_RECORD` + * :kconfig:option:`CONFIG_NFC_NDEF_TEXT_RECORD` + +These configuration options related to NFC must be enabled on the server: + + * :kconfig:option:`CONFIG_NFC_T2T_NRFXLIB` - for Type 2 Tag + * :kconfig:option:`CONFIG_NFC_T4T_NRFXLIB` - for Type 4 Tag + +Samples using the library +************************* + +The following |NCS| samples use this library: + +* :ref:`nrf_rpc_protocols_serialization_client` +* :ref:`nrf_rpc_protocols_serialization_server` + +Limitations +*********** + +The library currently supports serialization of the following: + + * :ref:`nrfxlib:type_2_tag` + * :ref:`nrfxlib:type_4_tag` + +The behavior of NFC with RPC is almost the same as without it, with the following exceptions: + + * Some NFC API functions get data by pointer, for example :c:func:`nfc_t4t_ndef_rwpayload_set`. + After calling the functions on the client, the data is sent to the server. + Any manipulation of data over the pointer will not affect the server's data instance. + * Even though the maximum payload for Type 4 Tag can be 65520 bytes, the real length is limited by :c:macro:`NDEF_FILE_SIZE`. + +Dependencies +************ + +The library has the following dependencies: + + * :ref:`nrf_rpc` + * :ref:`nfc` + +.. _nfc_rpc_api: + +API documentation +***************** + +This library does not define a new NFC API. + +| Header files: :file:`nrfxlib/nfc/include/nfc_t2t_lib.h`, :file:`nrfxlib/nfc/include/nfc_t4t_lib.h` +| Source files: :file:`subsys/nfc/rpc/` diff --git a/doc/nrf/libraries/others/dult.rst b/doc/nrf/libraries/others/dult.rst index 5a403fed03e9..a754129532a2 100644 --- a/doc/nrf/libraries/others/dult.rst +++ b/doc/nrf/libraries/others/dult.rst @@ -44,6 +44,25 @@ The following Kconfig options are also available for this module: * :kconfig:option:`CONFIG_DULT_BT_ANOS_INDICATION_COUNT` - This option allows to configure the number of simultaneously processed GATT indications by the ANOS. The default value is set to ``2``. +* :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR` - This option enables support for motion detector. + The motion detector is an optional feature in the DULT specification. + For more details see the `DULT motion detector`_ section of the DULT specification. + This option is disabled by default. + + * :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_TEST_MODE` - This option allows to configure motion detector parameters for testing purposes. + These values are defined in the DULT specification and should not be changed in the production code. + This option is disabled by default. + + * :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_BACKOFF_PERIOD` - This option allows to configure the period in minutes to disable the motion detector if the accessory is in the separated state. + If this option is configurable, its default value is set to ``2``. + Otherwise, its default value is set to ``360`` according to the DULT specification. + * :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MIN` - This option allows to configure the minimum time span in minutes in separated state before enabling motion detector. + If this option is configurable, its default value is set to ``3``. + Otherwise, its default value is set to ``480`` according to the DULT specification. + * :kconfig:option:`CONFIG_DULT_MOTION_DETECTOR_SEPARATED_UT_TIMEOUT_PERIOD_MAX` - This option allows to configure the maximum time span in minutes in separated state before enabling motion detector. + If this option is configurable, its default value is set to ``3``. + Otherwise, its default value is set to ``1440`` according to the DULT specification. + See the Kconfig help for details. Implementation details diff --git a/doc/nrf/libraries/security/nrf_security/doc/backend_config.rst b/doc/nrf/libraries/security/nrf_security/doc/backend_config.rst index 29bb8c413e83..7174b8060b6d 100644 --- a/doc/nrf/libraries/security/nrf_security/doc/backend_config.rst +++ b/doc/nrf/libraries/security/nrf_security/doc/backend_config.rst @@ -10,6 +10,10 @@ Legacy configurations and supported features This section covers the configurations available when using :ref:`legacy_crypto_support`. +.. caution:: + Legacy crypto toolbox APIs are marked as deprecated in the |NCS| version 2.8.0, and will be removed in a future version. + It is not recommended to use the legacy crypto toolbox APIs and the related configurations in any new designs. + .. _nrf_security_backend_config_multiple: Configuring backends diff --git a/doc/nrf/libraries/security/nrf_security/doc/configuration.rst b/doc/nrf/libraries/security/nrf_security/doc/configuration.rst index 100653336975..d77bb81b3924 100644 --- a/doc/nrf/libraries/security/nrf_security/doc/configuration.rst +++ b/doc/nrf/libraries/security/nrf_security/doc/configuration.rst @@ -19,25 +19,27 @@ PSA crypto support is included by default when you enable nRF Security through t PSA crypto support is provided through PSA Crypto APIs and is implemented by PSA core. PSA core uses PSA drivers to implement the cryptographic features either in software, or using hardware accelerators. -.. caution:: - The PSA Crypto APIs are only thread safe when provided by TF-M. - .. _legacy_crypto_support: Legacy crypto support ********************* -To enable the legacy crypto support mode of nRF Security, set both the :kconfig:option:`CONFIG_NORDIC_SECURITY_BACKEND` and :kconfig:option:`CONFIG_NRF_SECURITY` Kconfig options along with additional configuration options, as described in :ref:`nrf_security_legacy_config`. +To enable the legacy crypto support mode of nRF Security, set the :kconfig:option:`CONFIG_NORDIC_SECURITY_BACKEND` Kconfig option along with additional configuration options, as described in :ref:`nrf_security_legacy_config`. The legacy crypto support allows backwards compatibility for software that requires usage of Mbed TLS crypto toolbox functions prefixed with ``mbedtls_``. +.. caution:: + Mbed TLS legacy crypto toolbox APIs are marked as deprecated in the |NCS| version 2.8.0, and will be removed in a future version. + It is not recommended to use crypto toolbox functions prefixed with ``mbedtls_`` for any new designs. + Use the equivalent functionality from PSA crypto APIs instead. + + Setting the Kconfig option :kconfig:option:`CONFIG_NORDIC_SECURITY_BACKEND` will also enable the Kconfig option :kconfig:option:`MBEDTLS_LEGACY_CRYPTO_C`, which will show a deprecation warning in the build output. + Use the Kconfig option :kconfig:option:`CONFIG_NRF_SECURITY` instead. + Custom Mbed TLS configuration files *********************************** The nRF Security Kconfig options are used to generate an Mbed TLS configuration file. -Although not recommended, it is possible to provide a custom Mbed TLS configuration file by disabling :kconfig:option:`CONFIG_GENERATE_MBEDTLS_CFG_FILE`. -See :ref:`nrf_security_tls_header`. - Building with TF-M ****************** diff --git a/doc/nrf/libraries/security/nrf_security/doc/driver_config.rst b/doc/nrf/libraries/security/nrf_security/doc/driver_config.rst index 75945472b699..9dd473a864d5 100644 --- a/doc/nrf/libraries/security/nrf_security/doc/driver_config.rst +++ b/doc/nrf/libraries/security/nrf_security/doc/driver_config.rst @@ -23,10 +23,10 @@ To enable a PSA driver, set the configurations in the following table: +===============+==================================================+=====================================================+ | nrf_cc3xx | :kconfig:option:`CONFIG_PSA_CRYPTO_DRIVER_CC3XX` | Only on nRF52840, nRF91 Series, and nRF5340 devices | +---------------+--------------------------------------------------+-----------------------------------------------------+ -| nrf_oberon | :kconfig:option:`CONFIG_PSA_CRYPTO_DRIVER_OBERON`| | -+---------------+--------------------------------------------------+-----------------------------------------------------+ | nrf_cracen | :kconfig:option:`CONFIG_PSA_CRYPTO_DRIVER_CRACEN`| Only on nRF54L Series devices | +---------------+--------------------------------------------------+-----------------------------------------------------+ +| nrf_oberon | :kconfig:option:`CONFIG_PSA_CRYPTO_DRIVER_OBERON`| | ++---------------+--------------------------------------------------+-----------------------------------------------------+ If multiple drivers are enabled, the first ordered item in this table takes precedence for an enabled cryptographic feature, unless the driver does not enable or support it. @@ -106,7 +106,9 @@ The following table shows key type support for each driver: | DH Public Key | Not supported | Not supported | Not supported | +-----------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported key types. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported key types. + +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported key types. Cipher configurations ********************* @@ -154,10 +156,12 @@ The following table shows cipher algorithm support for each driver: | Stream cipher | Supported | Supported | Supported | +-----------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_CIPHER_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_CIPHER_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. The configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `Cipher configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_CIPHER_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + Key size configuration is supported as described in `AES key size configuration`_, for all algorithms except the stream cipher. .. note:: @@ -189,7 +193,9 @@ The following table shows Key agreement support for each driver: | FFDH | Not supported | Not supported | Not supported | +-------------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_AGREEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_AGREEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. + +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_KEY_AGREEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. The algorithm support when using ECC key types is dependent on one or more Kconfig options enabling curve support according to `ECC curve configurations`_. @@ -253,6 +259,8 @@ The following table shows key derivation function (KDF) support for each driver: The configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `Key derivation function configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_KEY_DERIVATION_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + MAC configurations ****************** @@ -283,10 +291,12 @@ The following table shows MAC algorithm support for each driver: | CBC-MAC | Not supported | Not supported | Not Supported | +----------------+--------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_MAC_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_MAC_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. The configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `MAC configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_MAC_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + Key size configuration for CMAC is supported as described in `AES key size configuration`_. .. note:: @@ -323,10 +333,12 @@ The following table shows AEAD algorithm support for each driver: | ChaCha20-Poly1305 | Supported | Supported | Supported | +-----------------------+---------------------------+---------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_AEAD_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_AEAD_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. Configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `AEAD configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_AEAD_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + Key size configuration for CCM and GCM is supported as described in `AES key size configuration`_. .. note:: @@ -392,10 +404,12 @@ The following table shows asymmetric signature algorithm support for each driver | RSA PSS any salt | Not supported | Supported | Not Supported | +---------------------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_ASYMMETRIC_SIGNATURE_DRIVER` enables the driver :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_ASYMMETRIC_SIGNATURE_DRIVER` enables the driver :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. Configuration of the :ref:`nrf_security_drivers_oberon` driver is automatically generated based on the user-enabled algorithms in `Asymmetric signature configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_ASYMMETRIC_SIGNATURE_DRIVER` enables the driver :ref:`nrf_security_drivers_cracen` for all supported algorithms. + The algorithm support when using ECC key types is dependent on one or more Kconfig options enabling curve support according to `ECC curve configurations`_. RSA key size configuration is supported as described in `RSA key size configuration`_. @@ -432,10 +446,12 @@ The following table shows asymmetric encryption algorithm support for each drive | RSA PKCS#1 v1.5 crypt | Supported | Supported | Supported | +---------------------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_ASYMMETRIC_ENCRYPTION_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_ASYMMETRIC_ENCRYPTION_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. Configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `Asymmetric encryption configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_ASYMMETRIC_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + RSA key size configuration is supported as described in `RSA key size configuration`_. .. note:: @@ -592,7 +608,9 @@ The following table shows ECC curve support for each driver: | FRP256v1 | Not supported | Not supported | Not supported | +--------------------------+---------------------------+----------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for key management using ECC curves. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for key management using ECC curves. + +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_KEY_MANAGEMENT_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for key management using ECC curves. RNG configurations ****************** @@ -618,15 +636,16 @@ When RNG is enabled, set at least one of the configurations in the following tab RNG support =========== -There are no public configurations for entropy and PRNG algorithm support and the choice of drivers that provide support is automatic. - -The PSA drivers using the Arm CryptoCell peripheral is enabled by default for nRF52840, nRF91 Series, and nRF5340 devices. - -For devices without a hardware-accelerated cryptographic engine, entropy is provided by the nRF RNG peripheral. PRNG support is provided by the Oberon PSA driver, which is implemented using software. +The PSA drivers using the Arm CryptoCell peripheral are enabled by default for nRF52840, nRF91 Series, and nRF5340 devices. .. note:: When using CryptoCell, only 1024 bytes can be requested at a time. +For devices without a hardware-accelerated cryptographic engine, entropy is provided by the nRF RNG peripheral. +PRNG support is provided by the Oberon PSA driver, which is implemented using software. + +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_CTR_DRBG_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for the CTR-DRBG algorithm. + Hash configurations ******************* @@ -717,10 +736,12 @@ The following table shows hash algorithm support for each driver: | RIPEMD160 | Not supported | Not supported | Not supported | +-----------------------+----------------------------+---------------------------+---------------------------+ -The option :kconfig:option:`CONFIG_PSA_USE_CC3XX_HASH_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CC3XX_HASH_DRIVER` enables the :ref:`nrf_security_drivers_cc3xx` for all supported algorithms. The configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `Hash configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_HASH_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + Password-authenticated key exchange configurations ************************************************** @@ -762,6 +783,8 @@ The following table shows PAKE algorithm support for each driver: Configuration of the :ref:`nrf_security_drivers_oberon` is automatically generated based on the user-enabled algorithms in `Password-authenticated key exchange configurations`_. +The Kconfig option :kconfig:option:`CONFIG_PSA_USE_CRACEN_PAKE_DRIVER` enables the :ref:`nrf_security_drivers_cracen` for all supported algorithms. + Key size configurations *********************** diff --git a/doc/nrf/links.txt b/doc/nrf/links.txt index 6e41d658bd5a..587557bc59ac 100644 --- a/doc/nrf/links.txt +++ b/doc/nrf/links.txt @@ -23,6 +23,8 @@ .. _`Zephyr net capture`: https://docs.zephyrproject.org/latest/samples/net/capture/README.html .. _`Zephyr net capture Linux setup`: https://docs.zephyrproject.org/latest/connectivity/networking/usbnet_setup.html#usb-device-networking-setup .. _`Zephyr net DHCPv4 server`: https://docs.zephyrproject.org/apidoc/latest/group__dhcpv4__server.html +.. _`Zephyr Wi-Fi NM API`: https://docs.zephyrproject.org/apidoc/latest/wifi__nm_8h.html +.. _`Zephyr Wi-Fi management`: https://docs.zephyrproject.org/latest/connectivity/networking/api/wifi.html .. ### Source: github.com @@ -45,6 +47,9 @@ .. _`Zephyr pull request #50305`: https://github.com/zephyrproject-rtos/zephyr/pull/50305 .. _`Zephyr issue #69546`: https://github.com/zephyrproject-rtos/zephyr/issues/69546 +.. _`print_toolchain_checksum.sh`: https://github.com/nrfconnect/sdk-nrf/blob/main/scripts/print_toolchain_checksum.sh +.. _`JLink License Agreement`: https://github.com/nrfconnect/sdk-nrf/blob/main/scripts/docker/jlink/license.txt + .. _`sdk-mcuboot`: https://github.com/nrfconnect/sdk-mcuboot .. _`MCUboot design`: https://github.com/mcu-tools/mcuboot/blob/main/docs/design.md .. _`MCUboot repository`: https://github.com/mcu-tools/mcuboot @@ -202,6 +207,8 @@ .. _`Memfault WebBluetooth Client source code`: https://github.com/memfault/web-ble-example/blob/main/mds.js .. _`Memfault-SDK`: https://github.com/memfault/memfault-firmware-sdk +.. _`Zephyr hostap fork`: https://github.com/zephyrproject-rtos/hostap + .. ### Source: github.io .. _`TinyCBOR`: https://intel.github.io/tinycbor/current/ @@ -631,8 +638,8 @@ .. _`nRF pynrfjprog`: https://docs.nordicsemi.com/bundle/ug_pynrfjprog/page/UG/pynrfjprog/pynrfjprog_lpage.html -.. _`Amazon Sidewalk documentation`: https://docs.nordicsemi.com/bundle/sidewalk_2.6.0/page/index.html -.. _`Setting up the SDK for Amazon Sidewalk`: https://docs.nordicsemi.com/bundle/sidewalk_2.6.0/page/setting_up_sidewalk_environment/setting_up_sdk.html +.. _`Amazon Sidewalk documentation`: https://docs.nordicsemi.com/bundle/sidewalk_latest/page/index.html +.. _`Setting up the SDK for Amazon Sidewalk`: https://docs.nordicsemi.com/bundle/sidewalk_latest/page/setting_up_sidewalk_environment/setting_up_sdk.html .. _`nRF9160 Product Specification`: https://docs.nordicsemi.com/bundle/ps_nrf9160/page/nRF9160_html5_keyfeatures.html .. _`nRF9160 GPS receiver specification`: https://docs.nordicsemi.com/bundle/ps_nrf9160/page/gps.html @@ -696,6 +703,8 @@ .. _`nRF91x1 Power saving mode setting`: https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/nw_service/cpsms.html .. _`nRF91x1 modem trace activation %XMODEMTRACE`: https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/mob_termination_ctrl_status/xmodemtrace.html +.. _`nRF54L15 Datasheet`: https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/keyfeatures_html5.html + .. _`nRF53 Series`: https://docs.nordicsemi.com/category/nrf-53-series .. _`nRF5340 Product Specification`: https://docs.nordicsemi.com/bundle/ps_nrf5340/page/keyfeatures_html5.html @@ -804,6 +813,8 @@ .. _`nAN34`: https://docs.nordicsemi.com/bundle/Application-Notes/resource/nan_34.pdf .. _`nRF Util`: https://docs.nordicsemi.com/bundle/nrfutil/page/README.html +.. _`Installing nRF Util`: https://docs.nordicsemi.com/bundle/nrfutil/page/guides/installing.html +.. _`Installing and upgrading nRF Util commands`: https://docs.nordicsemi.com/bundle/nrfutil/page/guides/installing_commands.html .. _`Installing nRF Util for nRF5 SDK`: https://docs.nordicsemi.com/bundle/nrfutil/page/guides-nrf5sdk/installing.html .. _`DFU over Zigbee`: https://docs.nordicsemi.com/bundle/nrfutil/page/guides-nrf5sdk/dfu_performing.html#dfu-over-zigbee .. _`Generating DFU packages`: https://docs.nordicsemi.com/bundle/nrfutil/page/guides-nrf5sdk/dfu_generating_packages.html @@ -813,6 +824,7 @@ .. _`nrfutil-trace`: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-trace/CHANGELOG.html .. _`nRF Sniffer for Bluetooth LE`: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/overview.html .. _`Device command overview`: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-device/guides/programming.html +.. _`Programming application firmware on the nRF54L15 SoC`: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-device/guides/programming_nrf54L15.html .. _`anomaly 19`: https://docs.nordicsemi.com/bundle/errata_nRF5340_EngA/page/ERR/nRF5340/EngineeringA/latest/anomaly_340_19.html @@ -862,6 +874,7 @@ .. _`Debugging overview`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/debug_concepts.html .. _`How to debug`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/debug_use.html .. _`How to debug applications for a multi-core System on Chip`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/debug_use.html#how-to-debug-applications-for-a-multi-core-system-on-chip +.. _`How to work with the Memory Explorer`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/debug_mem_explorer.html .. _`source control with west`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/west_about.html .. _`west module management`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/west_module_management.html .. _`Custom launch and debug configurations`: https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/guides/debug_custom.html @@ -912,6 +925,8 @@ .. _`Testing the nRF Connect platform with Apple, Google and Samsung ecosystems`: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/matter-testing-nrf-connect-sdk-platform-with-apple-google-and-samsung-ecosystems-218911247#mcetoc_1gkq24ojdf +.. _`Online Power Profiler for Wi-Fi`: https://devzone.nordicsemi.com/power/w/opp/14/online-power-profiler-for-wi-fi + .. ### Source: App stores (play.google.com & apps.apple.com) .. _`Fast Pair Validator app`: https://play.google.com/store/apps/details?id=com.google.location.nearby.apps.fastpair.validator @@ -1119,6 +1134,7 @@ .. _`DULT Manufacturer Network ID Registry`: https://www.ietf.org/archive/id/draft-detecting-unwanted-location-trackers-01.html#name-manufacturer-network-id-reg .. _`DULT Accessory Category Values table`: https://www.ietf.org/archive/id/draft-detecting-unwanted-location-trackers-01.html#_table-accessory-category-values .. _`DULT Sound maker`: https://www.ietf.org/archive/id/draft-detecting-unwanted-location-trackers-01.html#name-sound-maker +.. _`DULT motion detector`: https://www.ietf.org/archive/id/draft-detecting-unwanted-location-trackers-01.html#name-motion-detector .. ### Source: *.amazon.com @@ -1698,6 +1714,8 @@ .. _`nRF54H20 SoC Binaries v0.5.0`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.5.0.zip .. _`nRF54H20 SoC Binaries v0.6.2`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.6.2.zip .. _`nRF54H20 SoC binaries v0.6.5`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.6.5.zip +.. _`nRF54H20 SoC Binaries v0.7.0 for EngC DKs`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.7.0_engc.zip +.. _`nRF54H20 SoC Binaries v0.7.0 for EngB DKs`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.7.0_engb.zip .. _`BICR binary file`: https://files.nordicsemi.com/artifactory/SDSC/external/bicr_ext_loadcap.hex .. _`BICR new binary file`: https://files.nordicsemi.com/artifactory/SDSC/external/bicr/bicr.hex diff --git a/doc/nrf/protocols/lte/index.rst b/doc/nrf/protocols/lte/index.rst index c115ddf1fa85..82b29e5d2d73 100644 --- a/doc/nrf/protocols/lte/index.rst +++ b/doc/nrf/protocols/lte/index.rst @@ -38,7 +38,7 @@ It is designed for indoor coverage, low cost, and long battery life. NB-IoT operates in a small radio frequency band of 200 kHz. It is ideal for applications like smart metering, environmental monitoring, and smart lighting. -nRF91 Series devices such as nRF9151 DK, nRF9161 DK, nRF9160 DK, and Thingy:91 support both LTE-M and NB-IoT technologies. +nRF91 Series devices such as nRF9151 DK, nRF9161 DK, nRF9160 DK, Thingy:91, and Thingy:91 X support both LTE-M and NB-IoT technologies. Comparison between LTE-M and NB-IoT =================================== diff --git a/doc/nrf/protocols/matter/end_product/certification.rst b/doc/nrf/protocols/matter/end_product/certification.rst index 3c4e71e4ec45..b48176762220 100644 --- a/doc/nrf/protocols/matter/end_product/certification.rst +++ b/doc/nrf/protocols/matter/end_product/certification.rst @@ -357,7 +357,7 @@ Especially, make sure that: * ``ClusterRevision`` attributes for all clusters match the value of the Matter stack version that you want to use for your application certification. * ``Attribute List``, ``Accepted Command List`` and ``Generated Command List`` attributes for all clusters contain all the values that need to be there and nothing more. * Only the clusters, attributes and commands required by your application are enabled. - For example, the default configurations for the samples use both Thread Network Diagnostics and Wi-Fi Network Diagnostics clusters. + For example, the default configurations for the samples use both Thread Network Diagnostics and Wi-Fi Network Diagnostics clusters, and the Network Commissioning cluster has attributes for both Thread and Wi-Fi protocols enabled. This is done due to the Thread and Wi-Fi platforms common maintenance reasons, but should not be used in the final product. See the :ref:`ug_matter_creating_accessory` page for how to configure your application using the ZAP Tool. diff --git a/doc/nrf/protocols/matter/end_product/security.rst b/doc/nrf/protocols/matter/end_product/security.rst index 34928715f926..a51128bd9bde 100644 --- a/doc/nrf/protocols/matter/end_product/security.rst +++ b/doc/nrf/protocols/matter/end_product/security.rst @@ -7,14 +7,39 @@ Security :local: :depth: 3 -Nordic Matter samples leverage security features supported in the |NCS| that can be divided into three major categories: +Nordic Matter samples leverage :ref:`security` features supported in the |NCS| that can be divided into four major categories: +* Secure processing environment * Cryptography * Trusted storage * Securing production devices In the following sections you will learn more details about each listed category. +Secure processing environment +***************************** + +Depending on the board, Matter samples can use a secure processing environment. + +nRF54L with Trusted Firmware-M (TF-M) +===================================== + +On the nRF54L SoC, Matter samples support :ref:`app_boards_spe_nspe` with Trusted Firmware-M (TF-M). +All cryptographic operations within the Matter stack are performed by utilizing the `Platform Security Architecture (PSA)`_ API and executed in the secure TF-M environment. +The secure materials like Matter Session keys and other keys, except for the DAC private key, are stored in the TF-M secure storage using the :ref:`tfm_encrypted_its` module. +Matter samples use the full TF-M library, so you cannot use the :ref:`tfm_minimal_build` version of TF-M. + +To build a Matter sample with the TF-M support, :ref:`build ` for the :ref:`board target ` with the ``/ns`` variant. + +To configure partition layout for your application, you can edit the :file:`pm_static_nrf54l15dk_nrf54l15_cpuapp_ns.yml` file that is available in each sample directory. +To read more about the TF-M partitioning, see :ref:`ug_tfm_partition_alignment_requirements`. +While using TF-M, the application partition size and available RAM space for the application is lower than without TF-M. +You must keep this in mind and calculate the available space for the application partition. +The recommended values are provided in the :ref:`ug_matter_hw_requirements_layouts` section. + +By default, the DAC private key is stored in the KMU storage while using TF-M. +See the :ref:`matter_platforms_security_dac_priv_key_kmu` section for more information. + Cryptography ************ @@ -117,7 +142,7 @@ This is a reference configuration that can be modified in the production firmwar - PSA Crypto API - CRACEN - Yes - - Trusted Firmware-M (TF-M) + - Trusted Firmware-M (TF-M) + Key Management Unit (KMU) .. [1] The CryptoCell backend is used in parallel with the Oberon backend. By default, the CryptoCell backend is used only for Random Number Generation (RNG) and the AEAD key derivation driver. @@ -137,7 +162,7 @@ Storing Device Attestation Certificate private key In Matter samples based on the PSA crypto API, the Device Attestation Certificate's private key, which exists in the factory data set, can be migrated to secure storage. The secure storage used depends on the platform and the cryptographic backend. -To enable the migration of the DAC private key from the factory data set to secure storage, set the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY` Kconfig option to ``y``. +The migration of the DAC private key from the factory data set to secure storage is controlled by the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_MIGRATE_DAC_PRIV_KEY` Kconfig option and set to ``y`` by default. Currently, this feature is available only for the PSA crypto API. See the following table to learn about the default secure storage backends for the DAC private key and the available secure storage backends for each platform: @@ -150,24 +175,30 @@ See the following table to learn about the default secure storage backends for t - Default secure storage backend for DAC private key - Available secure storage backends * - nRF52840 SoC - - Trusted Storage library + SHA-256 hash - - Trusted Storage library + SHA-256 hash + - Trusted Storage library + SHA-256 hash (Zephyr Settings) + - Trusted Storage library + SHA-256 hash (Zephyr Settings) * - nRF5340 SoC - - Trusted Storage library + Hardware Unique Key (HUK) - - | Trusted Storage library + Hardware Unique Key (HUK), - | Trusted Storage library + SHA-256 hash + - Trusted Storage library + Hardware Unique Key (Zephyr Settings) + - | Trusted Storage library + Hardware Unique Key (Zephyr Settings), + | Trusted Storage library + SHA-256 hash (Zephyr Settings) * - nRF5340 SoC + nRF7002 companion IC - Not available - Not available * - nRF54L15 SoC - - Trusted Storage library + Hardware Unique Key (HUK) + - Key Management Unit (KMU) - | Key Management Unit (KMU), - | Trusted Storage library + Hardware Unique Key (HUK), - | Trusted Storage library + SHA-256 hash + | Trusted Storage library + Hardware Unique Key (Zephyr Settings), + | Trusted Storage library + SHA-256 hash (Zephyr Settings) * - nRF54L15 SoC + Trusted Firmware-M (TF-M) - - Trusted Firmware-M (TF-M) Storage + - Key Management Unit (KMU) - | Key Management Unit (KMU), - | Trusted Firmware-M (TF-M) Storage + | Trusted Firmware-M Storage (TF-M) + +If you migrate the DAC private key to storage based on Zephyr Settings storage, you cannot use the :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option. +This is because the factory reset feature will erase the secure storage, including the DAC private key, which has been removed from the factory data. +In this case, the DAC private key will be lost, and the device will not be able to authenticate to the network. + +You can use the :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option if you store the DAC private key in the KMU or TF-M secure storage (available on nRF54L SoCs only). .. _matter_platforms_security_dac_priv_key_its: @@ -176,7 +207,7 @@ DAC in Trusted Storage library The Device Attestation Certificates private key can be stored in the Trusted Storage library. The key is encrypted with the AEAD key derived from the Hardware Unique Key (HUK) or a SHA-256 hash. -This storage backend is selected by default for all platforms that support the PSA crypto API. +This storage backend is selected by default for all platforms that support the PSA crypto API, except for the nRF54L Series, which uses Key Management Unit (KMU). To enable storing the DAC private key in the Trusted Storage library, set the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_ITS` Kconfig option to ``y``. To select which encryption to use, set one of the following Kconfig options: @@ -195,7 +226,7 @@ The Key Management Unit (KMU) is a hardware peripheral that provides secure stor It is available in the nRF54L Series SoCs and can be used to store the DAC private key. This storage backend can be used with Trusted Firmware-M (TF-M). -You can enable storing the DAC private key in the KMU by setting the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU` Kconfig option to ``y``. +Storing the DAC private key in the KMU is controlled by the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU` Kconfig option and set to ``y`` by default. You can additionally encrypt the DAC private key in the KMU storage by setting the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_ENCRYPTED` Kconfig option to ``y``. This operation requires two additional KMU slots to store the nonce and the authentication tag, making the total number of slots used four. diff --git a/doc/nrf/protocols/matter/getting_started/hw_requirements.rst b/doc/nrf/protocols/matter/getting_started/hw_requirements.rst index fe51a9ad404e..94b515348f82 100644 --- a/doc/nrf/protocols/matter/getting_started/hw_requirements.rst +++ b/doc/nrf/protocols/matter/getting_started/hw_requirements.rst @@ -60,41 +60,47 @@ Values are provided in kilobytes (KB). +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ | Sample | MCUboot ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | +======================================================================+===============+===================+================+============+=============+=================================+ - | :ref:`Light Bulb ` (Debug) | 28 | 794 | 4 | 32 | 858 | 185 | + | :ref:`Light Bulb ` (Debug) | 28 | 793 | 4 | 32 | 857 | 184 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Debug + LTO) | 28 | 732 | 4 | 32 | 796 | 189 | + | :ref:`Light Bulb ` (Debug + LTO) | 28 | 730 | 4 | 32 | 794 | 188 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Release) | 28 | 691 | 4 | 32 | 755 | 179 | + | :ref:`Light Bulb ` (Release) | 28 | 693 | 4 | 32 | 757 | 178 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug) | 28 | 757 | 4 | 32 | 821 | 176 | + | :ref:`Light Switch ` (Debug) | 28 | 758 | 4 | 32 | 822 | 175 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug + LTO) | 28 | 693 | 4 | 32 | 757 | 180 | + | :ref:`Light Switch ` (Debug + LTO) | 28 | 693 | 4 | 32 | 757 | 179 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Release) | 28 | 654 | 4 | 32 | 718 | 169 | + | :ref:`Light Switch ` (Release) | 28 | 657 | 4 | 32 | 721 | 168 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug) | 28 | 770 | 4 | 32 | 834 | 177 | + | :ref:`Lock ` (Debug) | 28 | 771 | 4 | 32 | 835 | 178 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug + LTO) | 28 | 705 | 4 | 32 | 769 | 181 | + | :ref:`Lock ` (Debug + LTO) | 28 | 705 | 4 | 32 | 769 | 182 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Release) | 28 | 655 | 4 | 32 | 719 | 172 | + | :ref:`Lock ` (Release) | 28 | 658 | 4 | 32 | 722 | 172 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug) | 28 | 710 | 4 | 32 | 774 | 174 | + | :ref:`Smoke CO Alarm ` (Debug) | 28 | 746 | 4 | 32 | 810 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug + LTO) | 28 | 653 | 4 | 32 | 717 | 178 | + | :ref:`Smoke CO Alarm ` (Debug + LTO) | 28 | 682 | 4 | 32 | 746 | 180 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Release) | 28 | 615 | 4 | 32 | 679 | 168 | + | :ref:`Smoke CO Alarm ` (Release) | 28 | 647 | 4 | 32 | 711 | 170 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug) | 28 | 761 | 4 | 32 | 825 | 175 | + | :ref:`Template ` (Debug) | 28 | 712 | 4 | 32 | 776 | 173 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug + LTO) | 28 | 696 | 4 | 32 | 760 | 179 | + | :ref:`Template ` (Debug + LTO) | 28 | 653 | 4 | 32 | 717 | 177 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Release) | 28 | 652 | 4 | 32 | 716 | 169 | + | :ref:`Template ` (Release) | 28 | 619 | 4 | 32 | 683 | 167 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug) | 28 | 742 | 4 | 32 | 806 | 175 | + | :ref:`Thermostat ` (Debug) | 28 | 762 | 4 | 32 | 826 | 174 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug + LTO) | 28 | 680 | 4 | 32 | 744 | 178 | + | :ref:`Thermostat ` (Debug + LTO) | 28 | 695 | 4 | 32 | 759 | 178 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Release) | 28 | 641 | 4 | 32 | 705 | 169 | + | :ref:`Thermostat ` (Release) | 28 | 655 | 4 | 32 | 719 | 167 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Debug) | 28 | 743 | 4 | 32 | 807 | 174 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Debug + LTO) | 28 | 679 | 4 | 32 | 743 | 178 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Release) | 28 | 644 | 4 | 32 | 708 | 168 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ .. tab:: nRF5340 DK @@ -104,41 +110,51 @@ Values are provided in kilobytes (KB). +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ | Sample | MCUboot ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | +======================================================================+===============+===================+================+============+=============+=================================+ - | :ref:`Light Bulb ` (Debug) | 32 | 722 | 4 | 32 | 790 | 193 | + | :ref:`Bridge ` (Debug + LTO) | 32 | 654 | 4 | 32 | 722 | 205 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Bridge ` (Release) | 32 | 638 | 4 | 32 | 706 | 197 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Light Bulb ` (Debug) | 32 | 723 | 4 | 32 | 791 | 193 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Light Bulb ` (Debug + LTO) | 32 | 661 | 4 | 32 | 729 | 197 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Debug + LTO) | 32 | 660 | 4 | 32 | 728 | 197 | + | :ref:`Light Bulb ` (Release) | 32 | 621 | 4 | 32 | 689 | 186 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Release) | 32 | 617 | 4 | 32 | 685 | 187 | + | :ref:`Light Switch ` (Debug) | 32 | 688 | 4 | 32 | 756 | 184 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug) | 32 | 685 | 4 | 32 | 753 | 184 | + | :ref:`Light Switch ` (Debug + LTO) | 32 | 623 | 4 | 32 | 691 | 188 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug + LTO) | 32 | 621 | 4 | 32 | 689 | 188 | + | :ref:`Light Switch ` (Release) | 32 | 585 | 4 | 32 | 653 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Release) | 32 | 580 | 4 | 32 | 648 | 177 | + | :ref:`Lock ` (Debug) | 32 | 701 | 4 | 32 | 769 | 188 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug) | 32 | 698 | 4 | 32 | 766 | 186 | + | :ref:`Lock ` (Debug + LTO) | 32 | 635 | 4 | 32 | 703 | 192 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug + LTO) | 32 | 633 | 4 | 32 | 701 | 190 | + | :ref:`Lock ` (Release) | 32 | 585 | 4 | 32 | 653 | 181 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Release) | 32 | 581 | 4 | 32 | 649 | 179 | + | :ref:`Smoke CO Alarm ` (Debug) | 32 | 675 | 4 | 32 | 743 | 185 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug) | 32 | 638 | 4 | 32 | 706 | 182 | + | :ref:`Smoke CO Alarm ` (Debug + LTO) | 32 | 612 | 4 | 32 | 680 | 189 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug + LTO) | 32 | 581 | 4 | 32 | 649 | 186 | + | :ref:`Smoke CO Alarm ` (Release) | 32 | 575 | 4 | 32 | 643 | 179 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Release) | 32 | 542 | 4 | 32 | 610 | 176 | + | :ref:`Template ` (Debug) | 32 | 641 | 4 | 32 | 709 | 183 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug) | 32 | 689 | 4 | 32 | 757 | 183 | + | :ref:`Template ` (Debug + LTO) | 32 | 583 | 4 | 32 | 651 | 186 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug + LTO) | 32 | 623 | 4 | 32 | 691 | 187 | + | :ref:`Template ` (Release) | 32 | 546 | 4 | 32 | 614 | 175 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Release) | 32 | 578 | 4 | 32 | 646 | 176 | + | :ref:`Thermostat ` (Debug) | 32 | 691 | 4 | 32 | 759 | 183 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug) | 32 | 670 | 4 | 32 | 738 | 183 | + | :ref:`Thermostat ` (Debug + LTO) | 32 | 626 | 4 | 32 | 694 | 187 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug + LTO) | 32 | 607 | 4 | 32 | 675 | 187 | + | :ref:`Thermostat ` (Release) | 32 | 583 | 4 | 32 | 651 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Release) | 32 | 567 | 4 | 32 | 635 | 176 | + | :ref:`Window Covering ` (Debug) | 32 | 672 | 4 | 32 | 740 | 183 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Debug + LTO) | 32 | 610 | 4 | 32 | 678 | 187 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Release) | 32 | 572 | 4 | 32 | 640 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ .. tab:: Thingy:53 @@ -148,98 +164,124 @@ Values are provided in kilobytes (KB). +-------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ | Sample | MCUboot ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | +===================================================================+===============+===================+================+============+=============+=================================+ - | :ref:`Weather Station ` (Debug) | 64 | 731 | 16 | 48 | 859 | 236 | + | :ref:`Weather Station ` (Debug) | 64 | 734 | 16 | 48 | 862 | 236 | +-------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Weather Station ` (Debug + LTO) | 64 | 661 | 16 | 48 | 789 | 240 | + | :ref:`Weather Station ` (Debug + LTO) | 64 | 664 | 16 | 48 | 792 | 240 | +-------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Weather Station ` (Release) | 64 | 594 | 16 | 48 | 722 | 210 | + | :ref:`Weather Station ` (Release) | 64 | 599 | 16 | 48 | 727 | 210 | +-------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ .. tab:: nRF7002 DK - The following table lists memory requirements for samples running on the :ref:`nRF7002 DK ` (:ref:`nrf7002dk/nrf5340/cpuapp `). + The following table lists memory requirements for samples running on the :ref:`nRF7002 DK ` (:ref:`nrf7002dk/nrf5340/cpuapp `). +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ | Sample | MCUboot ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | +================================================================+===============+===================+================+============+=============+=================================+ - | :ref:`Bridge ` (Debug + LTO) | 48 | 810 | 4 | 32 | 894 | 282 | - +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Bridge ` (Release) | 48 | 818 | 4 | 32 | 902 | 274 | + | :ref:`Bridge ` (Debug + LTO) | 48 | 825 | 4 | 32 | 909 | 305 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Debug) | 48 | 893 | 4 | 32 | 977 | 275 | + | :ref:`Bridge ` (Release) | 48 | 835 | 4 | 32 | 919 | 297 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Debug + LTO) | 48 | 817 | 4 | 32 | 901 | 279 | + | :ref:`Light Bulb ` (Debug) | 48 | 909 | 4 | 32 | 993 | 298 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Release) | 48 | 797 | 4 | 32 | 881 | 267 | + | :ref:`Light Bulb ` (Debug + LTO) | 48 | 829 | 4 | 32 | 913 | 302 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug) | 48 | 902 | 4 | 32 | 986 | 276 | + | :ref:`Light Bulb ` (Release) | 48 | 814 | 4 | 32 | 898 | 290 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug + LTO) | 48 | 824 | 4 | 32 | 908 | 280 | + | :ref:`Light Switch ` (Debug) | 48 | 918 | 4 | 32 | 1002 | 299 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Release) | 48 | 806 | 4 | 32 | 890 | 267 | + | :ref:`Light Switch ` (Debug + LTO) | 48 | 836 | 4 | 32 | 920 | 303 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug) | 48 | 915 | 4 | 32 | 999 | 276 | + | :ref:`Light Switch ` (Release) | 48 | 822 | 4 | 32 | 906 | 290 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug + LTO) | 48 | 837 | 4 | 32 | 921 | 280 | + | :ref:`Lock ` (Debug + LTO) | 48 | 848 | 4 | 32 | 932 | 303 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Release) | 48 | 806 | 4 | 32 | 890 | 268 | + | :ref:`Lock ` (Release) | 48 | 747 | 4 | 32 | 831 | 295 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug) | 48 | 859 | 4 | 32 | 943 | 274 | + | :ref:`Template ` (Debug) | 48 | 876 | 4 | 32 | 960 | 297 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug + LTO) | 48 | 788 | 4 | 32 | 872 | 278 | + | :ref:`Template ` (Debug + LTO) | 48 | 800 | 4 | 32 | 884 | 301 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Release) | 48 | 771 | 4 | 32 | 855 | 266 | + | :ref:`Template ` (Release) | 48 | 788 | 4 | 32 | 872 | 289 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug) | 48 | 906 | 4 | 32 | 990 | 275 | + | :ref:`Thermostat ` (Debug) | 48 | 923 | 4 | 32 | 1007 | 298 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug + LTO) | 48 | 828 | 4 | 32 | 912 | 279 | + | :ref:`Thermostat ` (Debug + LTO) | 48 | 840 | 4 | 32 | 924 | 302 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Release) | 48 | 804 | 4 | 32 | 888 | 267 | + | :ref:`Thermostat ` (Release) | 48 | 821 | 4 | 32 | 905 | 290 | +----------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ .. tab:: nRF54L15 DK - The following table lists memory requirements for samples running on the :ref:`nRF54l15 DK ` (:ref:`nrf54l15dk/nrf54l15/cpuapp `). + The following table lists memory requirements for samples running on the :ref:`nRF54L15 DK ` (:ref:`nrf54l15dk/nrf54l15/cpuapp `). +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ | Sample | MCUboot ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | +======================================================================+===============+===================+================+============+=============+=================================+ - | :ref:`Light Bulb ` (Debug) | 48 | 819 | 4 | 32 | 903 | 185 | + | :ref:`Light Bulb ` (Debug) | 48 | 812 | 4 | 40 | 904 | 194 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Light Bulb ` (Debug + LTO) | 48 | 745 | 4 | 40 | 837 | 195 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Light Bulb ` (Release) | 48 | 710 | 4 | 40 | 802 | 187 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Debug + LTO) | 48 | 737 | 4 | 32 | 821 | 189 | + | :ref:`Light Switch ` (Debug) | 48 | 776 | 4 | 40 | 868 | 185 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Bulb ` (Release) | 48 | 708 | 4 | 32 | 792 | 178 | + | :ref:`Light Switch ` (Debug + LTO) | 48 | 707 | 4 | 40 | 799 | 186 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug) | 48 | 780 | 4 | 32 | 864 | 176 | + | :ref:`Light Switch ` (Release) | 48 | 673 | 4 | 40 | 765 | 177 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Debug + LTO) | 48 | 700 | 4 | 32 | 784 | 179 | + | :ref:`Lock ` (Debug) | 48 | 789 | 4 | 40 | 881 | 188 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Light Switch ` (Release) | 48 | 668 | 4 | 32 | 752 | 168 | + | :ref:`Lock ` (Debug + LTO) | 48 | 719 | 4 | 40 | 811 | 189 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug) | 48 | 792 | 4 | 32 | 876 | 177 | + | :ref:`Lock ` (Release) | 48 | 674 | 4 | 40 | 766 | 181 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Debug + LTO) | 48 | 712 | 4 | 32 | 796 | 181 | + | :ref:`Smoke CO Alarm ` (Debug) | 48 | 764 | 4 | 40 | 856 | 186 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Lock ` (Release) | 48 | 668 | 4 | 32 | 752 | 170 | + | :ref:`Smoke CO Alarm ` (Debug + LTO) | 48 | 697 | 4 | 40 | 789 | 186 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug) | 48 | 734 | 4 | 32 | 818 | 174 | + | :ref:`Smoke CO Alarm ` (Release) | 48 | 664 | 4 | 40 | 756 | 179 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Debug + LTO) | 48 | 661 | 4 | 32 | 745 | 178 | + | :ref:`Template ` (Debug) | 48 | 731 | 4 | 40 | 823 | 183 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Template ` (Release) | 48 | 631 | 4 | 32 | 715 | 167 | + | :ref:`Template ` (Debug + LTO) | 48 | 668 | 4 | 40 | 760 | 184 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug) | 48 | 784 | 4 | 32 | 868 | 175 | + | :ref:`Template ` (Release) | 48 | 636 | 4 | 40 | 728 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Debug + LTO) | 48 | 703 | 4 | 32 | 787 | 178 | + | :ref:`Thermostat ` (Debug) | 48 | 780 | 4 | 40 | 872 | 184 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Thermostat ` (Release) | 48 | 667 | 4 | 32 | 751 | 167 | + | :ref:`Thermostat ` (Debug + LTO) | 48 | 710 | 4 | 40 | 802 | 185 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug) | 48 | 764 | 4 | 32 | 848 | 174 | + | :ref:`Thermostat ` (Release) | 48 | 673 | 4 | 40 | 765 | 176 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Debug + LTO) | 48 | 686 | 4 | 32 | 770 | 178 | + | :ref:`Window Covering ` (Debug) | 48 | 760 | 4 | 40 | 852 | 184 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ - | :ref:`Window Covering ` (Release) | 48 | 655 | 4 | 32 | 739 | 167 | + | :ref:`Window Covering ` (Debug + LTO) | 48 | 694 | 4 | 40 | 786 | 185 | +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Release) | 48 | 660 | 4 | 40 | 752 | 177 | + +----------------------------------------------------------------------+---------------+-------------------+----------------+------------+-------------+---------------------------------+ + + .. tab:: nRF54L15 DK with TF-M + + The following table lists memory requirements for samples running on the :ref:`nRF54L15 DK with CMSE enabled ` (:ref:`nrf54l15dk/nrf54l15/cpuapp/ns `). + + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | Sample | MCUboot ROM | TF-M ROM | Application ROM | Factory data | Settings | Total ROM | Total RAM (incl. static HEAP) | + +================================================================+===============+============+===================+================+============+=============+=================================+ + | :ref:`Light Bulb ` (Debug) | 48 | 126 | 749 | 4 | 40 | 967 | 238 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Light Switch ` (Debug) | 48 | 126 | 713 | 4 | 40 | 931 | 229 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Lock ` (Debug) | 48 | 126 | 725 | 4 | 40 | 943 | 233 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Template ` (Debug) | 48 | 126 | 674 | 4 | 40 | 892 | 228 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Template ` (Release) | 48 | 126 | 580 | 4 | 40 | 798 | 221 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Thermostat ` (Debug) | 48 | 126 | 717 | 4 | 40 | 935 | 228 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ + | :ref:`Window Covering ` (Debug) | 48 | 126 | 697 | 4 | 40 | 915 | 228 | + +----------------------------------------------------------------+---------------+------------+-------------------+----------------+------------+-------------+---------------------------------+ .. @@ -263,7 +305,7 @@ For more information about configuration of memory layouts in Matter, see :ref:` .. tab:: nRF52840 DK - The following memory map is valid for Matter applications running on the :ref:`nRF52840 DK ` (:ref:`nrf52840dk_nrf52840 `). + The following memory map is valid for Matter applications running on the :ref:`nRF52840 DK ` (:ref:`nrf52840dk/nrf52840 `). Internal flash (size: 0x100000 = 1024kB) +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ @@ -623,6 +665,45 @@ For more information about configuration of memory layouts in Matter, see :ref:` | Static RAM (sram_primary) | 0kB (0x0) | 256kB (0x40000) |- |- |- | +-----------------------------------------------+---------------------+-------------------+---------------------+-----------------+-----------------+ + .. tab:: nRF54L15 DK with TF-M + + The following table lists memory requirements for samples running on the :ref:`nRF54L15 DK with CMSE enabled ` (:ref:`nrf54l15dk/nrf54l15/cpuapp/ns `). + + Application core flash (size: 0x17D000 = 1524kB) + + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | Partition | Offset | Size | Partition elements | Element offset | Element size | + +=========================================+=====================+===================+=====================+=================+===================+ + | Bootloader (mcuboot) | 0kB (0x0) | 48kB (0xC000) |- |- |- | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | Secure part (tfm_secure) | 48kB (0xc000) | 128kB (0x20000) | mcuboot_pad | 48kB (0xc000) | 2k (0x800) | + | | | +---------------------+-----------------+-------------------+ + | | | | tfm | 50kB (0xc800) | 126kB (0x1f800) | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | Non-Secure part (tfm_nonsecure) | 176kB (0x2C000) | 1272kB (0x13E000) | app | 176kB (0x2C000) | 1272kB (0x13E000) | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | Factory data (factory_data) | 1448kB (0x16A000) | 4kB (0x1000) |- |- |- | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | Non-volatile storage (settings_storage) | 1452kB (0x16B000) | 40kB (0xa000) |- |- |- | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + | TFM storage (tfm_storage) | 1492kB (0x175000) | 32kB (0x8000) | tfm_its | 8kB (0x175000) | 8kB (0x2000) | + | | | +---------------------+-----------------+-------------------+ + | | | | tfm_otp_nv_counters | 8kB (0x177000) | 8kB (0x2000) | + | | | +---------------------+-----------------+-------------------+ + | | | | tfm_ps | 16kB (0x179000) | 16kB (0x4000) | + +-----------------------------------------+---------------------+-------------------+---------------------+-----------------+-------------------+ + + Application core SRAM primary (size: 0x40000 = 256kB) + SRAM is located at the address ``0x20000000`` in the memory address space of the application. + + +-----------------------------------------------+---------------------+-------------------+---------------------+-----------------+-----------------+ + | Partition | Offset | Size | Partition elements | Element offset | Element size | + +===============================================+=====================+===================+=====================+=================+=================+ + | Secure Static RAM (sram_secure) | 0kB (0x0) | 256kB (0xF000) |- |- |- | + +-----------------------------------------------+---------------------+-------------------+---------------------+-----------------+-----------------+ + | Non-Secure Static RAM (sram_nonsecure) | 256kB (0xF000) | 196kB (0x31000) |- |- |- | + +-----------------------------------------------+---------------------+-------------------+---------------------+-----------------+-----------------+ + .. You can generate :ref:`Partition Manager's ASCII representation ` of these tables by running the following command for your respective *board_target*: diff --git a/doc/nrf/protocols/matter/index.rst b/doc/nrf/protocols/matter/index.rst index e6bc148f21fb..7fd50cf893cf 100644 --- a/doc/nrf/protocols/matter/index.rst +++ b/doc/nrf/protocols/matter/index.rst @@ -15,41 +15,52 @@ It supports a wide range of existing technologies, including Wi-Fi, Thread, and .. matter_intro_end -The |NCS| allows you to develop applications with different versions of Matter, as per the following table: +|NCS| |release| allows you to develop applications with Matter specification version 1.3.0 and `Matter SDK version`_ 1.3.0.0. +For a full list of |NCS| and Matter versions, view the following table: -+--------------------------+-----------------------------------------------------+------------------------+ -| nRF Connect SDK version | Matter specification version | `Matter SDK version`_ | -+==========================+=====================================================+========================+ -| |release| | :ref:`1.3.0 ` | 1.3.0.0 | -+--------------------------+-----------------------------------------------------+------------------------+ -| v2.6.1 | :ref:`1.2.0 ` | 1.2.0.1 | -+--------------------------+ | | -| v2.6.0 | | | -+--------------------------+-----------------------------------------------------+------------------------+ -| v2.5.2 | :ref:`1.1.0 ` | 1.1.0.1 | -+--------------------------+ | | -| v2.5.1 | | | -+--------------------------+ | | -| v2.5.0 | | | -+--------------------------+ | | -| v2.4.3 | | | -+--------------------------+ | | -| v2.4.2 | | | -+--------------------------+ | | -| v2.4.1 | | | -+--------------------------+ | | -| v2.4.0 | | | -+--------------------------+-----------------------------------------------------+------------------------+ -| v2.3.0 | :ref:`1.0.0 ` | 1.0.0.2 | -+--------------------------+ +------------------------+ -| v2.2.0 | | 1.0.0.0 | -+--------------------------+ +------------------------+ -| v2.1.4 | | 1.0.0.0 | -+--------------------------+ +------------------------+ -| v2.1.3 | | 1.0.0.0 | -+--------------------------+ +------------------------+ -| v2.1.2 | | 1.0.0.0 | -+--------------------------+-----------------------------------------------------+------------------------+ +.. toggle:: nRF Connect SDK, Matter specification, and Matter SDK versions + + +--------------------------+-----------------------------------------------------+------------------------+ + | nRF Connect SDK version | Matter specification version | Matter SDK version | + +==========================+=====================================================+========================+ + | |release| | :ref:`1.3.0 ` | 1.3.0.0 | + +--------------------------+ | | + | v2.7.0 | | | + +--------------------------+-----------------------------------------------------+------------------------+ + | v2.6.2 | :ref:`1.2.0 ` | 1.2.0.1 | + +--------------------------+ | | + | v2.6.1 | | | + +--------------------------+ | | + | v2.6.0 | | | + +--------------------------+-----------------------------------------------------+------------------------+ + | v2.5.3 | :ref:`1.1.0 ` | 1.1.0.1 | + +--------------------------+ | | + | v2.5.2 | | | + +--------------------------+ | | + | v2.5.1 | | | + +--------------------------+ | | + | v2.5.0 | | | + +--------------------------+ | | + | v2.4.4 | | | + +--------------------------+ | | + | v2.4.3 | | | + +--------------------------+ | | + | v2.4.2 | | | + +--------------------------+ | | + | v2.4.1 | | | + +--------------------------+ | | + | v2.4.0 | | | + +--------------------------+-----------------------------------------------------+------------------------+ + | v2.3.0 | :ref:`1.0.0 ` | 1.0.0.2 | + +--------------------------+ +------------------------+ + | v2.2.0 | | 1.0.0.0 | + +--------------------------+ +------------------------+ + | v2.1.4 | | 1.0.0.0 | + +--------------------------+ +------------------------+ + | v2.1.3 | | 1.0.0.0 | + +--------------------------+ +------------------------+ + | v2.1.2 | | 1.0.0.0 | + +--------------------------+-----------------------------------------------------+------------------------+ .. note:: The Matter SDK version is taken as the base for the `dedicated Matter fork`_, which can then include additional changes for each |NCS| release. @@ -62,7 +73,7 @@ The |NCS| allows you to develop applications with different versions of Matter, For more information about Matter compatibility, see :ref:`ug_matter_overview_dev_model_support` and :ref:`supported Matter features per SoC `. -See :ref:`matter_samples` for the list of available samples, :ref:`Matter Weather Station ` or :ref:`Matter bridge ` for specific Matter application. +See :ref:`matter_samples` for the list of available samples, or :ref:`Matter Weather Station ` or :ref:`Matter bridge ` for specific Matter applications. If you are new to Matter, you can follow along with the video tutorials on Nordic Semiconductor's YouTube channel, for example `Developing Matter 1.0 products with nRF Connect SDK`_. .. note:: diff --git a/doc/nrf/protocols/thread/configuring.rst b/doc/nrf/protocols/thread/configuring.rst index 8b2e2c4d5f57..66fef0f37d1c 100644 --- a/doc/nrf/protocols/thread/configuring.rst +++ b/doc/nrf/protocols/thread/configuring.rst @@ -265,11 +265,9 @@ Minimal Thread Device (MTD) Trusted Firmware-M support options ================================== -To configure your Thread application on the nRF5340 DK to run with Trusted Firmware-M, use the ``nrf5340dk/nrf5340/cpuapp/ns`` board target and enable the following Kconfig options: +To configure your Thread application to run with Trusted Firmware-M, use the following board target: -* :kconfig:option:`CONFIG_BUILD_WITH_TFM` -* :kconfig:option:`CONFIG_OPENTHREAD_CRYPTO_PSA` - -In the |NCS|, these options are enabled by default for the :ref:`application core ` of the :ref:`openthread_samples` that can be programmed with the ``nrf5340dk/nrf5340/cpuapp/ns`` board target. +* ``nrf5340dk/nrf5340/cpuapp/ns`` for the nRF5340 DK +* ``nrf54l15dk/nrf54l15/cpuapp/ns``` for the nRF54L15 DK For more Trusted Firmware-M documentation, see :ref:`ug_tfm` and the official `TF-M documentation`_. diff --git a/doc/nrf/protocols/thread/overview/architectures.rst b/doc/nrf/protocols/thread/overview/architectures.rst index f50d6c8991eb..b8a4ef0f8712 100644 --- a/doc/nrf/protocols/thread/overview/architectures.rst +++ b/doc/nrf/protocols/thread/overview/architectures.rst @@ -56,14 +56,14 @@ This design has the following advantages: It has the following disadvantages: -* For some use cases, the nRF52 Series and nRF53 Series MCUs can be too slow (for example, when the application does complex data processing). +* For some use cases, the nRF52 Series, nRF53 Series and nRF54L Series MCUs can be too slow (for example, when the application does complex data processing). * The application and the network share flash and RAM space, which can limit the application functionality. * Might require external flash for DFU if the secondary application slot does not fit in the primary memory because of increased application size. .. figure:: images/thread_platform_design_soc.svg - :alt: Thread-only architecture (nRF52) + :alt: Thread-only architecture (nRF52, nRF54L) - Thread-only architecture on nRF52 Series devices + Thread-only architecture on nRF52 Series and nRF54L Series devices .. figure:: images/thread_platform_design_nRF53.svg :alt: Thread-only architecture (nRF53) @@ -74,14 +74,14 @@ This platform design is suitable for the following development kits: .. table-from-rows:: /includes/sample_board_rows.txt :header: heading - :rows: nrf52840dk_nrf52840, nrf52833dk_nrf52833, nrf5340dk_nrf5340_cpuapp_and_cpuapp_ns, nrf21540dk_nrf52840 + :rows: nrf52840dk_nrf52840, nrf5340dk_nrf5340_cpuapp_and_cpuapp_ns, nrf54l15dk_nrf54l15_cpuapp_and_cpuapp_ns, nrf21540dk_nrf52840 .. _thread_architectures_designs_soc_designs_multiprotocol: Single-chip, multiprotocol (SoC) ================================ -nRF52 and nRF53 Series devices support multiple wireless technologies, including IEEE 802.15.4 and Bluetooth® Low Energy (Bluetooth LE). +nRF52 Series, nRF53 Series and nRF54L Series devices support multiple wireless technologies, including IEEE 802.15.4 and Bluetooth® Low Energy (Bluetooth LE). In a single-chip, multiprotocol design, the application layer and OpenThread run on the same processor. @@ -95,9 +95,9 @@ It has the following disadvantages: * Bluetooth LE activity can degrade the connectivity on Thread if not implemented with efficiency in mind. .. figure:: images/thread_platform_design_multi.svg - :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF52) + :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF52, nRF54L) - Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series devices + Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series and nRF54L Series devices .. figure:: images/thread_platform_design_nRF53_multi.svg :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF53) @@ -110,7 +110,7 @@ This platform design is suitable for the following development kits: .. table-from-rows:: /includes/sample_board_rows.txt :header: heading - :rows: nrf52840dk_nrf52840, nrf52833dk_nrf52833, nrf5340dk_nrf5340_cpuapp_and_cpuapp_ns + :rows: nrf52840dk_nrf52840, nrf5340dk_nrf5340_cpuapp_and_cpuapp_ns, nrf54l15dk_nrf54l15_cpuapp_and_cpuapp_ns .. _thread_architectures_designs_cp: @@ -190,7 +190,7 @@ This platform design is suitable for the following development kits: .. table-from-rows:: /includes/sample_board_rows.txt :header: heading - :rows: nrf52840dk_nrf52840, nrf52833dk_nrf52833, nrf21540dk_nrf52840 + :rows: nrf52833dk_nrf52833, nrf52840dk_nrf52840, nrf54l15dk_nrf54l15_cpuapp_and_cpuapp_ns, nrf21540dk_nrf52840 .. _thread_architectures_designs_cp_uart: diff --git a/doc/nrf/protocols/thread/overview/memory_tables/nrf52840.txt b/doc/nrf/protocols/thread/overview/memory_tables/nrf52840.txt index bd6c9988bc5d..c569aae49655 100644 --- a/doc/nrf/protocols/thread/overview/memory_tables/nrf52840.txt +++ b/doc/nrf/protocols/thread/overview/memory_tables/nrf52840.txt @@ -2,45 +2,45 @@ .. group-tab:: Single protocol - .. table:: nRF52840 single protocol Thread 1.3 memory requirements + .. table:: nRF52840 single protocol Thread 1.4 memory requirements - +-----------------------------+----------+-------+-------+ - | | master | FTD | MTD | - +=============================+==========+=======+=======+ - | ROM OT stack + App [kB] | 443 | 358 | 303 | - +-----------------------------+----------+-------+-------+ - | ROM Bluetooth LE stack [kB] | 0 | 0 | 0 | - +-----------------------------+----------+-------+-------+ - | Persistent storage [kB] | 32 | 32 | 32 | - +-----------------------------+----------+-------+-------+ - | Free ROM [kB] | 549 | 634 | 689 | - +-----------------------------+----------+-------+-------+ - | RAM OT stack + App [kB] | 102 | 93 | 83 | - +-----------------------------+----------+-------+-------+ - | RAM Bluetooth LE stack [kB] | 0 | 0 | 0 | - +-----------------------------+----------+-------+-------+ - | Free RAM [kB] | 154 | 163 | 173 | - +-----------------------------+----------+-------+-------+ + +-----------------------------+-------+-------+ + | | FTD | MTD | + +=============================+=======+=======+ + | ROM OT stack + App [kB] | 359 | 304 | + +-----------------------------+-------+-------+ + | ROM Bluetooth LE stack [kB] | 0 | 0 | + +-----------------------------+-------+-------+ + | Persistent storage [kB] | 32 | 32 | + +-----------------------------+-------+-------+ + | Free ROM [kB] | 633 | 688 | + +-----------------------------+-------+-------+ + | RAM OT stack + App [kB] | 93 | 83 | + +-----------------------------+-------+-------+ + | RAM Bluetooth LE stack [kB] | 0 | 0 | + +-----------------------------+-------+-------+ + | Free RAM [kB] | 163 | 173 | + +-----------------------------+-------+-------+ .. group-tab:: Multiprotocol - .. table:: nRF52840 multiprotocol Thread 1.3 memory requirements + .. table:: nRF52840 multiprotocol Thread 1.4 memory requirements - +-----------------------------+----------+-------+-------+ - | | master | FTD | MTD | - +=============================+==========+=======+=======+ - | ROM OT stack + App [kB] | 443 | 358 | 303 | - +-----------------------------+----------+-------+-------+ - | ROM Bluetooth LE stack [kB] | 75 | 75 | 76 | - +-----------------------------+----------+-------+-------+ - | Persistent storage [kB] | 32 | 32 | 32 | - +-----------------------------+----------+-------+-------+ - | Free ROM [kB] | 474 | 559 | 613 | - +-----------------------------+----------+-------+-------+ - | RAM OT stack + App [kB] | 102 | 93 | 83 | - +-----------------------------+----------+-------+-------+ - | RAM Bluetooth LE stack [kB] | 12 | 13 | 13 | - +-----------------------------+----------+-------+-------+ - | Free RAM [kB] | 142 | 150 | 160 | - +-----------------------------+----------+-------+-------+ + +-----------------------------+-------+-------+ + | | FTD | MTD | + +=============================+=======+=======+ + | ROM OT stack + App [kB] | 359 | 304 | + +-----------------------------+-------+-------+ + | ROM Bluetooth LE stack [kB] | 75 | 76 | + +-----------------------------+-------+-------+ + | Persistent storage [kB] | 32 | 32 | + +-----------------------------+-------+-------+ + | Free ROM [kB] | 558 | 612 | + +-----------------------------+-------+-------+ + | RAM OT stack + App [kB] | 93 | 83 | + +-----------------------------+-------+-------+ + | RAM Bluetooth LE stack [kB] | 13 | 13 | + +-----------------------------+-------+-------+ + | Free RAM [kB] | 150 | 160 | + +-----------------------------+-------+-------+ diff --git a/doc/nrf/protocols/thread/overview/memory_tables/nrf5340.txt b/doc/nrf/protocols/thread/overview/memory_tables/nrf5340.txt index 0331a3c0daf6..683aa512fd61 100644 --- a/doc/nrf/protocols/thread/overview/memory_tables/nrf5340.txt +++ b/doc/nrf/protocols/thread/overview/memory_tables/nrf5340.txt @@ -2,45 +2,45 @@ .. group-tab:: Single protocol - .. table:: nRF5340 single protocol Thread 1.3 memory requirements + .. table:: nRF5340 single protocol Thread 1.4 memory requirements +-----------------------------+-------+-------+ | | FTD | MTD | +=============================+=======+=======+ - | ROM OT stack + App [kB] | 329 | 275 | + | ROM OT stack + App [kB] | 330 | 276 | +-----------------------------+-------+-------+ | ROM Bluetooth LE stack [kB] | 0 | 0 | +-----------------------------+-------+-------+ | Persistent storage [kB] | 32 | 32 | +-----------------------------+-------+-------+ - | Free ROM [kB] | 663 | 717 | + | Free ROM [kB] | 662 | 716 | +-----------------------------+-------+-------+ - | RAM OT stack + App [kB] | 101 | 90 | + | RAM OT stack + App [kB] | 101 | 91 | +-----------------------------+-------+-------+ | RAM Bluetooth LE stack [kB] | 0 | 0 | +-----------------------------+-------+-------+ - | Free RAM [kB] | 411 | 422 | + | Free RAM [kB] | 411 | 421 | +-----------------------------+-------+-------+ .. group-tab:: Multiprotocol - .. table:: nRF5340 multiprotocol Thread 1.3 memory requirements + .. table:: nRF5340 multiprotocol Thread 1.4 memory requirements +-----------------------------+-------+-------+ | | FTD | MTD | +=============================+=======+=======+ - | ROM OT stack + App [kB] | 329 | 275 | + | ROM OT stack + App [kB] | 330 | 276 | +-----------------------------+-------+-------+ | ROM Bluetooth LE stack [kB] | 30 | 30 | +-----------------------------+-------+-------+ | Persistent storage [kB] | 32 | 32 | +-----------------------------+-------+-------+ - | Free ROM [kB] | 633 | 687 | + | Free ROM [kB] | 632 | 686 | +-----------------------------+-------+-------+ - | RAM OT stack + App [kB] | 101 | 90 | + | RAM OT stack + App [kB] | 101 | 91 | +-----------------------------+-------+-------+ - | RAM Bluetooth LE stack [kB] | 13 | 14 | + | RAM Bluetooth LE stack [kB] | 13 | 13 | +-----------------------------+-------+-------+ | Free RAM [kB] | 398 | 408 | +-----------------------------+-------+-------+ diff --git a/doc/nrf/protocols/thread/overview/memory_tables/nrf54l15.txt b/doc/nrf/protocols/thread/overview/memory_tables/nrf54l15.txt index 566f7ee16bb2..0781040f25ed 100644 --- a/doc/nrf/protocols/thread/overview/memory_tables/nrf54l15.txt +++ b/doc/nrf/protocols/thread/overview/memory_tables/nrf54l15.txt @@ -2,45 +2,45 @@ .. group-tab:: Single protocol - .. table:: nRF54L15 single protocol Thread 1.3 memory requirements + .. table:: nRF54L15 single protocol Thread 1.4 memory requirements +-----------------------------+----------+-------+-------+ | | master | FTD | MTD | +=============================+==========+=======+=======+ - | ROM OT stack + App [kB] | 453 | 366 | 313 | + | ROM OT stack + App [kB] | 478 | 368 | 315 | +-----------------------------+----------+-------+-------+ | ROM Bluetooth LE stack [kB] | 0 | 0 | 0 | +-----------------------------+----------+-------+-------+ | Persistent storage [kB] | 32 | 32 | 32 | +-----------------------------+----------+-------+-------+ - | Free ROM [kB] | 1039 | 1126 | 1179 | + | Free ROM [kB] | 1014 | 1124 | 1177 | +-----------------------------+----------+-------+-------+ - | RAM OT stack + App [kB] | 104 | 97 | 87 | + | RAM OT stack + App [kB] | 107 | 98 | 87 | +-----------------------------+----------+-------+-------+ | RAM Bluetooth LE stack [kB] | 0 | 0 | 0 | +-----------------------------+----------+-------+-------+ - | Free RAM [kB] | 152 | 159 | 169 | + | Free RAM [kB] | 149 | 158 | 169 | +-----------------------------+----------+-------+-------+ .. group-tab:: Multiprotocol - .. table:: nRF54L15 multiprotocol Thread 1.3 memory requirements + .. table:: nRF54L15 multiprotocol Thread 1.4 memory requirements +-----------------------------+----------+-------+-------+ | | master | FTD | MTD | +=============================+==========+=======+=======+ - | ROM OT stack + App [kB] | 453 | 366 | 313 | + | ROM OT stack + App [kB] | 478 | 368 | 315 | +-----------------------------+----------+-------+-------+ | ROM Bluetooth LE stack [kB] | 91 | 91 | 91 | +-----------------------------+----------+-------+-------+ | Persistent storage [kB] | 32 | 32 | 32 | +-----------------------------+----------+-------+-------+ - | Free ROM [kB] | 948 | 1035 | 1088 | + | Free ROM [kB] | 923 | 1033 | 1086 | +-----------------------------+----------+-------+-------+ - | RAM OT stack + App [kB] | 104 | 97 | 87 | + | RAM OT stack + App [kB] | 107 | 98 | 87 | +-----------------------------+----------+-------+-------+ | RAM Bluetooth LE stack [kB] | 14 | 14 | 14 | +-----------------------------+----------+-------+-------+ - | Free RAM [kB] | 138 | 145 | 155 | + | Free RAM [kB] | 135 | 144 | 155 | +-----------------------------+----------+-------+-------+ diff --git a/doc/nrf/protocols/thread/overview/ot_memory.rst b/doc/nrf/protocols/thread/overview/ot_memory.rst index 27dd0ba905c7..eda5160b4f4b 100644 --- a/doc/nrf/protocols/thread/overview/ot_memory.rst +++ b/doc/nrf/protocols/thread/overview/ot_memory.rst @@ -38,10 +38,10 @@ See :ref:`thread_device_types` for more information on device types, and :ref:`t .. _thread_ot_memory_54l15: -nRF5340 DK RAM and flash memory requirements +nRF54L15 DK RAM and flash memory requirements ********************************************* -The following tables present memory requirements for samples running on the :ref:`nRF54L15 DK ` (:ref:`nrf54l15dk `) with the software cryptography support provided by the :ref:`nrfxlib:nrf_oberon_readme` module. +The following tables present memory requirements for samples running on the :ref:`nRF54L15 DK ` (:ref:`nrf54l15dk `) with the cryptography support provided by the :ref:`nrf_security_drivers_cracen`. .. include:: memory_tables/nrf54l15.txt @@ -50,7 +50,7 @@ The following tables present memory requirements for samples running on the :ref nRF5340 DK RAM and flash memory requirements ********************************************* -The following tables present memory requirements for samples running on the :ref:`nRF5340 DK ` (:ref:`nrf5340dk `) with the software cryptography support provided by the :ref:`nrfxlib:nrf_oberon_readme` module. +The following tables present memory requirements for samples running on the :ref:`nRF5340 DK ` (:ref:`nrf5340dk `) with the cryptography support provided by the :ref:`nrf_security_drivers_oberon`. .. include:: memory_tables/nrf5340.txt @@ -59,6 +59,6 @@ The following tables present memory requirements for samples running on the :ref nRF52840 DK RAM and flash memory requirements ********************************************* -The following tables present memory requirements for samples running on the :ref:`nRF52840 DK ` (:ref:`nrf52840dk_nrf52840 `) with the software cryptography support provided by the :ref:`nrfxlib:nrf_oberon_readme` module. +The following tables present memory requirements for samples running on the :ref:`nRF52840 DK ` (:ref:`nrf52840dk_nrf52840 `) with the cryptography support provided by the :ref:`nrf_security_drivers_oberon`. .. include:: memory_tables/nrf52840.txt diff --git a/doc/nrf/protocols/thread/overview/power_consumption.rst b/doc/nrf/protocols/thread/overview/power_consumption.rst index 581f14561201..f0f31d4d6716 100644 --- a/doc/nrf/protocols/thread/overview/power_consumption.rst +++ b/doc/nrf/protocols/thread/overview/power_consumption.rst @@ -60,63 +60,63 @@ The following tables show the power consumption measured with the configuration .. table:: Configuration - +--------------------------+---------------------+--------------------------+ - | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | - +==========================+=====================+==========================+ - | Board revision | v3.0.2 | v2.0.2 | - +--------------------------+---------------------+--------------------------+ - | Supply voltage [V] | 3.0 | 3.0 | - +--------------------------+---------------------+--------------------------+ - | Transmission power [dBm] | 0 | 0 | - +--------------------------+---------------------+--------------------------+ - | Polling period [ms] | 1000 | 1000 | - +--------------------------+---------------------+--------------------------+ + +--------------------------+---------------------+--------------------------+----------------------------+ + | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | nrf54l15dk/nrf54l15/cpuapp | + +==========================+=====================+==========================+============================+ + | Board revision | v3.0.2 | v2.0.2 | v0.8.1 | + +--------------------------+---------------------+--------------------------+----------------------------+ + | Supply voltage [V] | 3.0 | 3.0 | 1.8 | + +--------------------------+---------------------+--------------------------+----------------------------+ + | Transmission power [dBm] | 0 | 0 | 0 | + +--------------------------+---------------------+--------------------------+----------------------------+ + | Polling period [ms] | 1000 | 1000 | 1000 | + +--------------------------+---------------------+--------------------------+----------------------------+ .. table:: Power consumption - +-------------------------------+-----------------------+----------------------------+ - | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | - +===============================+=======================+============================+ - | Total charge per minute [μC] | 1135.87 | 1196.07 | - +-------------------------------+-----------------------+----------------------------+ - | Average data poll charge [μC] | 16.48 | 17.14 | - +-------------------------------+-----------------------+----------------------------+ - | Average sleep current [μA] | 2.67 | 3.00 | - +-------------------------------+-----------------------+----------------------------+ + +-------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | nrf54l15dk/nrf54l15/cpuapp | + +===========================================+=======================+============================+==============================+ + | Average power consumption per minute [μW] | 58.41 | 62.64 | 34.42 | + +-------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Average data poll power consumption [mW] | 11.66 | 9.68 | 7.07 | + +-------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Average sleep current [μA] | 2.75 | 4.12 | 2.02 | + +-------------------------------------------+-----------------------+----------------------------+------------------------------+ .. group-tab:: Thread 1.3 SSED .. table:: Configuration - +--------------------------------+---------------------+--------------------------+ - | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | - +================================+=====================+==========================+ - | Board revision | v3.0.2 | v2.0.2 | - +--------------------------------+---------------------+--------------------------+ - | Supply voltage [V] | 3.0 | 3.0 | - +--------------------------------+---------------------+--------------------------+ - | Transmission power [dBm] | 0 | 0 | - +--------------------------------+---------------------+--------------------------+ - | CSL period [ms] | 1000 | 1000 | - +--------------------------------+---------------------+--------------------------+ - | CSL timeout [s] | 20 | 20 | - +--------------------------------+---------------------+--------------------------+ - | Parent's CSL accuracy [ppm] | ±20 | ±20 | - +--------------------------------+---------------------+--------------------------+ - | Parent's CSL uncertainty [μs] | ±120 | ±120 | - +--------------------------------+---------------------+--------------------------+ + +--------------------------------+---------------------+--------------------------+----------------------------+ + | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | nrf54l15dk/nrf54l15/cpuapp | + +================================+=====================+==========================+============================+ + | Board revision | v3.0.2 | v2.0.2 | v0.8.1 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | Supply voltage [V] | 3.0 | 3.0 | 1.8 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | Transmission power [dBm] | 0 | 0 | 0 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | CSL period [ms] | 1000 | 1000 | 1000 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | CSL timeout [s] | 20 | 20 | 20 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | Parent's CSL accuracy [ppm] | ±20 | ±20 | ±20 | + +--------------------------------+---------------------+--------------------------+----------------------------+ + | Parent's CSL uncertainty [μs] | ±120 | ±120 | ±120 | + +--------------------------------+---------------------+--------------------------+----------------------------+ .. table:: Power consumption - +---------------------------------+-----------------------+----------------------------+ - | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | - +=================================+=======================+============================+ - | Total charge per minute [μC] | 1049.87 | 1099.53 | - +---------------------------------+-----------------------+----------------------------+ - | Average CSL receive charge [μC] | 13.91 | 14.38 | - +---------------------------------+-----------------------+----------------------------+ - | Average data poll charge [μC] | 21.93 | 22.36 | - +---------------------------------+-----------------------+----------------------------+ - | Average sleep current [μA] | 2.67 | 2.97 | - +---------------------------------+-----------------------+----------------------------+ + +--------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Parameter | nrf52840dk/nrf52840 | nrf5340dk/nrf5340/cpuapp | nrf54l15dk/nrf54l15/cpuapp | + +============================================+=======================+============================+==============================+ + | Average power consumption per minute [μW] | 51.00 | 57.15 | 37.69 | + +--------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Average CSL receive power consumption [mW] | 5.46 | 5.61 | 3.80 | + +--------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Average data poll power consumption [mW] | 12.23 | 11.13 | 7.92 | + +--------------------------------------------+-----------------------+----------------------------+------------------------------+ + | Average sleep current [μA] | 2.76 | 4.17 | 2.05 | + +--------------------------------------------+-----------------------+----------------------------+------------------------------+ diff --git a/doc/nrf/protocols/thread/overview/supported_features.rst b/doc/nrf/protocols/thread/overview/supported_features.rst index f381b41c5264..ba7066b6471c 100644 --- a/doc/nrf/protocols/thread/overview/supported_features.rst +++ b/doc/nrf/protocols/thread/overview/supported_features.rst @@ -124,15 +124,6 @@ The Thread Domain operational configuration enables Thread Devices to join and p A user or network administrator may use functions of either Thread Commissioning or Thread Border Routers to set up a common Thread Domain operational configuration for Thread Devices. The Thread Devices can belong to different Thread networks or `Partitions `_ that have potentially different per-network credentials. -.. _ug_thread_12_support_limitations: - -Limitations for Thread 1.2 support -================================== - -The Thread 1.2 Specification support has the following limitation: - -* Due to code size limitation, the combination of complete set of Thread 1.2 features with the Bluetooth® LE multiprotocol support is not possible for the nRF52833 DKs. - .. _thread_ug_supported_features_v13: Thread 1.3 features diff --git a/doc/nrf/protocols/thread/tools.rst b/doc/nrf/protocols/thread/tools.rst index ba29190f8f8e..7877a5f883a0 100644 --- a/doc/nrf/protocols/thread/tools.rst +++ b/doc/nrf/protocols/thread/tools.rst @@ -154,7 +154,7 @@ To set up and configure the OpenThread Border Router, follow the official `OpenT cd ot-br-posix git pull --unshallow - git checkout 98dda6c + git checkout fbde28a * After the *Build and install OTBR* section, configure RCP device's UART baud rate in *otbr-agent*. Modify the :file:`/etc/default/otbr-agent` configuration file with default RCP baud rate: @@ -196,7 +196,7 @@ To install and configure the OpenThread Border Router using the Docker container .. code-block:: console - docker pull nrfconnect/otbr:98dda6c + docker pull nrfconnect/otbr:fbde28a #. Connect the radio co-processor that you configured in :ref:`ug_thread_tools_tbr_rcp` to the Border Router device. #. Start the OpenThread Border Router container using the following commands: @@ -206,7 +206,7 @@ To install and configure the OpenThread Border Router using the Docker container sudo modprobe ip6table_filter sudo docker run -it --rm --privileged --name otbr --network otbr -p 8080:80 \ --sysctl "net.ipv6.conf.all.disable_ipv6=0 net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1" \ - --volume /dev/ttyACM0:/dev/radio nrfconnect/otbr:98dda6c --radio-url spinel+hdlc+uart:///dev/radio?uart-baudrate=1000000 + --volume /dev/ttyACM0:/dev/radio nrfconnect/otbr:fbde28a --radio-url spinel+hdlc+uart:///dev/radio?uart-baudrate=1000000 Replace ``/dev/ttyACM0`` with the device node name of the OpenThread radio co-processor. diff --git a/doc/nrf/protocols/wifi/advanced_modes/index.rst b/doc/nrf/protocols/wifi/advanced_modes/index.rst index ad57cd8ce86c..fe1d9c4d44c0 100644 --- a/doc/nrf/protocols/wifi/advanced_modes/index.rst +++ b/doc/nrf/protocols/wifi/advanced_modes/index.rst @@ -13,3 +13,4 @@ The following subpages cover topics related to the transmission and reception of raw_tx_operation sniffer_rx_operation promiscuous_operation + offloaded_raw_tx diff --git a/doc/nrf/protocols/wifi/advanced_modes/mem_requirements_raw.rst b/doc/nrf/protocols/wifi/advanced_modes/mem_requirements_raw.rst index aa88172529fc..a8dab634b869 100644 --- a/doc/nrf/protocols/wifi/advanced_modes/mem_requirements_raw.rst +++ b/doc/nrf/protocols/wifi/advanced_modes/mem_requirements_raw.rst @@ -18,9 +18,9 @@ Footprint values are provided in kilobytes (KB). +----------------------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +====================================================+=============+===========================================+============================+======================+=================================+====================+======================+ - | :ref:`Raw TX packet ` | 507 | 54 | 69 | 180 | 298 | 207 | 13 | + | :ref:`Raw TX packet ` | 534 | 3 | 74 | 187 | 290 | 218 | 15 | +----------------------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`Monitor ` | 495 | 51 | 69 | 180 | 398 | 306 | 13 | + | :ref:`Monitor ` | 521 | 3 | 74 | 187 | 312 | 239 | 15 | +----------------------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`Promiscuous ` | 512 | 55 | 69 | 180 | 401 | 306 | 13 | + | :ref:`Promiscuous ` | 539 | 3 | 74 | 187 | 315 | 239 | 15 | +----------------------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ diff --git a/doc/nrf/protocols/wifi/advanced_modes/offloaded_raw_tx.rst b/doc/nrf/protocols/wifi/advanced_modes/offloaded_raw_tx.rst new file mode 100644 index 000000000000..320b238025af --- /dev/null +++ b/doc/nrf/protocols/wifi/advanced_modes/offloaded_raw_tx.rst @@ -0,0 +1,62 @@ +.. _ug_nrf70_developing_offloaded_raw_tx: + +Offloaded raw transmit operation +################################ + +.. contents:: + :local: + :depth: 2 + +The nRF70 Series ICs can be used as offloaded raw transmit devices, where the nRF70 Series device can transmit frames at regular intervals utilizing very low power. +The contents of the frame as well as parameters such as frequency and channel of transmission are programmable. + +The major functionality of transmitting the frames is offloaded to the nRF70 device, thereby placing minimal requirements on the host (mainly programming capability). +This results in minimal host memory requirements (RAM and flash memory). + +This can be used for applications such as indoor navigation and tracking, where it is essential for anchor nodes to perform low-power beaconing. +Anchor devices can transmit beacon-compliant packets containing tracking or location information inside the BSSID or SSID fields. +Devices scanning for these beacon-compliant packets can use this information. + +Offloaded raw TX mode in Wi-Fi driver +************************************* + +The offloaded raw transmit operation is supported as a separate stand-alone compile-time mode of operation in the nRF Wi-Fi driver and is exclusive to the following existing modes of operation: + +* Wi-Fi mode +* Radio Test mode + +In addition to providing start or stop control over the offloaded raw transmit operation, the driver supports the update of the following configuration parameters: + +* Frame contents +* Channel of operation +* Data rate +* Rate flags +* Periodicity of transmission +* Transmit power + +.. _ug_nrf70_developing_enabling_offloaded_raw_tx: + +Offloaded raw transmit API +************************** + +The offloaded raw transmit functionality of nRF70 Series ICs can be utilized by using the APIs provided by the driver. +The API reference can be found at: + +| Header file: :file:`zephyr/drivers/wifi/nrfwifi/off_raw_tx/off_raw_tx_api.h` + + +See the :ref:`Offloaded raw transmit sample ` to know more about the offloaded raw transmit API. + +.. _ug_nrf70_developing_offloaded_raw_tx_power_consumption: + +Power consumption +***************** + +The power consumed by the nRF70 Series device during the offloaded raw TX operation depends on the following parameters: + +* Operating data rate (for example, 6 Mbps, MCS0) : Power consumption decreases as the data rate increases. +* Payload length : Power consumption increases with the payload length. +* Periodicity of transmission : Power consumption increases as the period between successive transmissions decreases. +* Transmit power : Power consumption increases as the transmit power increases. + +For optimizing the power consumption of your application, you can use the `Online Power Profiler for Wi-Fi`_ tool. diff --git a/doc/nrf/protocols/wifi/provisioning/mem_requirements_ble.rst b/doc/nrf/protocols/wifi/provisioning/mem_requirements_ble.rst index e8d19ba15dac..7554492a3dc9 100644 --- a/doc/nrf/protocols/wifi/provisioning/mem_requirements_ble.rst +++ b/doc/nrf/protocols/wifi/provisioning/mem_requirements_ble.rst @@ -12,5 +12,5 @@ The following table lists memory requirements for the :ref:`Bluetooth LE based p +-------------------------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +=============================================================+=============+===========================================+===============================+======================+=================================+====================+======================+ -| :ref:`Bluetooth LE based provision ` | 571 | 54 | 69 | 180 | 277 | 164 | 13 | +| :ref:`Bluetooth LE based provision ` | 601 | 3 | 74 | 187 | 317 | 222 | 15 | +-------------------------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ diff --git a/doc/nrf/protocols/wifi/provisioning/mem_requirements_softap.rst b/doc/nrf/protocols/wifi/provisioning/mem_requirements_softap.rst index 98762defcc94..efa6219160a1 100644 --- a/doc/nrf/protocols/wifi/provisioning/mem_requirements_softap.rst +++ b/doc/nrf/protocols/wifi/provisioning/mem_requirements_softap.rst @@ -13,7 +13,7 @@ The following table lists memory requirements for the :ref:`SoftAP based provisi +-------------------------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +=============================================================+=============+===========================================+===============================+======================+=================================+====================+======================+ -| :ref:`SoftAP based provision `| 666 | 0 | 69 | 0 | 302 | 0 | 0 | +| :ref:`SoftAP based provision `| 656 | 0 | 74 | 0 | 217 | 0 | 0 | +-------------------------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ .. note:: diff --git a/doc/nrf/protocols/wifi/sap_mode/mem_requirements_sap.rst b/doc/nrf/protocols/wifi/sap_mode/mem_requirements_sap.rst index 11a0ce953df5..16612f0f640a 100644 --- a/doc/nrf/protocols/wifi/sap_mode/mem_requirements_sap.rst +++ b/doc/nrf/protocols/wifi/sap_mode/mem_requirements_sap.rst @@ -12,5 +12,5 @@ The following table lists the memory requirements for :ref:`SoftAP ` | 682 | 59 | 69 | 291 | 309 | 207 | 13 | +| :ref:`SoftAP ` | 716 | 3 | 74 | 300 | 309 | 228 | 15 | +--------------------------------------+-------------+-------------------------------------------+--------------------------+----------------------+---------------------------------+--------------------+----------------------+ diff --git a/doc/nrf/protocols/wifi/scan_mode/mem_requirements_scan.rst b/doc/nrf/protocols/wifi/scan_mode/mem_requirements_scan.rst index bd4cf06056d5..e2a79a98f425 100644 --- a/doc/nrf/protocols/wifi/scan_mode/mem_requirements_scan.rst +++ b/doc/nrf/protocols/wifi/scan_mode/mem_requirements_scan.rst @@ -18,7 +18,7 @@ Footprint values are provided in kilobytes (KB). +--------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +======================================+=============+===========================================+============================+======================+=================================+====================+======================+ - | :ref:`Scan ` | 152 | 25 | 25 | 0 | 78 | 45 | 0 | + | :ref:`Scan ` | 150 | 1 | 28 | 0 | 64 | 34 | 0 | +--------------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ .. tab:: nRF7002 DK @@ -38,9 +38,9 @@ Footprint values are provided in kilobytes (KB). +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +===================================+=============+===========================================+============================+======================+=================================+====================+======================+ - | :ref:`Location ` | 242 | 26 | 69 | 0 | 106 | 50 | 0 | + | :ref:`Location ` | 247 | 3 | 74 | 0 | 112 | 48 | 0 | +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`Scan ` | 146 | 25 | 25 | 0 | 73 | 45 | 0 | + | :ref:`Scan ` | 144 | 1 | 28 | 0 | 61 | 34 | 0 | +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ .. tab:: nRF9161 DK @@ -50,7 +50,7 @@ Footprint values are provided in kilobytes (KB). +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +===================================+=============+===========================================+============================+======================+=================================+====================+======================+ - | :ref:`Location ` | 249 | 26 | 69 | 0 | 106 | 50 | 0 | + | :ref:`Location ` | 254 | 3 | 74 | 0 | 113 | 48 | 0 | +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`Scan ` | 156 | 25 | 25 | 0 | 74 | 45 | 0 | + | :ref:`Scan ` | 154 | 1 | 28 | 0 | 61 | 34 | 0 | +-----------------------------------+-------------+-------------------------------------------+----------------------------+----------------------+---------------------------------+--------------------+----------------------+ diff --git a/doc/nrf/protocols/wifi/station_mode/mem_requirements_sta.rst b/doc/nrf/protocols/wifi/station_mode/mem_requirements_sta.rst index 5be24158cb90..2a2eef278b74 100644 --- a/doc/nrf/protocols/wifi/station_mode/mem_requirements_sta.rst +++ b/doc/nrf/protocols/wifi/station_mode/mem_requirements_sta.rst @@ -18,7 +18,7 @@ Footprint values are provided in kilobytes (KB). +--------------------------------------+-------------+-------------------------------------------+-----------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +======================================+=============+===========================================+=============================+======================+=================================+====================+======================+ - | :ref:`Station ` | 502 | 51 | 69 | 180 | 253 | 164 | 11 | + | :ref:`Station ` | 531 | 3 | 74 | 187 | 201 | 127 | 15 | +--------------------------------------+-------------+-------------------------------------------+-----------------------------+----------------------+---------------------------------+--------------------+----------------------+ .. tab:: nRF7002 DK @@ -28,19 +28,19 @@ Footprint values are provided in kilobytes (KB). +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ | Sample | Total ROM | Wi-Fi driver ROM | nRF70 FW patch ROM | WPA supplicant ROM | Total RAM (incl. static heap) | Wi-Fi driver RAM | WPA supplicant RAM | +===============================================+=============+===========================================+===============================+======================+=================================+====================+======================+ - | :ref:`UDP ` | 502 | 54 | 69 | 178 | 214 | 101 | 13 | + | :ref:`UDP ` | 510 | 3 | 74 | 184 | 212 | 129 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`Station ` | 499 | 53 | 69 | 180 | 254 | 164 | 13 | + | :ref:`Station ` | 532 | 3 | 74 | 187 | 207 | 127 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`AWS IoT ` | 693 | 53 | 69 | 233 | 305 | 101 | 13 | + | :ref:`AWS IoT ` | 712 | 3 | 74 | 239 | 324 | 129 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`CoAP Client ` | 590 | 55 | 69 | 178 | 291 | 170 | 13 | + | :ref:`CoAP Client ` | 601 | 3 | 74 | 184 | 220 | 129 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`HTTP Server ` | 640 | 55 | 69 | 180 | 273 | 121 | 13 | + | :ref:`HTTP Server ` | 665 | 3 | 74 | 186 | 256 | 137 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`HTTPS Client ` | 631 | 54 | 69 | 239 | 281 | 101 | 13 | + | :ref:`HTTPS Client ` | 641 | 3 | 74 | 245 | 302 | 129 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ - | :ref:`MQTT ` | 690 | 55 | 69 | 239 | 309 | 101 | 13 | + | :ref:`MQTT ` | 701 | 3 | 74 | 245 | 320 | 124 | 15 | +-----------------------------------------------+-------------+-------------------------------------------+-------------------------------+----------------------+---------------------------------+--------------------+----------------------+ .. note:: diff --git a/doc/nrf/protocols/zigbee/memory.rst b/doc/nrf/protocols/zigbee/memory.rst index ade92f864cea..55a51e41b002 100644 --- a/doc/nrf/protocols/zigbee/memory.rst +++ b/doc/nrf/protocols/zigbee/memory.rst @@ -38,27 +38,27 @@ Values are provided in kilobytes (KB). +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | Sample | ROM, ZBOSS stack + App | ROM, MCUboot bootloader | ROM, ZBOSS non-volatile memory | ROM, ZBOSS product config | Total ROM | RAM, ZBOSS stack + App | Total RAM | +========================================================================================================================+==========================+===========================+==================================+=============================+=============+==========================+=============+ - | :ref:`Network coordinator ` | 340 | 0 | 32 | 4 | 376 | 72 | 72 | + | :ref:`Network coordinator ` | 339 | 0 | 32 | 4 | 375 | 72 | 72 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light bulb ` | 365 | 0 | 32 | 4 | 401 | 58 | 58 | + | :ref:`Light bulb ` | 363 | 0 | 32 | 4 | 399 | 58 | 58 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` | 284 | 0 | 32 | 4 | 320 | 53 | 53 | + | :ref:`Light switch ` | 282 | 0 | 32 | 4 | 318 | 53 | 53 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | 298 | 48 | 32 | 4 | 382 | 61 | 61 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 396 | 0 | 32 | 4 | 432 | 70 | 70 | + | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 395 | 0 | 32 | 4 | 431 | 69 | 69 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | 411 | 48 | 32 | 4 | 495 | 78 | 78 | + | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | 411 | 48 | 32 | 4 | 495 | 76 | 76 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP ` | 360 | 0 | 32 | 4 | 396 | 84 | 84 | + | :ref:`NCP ` | 358 | 0 | 32 | 4 | 394 | 84 | 84 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP with USB transport ` | 377 | 64 | 32 | 4 | 477 | 93 | 93 | + | :ref:`NCP with USB transport ` | 376 | 64 | 32 | 4 | 476 | 93 | 93 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee application template ` | 340 | 0 | 32 | 4 | 376 | 67 | 67 | + | :ref:`Zigbee application template ` | 338 | 0 | 32 | 4 | 374 | 67 | 67 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell ` | 419 | 0 | 32 | 4 | 455 | 84 | 84 | + | :ref:`Zigbee shell ` | 417 | 0 | 32 | 4 | 453 | 84 | 84 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell over USB ` | 437 | 0 | 32 | 4 | 473 | 93 | 93 | + | :ref:`Zigbee shell over USB ` | 435 | 0 | 32 | 4 | 471 | 93 | 93 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ .. tab:: nRF52833 @@ -68,27 +68,27 @@ Values are provided in kilobytes (KB). +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | Sample | ROM, ZBOSS stack + App | ROM, MCUboot bootloader | ROM, ZBOSS non-volatile memory | ROM, ZBOSS product config | Total ROM | RAM, ZBOSS stack + App | Total RAM | +========================================================================================================================+==========================+===========================+==================================+=============================+=============+==========================+=============+ - | :ref:`Network coordinator ` | 323 | 0 | 16 | 4 | 343 | 67 | 67 | + | :ref:`Network coordinator ` | 322 | 0 | 16 | 4 | 342 | 66 | 66 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light bulb ` | 348 | 0 | 16 | 4 | 368 | 53 | 53 | + | :ref:`Light bulb ` | 346 | 0 | 16 | 4 | 366 | 53 | 53 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` | 267 | 0 | 16 | 4 | 287 | 48 | 48 | + | :ref:`Light switch ` | 265 | 0 | 16 | 4 | 285 | 47 | 47 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 379 | 0 | 16 | 4 | 399 | 65 | 65 | + | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 378 | 0 | 16 | 4 | 398 | 63 | 63 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP ` | 343 | 0 | 16 | 4 | 363 | 79 | 79 | + | :ref:`NCP ` | 341 | 0 | 16 | 4 | 361 | 79 | 79 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP with USB transport ` | 360 | 64 | 16 | 4 | 444 | 88 | 88 | + | :ref:`NCP with USB transport ` | 358 | 64 | 16 | 4 | 442 | 88 | 88 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee application template ` | 323 | 0 | 16 | 4 | 343 | 62 | 62 | + | :ref:`Zigbee application template ` | 321 | 0 | 16 | 4 | 341 | 61 | 61 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell ` | 402 | 0 | 16 | 4 | 422 | 78 | 78 | + | :ref:`Zigbee shell ` | 400 | 0 | 16 | 4 | 420 | 78 | 78 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell over USB ` | 419 | 0 | 16 | 4 | 439 | 88 | 88 | + | :ref:`Zigbee shell over USB ` | 418 | 0 | 16 | 4 | 438 | 88 | 88 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ .. tab:: nRF5340 @@ -100,15 +100,15 @@ Values are provided in kilobytes (KB). +========================================================================================================================+==========================+===========================+==================================+=============================+=============+==========================+=============+ | :ref:`Network coordinator ` | 314 | 0 | 32 | 4 | 350 | 77 | 77 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light bulb ` | 338 | 0 | 32 | 4 | 374 | 64 | 64 | + | :ref:`Light bulb ` | 339 | 0 | 32 | 4 | 375 | 64 | 64 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` | 257 | 0 | 32 | 4 | 293 | 58 | 58 | + | :ref:`Light switch ` | 258 | 0 | 32 | 4 | 294 | 58 | 58 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | 39 | 64 | 32 | 4 | 139 | 24 | 24 | + | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | 274 | 64 | 32 | 4 | 374 | 73 | 73 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 320 | 0 | 32 | 4 | 356 | 75 | 75 | + | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | 322 | 0 | 32 | 4 | 358 | 74 | 74 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | 336 | 64 | 32 | 4 | 436 | 87 | 87 | + | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | 338 | 64 | 32 | 4 | 438 | 88 | 88 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`NCP ` | 332 | 0 | 32 | 4 | 368 | 90 | 90 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ @@ -116,9 +116,9 @@ Values are provided in kilobytes (KB). +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Zigbee application template ` | 313 | 0 | 32 | 4 | 349 | 72 | 72 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell ` | 392 | 0 | 32 | 4 | 428 | 89 | 89 | + | :ref:`Zigbee shell ` | 393 | 0 | 32 | 4 | 429 | 89 | 89 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell over USB ` | 410 | 0 | 32 | 4 | 446 | 98 | 98 | + | :ref:`Zigbee shell over USB ` | 411 | 0 | 32 | 4 | 447 | 98 | 98 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ .. tab:: nRF21540 @@ -128,27 +128,27 @@ Values are provided in kilobytes (KB). +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | Sample | ROM, ZBOSS stack + App | ROM, MCUboot bootloader | ROM, ZBOSS non-volatile memory | ROM, ZBOSS product config | Total ROM | RAM, ZBOSS stack + App | Total RAM | +========================================================================================================================+==========================+===========================+==================================+=============================+=============+==========================+=============+ - | :ref:`Network coordinator ` | 338 | 0 | 32 | 4 | 374 | 72 | 72 | + | :ref:`Network coordinator ` | 337 | 0 | 32 | 4 | 373 | 72 | 72 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light bulb ` | 363 | 0 | 32 | 4 | 399 | 58 | 58 | + | :ref:`Light bulb ` | 362 | 0 | 32 | 4 | 398 | 58 | 58 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` | 282 | 0 | 32 | 4 | 318 | 53 | 53 | + | :ref:`Light switch ` | 281 | 0 | 32 | 4 | 317 | 53 | 53 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | 297 | 48 | 32 | 4 | 381 | 61 | 61 | + | :ref:`Light switch ` with :ref:`lib_zigbee_fota` | 296 | 48 | 32 | 4 | 380 | 61 | 61 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Light switch ` with :ref:`zigbee_light_switch_sample_nus` and :ref:`lib_zigbee_fota` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP ` | 358 | 0 | 32 | 4 | 394 | 84 | 84 | + | :ref:`NCP ` | 356 | 0 | 32 | 4 | 392 | 84 | 84 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP with USB transport ` | 375 | 64 | 32 | 4 | 475 | 93 | 93 | + | :ref:`NCP with USB transport ` | 374 | 64 | 32 | 4 | 474 | 93 | 93 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee application template ` | 338 | 0 | 32 | 4 | 374 | 67 | 67 | + | :ref:`Zigbee application template ` | 336 | 0 | 32 | 4 | 372 | 67 | 67 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell ` | 417 | 0 | 32 | 4 | 453 | 84 | 84 | + | :ref:`Zigbee shell ` | 415 | 0 | 32 | 4 | 451 | 84 | 84 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell over USB ` | 435 | 0 | 32 | 4 | 471 | 93 | 93 | + | :ref:`Zigbee shell over USB ` | 433 | 0 | 32 | 4 | 469 | 93 | 93 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ .. tab:: nRF52840 Dongle @@ -172,13 +172,13 @@ Values are provided in kilobytes (KB). +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`NCP ` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`NCP with USB transport ` | 372 | 4 | 32 | 4 | 412 | 92 | 92 | + | :ref:`NCP with USB transport ` | 370 | 4 | 32 | 4 | 410 | 92 | 92 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Zigbee application template ` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ | :ref:`Zigbee shell ` | n/a | n/a | n/a | n/a | n/a | n/a | n/a | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ - | :ref:`Zigbee shell over USB ` | 430 | 4 | 32 | 4 | 470 | 92 | 92 | + | :ref:`Zigbee shell over USB ` | 429 | 4 | 32 | 4 | 469 | 91 | 91 | +------------------------------------------------------------------------------------------------------------------------+--------------------------+---------------------------+----------------------------------+-----------------------------+-------------+--------------------------+-------------+ .. @@ -203,11 +203,11 @@ Values are provided in bytes (B). +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ | Sample | ``main`` thread stack usage | ``main`` thread stack size | ``zboss`` thread stack usage | ``zboss`` thread stack size | +================================================================+===============================+==============================+================================+===============================+ - | :ref:`Network coordinator ` | 688 | 2048 | 984 | 2048 | + | :ref:`Network coordinator ` | 688 | 2048 | 968 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ - | :ref:`Light bulb ` | 688 | 2048 | 984 | 2048 | + | :ref:`Light bulb ` | 688 | 2048 | 968 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ - | :ref:`Light switch ` | 672 | 2048 | 984 | 2048 | + | :ref:`Light switch ` | 672 | 2048 | 968 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ .. tab:: nRF53 Series @@ -219,7 +219,7 @@ Values are provided in bytes (B). +================================================================+===============================+==============================+================================+===============================+ | :ref:`Network coordinator ` | 756 | 2048 | 980 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ - | :ref:`Light bulb ` | 756 | 2048 | 1020 | 2048 | + | :ref:`Light bulb ` | 756 | 2048 | 980 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ | :ref:`Light switch ` | 756 | 2048 | 980 | 2048 | +----------------------------------------------------------------+-------------------------------+------------------------------+--------------------------------+-------------------------------+ diff --git a/doc/nrf/releases_and_maturity.rst b/doc/nrf/releases_and_maturity.rst index b492d6eda2d4..1f2f92ae00d2 100644 --- a/doc/nrf/releases_and_maturity.rst +++ b/doc/nrf/releases_and_maturity.rst @@ -28,3 +28,4 @@ If an issue is found in a release after it has taken place, those issues are lis releases_and_maturity/repository_revisions releases_and_maturity/software_maturity releases_and_maturity/abi_compatibility + releases_and_maturity/known_issues diff --git a/doc/nrf/releases_and_maturity/abi_compatibility.rst b/doc/nrf/releases_and_maturity/abi_compatibility.rst index 420cf9df5798..a04adf036ee7 100644 --- a/doc/nrf/releases_and_maturity/abi_compatibility.rst +++ b/doc/nrf/releases_and_maturity/abi_compatibility.rst @@ -28,6 +28,9 @@ The following table illustrates ABI compatibility between different versions of * - |NCS| versions - Compatible nRF54H20 SoC binaries version + * - |NCS| v2.8.0 + - `nRF54H20 SoC Binaries v0.7.0 for EngC DKs`_, compatible with the nRF54H20 DK v0.8.3 and later revisions. + `nRF54H20 SoC Binaries v0.7.0 for EngB DKs`_, compatible with the nRF54H20 DKs ranging from v0.8.0 to v0.8.2. * - |NCS| v2.7.99-cs2 - `nRF54H20 SoC Binaries v0.6.5`_ * - |NCS| v2.7.99-cs1 diff --git a/doc/nrf/releases_and_maturity/known_issues.rst b/doc/nrf/releases_and_maturity/known_issues.rst index 1d0b3f6795c1..a50e6e7929b4 100644 --- a/doc/nrf/releases_and_maturity/known_issues.rst +++ b/doc/nrf/releases_and_maturity/known_issues.rst @@ -1,5 +1,3 @@ -:orphan: - .. _known_issues: Known issues diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_1.x_to_2.x.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_1.x_to_2.x.rst index a70e4ccbabe4..d58b1e5db81a 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_1.x_to_2.x.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_1.x_to_2.x.rst @@ -1,5 +1,3 @@ -:orphan: - .. _ncs_2.0.0_migration: Migration notes for |NCS| v2.0.0 diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.4.99-cs3_to_2.6.99-cs2.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.4.99-cs3_to_2.6.99-cs2.rst index 2fb0f6413515..a5791574fac8 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.4.99-cs3_to_2.6.99-cs2.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.4.99-cs3_to_2.6.99-cs2.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_cs3_to_2_6_99_cs2: Migration notes for |NCS| v2.6.99_cs2 for v2.4.99-cs3 users diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.5.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.5.rst index b2cac995fd0b..b7f4539c88be 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.5.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.5.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_2.5: Migration guide for |NCS| v2.5.0 diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.6.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.6.rst index a74ee2b8c93f..86f04155e708 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.6.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.6.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_2.6: Migration guide for |NCS| v2.6.0 diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst index fea0e6e69baf..6921ef6bee69 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_2.7: Migration guide for |NCS| v2.7.0 diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.8.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.8.rst index 65ceecc9665b..57c4ee5bcec3 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.8.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.8.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_2.8: Migration guide for |NCS| v2.8.0 (Working draft) @@ -23,6 +21,170 @@ This document describes the changes required or recommended when migrating your * Change1 and description * Change2 and description +.. _migration_2.8_nrf54h: + +nRF54H20 +******** + +This section describes the changes specific to the nRF54H20 SoC and DK support in the |NCS|. + +DK compatibility +================ + +.. toggle:: + + * The |NCS| v2.8.0 is compatible only with the following versions of the nRF54H20 DK, PCA10175: + + * Engineering B - versions ranging from v0.8.0 to 0.8.2 + * Engineering C - v0.8.3 and later revisions + + Check the version number on your DK's sticker to verify its compatibility with the |NCS|. + +Dependencies +============ + +The following required dependencies for the nRF54H20 SoC and DK have been updated. + +nRF54H20 BICR +------------- + +.. toggle:: + + * The nRF54H20 BICR has been updated (from the one supporting |NCS| v2.7.0). + + .. note:: + BICR update is not required if migrating from |NCS| v2.7.99-cs1 or v2.7.99-cs2. + + To update the BICR of your development kit while in Root of Trust, do the following: + + 1. Download the `BICR new binary file`_. + #. Connect the nRF54H20 DK to your computer using the **DEBUGGER** port on the DK. + + .. note:: + On MacOS, connecting the DK might repeatedly trigger a popup displaying the message ``Disk Not Ejected Properly``. + To disable this, run ``JLinkExe``, then run ``MSDDisable`` in the J-Link Commander interface. + + #. List all the connected development kits to see their serial number (matching the one on the DK's sticker):: + + nrfutil device list + + #. Move the BICR HEX file to a folder of your choice, then program the BICR by running nRF Util from that folder using the following command:: + + nrfutil device program --options chip_erase_mode=ERASE_NONE --firmware --core Application --serial-number + +nRF54H20 SoC binaries +--------------------- + +.. toggle:: + + * The *nRF54H20 SoC binaries* bundle has been updated to version 0.7.0. + + .. caution:: + If migrating from |NCS| v2.7.0, before proceeding with the SoC binaries update, you must first update the BICR as described in the previous section. + + To update the SoC binaries bundle of your development kit while in Root of Trust, do the following: + + 1. Download the nRF54H20 SoC binaries v0.7.0: + + * `nRF54H20 SoC Binaries v0.7.0 for EngC DKs`_, compatible with the nRF54H20 DK v0.8.3 and later revisions + * `nRF54H20 SoC Binaries v0.7.0 for EngB DKs`_, compatible with the nRF54H20 DKs ranging from v0.8.0 to v0.8.2. + + .. note:: + On MacOS, ensure that the ZIP file is not unpacked automatically upon download. + + #. Purge the device as follows:: + + nrfutil device recover --core Application --serial-number + nrfutil device recover --core Network --serial-number + + #. Run ``west update``. + #. Move the correct :file:`.zip` bundle to a folder of your choice, then run nRF Util to program the binaries using one of the following commands, depending on your DK: + + * For Engineering B:: + + nrfutil device x-suit-dfu --firmware nrf54h20_soc_binaries_v0.7.0_.zip --serial-number + + * For Engineering C:: + + nrfutil device x-suit-dfu --firmware nrf54h20_soc_binaries_v0.7.0_.zip --serial-number --update-candidate-info-address 0x0e1ef340 + +nrfutil device +-------------- + +.. toggle:: + + * ``nrfutil device`` has been updated to version 2.7.2. + + Install the nRF Util ``device`` command version 2.7.2 as follows:: + + nrfutil install device=2.7.2 --force + + For more information, consult the `nRF Util`_ documentation. + +nrfutil-trace +------------- + +.. toggle:: + + * ``nrfutil-trace`` has been updated to version 2.11.0. + + Install the nRF Util ``trace`` command version 2.11.0 as follows:: + + nrfutil install trace=2.11.0 --force + + For more information, consult the `nRF Util`_ documentation. + +nrf-regtool +----------- + +.. toggle:: + + * ``nrf-regtool`` has been updated to version 7.0.0. + + 1. Open nRF Connect for Desktop, navigate to the Toolchain Manager, select the v2.7.99-cs2 toolchain, and click the :guilabel:`Open terminal` button. + #. In the terminal window, install ``nrf-regtool`` version 7.0.0 as follows:: + + pip install nrf-regtool==7.0.0 + + +SEGGER J-Link +------------- + +.. toggle:: + + * A new version of SEGGER J-Link is supported: `SEGGER J-Link` version 7.94i. + + .. note:: + On Windows, to update to the new J-link version, including the USB Driver for J-Link, you must manually install J-Link v7.94i from the command line, using the ``-InstUSBDriver=1`` parameter: + + 1. Navigate to the download location of the J-Link executable and run one of the following commands: + + * From the Command Prompt:: + + JLink_Windows_V794i_x86_64.exe -InstUSBDriver=1 + + * From PowerShell:: + + .\JLink_Windows_V794i_x86_64.exe -InstUSBDriver=1 + + #. In the :guilabel:`Choose optional components` window, select :guilabel:`update existing installation`. + #. Add the J-Link executable to the system path on Linux and MacOS, or to the environment variables on Windows, to run it from anywhere on the system. + + * The STM logging feature for the nRF54H20 SoC was tested using the J-Trace PRO V2 Cortex-M, with firmware compiled on ``Mar 28 2024 15:14:04``. + Using this feature also requires ``nrfutil-trace`` version 2.10.0 or later. + +nRF Connect Device Manager +-------------------------- + +.. toggle:: + + * The nRF54H20 SUIT DFU feature now requires `nRF Connect Device Manager`_ version v2.2.2 or higher. + +Samples and applications +======================== + +For more information on changes related to samples and applications usage on the nRF54H20 DK, see :ref:`migration_2.8_required_nrf54h`. + .. _migration_2.8_required: Required changes @@ -35,6 +197,14 @@ Samples and applications This section describes the changes related to samples and applications. +nRF54L Series +------------- + +.. toggle:: + + * Use the :ref:`ZMS (Zephyr Memory Storage) ` storage system for all devices with RRAM memory technology, such as the nRF54L Series devices. + See the :ref:`memory_storage` page for more details on how to enable ZMS for the nRF54L Series devices. + Serial LTE Modem (SLM) ---------------------- @@ -55,12 +225,17 @@ Serial LTE Modem (SLM) * ``AT#XSOCKETOPT=1,53,`` with ``AT#XSOCKETOPT=1,61,4`` to indicate ``RAI_ONGOING``. * ``AT#XSOCKETOPT=1,54,`` with ``AT#XSOCKETOPT=1,61,5`` to indicate ``RAI_WAIT_MORE``. -SUIT DFU for nRF54H20 ---------------------- +.. _migration_2.8_required_nrf54h: + +nRF54H20 +-------- .. toggle:: - * The manifest sequence number is no longer configured through a :ref:`sysbuild ` Kconfig option. + * When using the nRF54H20 DK Engineering B (from v0.8.0 to 0.8.2), you must build samples and applications using the board revision 0.8.0 with the ``@`` syntax. + For example , ``nrf54h20dk@0.8.0/nrf54h20/cpuapp`` when building for the application core, or ``nrf54h20dk@0.8.0/nrf54h20/cpurad`` when building for the radio core. + + * When using SUIT DFU on the nRF54H20 SoC, the manifest sequence number is no longer configured through a :ref:`sysbuild ` Kconfig option. The values are now read from the :file:`VERSION` file, used for :ref:`zephyr:app-version-details` in Zephyr and the |NCS|. This change to the :ref:`sysbuild ` Kconfig option requires the following updates in the SUIT templates for your project: @@ -84,6 +259,15 @@ SUIT DFU for nRF54H20 For the list of all variables, set through the :file:`VERSION`, refer to the :ref:`ug_nrf54h20_suit_customize_dfu`. + * When using MCU Manager, the ``Confirm`` command is now needed to trigger a device firmware update. + * The build command to enable DFU from the external flash is now the following:: + + west build ./ -b nrf54h20dk/nrf54h20/cpuapp -T sample.suit.smp_transfer.cache_push.extflash.bt + + * For updating using the SUIT Device Manager application, you can also use the following zip file: :file:`/zephyr/dfu_suit_recovery.zip`. + * Some Kconfig options and SUIT manifests have been modified, changing names and configurations. + Ensure the compatibility of your application with these changes. + Nordic Secure Immutable Bootloader (NSIB, B0, or B0n) ----------------------------------------------------- @@ -125,6 +309,19 @@ Libraries This section describes the changes related to libraries. +Wi-Fi® +------ + +.. toggle:: + + * For :ref:`lib_wifi_credentials` library: + + * Syntax for ``add`` command has been modified to support ``getopt`` model. + For example, the following command with old syntax: + ``wifi_cred add SSID WPA2-PSK password`` should be replaced with the following command with new syntax: + ``wifi_cred add -s SSID -k 1 -p password``. + ``wifi_cred add --help`` command will provide more information on the new syntax. + LTE link control library ------------------------ diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7.rst index 74fe158b2745..faeeff027ef1 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_nrf54h20_to_2.7: Migration notes for |NCS| v2.7.0 and the nRF54H20 DK diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs1.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs1.rst index 1885f9f2a449..615f6086bf7c 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs1.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs1.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_nrf54h20_to_2.7.99-cs1: Migration notes for |NCS| v2.7.99-cs1 and the nRF54H20 DK diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs2.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs2.rst index 882d359fac3d..fdc471bc30c7 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs2.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_nRF54H20_cs_to_2_7_99-cs2.rst @@ -1,5 +1,3 @@ -:orphan: - .. _migration_nrf54h20_to_2.7.99-cs2: Migration notes for |NCS| v2.7.99-cs2 and the nRF54H20 DK diff --git a/doc/nrf/releases_and_maturity/migration/migration_hwmv2.rst b/doc/nrf/releases_and_maturity/migration/migration_hwmv2.rst index a0e50e87b666..c8721e98a065 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_hwmv2.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_hwmv2.rst @@ -1,5 +1,3 @@ -:orphan: - .. _hwmv1_to_v2_migration: Migrating to the current hardware model diff --git a/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst b/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst index c191a9593a54..8196089eeb73 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst @@ -1,5 +1,3 @@ -:orphan: - .. _child_parent_to_sysbuild_migration: Migrating from multi-image builds to sysbuild diff --git a/doc/nrf/releases_and_maturity/migration_guides.rst b/doc/nrf/releases_and_maturity/migration_guides.rst index 19be4b4d05af..d169e313c883 100644 --- a/doc/nrf/releases_and_maturity/migration_guides.rst +++ b/doc/nrf/releases_and_maturity/migration_guides.rst @@ -9,17 +9,10 @@ Migration guides are also provided for major functionality updates. .. note:: |migration_contact_devzone| -* `Migrating from multi-image builds to sysbuild`_ -* `Migrating to the current hardware model`_ -* `Migration guide for nRF Connect SDK v2.8.0 (Working draft) `_ -* `Migration guide for nRF Connect SDK v2.7.0`_ -* `Migration guide for nRF Connect SDK v2.6.0`_ -* `Migration guide for nRF Connect SDK v2.5.0`_ -* `Migration guide for nRF Connect SDK v2.0.0`_ +.. toctree:: + :maxdepth: 1 + :glob: + :reversed: + :caption: Subpages: -For nRF54H20 customer sampling participants: - -* `Migration notes for nRF Connect SDK v2.7.99-cs2 and the nRF54H20 DK`_ -* `Migration notes for nRF Connect SDK v2.7.99-cs1 and the nRF54H20 DK`_ -* `Migration notes for nRF Connect SDK v2.7.0 for nRF54H20 DK users`_ -* `Migration guide for nRF Connect SDK v2.6.99_cs2 for v2.4.99-cs3 users`_ + migration/* 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 3cb0cc84bafa..7cb144fd8129 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst @@ -1,7 +1,7 @@ .. _ncs_release_notes_changelog: -Changelog for |NCS| v2.8.0-preview1 -################################### +Changelog for |NCS| v2.7.99 +########################### .. contents:: :local: @@ -285,7 +285,7 @@ Thread Zigbee ------ -|no_changes_yet_note| +* Fixed the :file:`zb_add_ota_header.py` script not being able to handle an ``APPLICATION_VERSION_STRING`` which includes a tweak, such as ``1.0.0+3``. Wi-Fi ----- @@ -435,7 +435,7 @@ Bluetooth samples * The :ref:`ble_radio_notification_conn_cb` sample demonstrating how to use the :ref:`ug_radio_notification_conn_cb` feature. * The :ref:`bluetooth_conn_time_synchronization` sample demonstrating microsecond-accurate synchronization of connections that are happening over Bluetooth® Low Energy Asynchronous Connection-oriented Logical transport (ACL). * The :ref:`ble_subrating` sample that showcases the effect of the LE Connection Subrating feature on the duty cycle of a connection. - * The :ref:`broadcast_configuration_tool` sample that implements the :ref:`BIS gateway mode ` and may act as an `Auracastâ„¢`_ broadcaster if you are using a preset compatible with Auracast. + * The :ref:`nrf_auraconfig` sample that implements the :ref:`BIS gateway mode ` and may act as an `Auracastâ„¢`_ broadcaster if you are using a preset compatible with Auracast. * Support for the :ref:`zephyr:nrf54l15dk_nrf54l15` board in the following samples: * :ref:`central_bas` diff --git a/doc/nrf/releases_and_maturity/software_maturity.rst b/doc/nrf/releases_and_maturity/software_maturity.rst index ec430ed3caac..debee9c0f820 100644 --- a/doc/nrf/releases_and_maturity/software_maturity.rst +++ b/doc/nrf/releases_and_maturity/software_maturity.rst @@ -197,7 +197,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -211,7 +211,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -253,7 +253,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -267,7 +267,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -281,7 +281,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -349,10 +349,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -377,10 +377,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -391,10 +391,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -405,10 +405,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -419,10 +419,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -433,10 +433,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental - - Experimental + - Supported + - Supported - -- - - Experimental + - Supported - -- - -- - -- @@ -467,62 +467,313 @@ The following table indicates the software maturity levels of the support for ea - nRF9151 - nRF9160 - nRF9161 - * - **Bluetooth LE Peripheral/Central** + * - **2 Mbps PHY** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Coded PHY (Long Range)** + - -- + - Supported + - Supported + - -- + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Concurrent Roles**\ :sup:`1` + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Data Length Extensions** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Advertising Extensions** + - Supported + - Supported + - Supported + - Supported + - Supported - Supported - Supported - Experimental - Supported + - -- + - -- + - -- + - -- + * - **Periodic Advertising with Responses** + - Supported + - Supported + - Supported + - Supported - Supported - Supported - Supported - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Periodic Advertising Sync Transfer** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported - Experimental + - Supported - -- - -- - -- - -- - * - **Connectionless/Connected CTE Transmitter** + * - **Isochronous Channels** + - Supported\ :sup:`2` + - Supported\ :sup:`2` + - Supported + - Supported\ :sup:`2` + - Supported + - Supported\ :sup:`2` + - Supported + - Experimental + - Supported + - -- + - -- - -- + - -- + * - **Direction Finding**\ :sup:`3` + - -- + - Supported - Supported + - -- + - Supported + - -- + - Supported + - Experimental - Experimental - -- + - -- + - -- + - -- + * - **LE Power Control** + - Supported + - Supported + - Supported + - Supported - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- - -- + - -- + * - **Connection Subrating** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported - Supported - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Channel Sounding** + - -- + - -- + - -- + - -- + - -- + - -- + - -- + - -- - Experimental - -- - -- - -- - -- - * - **LE Coded PHY** + * - **GATT Database Hash** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- - -- + * - **Enhanced ATT** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported - Supported - Experimental + - Supported + - -- + - -- - -- + - -- + * - **L2CAP Connection Oriented Channels** + - Supported + - Supported + - Supported + - Supported - Supported - Supported - Supported - Experimental + - Supported + - -- + - -- + - -- + - -- + + | [1]: Concurrent central, observer, peripheral, and broadcaster roles with up to 20 concurrent connections along with one Observer and one Broadcaster (subject to RAM availability) + | [2]: Do not support encrypting and decrypting the Isochronous Channels packets + | [3]: Only AoA transmitter is supported + +The following table indicates the software maturity levels of the support for each proprietary Bluetooth feature: + +.. toggle:: + + .. list-table:: + :widths: auto + :header-rows: 1 + + * - + - nRF52810 + - nRF52811 + - nRF52820 + - nRF52832 + - nRF52833 + - nRF52840 + - nRF5340 + - nRF54H20 + - nRF54L15 + - nRF9131 + - nRF9151 + - nRF9160 + - nRF9161 + * - **Low Latency Packet Mode** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - -- - Experimental + - Supported - -- - -- - -- - -- - * - **LLPM** + * - **Multi-protocol Support** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- - -- - -- - -- + * - **QoS Conn Event Reports** + - Supported + - Supported + - Supported - Supported - Supported - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- - -- + * - **QoS Channel Survey** + - Experimental + - Experimental + - Experimental + - Experimental + - Experimental + - Experimental + - Experimental - Experimental - Experimental - -- - -- - -- - -- + * - **Radio Coexistence** + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Supported + - Experimental + - Supported + - -- + - -- + - -- + - -- Thread features support *********************** @@ -572,7 +823,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -586,7 +837,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -600,7 +851,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -614,7 +865,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -628,7 +879,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -642,7 +893,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -656,7 +907,21 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental + - Supported + - -- + - -- + - -- + - -- + * - **Thread 1.4 - Core** + - -- + - -- + - -- + - -- + - Supported + - Supported + - Supported - Experimental + - Supported - -- - -- - -- @@ -670,7 +935,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -684,7 +949,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -698,7 +963,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - -- - -- - - Experimental + - Supported - -- - -- - -- @@ -709,10 +974,10 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- + - Supported + - Supported - Experimental - - Experimental - - Experimental - - Experimental + - Supported - -- - -- - -- @@ -754,7 +1019,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -768,7 +1033,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -782,7 +1047,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -796,7 +1061,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -810,7 +1075,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -824,7 +1089,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Supported - Experimental - - Experimental + - Supported - -- - -- - -- @@ -851,8 +1116,8 @@ The following table indicates the software maturity levels of the support for ea - -- - Supported - Supported - - Supported - Experimental + - Supported - -- - -- - -- @@ -1042,7 +1307,7 @@ The following table indicates the software maturity levels of the support for ea - -- - -- - -- - - Experimental\ :sup:`2` + - Supported\ :sup:`2` - -- - -- - -- @@ -1123,8 +1388,8 @@ The following table indicates the software maturity levels of the support for ea | [1]: Only with nRF7002 DK, nRF7002 DK in nRF7001 emulation mode, nRF7002 EB, nRF7002 EK or nRF7002 EK in nRF7001 emulation mode | [2]: Only with nRF7002 DK, nRF7002 DK in nRF7001 emulation mode or nRF7002 EK | [3]: Only with nRF7002 EK or nRF7002 EK in nRF7001 emulation mode - | [4]: Only with nRF700X_nRF54H20DK - | [5]: Only with nRF700X_nRF54L15PDK + | [4]: Only with nrf7002 EB and nRF7002 EB-interposer + | [5]: Only with nrf7002 EB and nRF7002 EB-interposer | [6]: Only with nRF7002 EK, nRF7002 EK in nRF7000 emulation mode or nRF7002 EK in nRF7001 emulation mode | [7]: Only with nRF7002 DK, nRF7002 EB, nRF7002 EK, nRF7002 EK in nRF7000 emulation mode or nRF7002 EK in nRF7001 emulation mode @@ -1189,7 +1454,7 @@ The following table indicates the software maturity levels of the support for Go - Supported - Experimental - -- - - Experimental + - Supported - -- - -- - -- @@ -1229,7 +1494,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Experimental - -- - - Experimental + - Supported - -- - -- - -- @@ -1285,7 +1550,7 @@ The following table indicates the software maturity levels of the support for ea - Supported - Experimental - -- - - Experimental + - Supported - -- - -- - -- @@ -1307,52 +1572,54 @@ Trusted Firmware-M support .. toggle:: - .. list-table:: - :widths: auto - :header-rows: 1 - - * - - - nRF52810 - - nRF52811 - - nRF52820 - - nRF52832 - - nRF52833 - - nRF52840 - - nRF5340 - - nRF54H20 - - nRF54L15 - - nRF9131 - - nRF9151 - - nRF9160 - - nRF9161 - * - **Full build** - - -- - - -- - - -- - - -- - - -- - - -- - - Experimental - - -- - - Experimental - - -- - - Experimental - - Experimental - - Experimental - * - **Minimal Build** - - -- - - -- - - -- - - -- - - -- - - -- - - Supported - - -- - - -- - - Experimental - - Supported - - Supported - - Supported + .. list-table:: + :widths: auto + :header-rows: 1 + + * - + - nRF52810 + - nRF52811 + - nRF52820 + - nRF52832 + - nRF52833 + - nRF52840 + - nRF5340 + - nRF54H20 + - nRF54L15 + - nRF9131 + - nRF9151 + - nRF9160 + - nRF9161 + * - **Full build** + - -- + - -- + - -- + - -- + - -- + - -- + - Experimental + - -- + - Experimental\ :sup:`1` + - -- + - Experimental + - Experimental + - Experimental + * - **Minimal Build** + - -- + - -- + - -- + - -- + - -- + - -- + - Supported + - -- + - Experimental + - Experimental + - Supported + - Supported + - Supported + + | [1]: The attestation service is not supported. PSA Crypto support ================== @@ -1377,7 +1644,7 @@ PSA Crypto support - nRF9151 - nRF9160 - nRF9161 - * - **PSA Crypto APIs** + * - **Oberon PSA core** - -- - -- - -- @@ -1385,12 +1652,40 @@ PSA Crypto support - Supported - Supported - Supported + - -- + - Supported - Experimental + - Supported + - Supported + - Supported + * - **TF-M crypto service** + - -- + - -- + - -- + - Supported + - Supported + - Supported + - Supported + - -- - Experimental - Experimental - Supported - Supported - Supported + * - **SSF crypto service** + - -- + - -- + - -- + - -- + - -- + - -- + - -- + - Experimental + - -- + - -- + - -- + - -- + - -- |NSIB| ====== @@ -1471,6 +1766,8 @@ Hardware Unique Key Trusted storage =============== +Trusted storage implements the PSA Certified Secure Storage APIs without TF-M. + .. toggle:: .. list-table:: @@ -1491,7 +1788,7 @@ Trusted storage - nRF9151 - nRF9160 - nRF9161 - * - **Trusted storage implements the PSA Certified Secure Storage APIs without TF-M** + * - **Trusted storage** - -- - -- - -- @@ -1500,7 +1797,7 @@ Trusted storage - Supported - Supported - Experimental - - Experimental + - Supported - -- - Supported - Supported diff --git a/doc/nrf/scripts.rst b/doc/nrf/scripts.rst index 97634c77be0e..f7b66c709071 100644 --- a/doc/nrf/scripts.rst +++ b/doc/nrf/scripts.rst @@ -15,6 +15,7 @@ Here you can find documentation for these scripts. ../../scripts/shell/*/* ../../scripts/nrf_provision/*/* ../../scripts/hid_configurator/* + ../../scripts/docker/* ../../scripts/partition_manager/* ../../scripts/west_commands/sbom/* ../../scripts/memfault/* diff --git a/doc/nrf/shortcuts.txt b/doc/nrf/shortcuts.txt index 9040b87667e8..657831af3764 100644 --- a/doc/nrf/shortcuts.txt +++ b/doc/nrf/shortcuts.txt @@ -89,8 +89,8 @@ .. ### Zigbee & ZBOSS shortcuts .. |zigbee_version| replace:: Zigbee 3.0 -.. |zboss_version| replace:: 3.11.4.0 -.. |zigbee_ncp_package_version| replace:: 2.2.3 +.. |zboss_version| replace:: 3.11.5.0 +.. |zigbee_ncp_package_version| replace:: 2.2.4 .. |zigbee_description| replace:: Zigbee is a portable, low-power software networking protocol that provides connectivity over an 802.15.4-based mesh network. .. |enable_zigbee_before_testing| replace:: Make sure to configure the Zigbee stack before building and testing this sample. See :ref:`ug_zigbee_configuring` for more information. diff --git a/doc/nrfxlib/nrfxlib.doxyfile.in b/doc/nrfxlib/nrfxlib.doxyfile.in index 58339bf57cb2..a36f884c929c 100644 --- a/doc/nrfxlib/nrfxlib.doxyfile.in +++ b/doc/nrfxlib/nrfxlib.doxyfile.in @@ -962,11 +962,7 @@ WARN_LOGFILE = # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING # Note: If this tag is empty the current directory is searched. -INPUT = @DOCSET_SOURCE_BASE@ \ - @DOCSET_SOURCE_BASE@/nrf_wifi/fw_if/umac_if/inc/fmac_api_common.h \ - @DOCSET_SOURCE_BASE@/nrf_wifi/fw_if/umac_if/inc/fmac_structs_common.h \ - @DOCSET_SOURCE_BASE@/nrf_wifi/fw_if/umac_if/inc/default \ - @DOCSET_SOURCE_BASE@/nrf_wifi/fw_if/umac_if/inc/radio_test/fmac_api.h +INPUT = @DOCSET_SOURCE_BASE@ # This tag can be used to specify the character encoding of the source files # that Doxygen parses. Internally Doxygen uses the UTF-8 encoding. Doxygen uses diff --git a/doc/wifi/wifi.doxyfile.in b/doc/wifi/wifi.doxyfile.in new file mode 100644 index 000000000000..a7a329491b2e --- /dev/null +++ b/doc/wifi/wifi.doxyfile.in @@ -0,0 +1,2876 @@ +# Doxyfile 1.12.0 + +# This file describes the settings to be used by the documentation system +# Doxygen (www.doxygen.org) for a project. +# +# All text after a double hash (##) is considered a comment and is placed in +# front of the TAG it is preceding. +# +# All text after a single hash (#) is considered a comment and will be ignored. +# The format is: +# TAG = value [value, ...] +# For lists, items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (\" \"). +# +# Note: +# +# Use Doxygen to compare the used configuration file with the template +# configuration file: +# doxygen -x [configFile] +# Use Doxygen to compare the used configuration file with the template +# configuration file without replacing the environment variables or CMake type +# replacement variables: +# doxygen -x_noenv [configFile] + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# This tag specifies the encoding used for all characters in the configuration +# file that follow. The default is UTF-8 which is also the encoding used for all +# text before the first occurrence of this tag. Doxygen uses libiconv (or the +# iconv built into libc) for the transcoding. See +# https://www.gnu.org/software/libiconv/ for the list of possible encodings. +# The default value is: UTF-8. + +DOXYFILE_ENCODING = UTF-8 + +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by +# double-quotes, unless you are using Doxywizard) that should identify the +# project for which the documentation is generated. This name is used in the +# title of most generated pages and in a few other places. +# The default value is: My Project. + +PROJECT_NAME = "nRF WiFi" + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. This +# could be handy for archiving the generated documentation or if some version +# control system is used. + +PROJECT_NUMBER = @DOCSET_VERSION@ + +# Using the PROJECT_BRIEF tag one can provide an optional one line description +# for a project that appears at the top of each page and should give viewer a +# quick idea about the purpose of the project. Keep the description short. + +PROJECT_BRIEF = + +# With the PROJECT_LOGO tag one can specify a logo or an icon that is included +# in the documentation. The maximum height of the logo should not exceed 55 +# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy +# the logo to the output directory. + +PROJECT_LOGO = @NRF_BASE@/doc/_doxygen/logo.png + +# With the PROJECT_ICON tag one can specify an icon that is included in the tabs +# when the HTML document is shown. Doxygen will copy the logo to the output +# directory. + +PROJECT_ICON = + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path +# into which the generated documentation will be written. If a relative path is +# entered, it will be relative to the location where Doxygen was started. If +# left blank the current directory will be used. + +OUTPUT_DIRECTORY = @DOCSET_BUILD_DIR@ + +# If the CREATE_SUBDIRS tag is set to YES then Doxygen will create up to 4096 +# sub-directories (in 2 levels) under the output directory of each output format +# and will distribute the generated files over these directories. Enabling this +# option can be useful when feeding Doxygen a huge amount of source files, where +# putting all generated files in the same directory would otherwise causes +# performance problems for the file system. Adapt CREATE_SUBDIRS_LEVEL to +# control the number of sub-directories. +# The default value is: NO. + +CREATE_SUBDIRS = NO + +# Controls the number of sub-directories that will be created when +# CREATE_SUBDIRS tag is set to YES. Level 0 represents 16 directories, and every +# level increment doubles the number of directories, resulting in 4096 +# directories at level 8 which is the default and also the maximum value. The +# sub-directories are organized in 2 levels, the first level always has a fixed +# number of 16 directories. +# Minimum value: 0, maximum value: 8, default value: 8. +# This tag requires that the tag CREATE_SUBDIRS is set to YES. + +CREATE_SUBDIRS_LEVEL = 8 + +# If the ALLOW_UNICODE_NAMES tag is set to YES, Doxygen will allow non-ASCII +# characters to appear in the names of generated files. If set to NO, non-ASCII +# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode +# U+3044. +# The default value is: NO. + +ALLOW_UNICODE_NAMES = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by Doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Bulgarian, +# Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, English +# (United States), Esperanto, Farsi (Persian), Finnish, French, German, Greek, +# Hindi, Hungarian, Indonesian, Italian, Japanese, Japanese-en (Japanese with +# English messages), Korean, Korean-en (Korean with English messages), Latvian, +# Lithuanian, Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, +# Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, +# Swedish, Turkish, Ukrainian and Vietnamese. +# The default value is: English. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES, Doxygen will include brief member +# descriptions after the members that are listed in the file and class +# documentation (similar to Javadoc). Set to NO to disable this. +# The default value is: YES. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES, Doxygen will prepend the brief +# description of a member or function before the detailed description +# +# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. +# The default value is: YES. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator that is +# used to form the text in various listings. Each string in this list, if found +# as the leading text of the brief description, will be stripped from the text +# and the result, after processing the whole list, is used as the annotated +# text. Otherwise, the brief description is used as-is. If left blank, the +# following values are used ($name is automatically replaced with the name of +# the entity):The $name class, The $name widget, The $name file, is, provides, +# specifies, contains, represents, a, an and the. + +ABBREVIATE_BRIEF = "The $name class" \ + "The $name widget" \ + "The $name file" \ + is \ + provides \ + specifies \ + contains \ + represents \ + a \ + an \ + the + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. +# The default value is: NO. + +ALWAYS_DETAILED_SEC = YES + +# If the INLINE_INHERITED_MEMB tag is set to YES, Doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. +# The default value is: NO. + +INLINE_INHERITED_MEMB = YES + +# If the FULL_PATH_NAMES tag is set to YES, Doxygen will prepend the full path +# before files name in the file list and in the header files. If set to NO the +# shortest path that makes the file name unique will be used +# The default value is: YES. + +FULL_PATH_NAMES = YES + +# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. +# Stripping is only done if one of the specified strings matches the left-hand +# part of the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which Doxygen is run is used as the path to +# strip. +# +# Note that you can specify absolute paths here, but also relative paths, which +# will be relative from the directory where Doxygen is started. +# This tag requires that the tag FULL_PATH_NAMES is set to YES. + +STRIP_FROM_PATH = @DOCSET_SOURCE_BASE@/drivers/nrf_wifi + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the +# path mentioned in the documentation of a class, which tells the reader which +# header file to include in order to use a class. If left blank only the name of +# the header file containing the class definition is used. Otherwise one should +# specify the list of include paths that are normally passed to the compiler +# using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, Doxygen will generate much shorter (but +# less readable) file names. This can be useful is your file systems doesn't +# support long names like on DOS, Mac, or CD-ROM. +# The default value is: NO. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen will interpret the +# first line (until the first dot) of a Javadoc-style comment as the brief +# description. If set to NO, the Javadoc-style will behave just like regular Qt- +# style comments (thus requiring an explicit @brief command for a brief +# description.) +# The default value is: NO. + +JAVADOC_AUTOBRIEF = NO + +# If the JAVADOC_BANNER tag is set to YES then Doxygen will interpret a line +# such as +# /*************** +# as being the beginning of a Javadoc-style comment "banner". If set to NO, the +# Javadoc-style will behave just like regular comments and it will not be +# interpreted by Doxygen. +# The default value is: NO. + +JAVADOC_BANNER = NO + +# If the QT_AUTOBRIEF tag is set to YES then Doxygen will interpret the first +# line (until the first dot) of a Qt-style comment as the brief description. If +# set to NO, the Qt-style will behave just like regular Qt-style comments (thus +# requiring an explicit \brief command for a brief description.) +# The default value is: NO. + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen treat a +# multi-line C++ special comment block (i.e. a block of //! or /// comments) as +# a brief description. This used to be the default behavior. The new default is +# to treat a multi-line C++ comment block as a detailed description. Set this +# tag to YES if you prefer the old behavior instead. +# +# Note that setting this tag to YES also means that rational rose comments are +# not recognized any more. +# The default value is: NO. + +MULTILINE_CPP_IS_BRIEF = NO + +# By default Python docstrings are displayed as preformatted text and Doxygen's +# special commands cannot be used. By setting PYTHON_DOCSTRING to NO the +# Doxygen's special commands can be used and the contents of the docstring +# documentation blocks is shown as Doxygen documentation. +# The default value is: YES. + +PYTHON_DOCSTRING = YES + +# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the +# documentation from any documented member that it re-implements. +# The default value is: YES. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES then Doxygen will produce a new +# page for each member. If set to NO, the documentation of a member will be part +# of the file/class/namespace that contains it. +# The default value is: NO. + +SEPARATE_MEMBER_PAGES = YES + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen +# uses this value to replace tabs by spaces in code fragments. +# Minimum value: 1, maximum value: 16, default value: 4. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that act as commands in +# the documentation. An alias has the form: +# name=value +# For example adding +# "sideeffect=@par Side Effects:^^" +# will allow you to put the command \sideeffect (or @sideeffect) in the +# documentation, which will result in a user-defined paragraph with heading +# "Side Effects:". Note that you cannot put \n's in the value part of an alias +# to insert newlines (in the resulting output). You can put ^^ in the value part +# of an alias to insert a newline as if a physical newline was in the original +# file. When you need a literal { or } or , in the value part of an alias you +# have to escape them by means of a backslash (\), this can lead to conflicts +# with the commands \{ and \} for these it is advised to use the version @{ and +# @} or use a double escape (\\{ and \\}) + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources +# only. Doxygen will then generate output that is more tailored for C. For +# instance, some of the names that are used will be different. The list of all +# members will be omitted, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_FOR_C = YES + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or +# Python sources only. Doxygen will then generate output that is more tailored +# for that language. For instance, namespaces will be presented as packages, +# qualified scopes will look different, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources. Doxygen will then generate output that is tailored for Fortran. +# The default value is: NO. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for VHDL. +# The default value is: NO. + +OPTIMIZE_OUTPUT_VHDL = NO + +# Set the OPTIMIZE_OUTPUT_SLICE tag to YES if your project consists of Slice +# sources only. Doxygen will then generate output that is more tailored for that +# language. For instance, namespaces will be presented as modules, types will be +# separated into more groups, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_SLICE = NO + +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, and +# language is one of the parsers supported by Doxygen: IDL, Java, JavaScript, +# Csharp (C#), C, C++, Lex, D, PHP, md (Markdown), Objective-C, Python, Slice, +# VHDL, Fortran (fixed format Fortran: FortranFixed, free formatted Fortran: +# FortranFree, unknown formatted Fortran: Fortran. In the later case the parser +# tries to guess whether the code is fixed or free formatted code, this is the +# default for Fortran type files). For instance to make Doxygen treat .inc files +# as Fortran files (default is PHP), and .f files as C (default is Fortran), +# use: inc=Fortran f=C. +# +# Note: For files without extension you can use no_extension as a placeholder. +# +# Note that for custom extensions you also need to set FILE_PATTERNS otherwise +# the files are not read by Doxygen. When specifying no_extension you should add +# * to the FILE_PATTERNS. +# +# Note see also the list of default file extension mappings. + +EXTENSION_MAPPING = + +# If the MARKDOWN_SUPPORT tag is enabled then Doxygen pre-processes all comments +# according to the Markdown format, which allows for more readable +# documentation. See https://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by Doxygen, so you can +# mix Doxygen, HTML, and XML commands with Markdown formatting. Disable only in +# case of backward compatibilities issues. +# The default value is: YES. + +MARKDOWN_SUPPORT = YES + +# When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings up +# to that level are automatically included in the table of contents, even if +# they do not have an id attribute. +# Note: This feature currently applies only to Markdown headings. +# Minimum value: 0, maximum value: 99, default value: 6. +# This tag requires that the tag MARKDOWN_SUPPORT is set to YES. + +TOC_INCLUDE_HEADINGS = 6 + +# The MARKDOWN_ID_STYLE tag can be used to specify the algorithm used to +# generate identifiers for the Markdown headings. Note: Every identifier is +# unique. +# Possible values are: DOXYGEN use a fixed 'autotoc_md' string followed by a +# sequence number starting at 0 and GITHUB use the lower case version of title +# with any whitespace replaced by '-' and punctuation characters removed. +# The default value is: DOXYGEN. +# This tag requires that the tag MARKDOWN_SUPPORT is set to YES. + +MARKDOWN_ID_STYLE = DOXYGEN + +# When enabled Doxygen tries to link words that correspond to documented +# classes, or namespaces to their corresponding documentation. Such a link can +# be prevented in individual cases by putting a % sign in front of the word or +# globally by setting AUTOLINK_SUPPORT to NO. +# The default value is: YES. + +AUTOLINK_SUPPORT = YES + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want +# to include (a tag file for) the STL sources as input, then you should set this +# tag to YES in order to let Doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); +# versus func(std::string) {}). This also makes the inheritance and +# collaboration diagrams that involve STL classes more complete and accurate. +# The default value is: NO. + +BUILTIN_STL_SUPPORT = NO + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. +# The default value is: NO. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip (see: +# https://www.riverbankcomputing.com/software) sources only. Doxygen will parse +# them like normal C++ but will assume all classes use public instead of private +# inheritance when no explicit protection keyword is present. +# The default value is: NO. + +SIP_SUPPORT = NO + +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to YES will make +# Doxygen to replace the get and set methods by a property in the documentation. +# This will only work if the methods are indeed getting or setting a simple +# type. If this is not the case, or you want to show the methods anyway, you +# should set this option to NO. +# The default value is: YES. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES then Doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. +# The default value is: NO. + +DISTRIBUTE_GROUP_DOC = NO + +# If one adds a struct or class to a group and this option is enabled, then also +# any nested class or struct is added to the same group. By default this option +# is disabled and one has to add nested compounds explicitly via \ingroup. +# The default value is: NO. + +GROUP_NESTED_COMPOUNDS = NO + +# Set the SUBGROUPING tag to YES to allow class member groups of the same type +# (for instance a group of public functions) to be put as a subgroup of that +# type (e.g. under the Public Functions section). Set it to NO to prevent +# subgrouping. Alternatively, this can be done per class using the +# \nosubgrouping command. +# The default value is: YES. + +SUBGROUPING = YES + +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions +# are shown inside the group in which they are included (e.g. using \ingroup) +# instead of on a separate page (for HTML and Man pages) or section (for LaTeX +# and RTF). +# +# Note that this feature does not work in combination with +# SEPARATE_MEMBER_PAGES. +# The default value is: NO. + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions +# with only public data fields or simple typedef fields will be shown inline in +# the documentation of the scope in which they are defined (i.e. file, +# namespace, or group documentation), provided this scope is documented. If set +# to NO, structs, classes, and unions are shown on a separate page (for HTML and +# Man pages) or section (for LaTeX and RTF). +# The default value is: NO. + +INLINE_SIMPLE_STRUCTS = NO + +# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or +# enum is documented as struct, union, or enum with the name of the typedef. So +# typedef struct TypeS {} TypeT, will appear in the documentation as a struct +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named TypeS. This can typically be +# useful for C code in case the coding convention dictates that all compound +# types are typedef'ed and only the typedef is referenced, never the tag name. +# The default value is: NO. + +TYPEDEF_HIDES_STRUCT = YES + +# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This +# cache is used to resolve symbols given their name and scope. Since this can be +# an expensive process and often the same symbol appears multiple times in the +# code, Doxygen keeps a cache of pre-resolved symbols. If the cache is too small +# Doxygen will become slower. If the cache is too large, memory is wasted. The +# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range +# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 +# symbols. At the end of a run Doxygen will report the cache usage and suggest +# the optimal cache size from a speed point of view. +# Minimum value: 0, maximum value: 9, default value: 0. + +LOOKUP_CACHE_SIZE = 0 + +# The NUM_PROC_THREADS specifies the number of threads Doxygen is allowed to use +# during processing. When set to 0 Doxygen will based this on the number of +# cores available in the system. You can set it explicitly to a value larger +# than 0 to get more control over the balance between CPU load and processing +# speed. At this moment only the input processing can be done using multiple +# threads. Since this is still an experimental feature the default is set to 1, +# which effectively disables parallel processing. Please report any issues you +# encounter. Generating dot graphs in parallel is controlled by the +# DOT_NUM_THREADS setting. +# Minimum value: 0, maximum value: 32, default value: 1. + +NUM_PROC_THREADS = 1 + +# If the TIMESTAMP tag is set different from NO then each generated page will +# contain the date or date and time when the page was generated. Setting this to +# NO can help when comparing the output of multiple runs. +# Possible values are: YES, NO, DATETIME and DATE. +# The default value is: NO. + +TIMESTAMP = YES + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES, Doxygen will assume all entities in +# documentation are documented, even if no documentation was available. Private +# class members and static file members will be hidden unless the +# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. +# Note: This will also disable the warnings about undocumented members that are +# normally produced when WARNINGS is set to YES. +# The default value is: NO. + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will +# be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual +# methods of a class will be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIV_VIRTUAL = NO + +# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal +# scope will be included in the documentation. +# The default value is: NO. + +EXTRACT_PACKAGE = YES + +# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be +# included in the documentation. +# The default value is: NO. + +EXTRACT_STATIC = YES + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined +# locally in source files will be included in the documentation. If set to NO, +# only classes defined in header files are included. Does not have any effect +# for Java sources. +# The default value is: YES. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. If set to YES, local methods, +# which are defined in the implementation section but not in the interface are +# included in the documentation. If set to NO, only methods in the interface are +# included. +# The default value is: NO. + +EXTRACT_LOCAL_METHODS = NO + +# If this flag is set to YES, the members of anonymous namespaces will be +# extracted and appear in the documentation as a namespace called +# 'anonymous_namespace{file}', where file will be replaced with the base name of +# the file that contains the anonymous namespace. By default anonymous namespace +# are hidden. +# The default value is: NO. + +EXTRACT_ANON_NSPACES = NO + +# If this flag is set to YES, the name of an unnamed parameter in a declaration +# will be determined by the corresponding definition. By default unnamed +# parameters remain unnamed in the output. +# The default value is: YES. + +RESOLVE_UNNAMED_PARAMS = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members inside documented classes or files. If set to NO these +# members will be included in the various overviews, but no documentation +# section is generated. This option has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. If set +# to NO, these classes will be included in the various overviews. This option +# will also hide undocumented C++ concepts if enabled. This option has no effect +# if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all friend +# declarations. If set to NO, these declarations will be included in the +# documentation. +# The default value is: NO. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. If set to NO, these +# blocks will be appended to the function's detailed documentation block. +# The default value is: NO. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation that is typed after a +# \internal command is included. If the tag is set to NO then the documentation +# will be excluded. Set it to YES to include the internal documentation. +# The default value is: NO. + +INTERNAL_DOCS = NO + +# With the correct setting of option CASE_SENSE_NAMES Doxygen will better be +# able to match the capabilities of the underlying filesystem. In case the +# filesystem is case sensitive (i.e. it supports files in the same directory +# whose names only differ in casing), the option must be set to YES to properly +# deal with such files in case they appear in the input. For filesystems that +# are not case sensitive the option should be set to NO to properly deal with +# output files written for symbols that only differ in casing, such as for two +# classes, one named CLASS and the other named Class, and to also support +# references to files without having to specify the exact matching casing. On +# Windows (including Cygwin) and macOS, users should typically set this option +# to NO, whereas on Linux or other Unix flavors it should typically be set to +# YES. +# Possible values are: SYSTEM, NO and YES. +# The default value is: SYSTEM. + +CASE_SENSE_NAMES = SYSTEM + +# If the HIDE_SCOPE_NAMES tag is set to NO then Doxygen will show members with +# their full class and namespace scopes in the documentation. If set to YES, the +# scope will be hidden. +# The default value is: NO. + +HIDE_SCOPE_NAMES = NO + +# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then Doxygen will +# append additional text to a page's title, such as Class Reference. If set to +# YES the compound reference will be hidden. +# The default value is: NO. + +HIDE_COMPOUND_REFERENCE= NO + +# If the SHOW_HEADERFILE tag is set to YES then the documentation for a class +# will show which file needs to be included to use the class. +# The default value is: YES. + +SHOW_HEADERFILE = YES + +# If the SHOW_INCLUDE_FILES tag is set to YES then Doxygen will put a list of +# the files that are included by a file in the documentation of that file. +# The default value is: YES. + +SHOW_INCLUDE_FILES = YES + +# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each +# grouped member an include statement to the documentation, telling the reader +# which file to include in order to use the member. +# The default value is: NO. + +SHOW_GROUPED_MEMB_INC = NO + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen will list include +# files with double quotes in the documentation rather than with sharp brackets. +# The default value is: NO. + +FORCE_LOCAL_INCLUDES = NO + +# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the +# documentation for inline members. +# The default value is: YES. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES then Doxygen will sort the +# (detailed) documentation of file and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. +# The default value is: YES. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then Doxygen will sort the brief +# descriptions of file, namespace and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. Note that +# this will also influence the order of the classes in the class list. +# The default value is: NO. + +SORT_BRIEF_DOCS = NO + +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then Doxygen will sort the +# (brief and detailed) documentation of class members so that constructors and +# destructors are listed first. If set to NO the constructors will appear in the +# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. +# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief +# member documentation. +# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting +# detailed member documentation. +# The default value is: NO. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then Doxygen will sort the hierarchy +# of group names into alphabetical order. If set to NO the group names will +# appear in their defined order. +# The default value is: NO. + +SORT_GROUP_NAMES = YES + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by +# fully-qualified names, including namespaces. If set to NO, the class list will +# be sorted only by class name, not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the alphabetical +# list. +# The default value is: NO. + +SORT_BY_SCOPE_NAME = NO + +# If the STRICT_PROTO_MATCHING option is enabled and Doxygen fails to do proper +# type resolution of all parameters of a function it will reject a match between +# the prototype and the implementation of a member function even if there is +# only one candidate or it is obvious which candidate to choose by doing a +# simple string match. By disabling STRICT_PROTO_MATCHING Doxygen will still +# accept a match between prototype and implementation in such cases. +# The default value is: NO. + +STRICT_PROTO_MATCHING = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo +# list. This list is created by putting \todo commands in the documentation. +# The default value is: YES. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test +# list. This list is created by putting \test commands in the documentation. +# The default value is: YES. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug +# list. This list is created by putting \bug commands in the documentation. +# The default value is: YES. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) +# the deprecated list. This list is created by putting \deprecated commands in +# the documentation. +# The default value is: YES. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional documentation +# sections, marked by \if ... \endif and \cond +# ... \endcond blocks. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the +# initial value of a variable or macro / define can have for it to appear in the +# documentation. If the initializer consists of more lines than specified here +# it will be hidden. Use a value of 0 to hide initializers completely. The +# appearance of the value of individual variables and macros / defines can be +# controlled using \showinitializer or \hideinitializer command in the +# documentation regardless of this setting. +# Minimum value: 0, maximum value: 10000, default value: 30. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at +# the bottom of the documentation of classes and structs. If set to YES, the +# list will mention the files that were used to generate the documentation. +# The default value is: YES. + +SHOW_USED_FILES = YES + +# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This +# will remove the Files entry from the Quick Index and from the Folder Tree View +# (if specified). +# The default value is: YES. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces +# page. This will remove the Namespaces entry from the Quick Index and from the +# Folder Tree View (if specified). +# The default value is: YES. + +SHOW_NAMESPACES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# Doxygen should invoke to get the current version for each file (typically from +# the version control system). Doxygen will invoke the program by executing (via +# popen()) the command command input-file, where command is the value of the +# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided +# by Doxygen. Whatever the program writes to standard output is used as the file +# version. For an example see the documentation. + +FILE_VERSION_FILTER = + +# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed +# by Doxygen. The layout file controls the global structure of the generated +# output files in an output format independent way. To create the layout file +# that represents Doxygen's defaults, run Doxygen with the -l option. You can +# optionally specify a file name after the option, if omitted DoxygenLayout.xml +# will be used as the name of the layout file. See also section "Changing the +# layout of pages" for information. +# +# Note that if you run Doxygen from a directory containing a file called +# DoxygenLayout.xml, Doxygen will parse it automatically even if the LAYOUT_FILE +# tag is left empty. + +LAYOUT_FILE = + +# The CITE_BIB_FILES tag can be used to specify one or more bib files containing +# the reference definitions. This must be a list of .bib files. The .bib +# extension is automatically appended if omitted. This requires the bibtex tool +# to be installed. See also https://en.wikipedia.org/wiki/BibTeX for more info. +# For LaTeX the style of the bibliography can be controlled using +# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the +# search path. See also \cite for info how to create references. + +CITE_BIB_FILES = + +# The EXTERNAL_TOOL_PATH tag can be used to extend the search path (PATH +# environment variable) so that external tools such as latex and gs can be +# found. +# Note: Directories specified with EXTERNAL_TOOL_PATH are added in front of the +# path already specified by the PATH variable, and are added in the order +# specified. +# Note: This option is particularly useful for macOS version 14 (Sonoma) and +# higher, when running Doxygen from Doxywizard, because in this case any user- +# defined changes to the PATH are ignored. A typical example on macOS is to set +# EXTERNAL_TOOL_PATH = /Library/TeX/texbin /usr/local/bin +# together with the standard path, the full search path used by doxygen when +# launching external tools will then become +# PATH=/Library/TeX/texbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin + +EXTERNAL_TOOL_PATH = + +#--------------------------------------------------------------------------- +# Configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated to +# standard output by Doxygen. If QUIET is set to YES this implies that the +# messages are off. +# The default value is: NO. + +QUIET = YES + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated to standard error (stderr) by Doxygen. If WARNINGS is set to YES +# this implies that the warnings are on. +# +# Tip: Turn warnings on while writing the documentation. +# The default value is: YES. + +WARNINGS = YES + +# If the WARN_IF_UNDOCUMENTED tag is set to YES then Doxygen will generate +# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: YES. + +WARN_IF_UNDOCUMENTED = YES + +# If the WARN_IF_DOC_ERROR tag is set to YES, Doxygen will generate warnings for +# potential errors in the documentation, such as documenting some parameters in +# a documented function twice, or documenting parameters that don't exist or +# using markup commands wrongly. +# The default value is: YES. + +WARN_IF_DOC_ERROR = YES + +# If WARN_IF_INCOMPLETE_DOC is set to YES, Doxygen will warn about incomplete +# function parameter documentation. If set to NO, Doxygen will accept that some +# parameters have no documentation without warning. +# The default value is: YES. + +WARN_IF_INCOMPLETE_DOC = YES + +# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that +# are documented, but have no documentation for their parameters or return +# value. If set to NO, Doxygen will only warn about wrong parameter +# documentation, but not about the absence of documentation. If EXTRACT_ALL is +# set to YES then this flag will automatically be disabled. See also +# WARN_IF_INCOMPLETE_DOC +# The default value is: NO. + +WARN_NO_PARAMDOC = NO + +# If WARN_IF_UNDOC_ENUM_VAL option is set to YES, Doxygen will warn about +# undocumented enumeration values. If set to NO, Doxygen will accept +# undocumented enumeration values. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: NO. + +WARN_IF_UNDOC_ENUM_VAL = NO + +# If the WARN_AS_ERROR tag is set to YES then Doxygen will immediately stop when +# a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS +# then Doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but +# at the end of the Doxygen process Doxygen will return with a non-zero status. +# If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS_PRINT then Doxygen behaves +# like FAIL_ON_WARNINGS but in case no WARN_LOGFILE is defined Doxygen will not +# write the warning messages in between other messages but write them at the end +# of a run, in case a WARN_LOGFILE is defined the warning messages will be +# besides being in the defined file also be shown at the end of a run, unless +# the WARN_LOGFILE is defined as - i.e. standard output (stdout) in that case +# the behavior will remain as with the setting FAIL_ON_WARNINGS. +# Possible values are: NO, YES, FAIL_ON_WARNINGS and FAIL_ON_WARNINGS_PRINT. +# The default value is: NO. + +WARN_AS_ERROR = YES + +# The WARN_FORMAT tag determines the format of the warning messages that Doxygen +# can produce. The string should contain the $file, $line, and $text tags, which +# will be replaced by the file and line number from which the warning originated +# and the warning text. Optionally the format may contain $version, which will +# be replaced by the version of the file (if it could be obtained via +# FILE_VERSION_FILTER) +# See also: WARN_LINE_FORMAT +# The default value is: $file:$line: $text. + +WARN_FORMAT = "$file:$line: $text" + +# In the $text part of the WARN_FORMAT command it is possible that a reference +# to a more specific place is given. To make it easier to jump to this place +# (outside of Doxygen) the user can define a custom "cut" / "paste" string. +# Example: +# WARN_LINE_FORMAT = "'vi $file +$line'" +# See also: WARN_FORMAT +# The default value is: at line $line of file $file. + +WARN_LINE_FORMAT = "at line $line of file $file" + +# The WARN_LOGFILE tag can be used to specify a file to which warning and error +# messages should be written. If left blank the output is written to standard +# error (stderr). In case the file specified cannot be opened for writing the +# warning and error messages are written to standard error. When as file - is +# specified the warning and error messages are written to standard output +# (stdout). + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# Configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag is used to specify the files and/or directories that contain +# documented source files. You may enter file names like myfile.cpp or +# directories like /usr/src/myproject. Separate the files or directories with +# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING +# Note: If this tag is empty the current directory is searched. + +INPUT = @DOCSET_SOURCE_BASE@/drivers/nrf_wifi + +# This tag can be used to specify the character encoding of the source files +# that Doxygen parses. Internally Doxygen uses the UTF-8 encoding. Doxygen uses +# libiconv (or the iconv built into libc) for the transcoding. See the libiconv +# documentation (see: +# https://www.gnu.org/software/libiconv/) for the list of possible encodings. +# See also: INPUT_FILE_ENCODING +# The default value is: UTF-8. + +INPUT_ENCODING = UTF-8 + +# This tag can be used to specify the character encoding of the source files +# that Doxygen parses The INPUT_FILE_ENCODING tag can be used to specify +# character encoding on a per file pattern basis. Doxygen will compare the file +# name with each pattern and apply the encoding instead of the default +# INPUT_ENCODING) if there is a match. The character encodings are a list of the +# form: pattern=encoding (like *.php=ISO-8859-1). +# See also: INPUT_ENCODING for further information on supported encodings. + +INPUT_FILE_ENCODING = + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and +# *.h) to filter out the source-files in the directories. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# read by Doxygen. +# +# Note the list of default checked file patterns might differ from the list of +# default file extension mappings. +# +# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cxxm, +# *.cpp, *.cppm, *.ccm, *.c++, *.c++m, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, +# *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp, *.h++, *.ixx, *.l, *.cs, *.d, +# *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown, *.md, *.mm, *.dox (to +# be provided as Doxygen C comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, +# *.f18, *.f, *.for, *.vhd, *.vhdl, *.ucf, *.qsf and *.ice. + +FILE_PATTERNS = *.h + +# The RECURSIVE tag can be used to specify whether or not subdirectories should +# be searched for input files as well. +# The default value is: NO. + +RECURSIVE = YES + +# The EXCLUDE tag can be used to specify files and/or directories that should be +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. +# +# Note that relative paths are relative to the directory from which Doxygen is +# run. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or +# directories that are symbolic links (a Unix file system feature) are excluded +# from the input. +# The default value is: NO. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories for example use the pattern */test/* + +EXCLUDE_PATTERNS = + +# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names +# (namespaces, classes, functions, etc.) that should be excluded from the +# output. The symbol name can be a fully qualified name, a word, or if the +# wildcard * is used, a substring. Examples: ANamespace, AClass, +# ANamespace::AClass, ANamespace::*Test + +EXCLUDE_SYMBOLS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or directories +# that contain example code fragments that are included (see the \include +# command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and +# *.h) to filter out the source-files in the directories. If left blank all +# files are included. + +EXAMPLE_PATTERNS = * + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude commands +# irrespective of the value of the RECURSIVE tag. +# The default value is: NO. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or directories +# that contain images that are to be included in the documentation (see the +# \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that Doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command: +# +# +# +# where is the value of the INPUT_FILTER tag, and is the +# name of an input file. Doxygen will then use the output that the filter +# program writes to standard output. If FILTER_PATTERNS is specified, this tag +# will be ignored. +# +# Note that the filter must not add or remove lines; it is applied before the +# code is scanned, but not when the output code is generated. If lines are added +# or removed, the anchors will not be placed correctly. +# +# Note that Doxygen will use the data processed and written to standard output +# for further processing, therefore nothing else, like debug statements or used +# commands (so in case of a Windows batch file always use @echo OFF), should be +# written to standard output. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by Doxygen. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: pattern=filter +# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how +# filters are used. If the FILTER_PATTERNS tag is empty or if none of the +# patterns match the file name, INPUT_FILTER is applied. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by Doxygen. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will also be used to filter the input files that are used for +# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). +# The default value is: NO. + +FILTER_SOURCE_FILES = NO + +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and +# it is also possible to disable source filtering for a specific pattern using +# *.ext= (so without naming a filter). +# This tag requires that the tag FILTER_SOURCE_FILES is set to YES. + +FILTER_SOURCE_PATTERNS = + +# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that +# is part of the input, its contents will be placed on the main page +# (index.html). This can be useful if you have a project on for instance GitHub +# and want to reuse the introduction page also for the Doxygen output. + +USE_MDFILE_AS_MAINPAGE = + +# The Fortran standard specifies that for fixed formatted Fortran code all +# characters from position 72 are to be considered as comment. A common +# extension is to allow longer lines before the automatic comment starts. The +# setting FORTRAN_COMMENT_AFTER will also make it possible that longer lines can +# be processed before the automatic comment starts. +# Minimum value: 7, maximum value: 10000, default value: 72. + +FORTRAN_COMMENT_AFTER = 72 + +#--------------------------------------------------------------------------- +# Configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will be +# generated. Documented entities will be cross-referenced with these sources. +# +# Note: To get rid of all source code in the generated output, make sure that +# also VERBATIM_HEADERS is set to NO. +# The default value is: NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body of functions, +# multi-line macros, enums or list initialized variables directly into the +# documentation. +# The default value is: NO. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES will instruct Doxygen to hide any +# special comment blocks from generated source code fragments. Normal C, C++ and +# Fortran comments will always remain visible. +# The default value is: YES. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES then for each documented +# entity all documented functions referencing it will be listed. +# The default value is: NO. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES then for each documented function +# all documented entities called/used by that function will be listed. +# The default value is: NO. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set +# to YES then the hyperlinks from functions in REFERENCES_RELATION and +# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will +# link to the documentation. +# The default value is: YES. + +REFERENCES_LINK_SOURCE = YES + +# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the +# source code will show a tooltip with additional information such as prototype, +# brief description and links to the definition and documentation. Since this +# will make the HTML file larger and loading of large files a bit slower, you +# can opt to disable this feature. +# The default value is: YES. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +SOURCE_TOOLTIPS = YES + +# If the USE_HTAGS tag is set to YES then the references to source code will +# point to the HTML generated by the htags(1) tool instead of Doxygen built-in +# source browser. The htags tool is part of GNU's global source tagging system +# (see https://www.gnu.org/software/global/global.html). You will need version +# 4.8.6 or higher. +# +# To use it do the following: +# - Install the latest version of global +# - Enable SOURCE_BROWSER and USE_HTAGS in the configuration file +# - Make sure the INPUT points to the root of the source tree +# - Run doxygen as normal +# +# Doxygen will invoke htags (and that will in turn invoke gtags), so these +# tools must be available from the command line (i.e. in the search path). +# +# The result: instead of the source browser generated by Doxygen, the links to +# source code will now point to the output of htags. +# The default value is: NO. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set the YES then Doxygen will generate a +# verbatim copy of the header file for each class for which an include is +# specified. Set to NO to disable this. +# See also: Section \class. +# The default value is: YES. + +VERBATIM_HEADERS = YES + +# If the CLANG_ASSISTED_PARSING tag is set to YES then Doxygen will use the +# clang parser (see: +# http://clang.llvm.org/) for more accurate parsing at the cost of reduced +# performance. This can be particularly helpful with template rich C++ code for +# which Doxygen's built-in parser lacks the necessary type information. +# Note: The availability of this option depends on whether or not Doxygen was +# generated with the -Duse_libclang=ON option for CMake. +# The default value is: NO. + +CLANG_ASSISTED_PARSING = NO + +# If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_INC_PATHS +# tag is set to YES then Doxygen will add the directory of each input to the +# include path. +# The default value is: YES. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_ADD_INC_PATHS = YES + +# If clang assisted parsing is enabled you can provide the compiler with command +# line options that you would normally use when invoking the compiler. Note that +# the include paths will already be set by Doxygen for the files and directories +# specified with INPUT and INCLUDE_PATH. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_OPTIONS = + +# If clang assisted parsing is enabled you can provide the clang parser with the +# path to the directory containing a file called compile_commands.json. This +# file is the compilation database (see: +# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) containing the +# options used when the source files were built. This is equivalent to +# specifying the -p option to a clang tool, such as clang-check. These options +# will then be passed to the parser. Any options specified with CLANG_OPTIONS +# will be added as well. +# Note: The availability of this option depends on whether or not Doxygen was +# generated with the -Duse_libclang=ON option for CMake. + +CLANG_DATABASE_PATH = + +#--------------------------------------------------------------------------- +# Configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all +# compounds will be generated. Enable this if the project contains a lot of +# classes, structs, unions or interfaces. +# The default value is: YES. + +ALPHABETICAL_INDEX = YES + +# The IGNORE_PREFIX tag can be used to specify a prefix (or a list of prefixes) +# that should be ignored while generating the index headers. The IGNORE_PREFIX +# tag works for classes, function and member names. The entity will be placed in +# the alphabetical list under the first letter of the entity name that remains +# after removing the prefix. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES, Doxygen will generate HTML output +# The default value is: YES. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a +# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of +# it. +# The default directory is: html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_OUTPUT = wifi + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each +# generated HTML page (for example: .htm, .php, .asp). +# The default value is: .html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a user-defined HTML header file for +# each generated HTML page. If the tag is left blank Doxygen will generate a +# standard header. +# +# To get valid HTML the header file that includes any scripts and style sheets +# that Doxygen needs, which is dependent on the configuration options used (e.g. +# the setting GENERATE_TREEVIEW). It is highly recommended to start with a +# default header using +# doxygen -w html new_header.html new_footer.html new_stylesheet.css +# YourConfigFile +# and then modify the file new_header.html. See also section "Doxygen usage" +# for information on how to generate the default header that Doxygen normally +# uses. +# Note: The header is subject to change so you typically have to regenerate the +# default header when upgrading to a newer version of Doxygen. For a description +# of the possible markers and block names see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_HEADER = @NRF_BASE@/doc/_doxygen/header.html + +# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each +# generated HTML page. If the tag is left blank Doxygen will generate a standard +# footer. See HTML_HEADER for more information on how to generate a default +# footer and what special commands can be used inside the footer. See also +# section "Doxygen usage" for information on how to generate the default footer +# that Doxygen normally uses. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style +# sheet that is used by each HTML page. It can be used to fine-tune the look of +# the HTML output. If left blank Doxygen will generate a default style sheet. +# See also section "Doxygen usage" for information on how to generate the style +# sheet that Doxygen normally uses. +# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as +# it is more robust and this tag (HTML_STYLESHEET) will in the future become +# obsolete. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_STYLESHEET = + +# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined +# cascading style sheets that are included after the standard style sheets +# created by Doxygen. Using this option one can overrule certain style aspects. +# This is preferred over using HTML_STYLESHEET since it does not replace the +# standard style sheet and is therefore more robust against future updates. +# Doxygen will copy the style sheet files to the output directory. +# Note: The order of the extra style sheet files is of importance (e.g. the last +# style sheet in the list overrules the setting of the previous ones in the +# list). +# Note: Since the styling of scrollbars can currently not be overruled in +# Webkit/Chromium, the styling will be left out of the default doxygen.css if +# one or more extra stylesheets have been specified. So if scrollbar +# customization is desired it has to be added explicitly. For an example see the +# documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_STYLESHEET = @NRF_BASE@/doc/_doxygen/doxygen-awesome.css + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that the +# files will be copied as-is; there are no commands or markers available. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_FILES = @NRF_BASE@/doc/_doxygen/doxygen-awesome-darkmode-toggle.js \ + @NRF_BASE@/doc/_doxygen/doxygen-awesome-paragraph-link.js \ + @NRF_BASE@/doc/_doxygen/doxygen-awesome-interactive-toc.js + +# The HTML_COLORSTYLE tag can be used to specify if the generated HTML output +# should be rendered with a dark or light theme. +# Possible values are: LIGHT always generates light mode output, DARK always +# generates dark mode output, AUTO_LIGHT automatically sets the mode according +# to the user preference, uses light mode if no preference is set (the default), +# AUTO_DARK automatically sets the mode according to the user preference, uses +# dark mode if no preference is set and TOGGLE allows a user to switch between +# light and dark mode via a button. +# The default value is: AUTO_LIGHT. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE = AUTO_LIGHT + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen +# will adjust the colors in the style sheet and background images according to +# this color. Hue is specified as an angle on a color-wheel, see +# https://en.wikipedia.org/wiki/Hue for more information. For instance the value +# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 +# purple, and 360 is red again. +# Minimum value: 0, maximum value: 359, default value: 220. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_HUE = 220 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors +# in the HTML output. For a value of 0 the output will use gray-scales only. A +# value of 255 will produce the most vivid colors. +# Minimum value: 0, maximum value: 255, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_SAT = 100 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the +# luminance component of the colors in the HTML output. Values below 100 +# gradually make the output lighter, whereas values above 100 make the output +# darker. The value divided by 100 is the actual gamma applied, so 80 represents +# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not +# change the gamma. +# Minimum value: 40, maximum value: 240, default value: 80. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_GAMMA = 80 + +# If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML +# documentation will contain a main index with vertical navigation menus that +# are dynamically created via JavaScript. If disabled, the navigation index will +# consists of multiple levels of tabs that are statically embedded in every HTML +# page. Disable this option to support browsers that do not have JavaScript, +# like the Qt help browser. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_MENUS = YES + +# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML +# documentation will contain sections that can be hidden and shown after the +# page has loaded. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_SECTIONS = NO + +# If the HTML_CODE_FOLDING tag is set to YES then classes and functions can be +# dynamically folded and expanded in the generated HTML source code. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_CODE_FOLDING = YES + +# If the HTML_COPY_CLIPBOARD tag is set to YES then Doxygen will show an icon in +# the top right corner of code and text fragments that allows the user to copy +# its content to the clipboard. Note this only works if supported by the browser +# and the web page is served via a secure context (see: +# https://www.w3.org/TR/secure-contexts/), i.e. using the https: or file: +# protocol. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COPY_CLIPBOARD = YES + +# Doxygen stores a couple of settings persistently in the browser (via e.g. +# cookies). By default these settings apply to all HTML pages generated by +# Doxygen across all projects. The HTML_PROJECT_COOKIE tag can be used to store +# the settings under a project specific key, such that the user preferences will +# be stored separately. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_PROJECT_COOKIE = + +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries +# shown in the various tree structured indices initially; the user can expand +# and collapse entries dynamically later on. Doxygen will expand the tree to +# such a level that at most the specified number of entries are visible (unless +# a fully collapsed tree already exceeds this amount). So setting the number of +# entries 1 will produce a full collapsed tree by default. 0 is a special value +# representing an infinite number of entries and will result in a full expanded +# tree by default. +# Minimum value: 0, maximum value: 9999, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_INDEX_NUM_ENTRIES = 100 + +# If the GENERATE_DOCSET tag is set to YES, additional index files will be +# generated that can be used as input for Apple's Xcode 3 integrated development +# environment (see: +# https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To +# create a documentation set, Doxygen will generate a Makefile in the HTML +# output directory. Running make will produce the docset in that directory and +# running make install will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at +# startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy +# genXcode/_index.html for more information. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_DOCSET = NO + +# This tag determines the name of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# The default value is: Doxygen generated docs. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# This tag determines the URL of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDURL = + +# This tag specifies a string that should uniquely identify the documentation +# set bundle. This should be a reverse domain-name style string, e.g. +# com.mycompany.MyDocSet. Doxygen will append .docset to the name. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify +# the documentation publisher. This should be a reverse domain-name style +# string, e.g. com.mycompany.MyDocSet.documentation. +# The default value is: org.doxygen.Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. +# The default value is: Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_NAME = Publisher + +# If the GENERATE_HTMLHELP tag is set to YES then Doxygen generates three +# additional HTML index files: index.hhp, index.hhc, and index.hhk. The +# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop +# on Windows. In the beginning of 2021 Microsoft took the original page, with +# a.o. the download links, offline the HTML help workshop was already many years +# in maintenance mode). You can download the HTML help workshop from the web +# archives at Installation executable (see: +# http://web.archive.org/web/20160201063255/http://download.microsoft.com/downlo +# ad/0/A/9/0A939EF6-E31C-430F-A3DF-DFAE7960D564/htmlhelp.exe). +# +# The HTML Help Workshop contains a compiler that can convert all HTML output +# generated by Doxygen into a single compiled HTML file (.chm). Compiled HTML +# files are now used as the Windows 98 help format, and will replace the old +# Windows help format (.hlp) on all Windows platforms in the future. Compressed +# HTML files also contain an index, a table of contents, and you can search for +# words in the documentation. The HTML workshop also contains a viewer for +# compressed HTML files. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_HTMLHELP = NO + +# The CHM_FILE tag can be used to specify the file name of the resulting .chm +# file. You can add a path in front of the file if the result should not be +# written to the html output directory. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_FILE = + +# The HHC_LOCATION tag can be used to specify the location (absolute path +# including file name) of the HTML help compiler (hhc.exe). If non-empty, +# Doxygen will try to run the HTML help compiler on the generated index.hhp. +# The file has to be specified with full path. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +HHC_LOCATION = + +# The GENERATE_CHI flag controls if a separate .chi index file is generated +# (YES) or that it should be included in the main .chm file (NO). +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +GENERATE_CHI = NO + +# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) +# and project file content. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_INDEX_ENCODING = + +# The BINARY_TOC flag controls whether a binary table of contents is generated +# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it +# enables the Previous and Next buttons. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members to +# the table of contents of the HTML help documentation and to the tree view. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +TOC_EXPAND = NO + +# The SITEMAP_URL tag is used to specify the full URL of the place where the +# generated documentation will be placed on the server by the user during the +# deployment of the documentation. The generated sitemap is called sitemap.xml +# and placed on the directory specified by HTML_OUTPUT. In case no SITEMAP_URL +# is specified no sitemap is generated. For information about the sitemap +# protocol see https://www.sitemaps.org +# This tag requires that the tag GENERATE_HTML is set to YES. + +SITEMAP_URL = + +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that +# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help +# (.qch) of the generated HTML documentation. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify +# the file name of the resulting .qch file. The path specified is relative to +# the HTML output folder. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help +# Project output. For more information please see Qt Help Project / Namespace +# (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace). +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_NAMESPACE = org.doxygen.Project + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt +# Help Project output. For more information please see Qt Help Project / Virtual +# Folders (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders). +# The default value is: doc. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_VIRTUAL_FOLDER = doc + +# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom +# filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_NAME = + +# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_ATTRS = + +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's filter section matches. Qt Help Project / Filter Attributes (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#filter-attributes). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_SECT_FILTER_ATTRS = + +# The QHG_LOCATION tag can be used to specify the location (absolute path +# including file name) of Qt's qhelpgenerator. If non-empty Doxygen will try to +# run qhelpgenerator on the generated .qhp file. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHG_LOCATION = + +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be +# generated, together with the HTML files, they form an Eclipse help plugin. To +# install this plugin and make it available under the help contents menu in +# Eclipse, the contents of the directory containing the HTML and XML files needs +# to be copied into the plugins directory of eclipse. The name of the directory +# within the plugins directory should be the same as the ECLIPSE_DOC_ID value. +# After copying Eclipse needs to be restarted before the help appears. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_ECLIPSEHELP = NO + +# A unique identifier for the Eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have this +# name. Each documentation set should have its own identifier. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. + +ECLIPSE_DOC_ID = org.doxygen.Project + +# If you want full control over the layout of the generated HTML pages it might +# be necessary to disable the index and replace it with your own. The +# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top +# of each HTML page. A value of NO enables the index and the value YES disables +# it. Since the tabs in the index contain the same information as the navigation +# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +DISABLE_INDEX = NO + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. If the tag +# value is set to YES, a side panel will be generated containing a tree-like +# index structure (just like the one that is generated for HTML Help). For this +# to work a browser that supports JavaScript, DHTML, CSS and frames is required +# (i.e. any modern browser). Windows users are probably better off using the +# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can +# further fine tune the look of the index (see "Fine-tuning the output"). As an +# example, the default style sheet generated by Doxygen has an example that +# shows how to put an image at the root of the tree instead of the PROJECT_NAME. +# Since the tree basically has the same information as the tab index, you could +# consider setting DISABLE_INDEX to YES when enabling this option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_TREEVIEW = YES + +# When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the +# FULL_SIDEBAR option determines if the side bar is limited to only the treeview +# area (value NO) or if it should extend to the full height of the window (value +# YES). Setting this to YES gives a layout similar to +# https://docs.readthedocs.io with more room for contents, but less room for the +# project logo, title, and description. If either GENERATE_TREEVIEW or +# DISABLE_INDEX is set to NO, this option has no effect. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FULL_SIDEBAR = NO + +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that +# Doxygen will group on one line in the generated HTML documentation. +# +# Note that a value of 0 will completely suppress the enum values from appearing +# in the overview section. +# Minimum value: 0, maximum value: 20, default value: 4. +# This tag requires that the tag GENERATE_HTML is set to YES. + +ENUM_VALUES_PER_LINE = 4 + +# When the SHOW_ENUM_VALUES tag is set doxygen will show the specified +# enumeration values besides the enumeration mnemonics. +# The default value is: NO. + +SHOW_ENUM_VALUES = NO + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used +# to set the initial width (in pixels) of the frame in which the tree is shown. +# Minimum value: 0, maximum value: 1500, default value: 250. +# This tag requires that the tag GENERATE_HTML is set to YES. + +TREEVIEW_WIDTH = 250 + +# If the EXT_LINKS_IN_WINDOW option is set to YES, Doxygen will open links to +# external symbols imported via tag files in a separate window. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +EXT_LINKS_IN_WINDOW = NO + +# If the OBFUSCATE_EMAILS tag is set to YES, Doxygen will obfuscate email +# addresses. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +OBFUSCATE_EMAILS = YES + +# If the HTML_FORMULA_FORMAT option is set to svg, Doxygen will use the pdf2svg +# tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see +# https://inkscape.org) to generate formulas as SVG images instead of PNGs for +# the HTML output. These images will generally look nicer at scaled resolutions. +# Possible values are: png (the default) and svg (looks nicer but requires the +# pdf2svg or inkscape tool). +# The default value is: png. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FORMULA_FORMAT = png + +# Use this tag to change the font size of LaTeX formulas included as images in +# the HTML documentation. When you change the font size after a successful +# Doxygen run you need to manually remove any form_*.png images from the HTML +# output directory to force them to be regenerated. +# Minimum value: 8, maximum value: 50, default value: 10. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_FONTSIZE = 10 + +# The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands +# to create new LaTeX commands to be used in formulas as building blocks. See +# the section "Including formulas" for details. + +FORMULA_MACROFILE = + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see +# https://www.mathjax.org) which uses client side JavaScript for the rendering +# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX +# installed or if you want to formulas look prettier in the HTML output. When +# enabled you may also need to install MathJax separately and configure the path +# to it using the MATHJAX_RELPATH option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +USE_MATHJAX = NO + +# With MATHJAX_VERSION it is possible to specify the MathJax version to be used. +# Note that the different versions of MathJax have different requirements with +# regards to the different settings, so it is possible that also other MathJax +# settings have to be changed when switching between the different MathJax +# versions. +# Possible values are: MathJax_2 and MathJax_3. +# The default value is: MathJax_2. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_VERSION = MathJax_2 + +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. For more details about the output format see MathJax +# version 2 (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) and MathJax version 3 +# (see: +# http://docs.mathjax.org/en/latest/web/components/output.html). +# Possible values are: HTML-CSS (which is slower, but has the best +# compatibility. This is the name for Mathjax version 2, for MathJax version 3 +# this will be translated into chtml), NativeMML (i.e. MathML. Only supported +# for MathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This +# is the name for Mathjax version 3, for MathJax version 2 this will be +# translated into HTML-CSS) and SVG. +# The default value is: HTML-CSS. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the HTML +# output directory using the MATHJAX_RELPATH option. The destination directory +# should contain the MathJax.js script. For instance, if the mathjax directory +# is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax +# Content Delivery Network so you can quickly see the result without installing +# MathJax. However, it is strongly recommended to install a local copy of +# MathJax from https://www.mathjax.org before deployment. The default value is: +# - in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2 +# - in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3 +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_RELPATH = + +# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax +# extension names that should be enabled during MathJax rendering. For example +# for MathJax version 2 (see +# https://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions): +# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols +# For example for MathJax version 3 (see +# http://docs.mathjax.org/en/latest/input/tex/extensions/index.html): +# MATHJAX_EXTENSIONS = ams +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_EXTENSIONS = + +# The MATHJAX_CODEFILE tag can be used to specify a file with JavaScript pieces +# of code that will be used on startup of the MathJax code. See the MathJax site +# (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an +# example see the documentation. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled Doxygen will generate a search box for +# the HTML output. The underlying search engine uses JavaScript and DHTML and +# should work on any modern browser. Note that when using HTML help +# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) +# there is already a search function so this one should typically be disabled. +# For large projects the JavaScript based search engine can be slow, then +# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to +# search using the keyboard; to jump to the search box use + S +# (what the is depends on the OS and browser, but it is typically +# , /