You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Alberto Escolar Piedras c5daf6abe8 ECB: Provide cheat interface to adjust the time it takes to complete
Signed-off-by: Alberto Escolar Piedras <>
3 days ago
.github/workflows ci: Fetch less and in own folders 10 months ago
docs docs: Add notes on ARM peripherals 2 weeks ago
src ECB: Provide cheat interface to adjust the time it takes to complete 3 days ago
zephyr Convert into a west module 3 years ago
.gitignore gitignore: ignore typical project files 3 years ago
CMakeLists.txt nrfx: Use actual nrfx instead of manually modified files 3 years ago
Depends First commit 5 years ago
Makefile Model a nrf52833 instead of a nrf52832 2 months ago
TODO.txt RADIO: Handle 15.4 packet format at Rx 3 weeks ago
version Add version file 1 week ago


Models of some of the HW present in a NRF52xxx

Where relevant differences exist, these models try to align with a NRF52833.

This repo contains both models of the NRF52 HW as well as some replacement nrfx HAL functions. When used in combination with the real nrfx, these should enable code meant for the nrfx to run without needing further changes. This includes Zephyr SW.

When compiling this component using the provided Makefile (not with Zephyr's build system), the environment variable NRFX_BASE must be set to the path where a nrfx has been cloned. The nrfx must be at least version 2.3.0. So for example, if the nrfx has been cloned as:

cd /some_path/nrfx/
git clone .

NRFX_BASE must be set as:

export NRFX_BASE=/some_path/nrfx/

See the nrfx/hal/ for more details.

These models can be used directly with Zephyr's nrf52_bsim target.

The NRF_RADIO peripheral model uses BabbleSim for the radio environment simulation.

For more information about the HW models, or how to use them without the nrf52_bsim please refer to

Faithfullness of these models

These models are accurate enough to allow the current Zephyr to run, and its BLE stack to function. For more details please see the notes on the source files for each peripheral model.

These models are based solely on the public SOC specifications

They have been developed without any other knowledge and probably contain inacuracies, and defects.

Several of the peripherals which are not necessary for typical BLE applications are not modelled. Moreover, in the modelled peripherals, functionality which is not used in the Zephyr drivers is normally not modelled either. The TODO file list some mayor omissions. It is certainly possible to expand these models to include the rest.

About the ARM processor peripherals

These models do not include the ARM processor peripherals (for ex. the SCB) Even though it would be technically possible to add those, it is considered both risky and unnecessary.

Risky in the sense that adding the equivalent register structures would immediately hide the compiler errors which otherwise would identify the places in which they are used in the embeded code; while at the same time these models would not be precise enough to not require, with very high likelyhood, modification of that part of the embedded code which was using them.

And unnecessary in the sense that the lack of these peripherals can be hidden most of the time if the CMSIS-Core APIs are used instead of direct register accesses, and where these APIs do not provide the necessary functionality, changes to the embedded code would be needed with high likelyhood to trigger sideeffects or so.