From 3f8f4ab9ad1698add0d0df8c4344aad2331d6394 Mon Sep 17 00:00:00 2001 From: Francesco Domenico Servidio Date: Mon, 26 Aug 2024 15:18:03 +0200 Subject: [PATCH] doc: Documentation edits for 2.7.99-cs1 release Added firmware bundle compatibility table. Updated nRF54H20 GS guide. Added initial power management documentation. Added initial clock control documentation Signed-off-by: Francesco Domenico Servidio --- doc/nrf/app_dev/device_guides/nrf54h.rst | 13 + .../nrf54h/ug_nrf54h20_architecture.rst | 2 + .../ug_nrf54h20_architecture_clockman.rst | 105 ++++++++ .../nrf54h/ug_nrf54h20_architecture_pm.rst | 247 ++++++++++++++++++ .../nrf54h/ug_nrf54h20_gs.rst | 72 ++--- doc/nrf/links.txt | 5 + doc/nrf/samples/other.rst | 1 + tests/benchmarks/multicore/idle/README.rst | 10 +- 8 files changed, 401 insertions(+), 54 deletions(-) create mode 100644 doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst create mode 100644 doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_pm.rst diff --git a/doc/nrf/app_dev/device_guides/nrf54h.rst b/doc/nrf/app_dev/device_guides/nrf54h.rst index 23c78aa84dcd..d4c00818ed9f 100644 --- a/doc/nrf/app_dev/device_guides/nrf54h.rst +++ b/doc/nrf/app_dev/device_guides/nrf54h.rst @@ -21,6 +21,19 @@ Zephyr and the |NCS| provide support and contain board definitions for developin | ``nrf54h20dk_nrf54h20_cpurad`` | ``nrf54h20dk_nrf54h20_cpuppr`` +The following table indicates the compatibility between nRF54H20 firmware bundle versions and |NCS| versions: + +.. list-table:: + :header-rows: 1 + + * - |NCS| version + - nRF54H20 firmware bundle version + * - v2.7 + - v0.5.0 + * - v2.7.99-cs1 + - v0.6.2 + + .. toctree:: :maxdepth: 2 :caption: Subpages: diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture.rst index c6f9eb2b191c..c1579082e492 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture.rst @@ -21,3 +21,5 @@ The following pages briefly describe topics like the responsibilities of the cor ug_nrf54h20_architecture_ipc ug_nrf54h20_architecture_boot ug_nrf54h20_architecture_lifecycle + ug_nrf54h20_architecture_pm + ug_nrf54h20_architecture_clockman diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst new file mode 100644 index 000000000000..5d0ee0553d69 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst @@ -0,0 +1,105 @@ +.. _ug_nrf54h20_architecture_clockman: + +nRF54H20 clock management +######################### + +.. contents:: + :local: + :depth: 2 + +The nRF54H20 SoC consists of multiple asynchronous clock domains and requires clock sources for correct operation. +Each of the clock sources needs proper management for the following reasons: + +* To start and stop the clock at the appropriate time. +* To select the proper clock source. +* To calibrate or synchronize the clock to a more accurate source. + +Some of the clock management operations are performed solely by the hardware circuits, but others require software intervention. +Most of the clocks can be locked to other, more accurate ones to improve their accuracy. + +Clock domains +************* + +The nRF54H20 SoC consists of the following clock domains: + +* Low frequency clock (LFCLK) +* High-frequency oscillator (HFXO) +* FLL16M +* Application Core HSFLL +* Radio Core HSFLL +* Secure Domain HSFLL +* Global HSFLL + +Each clock domain is enabled independently of others, and it is automatically enabled when at least one sink is active. +The firmware can choose to keep each clock domains enabled even when all its sinks are inactive. + +Clock domain sources are selected by ``clock_control`` drivers based on the clock parameter requirements reported by the software modules using the ``clock_control`` functions. +These requirements may include clock frequency, accuracy, or precision. +Some clock domains are configured by ``clock_control`` drivers using ``LRCCONF`` peripherals, while others are configured with the assistance of the System Controller Firmware. + +The application-facing APIs expose only the domain that directly clocks the component used by the application. +The management of the clocks on which this domain depends is handled internally by the associated clock driver. + +For example, a firmware module might request better timing accuracy for a fast UART instance. +In this case, the firmware module requests the accuracy from the global HSFLL device driver, which directly clocks the UART. +The dependencies, such as FLL16M and LFXO, are managed internally by the global HSFLL driver, not directly by the firmware module. + +LFCLK +===== + +The Low-Frequency Clock domain is responsible for generating a 32768 Hz clock signal for ultra-low-power peripherals like ``GRTC`` or ``RTC``. + +HFXO +==== + +The high-frequency crystal oscillator domain is responsible for clocking peripherals requiring high accuracy and MHz range frequency. +The drawback of this clock source is relatively high power consumption so it is enabled only when needed. + +Hardware capabilities +--------------------- + +The HFXO, like any other clock domain, can be connected in hardware to one of the available sources. +Additionally, it provides the clock signal to all of its sinks. + +FLL16M +====== + +The FLL16M clock domain clocks most of the peripherals in the system ("slow", 16 MHz). +Its accuracy results in the timing accuracy of slow ``UART``, ``SPI``, ``TWI``, ``PWM``, ``SAADC``, among others. + +Local HSFLLs +============ + +Local HSFLLs are clocking CPUs in local domains, fast peripherals around them, and local RAM. + +Global HSFLL +============ + +Global HSFLL clocks "fast" peripherals, FLPR, RAM, and MRAM blocks. + +Zephyr clock control API +************************ + +Zephyr RTOS contains a ``clock_control`` device driver class for managing clocks. +The ``clock_control`` API is designed to support multiple requestors. +Moreover, the ``clock_control`` API supports blocking or asynchronous operations based on notifications when the requested clock settings are applied. + +The ``clock_control`` subsystem exposes portable parameters in its functions, which include: + +* Accuracy requests in ppm values for all the clock domains. +* Precision requests in enumerated high- and low-precision modes. +* Clock rate requests (frequency) for the Application core HSFLL (all the other clock domains have fixed frequencies) + +For more details, see the following links: + +* :ref:`zephyr:clock_control_api`. +* The following calls in the `Zephyr's nRF clock control API extensions`_ (:file:`include/zephyr/drivers/clock_control/nrf_clock_control.h`): + + * ``nrf_clock_control_request()``: Requests a reservation to use a given clock with specified attributes. + * ``nrf_clock_control_release()``: Releases a reserved use of a clock. + * ``nrf_clock_control_cancel_or_release()``: Safely cancels a reservation request. + +* The following calls in the `clocks devicetree macro API`_ (:file:`include/zephyr/devicetree/clocks.h`): + + * ``DT_CLOCKS_CTLR_BY_IDX()``: Gets the node identifier for the controller phandle from a *clocks* phandle-array property at an index. + * ``DT_CLOCKS_CTLR()``: It is equivalent to ``DT_CLOCKS_CTLR_BY_IDX()``. diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_pm.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_pm.rst new file mode 100644 index 000000000000..d1dc886440c3 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_pm.rst @@ -0,0 +1,247 @@ +.. _ug_nrf54h20_architecture_pm: + +nRF54H20 Power Management +######################### + +.. contents:: + :local: + :depth: 2 + +The nRF54H20 SoC is a distributed system where each domain tries to achieve minimal power consumption for itself. +When all CPUs are ready to fully minimize power consumption by entering the System Off hardware state, the System Controller prepares the system and triggers the entrance in this state. + +Power states +************ + +The nRF54H20 ARM Cortex CPUs currently support the following software power states: + +* Active +* Idle +* Local suspend to Ram + +Overview +******** + +Each CPU in the nRF54H20 SoC tries to preserve as much power as possible, independently from other CPUs. +The power management subsystem, operating independently within each CPU, continuously selects the most optimal power state based on the current conditions of the CPU. + +Power states details +******************** + +The following sections describes the details of each of the software power states available on the nRF54H20 SoC. + +Active +====== + +*Active* is the power state in which the CPU is actively processing. + +.. list-table:: + :widths: auto + + * - CPU + - Powered on and clocked. + + * - RAM + - Banks used by the executed code are enabled. + Other banks may be in any state. + + * - System state + - *System ON* + + * - Peripherals + - All can be active. + The state of all inactive peripherals is retained in the hardware flip-flops. + + * - Coprocessors + - All can be active. + The state of inactive coprocessors is retained according to their selected sleep state. + + * - System timer (based on GRTC) + - Active + +This is the power state with the highest power consumption. +The software execution latency is minimal. +The primary source of latency is the wake-up of the ``MRAMC``. +The maximum latency depends on the MRAM power state configured by the System Controller. + +Idle +==== + +*Idle* is the lightest sleep power state available in the system where the cache content is retained. + +.. list-table:: + :widths: auto + + * - CPU + - Powered on but suspended (not clocked). + + * - RAM + - Banks used by the executed code are enabled. + Other banks may be in any state. + + * - System state + - *System ON* + + * - Peripherals + - All can be active. + The local peripherals are powered and preserve their state. + The state of inactive peripherals in other domains is retained in the hardware flip-flops. + + * - Coprocessors + - All can be active. + The state of inactive coprocessors is retained according to their selected sleep state. + + * - System timer (based on GRTC) + - Active + +The power consumption in this state is lower than in *Active*, but higher than in other power states. +The wake-up latency is higher than in *Active*, but lower than in the other power states. +The primary sources of wake-up latency are the wake-up of the ``MRAMC`` and the startup of clock sources. +The maximum latency depends on the MRAM power state configured by the System Controller. + +Local Suspend to RAM +******************** + +*Local Suspend to RAM* is a sleep state that balances between power consumption and wake-up latency. + +This state is available only for DVFS-capable domains. +Other domains, such as Radio, cannot retain the CPU and local peripherals in the *System ON (All) Idle* state. + +In this state, the entire local Active Power Domain, including the CPU, is unpowered. +The state of the CPU and the peripherals powered by the local Active Power Domain is not retained by hardware flip-flops. +Instead, their state is retained by software in RAM. + +.. list-table:: + :widths: auto + + * - CPU + - Unpowered. + Its state is retained in RAM. + + * - RAM + - Enabled or retained depending on the hardware state. + + * - System state + - * *System ON* if at least one other CPU or a peripheral clocked greater than 32 kHz is active. + * *System ON Idle* if all CPUs are disabled and the only active peripherals are clocked with 32 kHz (real-time part of ``GRTC``, ``RTC``, ``WDT``) or System Off wake-up sources. + * *System ON All Idle* if all other CPUs and all peripherals except System Off wake-up sources are disabled. + + The hardware automatically selects one of these states based on the activity of other CPUs and peripherals. + + * - Peripherals + - * Powered by the local Active Power Domain must be disabled. + * Powered by any other power domain can be active. + + The state of the inactive peripherals located in other power domains is retained in the hardware flip-flops. + + It is recommended to use only 32 kHz clocked peripherals in this state to allow entering *System ON Idle*. + One example could be using GPIO as CSN to wake up the system and enable an SPIS peripheral only after the system is woken up. + + * - Coprocessors + - Global can be active. + There are no local coprocessors in the domains supporting this sleep state. + The state of inactive coprocessors is retained according to their selected sleep state. + + * - System timer (based on GRTC) + - Active + +The power consumption in this state depends on the overall System state but is lower than in any of the *Idle* states. +The wake-up latency is higher than in any of the *Idle* states due to the CPU state restoration procedure. + +Selecting the optimal power state +********************************* + +In the nRF54H20 SoC, each local domain is responsible for selecting the power state that results in minimal power consumption while maintaining an acceptable level of performance. + +Entering a deeper sleep state leads to power savings when the system is idle, but it requires increased power consumption to enter and exit the sleep state. +There is a minimum sleep duration that justifies the energy spent on entering and exiting a sleep state, and this duration varies for each sleep state. + +In the SoC, a local domain has full control over entering and exiting local sleep states, allowing it to assess whether entering these sleep states is optimal at any given moment. +However, entering sleep states associated with system-off requires cooperation between local domains and the System Controller. +Local domains have limited control over the time and energy required to enter or exit system-off, as well as the power consumption during system-off. + +Latency management +****************** + +The sources of wake-up latency in the nRF54H20 SoC can be categorized into two types: local and global. +Each CPU is responsible for managing its latency sources, with local sources handled by local domains and global sources managed by the System Controller. + +Local cores are responsible for handling latencies caused by restoring the system from suspend-to-RAM states. +Local cores schedule their wake-up in advance of expected events. +The timing of expected events is reported to the power management subsystem in the RTOS by the software modules anticipating these events. +The power management subsystem sets a ``GRTC`` channel in advance of the next expected event to compensate for local wake-up latency. + +The System Controller is responsible for handling latencies caused by restoring the system from the system-off state (the warm boot procedure latency). +The System Controller schedules the system wake-up from the system-off state in advance of the next ``GRTC`` event to compensate for the warm-boot latency of the system. + +Because the warm-boot latency is compensated by the System Controller, from a local CPU's perspective, the latency when restoring from the local-off state and the system-off state is expected to be the same. + +Latency in local domains +======================== + +Any local software module (like a device driver) can anticipate events like ISRs. +Some of these events have predictable timing, while others have unpredictable timing. +Handling the latency of events with unpredictable timing is the same in both simple and complex systems. + +If handling an event with predictable timing requires restoring the state of the software module or the peripherals used by this module before the event is processed, the software module is responsible for scheduling a timer event in advance. +This scheduled event is used to restore the state of the software module or peripherals. + +The Power Management subsystem in a local domain is responsible for scheduling a wake-up in advance to compensate for the domain's core state restoration latency from the local power state. +The wake-up time scheduled in advance by the power management subsystem is combined with the advance time added by the software module. +This approach ensures that the local domain and the software modules anticipating an event have sufficient time to fully restore before the event occurs, allowing the event to be handled without latency. + +Unretained hardware classification +********************************** + +Some power states in the nRF54H20 SoC result in powering off certain peripherals. +The state of these peripherals is not retained by hardware and must be restored by software before the peripheral is activated. + +See the following sections for the lists of peripheral groups and the related software modules responsible for restoring the peripheral's state for each group. + +Peripherals in local domains +============================ + +All local domains include a common set of hardware modules. +In addition to these, most local domains also contain domain-specific peripherals. + +Common peripherals for all local domains +---------------------------------------- + +Each local domain contains a set of peripherals that are classified consistently across all local domains. +The following table summarizes the active peripherals that need handling when exiting the *Local Suspend to RAM* state. + ++---------------+--------------------+--------------------+--------------------+--------------------------+ +|Type | List of the | Source of data to | Time of restoration| Software module | +| | peripherals | restore | | responsible for restoring| ++===============+====================+====================+====================+==========================+ +|Active | * ``MVDMA`` | Device driver's | Decided by the | The device driver | +|peripherals | | code and data | driver | | ++---------------+--------------------+--------------------+--------------------+--------------------------+ + +Peripherals specific to the Application Domain +---------------------------------------------- + +There are no peripherals specific to the Application Domain. + +Peripherals specific to the Secure Domain +----------------------------------------- + +The Secure Domain contains additional peripherals that require handling in the *Local Suspend to RAM* state. + ++---------------+--------------------+--------------------+--------------------+--------------------------+ +|Type | List of the | Source of data to | Time of restoration| Software module | +| | peripherals | restore | | responsible for restoring| ++===============+====================+====================+====================+==========================+ +|Active | * ``CRACEN`` | Device driver's | Decided by the | The device driver | +|peripherals | | code and data | driver | | ++---------------+--------------------+--------------------+--------------------+--------------------------+ + +Peripherals specific to the Radio Domain +---------------------------------------- + +The Radio Domain does not implement the *Local Suspend to RAM* state. + +Power management benchmark +************************** + +To benchmark the power consumption in *Idle* state, see :ref:`multicore_idle_test`. 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 cad878626bae..5afef511a0a1 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,9 @@ Make sure you have all the required hardware and that your computer has one of t Hardware ======== -* nRF54H20 DK version PCA10175 v0.7.2 (ES3) or PCA10175 v0.8.0 (ES3.3, ES4). - These are the only versions of the nRF54H20 DK compatible with the |NCS| v2.7.0. - Check the version number on your DK's sticker to verify its compatibility with the |NCS| version v2.7.0. +* nRF54H20 DK version PCA10175 v0.8.0 (ES4). + This is the only version of the nRF54H20 DK compatible with the |NCS| v2.7.99-cs1. + Check the version number on your DK's sticker to verify its compatibility with the |NCS| version v2.7.99-cs1. * USB-C cable. Software @@ -81,10 +81,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.0 and its toolchain -********************************************* +Installing the |NCS| v2.7.99-cs1 and its toolchain +************************************************** -You can install the |NCS| v2.7.0 and its toolchain by using Toolchain Manager. +You can install the |NCS| v2.7.99-cs1 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 +109,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.0. + #. In :guilabel:`SDK ENVIRONMENTS`, click the :guilabel:`Install` button next to the |NCS| version 2.7.99-cs1. - The |NCS| version 2.7.0 is installed on your machine. + The |NCS| version 2.7.99-cs1 is installed on your machine. The :guilabel:`Install` button changes to :guilabel:`Open VS Code`. #. Set up the preferred building method: @@ -157,10 +157,10 @@ 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.0 requires the following: +Using the nRF54H20 DK with the |NCS| v2.7.99-cs1 requires the following: * nRF Util version 7.11.1 or above -* nRF Util ``device`` version 2.4.0 +* nRF Util ``device`` version 2.4.6 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,9 +180,9 @@ Using the nRF54H20 DK with the |NCS| v2.7.0 requires the following: nrfutil self-upgrade -#. Install the nRF Util ``device`` command to version 2.4.0 as follows:: +#. Install the nRF Util ``device`` command to version 2.4.6 as follows:: - nrfutil install device=2.4.0 --force + nrfutil install device=2.4.6 --force For more information, consult the `nRF Util`_ documentation. @@ -201,7 +201,7 @@ Programming the BICR The Board Information Configuration Registers (BICR) are non-volatile memory (NVM) registers that contain information on how the nRF54H20 SoC must interact with other board elements, including the information about the power and clock delivery to the SoC. To prepare the nRF54H20 DK for first use, you must manually program the values of the BICR using a precompiled BICR binary file (:file:`bicr_ext_loadcap.hex`). -1. Download the `BICR binary file`_ . +1. Download the `BICR new binary file`_. #. Connect the nRF54H20 DK to your computer using the **DEBUGGER** port on the DK. .. note:: @@ -214,17 +214,17 @@ 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 bicr_ext_loadcap.hex --core Secure --serial-number + nrfutil device program --options chip_erase_mode=ERASE_NONE --firmware build/zephyr/bicr.hex --core Application --serial-number .. rst-class:: numbered-step Programming the SDFW and SCFW ============================= -After programming the BICR, the nRF54H20 SoC requires the provisioning of a bundle ( :file:`nrf54h20_soc_binaries_v0.5.0.zip`) containing the precompiled firmware for the Secure Domain and System Controller. +After programming the BICR, the nRF54H20 SoC requires the provisioning of a bundle ( :file:`nrf54h20_soc_binaries_v0.6.2.zip`) containing the precompiled firmware for the Secure Domain and System Controller. To program the Secure Domain Firmware (SDFW, also known as ``urot``) and the System Controller Firmware (SCFW) from the firmware bundle to the nRF54H20 DK, do the following: -1. Download the `nRF54H20 firmware bundle v0.5.0`_. +1. Download the `nRF54H20 firmware bundle v0.6.2`_. .. note:: On MacOS, ensure that the ZIP file is not unpacked automatically upon download. @@ -235,32 +235,6 @@ To program the Secure Domain Firmware (SDFW, also known as ``urot``) and the Sys .. rst-class:: numbered-step -Updating the FICR -================= - -.. caution:: - This step is required only if your nRF54H20 DK is version PCA10175 v0.7.2 or v0.8.0 ES3.3. - Jump to the next step if your DK is version ES4, meaning v0.8.0 with no ES markings. - -After programming the SDFW and SCFW from the firmware bundle, you must update the Factory Information Configuration Registers (FICR) to correctly configure some trims of the nRF54H20 SoC. -To update the FICR, you must run a J-Link script: - -1. Get the Jlink script that updates the FICR:: - - curl -LO https://files.nordicsemi.com/artifactory/swtools/external/scripts/nrf54h20es_trim_adjust.jlink - -#. Run the script: - - * Linux and Mac OS:: - - JLinkExe -CommanderScript nrf54h20es_trim_adjust.jlink - - * Windows:: - - jlink.exe -CommanderScript nrf54h20es_trim_adjust.jlink - -.. rst-class:: numbered-step - Transitioning the nRF54H20 SoC to RoT ===================================== @@ -332,8 +306,8 @@ To transition the LCS to ``RoT``, do the following: .. _ug_nrf54h20_gs_sample: -Programming the sample -********************** +Building and programming the sample +*********************************** The :zephyr:code-sample:`sysbuild_hello_world` sample is a multicore sample running on both the application core (``cpuapp``) and the Peripheral Processor (PPR, ``cpuppr``). It uses the ``nrf54h20dk/nrf54h20/cpuapp`` board target. @@ -341,18 +315,18 @@ 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.0 toolchain, and click the :guilabel:`Open terminal` button. +#. Open nRF Connect for Desktop, navigate to the Toolchain Manager, select the v2.7.99-cs1 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:: west build -p -b nrf54h20dk/nrf54h20/cpuapp -T sample.sysbuild.hello_world.nrf54h20dk_cpuapp_cpurad . -#. Program the sample. - If you have multiple Nordic Semiconductor devices, make sure that only the nRF54H20 DK you want to program is connected. +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. - .. code-block:: console +.. code-block:: console - west flash + west flash The sample will be automatically built and programmed on both the application core and the Peripheral Processor (PPR) of the nRF54H20. diff --git a/doc/nrf/links.txt b/doc/nrf/links.txt index 14221bbdd6ee..9f8298c480cb 100644 --- a/doc/nrf/links.txt +++ b/doc/nrf/links.txt @@ -1651,9 +1651,14 @@ .. _`nRF54H20 firmware bundle`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.5.0.zip .. _`nRF54H20 firmware bundle v0.3.3`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.3.3.zip .. _`nRF54H20 firmware bundle v0.5.0`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.5.0.zip +.. _`nRF54H20 firmware bundle v0.6.2`: https://files.nordicsemi.com/artifactory/SDSC/external/nrf54h20_soc_binaries_v0.6.2.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 .. _`J-Link version 7.94e`: https://www.segger.com/downloads/jlink/ .. _`J-Link version 7.88j`: https://www.segger.com/downloads/jlink/ + +.. _`Zephyr's nRF clock control API extensions`: https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/drivers/clock_control/nrf_clock_control.h +.. _`clocks devicetree macro API`: https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/devicetree/clocks.h diff --git a/doc/nrf/samples/other.rst b/doc/nrf/samples/other.rst index 37baab622fd4..d7e4ba380729 100644 --- a/doc/nrf/samples/other.rst +++ b/doc/nrf/samples/other.rst @@ -12,3 +12,4 @@ Other samples ../../../samples/ipc/*/README ../../../samples/mpsl/*/README ../../../samples/benchmarks/*/README + ../../../tests/benchmarks/multicore/*/README diff --git a/tests/benchmarks/multicore/idle/README.rst b/tests/benchmarks/multicore/idle/README.rst index c1e1b19c954f..d9586335209d 100644 --- a/tests/benchmarks/multicore/idle/README.rst +++ b/tests/benchmarks/multicore/idle/README.rst @@ -1,5 +1,3 @@ -:orphan: - .. _multicore_idle_test: Multicore idle test @@ -24,6 +22,7 @@ Overview ******** The test demonstrates how to build a multicore idle application with :ref:`configuration_system_overview_sysbuild`. + When building with sysbuild, the build system adds child images based on the options selected in the project's additional configuration and build files. This test shows how to inform the build system about dedicated sources for additional images. The test comes with the following additional files: @@ -41,8 +40,9 @@ Building and running .. include:: /includes/build_and_run_test.txt -The remote board needs to be specified using ``SB_CONFIG_REMOTE_BOARD``. -As shown below, it is recommended to use configuration setups from :file:`testcase.yaml` using the ``-T`` option to build the test. +The remote board must be specified using ``SB_CONFIG_REMOTE_BOARD``. +To build the test, use configuration setups from :file:`testcase.yaml` using the ``-T`` option. +See the following examples: nRF5340 DK You can build the test for application and network cores as follows: @@ -70,7 +70,7 @@ nRF54H20 DK An additional configuration setup is provided to execute code directly from the non-volatile memory (MRAM) on the PPR core. This configuration uses :ref:`zephyr:nordic-ppr-xip` and enables :kconfig:option:`CONFIG_XIP` on the PPR core. - It can be built as follows: + You can build the sample as follows: .. code-block:: console