nRF53/91 require usage of nrf_regulators_system_off, so the API is not
common with nRF51/52. This was an oversight during the conversion.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Nordic SoCs do all power management automagically when going to idle (ie
k_cpu_idle()). The only extra state, system off, is now handled via
sys_shutdown(), so there's no need to support the PM subsystem.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Remove unnecessary __weak attribute from power management functions.
These functions are now defined once, globally, and mandatory for
systems that support CONFIG_PM.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add a new Kconfig option that has to be selected by SoCs providing PM
hooks. This option will be now required to enable CONFIG_PM. Before this
change, CONFIG_PM could always be enabled, regardless of SoC providing
any kind of low-power support.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
On nRF5340 net core it was observed that when `wfi` instruction was
followed by `pop {r0, lr}` in the `arch_cpu_idle` function,
the value of `lr` sometimes got read as 0 from memory despite
having correct value stored in the memory.
This commit inserts additional `nop` instruction after waking up
to delay access to the memory.
Signed-off-by: Andrzej Kuroś <andrzej.kuros@nordicsemi.no>
NMI_INIT() is now a no-op, so remove it from all SoC code. Also remove
the irq lock/unlock pattern as it was likely a cause of copy&paste when
NMI_INIT() was called.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The Nordic board are selecting CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT by
default and rely on some HAL code to implement a cycle accurate busy
delay loop.
This is in general fine for real hardware but when QEMU and emulation is
taken into account, a cycle accurate busy wait implementation based on
delay in executing machine code can be misleading.
Let's take for example qemu_cortex_m0 (that is based on the nRF51
chipset) and this code:
uint32_t before, after;
while (1) {
before = k_cycle_get_32();
k_busy_wait(1000 * 1000);
after = k_cycle_get_32();
printk("diff cycles: %d\n", after - before);
}
With CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=1000000 this diff cycles should
be always around 1000000, in reality when executed with:
qemu-system-arm -cpu cortex-m0 -machine microbit -nographic
-kernel build/zephyr/zephyr.elf
This results in something like this:
diff cycles: 22285
diff cycles: 24339
diff cycles: 21483
diff cycles: 21063
diff cycles: 21116
diff cycles: 19633
This is possibly due to the fact that the cycle accurate delay busy loop
is too fast in emulation.
When dealing with QEMU let's use the reliable busy loop implementation
based on k_cycle_get_32() instead.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Although existing nRF SoCs have only one I2S instance, the nrfx_i2s
driver has now multi-instance API and the related nrfx configuration
symbols need to be used appropriately.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Clearing of shared memory by one side of the communication
is no longer required after
commit 0620cb1fe1
("ipc: ipc_service: icmsg: Increase reliability of bonding")
was merged.
Signed-off-by: Emil Obalski <Emil.Obalski@nordicsemi.no>
Deprecates setting GPREGRET to the reset reason as this has been
replaced with the boot mode retention subsystem for nRF51/nRF52.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This prevents configuration errors if a board is configured when
the SoC indicates segger RTT support but the segger module is
not available.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
The nRF9161 is technically a SiP (System-in-Package) that consists of
the nRF9120 SoC and additional components like PMIC, FEM, and XTAL,
so for nrfx/MDK the nRF9120 SoC is to be selected as the build target,
but since the nRF9161 is what a user can actually see on a board, using
only nRF9120 in the Zephyr build infrastructure might be confusing.
That's why in the top level of SoC definitions (for user-configurable
options in Kconfig, for example) the nRF9161 term is used and nRF9120
underneath.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Use one common `if SOC_SERIES_NRF52X` instead of `depends on` for
each particular SoC option.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commit 4be102f8e05a9fa12290d8209a8cb38569265478.
Inclusion of `<system_nrf*.>` from `soc.c` files is no longer needed
since `SystemInit()` is not called from those files.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove per soc definitions that are already defined in the exact same
way in include/zephyr/arch/arm/aarch32/nmi.h.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Initialization part of this anomaly is now handled internally
by the startup code provided by the MDK.
Signed-off-by: Nikodem Kastelik <nikodem.kastelik@nordicsemi.no>
In general, RTC and TIMER driver implements counter API but there
are exception when those peripherals are used in a custom way
(e.g. for system timer or bluetooth). In that case, system must
prevent using counter based on a reserved instance. Previously,
it was managed by Kconfig options but that cannot be maintained
when switching to devicetree configuration of the counter driver.
A new approach removes Kconfig options and instead adds static
asserts in the files which are using direct peripherals. Those
asserts check if given node is not enabled in the device tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This is a follow-up to commit 7195db01f4.
Restore the check that was accidentaliy removed in the above commit,
so that the message is again logged only once per detection of the
anomaly 160 conditions.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commit fe3b97a87f.
This message should not be a warning, as it does not actually indicate
that something potentially bad happened. On the contrary, it informs
that conditions in which the anomaly 160 could occur were detected and
the anomaly was prevented from occurring. There is no need for this
message to appear in the default configuration (INFO level). In fact,
the message would undesirably flood the console in some cases (like
the kernel/mem_protect/stack_random test) and sometimes it would also
require enlarging the stack of the idle thread (the function is called
underneath k_cpu_idle()). Therefore, the logging level of this message
is changed to DEBUG.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Since PINCTRL and pinctrl-0 is now required, there's no point in doing
extra validation at driver level. Modify the macro to just check that
sleep state is present when needed, since it was the only remaining
assertion that was not covered. Renamed the macro to make it more clear
what it does: NRF_DT_CHECK_NODE_HAS_PINCTRL_SLEEP
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This is a follow-up to commit fe3b97a87f.
Add a cmake warning issued when the workaround for the nRF5340 anomaly
160 cannot be applied because the application is configured with no
system clock.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Implement a workaround for the nRF53 anomaly 160. This consist of
a set of writes to certain hardware registers that is done at boot
and a piece of code that is executed when the CPU is made idle and
that prevents the CPU from switching between active and sleep modes
more than five times within a 200 us period.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The nRF HW models have been updated to correspond to a 52833 instead
of a 52832. Let's follow them.
The motivation for the change is to enable proper BIS encryption support
(for BT LE Audio ISO).
Changes:
* Point in manifest to latest HW models
* SOC_COMPATIBLE_NRF52832 has been removed, and SOC_COMPATIBLE_NRF52833
added in its place (with no uses at this point)
* Where SOC_COMPATIBLE_NRF52832 was used to set encryption like for a 52832
(to avoid using the MAXPACKETLENGHT), we set the condition to just
SOC_NRF52832.
Note: The MAXPACKETLENGHT register exists in the new simulated nrf52833,
thought it does nothing.
* In the BLE ctrl LLL radio HAL, all macros are renamed accordingly
(timings are NOT changed).
* Board dts definition now refers to the 52833 soc definition. New 52833
features set as not supported by now.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The value in this bitfield is provided in the two's complement form,
so it requires special handling. Previously, it was read as just an
unsigned value and this could result in a wrongly computed CAPVALUE.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Enabling by default (if SPI3 used) because it affects all revisions
since "Engineering B", including the most recent one as of today
(revision 3).
Size changes when enabled:
- -Og: flash +160 bytes (+0.02%), RAM +8 bytes (+0.01%)
- -Os: flash +144 bytes (+0.02%), no change to RAM usage
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Clean up occurrences of "#if IS_ENABLED(CONFIG_FOO)" an replace
with classical "#if defined(CONFIG_FOO)".
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
The icmsg backend for ipc_service has a limitation of supporting only
on endpoint. This limitation is acceptable for many IPC instances.
However, some require to use multiple endpoints sharing a single
instance. To preserve the simple and the most efficient single-instance
backend, a separated backend is introduced implementing a wrapper
around icmsg core which adds multiple endpoints support.
There are two multi-endpoint ipc_service icmsg backends: one in the
initiator role, and the other one in the follower role. In a IPC
configuration one end of communication must be in the follower role
while the other one is in the initiator. The initiator initiates
an endpoint discovery handshake to establish enpoint identifiers for
requested endpoint names. The follower responds to requests sent by
the initiator.
Signed-off-by: Hubert Miś <hubert.mis@nordicsemi.no>
Allow building for nRF non-secure and TF-M enabled without having the
platform partition enabled.
In this configuration the soc_secure functions have no valid
implementation, leave it as a compilation error if the application
includes the functions.
Add missing dependency on soc_secure functions being available for
SOC_HFXO_CAP_INTERNAL configuration.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Make Kconfig produce an error when GPIOs cannot be forwarded in the
current configuration instead of silently excluding the forwarding.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit replaces API that became deprecated with the release
of nrfx2.9 - see CHANGELOG in zephyrproject-rtos:hal_nordic repository
Signed-off-by: Adam Wojasinski <adam.wojasinski@nordicsemi.no>
Increase the default user-allocable number of RTC channels to meet
the nrf_802154 driver requirements.
Signed-off-by: Adam Zelik <adam.zelik@nordicsemi.no>
Remove NET_CONFIG_IEEE802154_DEV_NAME in favor of DT based choice using
zephyr,ieee802154.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
All IEEE 802.15.4 drivers are now automatically enabled if they are
'okay' in DT and all of its dependencies are 'y', including
CONFIG_IEEE802154. This means individual driver enablement is not
necessary anymore in Kconfig.defconfig files or samples/tests. Boards
need to still make sure any dependencies are enabled, e.g. SPI bus in
some cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use Devicetree to describe the radio and IEEE 802.15.4. This allows to
remove usage of IEEE802154_NRF5_DRV_NAME in preparation for the
removal of NET_CONFIG_IEEE802154_DEV_NAME.
All SoC files have been updated with the addition of an ieee802154 node
(disabled and only on those SoCs that define ieee802154-supported. The
peripheral has been enabled in the nRF52840DK board (used for testing
ieee802154).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Include linker sections header to move z_arm_platform_init to text
section. It is now is placed in the TEXT section.
Signed-off-by: Bernard Lee <bernard.lee@nordicsemi.no>
Set SYS_CLOCK_TICKS_PER_SEC to 128 for non-tickless kernel.
Previously it was set to 32768 disregarding kernel mode and that
lead to too frequent interrupts in non-tickless mode (tick every
30 us). Change to smaller value.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The drive-mode property is nRF specific, so prefix it with `nordic,`,
same as the `nordic,invert` property.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This is a follow-up to commit 586e26e8fc.
Add missing `qdec0` node labels in definitions of SoCs that have only
one QDEC instance so that the `HAS_HW_NRF_QDEC0` option is properly set
for them. Use the same pattern as in the WDT case and keep the existing
`qdec` labels for backward compatibility.
Also update validation of base addresses so that both QDEC0/QDEC and
QDEC1 are checked.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
