123 lines
5.0 KiB
ReStructuredText
123 lines
5.0 KiB
ReStructuredText
.. _nrf5340bsim:
|
|
|
|
NRF5340 simulated boards (BabbleSim)
|
|
####################################
|
|
|
|
.. contents::
|
|
:depth: 1
|
|
:backlinks: entry
|
|
:local:
|
|
|
|
|
|
Overview
|
|
********
|
|
|
|
To allow simulating nrf5340 SOCs two Zephyr target boards are provided: the
|
|
``nrf5340bsim/nrf5340/cpuapp`` and ``nrf5340bsim/nrf5340/cpunet``.
|
|
|
|
These use `BabbleSim`_ to simulate the radio activity, and the
|
|
:ref:`POSIX architecture<Posix arch>` and the `native simulator`_ to
|
|
run applications natively on the development system. This has the benefit of
|
|
providing native code execution performance and easy debugging using
|
|
native tools, but inherits :ref:`its limitations <posix_arch_limitations>`.
|
|
|
|
Just like for the nrf5340dk targets,
|
|
the nrf5340bsim/nrf5340/cpuapp build target provides support for the application core,
|
|
and the nrf5340bsim/nrf5340/cpunet build target provides support for the network
|
|
core on the simulated nRF5340 SOC.
|
|
|
|
These boards include models of some of the nRF5340 SOC peripherals:
|
|
|
|
* AAR (Accelerated Address Resolver)
|
|
* AES CCM & AES ECB encryption HW
|
|
* CLOCK (Clock control)
|
|
* DPPI (Distributed Programmable Peripheral Interconnect)
|
|
* EGU (Event Generator Unit)
|
|
* FICR (Factory Information Configuration Registers)
|
|
* IPC (Interprocessor communication)
|
|
* MUTEX (Mutual exclusive peripheral)
|
|
* NVMC (Non-Volatile Memory Controller / Flash)
|
|
* RADIO
|
|
* RNG (Random Number Generator)
|
|
* RTC (Real Time Counter)
|
|
* TEMP (Temperature sensor)
|
|
* TIMER
|
|
* UICR (User Information Configuration Registers)
|
|
|
|
and will use the same drivers as the nrf5340dk targets for these.
|
|
For more information on what is modelled to which level of detail,
|
|
check the `HW models implementation status`_.
|
|
|
|
Note that unlike a real nrf5340 device, the nrf5340bsim boards have unlimited RAM and flash for
|
|
code.
|
|
|
|
.. _BabbleSim:
|
|
https://BabbleSim.github.io
|
|
|
|
.. _native simulator:
|
|
https://github.com/BabbleSim/native_simulator/blob/main/docs/README.md
|
|
|
|
.. _HW models implementation status:
|
|
https://github.com/BabbleSim/ext_nRF_hw_models/blob/main/docs/README_impl_status.md
|
|
|
|
|
|
Building for, and using these boards
|
|
************************************
|
|
|
|
If you are interested in developing on only one of the MCUs in this SOC, you
|
|
can use the corresponding simulated target, nrf5340bsim/nrf5340/cpuapp or nrf5340bsim/nrf5340/cpunet
|
|
following the instructions from the :ref:`nrf52_bsim board <nrf52bsim_build_and_run>`.
|
|
Simply change the board/target appropriately when building.
|
|
|
|
|
|
.. note::
|
|
|
|
Unlike in real HW, the net core MCU is set-up to automatically boot at start, to facilitate
|
|
developing without an image in the application core. You can control
|
|
this with either :kconfig:option:`CONFIG_NATIVE_SIMULATOR_AUTOSTART_MCU`, or the command line
|
|
option ``--cpu1_autostart``.
|
|
|
|
If an MCU is booted without any image, it will automatically set itself to sleep.
|
|
|
|
|
|
Assembling both MCUs images into a single executable
|
|
****************************************************
|
|
|
|
By default, when you build targeting either nrf5340bsim/nrf5340/cpuapp or
|
|
nrf5340bsim/nrf5340/cpunet you will end up with a library (``zephyr/zephyr.elf``) that corresponds
|
|
to that MCU code image, and an executable (``zephyr/zephyr.exe``) that includes the native simulator
|
|
runner, SOC HW models, that image, and an empty image for the other MCU.
|
|
|
|
If you want to assemble an executable including a previously built image for the other MCU,
|
|
built with either Zephyr's build system or another native simulator compatible build system,
|
|
you can provide that image to the Zephyr build of the second image using
|
|
:kconfig:option:`CONFIG_NATIVE_SIMULATOR_EXTRA_IMAGE_PATHS`.
|
|
|
|
You can also use :ref:`System build (sysbuild) <sysbuild>` to build your dual MCU executable.
|
|
The best way to understand how, may be to look into how this is done in one of the examples
|
|
in the tree. For example, for :ref:`the nrf53_sync_rtc sample <nrf53_sync_rtc_sample_build_bsim>`,
|
|
:zephyr_file:`samples/boards/nrf/nrf53_sync_rtc/sysbuild.cmake`.
|
|
|
|
|
|
.. note::
|
|
|
|
These libraries/images are **not** embedded images. You cannot use them for embedded devices,
|
|
and cannot use an embedded image to assemble a native executable.
|
|
|
|
TrustZone, TF-M and other security considerations
|
|
*************************************************
|
|
|
|
ARM's TrustZone is not modelled in these boards. This means that:
|
|
|
|
* There is no differentiation between secure and non secure execution states or bus accesses.
|
|
* All RAM, flash and peripherals are in principle accessible from all SW. Peripherals with their
|
|
own interconnect master ports can, in principle, access any other peripheral or RAM area.
|
|
* There is no nrf5340bsim/nrf5340/cpuapp/ns board/build target, or posibility of mixing secure
|
|
and non-secure images.
|
|
* Currently there is no model of the SPU, and therefore neither flash, RAM areas or peripherals
|
|
can be labelled as restricted for secure or non secure access.
|
|
* TF-M cannot be used.
|
|
|
|
Note that the ARM cryptocell-312 peripheral is not modelled. The mbedTLS library can still be used
|
|
but with a SW crypto backend instead of the cryptocell HW acceleration.
|