1.. _nrf5340bsim:
2
3NRF5340 simulated boards (BabbleSim)
4####################################
5
6.. contents::
7   :depth: 1
8   :backlinks: entry
9   :local:
10
11
12Overview
13********
14
15To allow simulating nrf5340 SOCs two Zephyr target boards are provided: the
16``nrf5340bsim/nrf5340/cpuapp`` and ``nrf5340bsim/nrf5340/cpunet``.
17
18These use `BabbleSim`_ to simulate the radio activity, and the
19:ref:`POSIX architecture<Posix arch>` and the `native simulator`_ to
20run applications natively on the development system. This has the benefit of
21providing native code execution performance and easy debugging using
22native tools, but inherits :ref:`its limitations <posix_arch_limitations>`.
23
24Just like for the nrf5340dk targets,
25the nrf5340bsim/nrf5340/cpuapp build target provides support for the application core,
26and the nrf5340bsim/nrf5340/cpunet build target provides support for the network
27core on the simulated nRF5340 SOC.
28
29These boards include models of some of the nRF5340 SOC peripherals:
30
31* AAR (Accelerated Address Resolver)
32* AES CCM & AES ECB encryption HW
33* CLOCK (Clock control)
34* DPPI (Distributed Programmable Peripheral Interconnect)
35* EGU (Event Generator Unit)
36* FICR (Factory Information Configuration Registers)
37* IPC (Interprocessor communication)
38* MUTEX (Mutual exclusive peripheral)
39* NVMC (Non-Volatile Memory Controller / Flash)
40* RADIO
41* RNG (Random Number Generator)
42* RTC (Real Time Counter)
43* TEMP (Temperature sensor)
44* TIMER
45* UICR (User Information Configuration Registers)
46
47and will use the same drivers as the nrf5340dk targets for these.
48For more information on what is modelled to which level of detail,
49check the `HW models implementation status`_.
50
51Note that unlike a real nrf5340 device, the nrf5340bsim boards have unlimited RAM and flash for
52code.
53
54.. _BabbleSim:
55   https://BabbleSim.github.io
56
57.. _native simulator:
58   https://github.com/BabbleSim/native_simulator/blob/main/docs/README.md
59
60.. _HW models implementation status:
61   https://github.com/BabbleSim/ext_nRF_hw_models/blob/main/docs/README_impl_status.md
62
63
64Building for, and using these boards
65************************************
66
67If you are interested in developing on only one of the MCUs in this SOC, you
68can use the corresponding simulated target, nrf5340bsim/nrf5340/cpuapp or nrf5340bsim/nrf5340/cpunet
69following the instructions from the :ref:`nrf52_bsim board <nrf52bsim_build_and_run>`.
70Simply change the board/target appropriately when building.
71
72
73.. note::
74
75   Unlike in real HW, the net core MCU is set-up to automatically boot at start, to facilitate
76   developing without an image in the application core. You can control
77   this with either :kconfig:option:`CONFIG_NATIVE_SIMULATOR_AUTOSTART_MCU`, or the command line
78   option ``--cpu1_autostart``.
79
80   If an MCU is booted without any image, it will automatically set itself to sleep.
81
82
83Assembling both MCUs images into a single executable
84****************************************************
85
86By default, when you build targeting either nrf5340bsim/nrf5340/cpuapp or
87nrf5340bsim/nrf5340/cpunet you will end up with a library (``zephyr/zephyr.elf``) that corresponds
88to that MCU code image, and an executable (``zephyr/zephyr.exe``) that includes the native simulator
89runner, SOC HW models, that image, and an empty image for the other MCU.
90
91If you want to assemble an executable including a previously built image for the other MCU,
92built with either Zephyr's build system or another native simulator compatible build system,
93you can provide that image to the Zephyr build of the second image using
94:kconfig:option:`CONFIG_NATIVE_SIMULATOR_EXTRA_IMAGE_PATHS`.
95
96You can also use :ref:`System build (sysbuild) <sysbuild>` to build your dual MCU executable.
97The best way to understand how, may be to look into how this is done in one of the examples
98in the tree. For example, for :ref:`the nrf53_sync_rtc sample <nrf53_sync_rtc_sample_build_bsim>`,
99:zephyr_file:`samples/boards/nrf/nrf53_sync_rtc/sysbuild.cmake`.
100
101
102.. note::
103
104   These libraries/images are **not** embedded images. You cannot use them for embedded devices,
105   and cannot use an embedded image to assemble a native executable.
106
107TrustZone, TF-M and other security considerations
108*************************************************
109
110ARM's TrustZone is not modelled in these boards. This means that:
111
112* There is no differentiation between secure and non secure execution states or bus accesses.
113* All RAM, flash and peripherals are in principle accessible from all SW. Peripherals with their
114  own interconnect master ports can, in principle, access any other peripheral or RAM area.
115* There is no nrf5340bsim/nrf5340/cpuapp/ns board/build target, or posibility of mixing secure
116  and non-secure images.
117* Currently there is no model of the SPU, and therefore neither flash, RAM areas or peripherals
118  can be labelled as restricted for secure or non secure access.
119* TF-M cannot be used.
120
121Note that the ARM cryptocell-312 peripheral is not modelled. The mbedTLS library can still be used
122but with a SW crypto backend instead of the cryptocell HW acceleration.
123