Remove the top-level "structured data" group as in practice it was used
only by JSON APIs.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new top-level group for APIs that interact with third-party
services or applications. Included in the group:
- MCUboot image control API
- Hawkbit
- UpdateHub
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
While these APIs are kind of independent from the PM subsys (why?), they
all belong to the "power management" domain, so add them to the
subsys_pm group.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new top-level for general utilities, like utility functions,
linear range API, time utils, etc. This category should be used by stuff
that is not strictly bound to the OS, like are OS services.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a USB Doxygen group, part of the top-level connectivity group.
Added some existing groups to the usb group, note that USB Doxygen needs
to be improved, though.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new connectivity group and add to it the following other groups:
- LoRaWAN
- Networking
- Bluetooth
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Testing NMI on emulated QEMU platforms brings some interesting and wrong
results like:
START - test_arm_runtime_nmi
Trigger NMI in 10s: 0 s
Trigger NMI in 10s: 1 s
Trigger NMI in 10s: 2 s
Trigger NMI in 10s: 3 s
Trigger NMI in 10s: 4 s
Trigger NMI in 10s: 5 s
Trigger NMI in 10s: 6 s
Trigger NMI in 10s: 7 s
Trigger NMI in 10s: 8 s
Trigger NMI in 10s: 9 s
NMI triggered (test_handler_isr)!
Assertion failed at ... arm_runtime_nmi_fn_test_arm_runtime_nmi:
(nmi_triggered is false)
Isr not triggered!
where the NMI handler is correctly called, see `NMI triggered`, but the
assert still fails on `nmi_triggered` being false.
This is due to a limitation in the emulation but also in the test not
being strictly architecturally compliant (you need a DSB;ISB sequence
after writing to SCB).
Add the proper barriers after writing to `SCB->ISCR` to make it
compliant and making it pass on QEMU as well.
Also reduce the timing to 2 sec.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The NRF timer emulated by QEMU is not behaving correctly when icount is
used.
This is easily reproducible with the following snippet:
unsigned int key = irq_lock();
k_busy_wait(15000);
irq_unlock(key);
printk("done\n");
where the `printk` is never executed and `k_busy_wait` is never left.
This particular code is only mis-behaving when `-icount` is used:
This works fine:
qemu-system-arm -cpu cortex-m0 -machine microbit -nographic
-kernel build/zephyr/zephyr.elf -rtc clock=vm
This doesn't work:
qemu-system-arm -cpu cortex-m0 -machine microbit -nographic
-kernel build/zephyr/zephyr.elf -rtc clock=vm
-icount shift=6,align=off,sleep=off
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
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>
It's long forgotten what is the issue the comment in this FIXME is
referring to, but the clock is currently running at twice the frequency
on the qemu_cortex_m0.
This is easily provable comparing the k_msleep() delay to the wall
clock. For example:
while (1) {
k_msleep(1000);
printk("hello\n");
}
is printing "hello" at 2Hz instead of 1Hz when running with:
qemu-system-arm -cpu cortex-m0 -machine microbit -nographic -kernel
build/zephyr/zephyr.elf
Fix this by setting the correct pre-scaler value.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Suggested-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Recently, a race condition was discovered in `pthread_create()`
and `pthread_join()` that would trigger an assertion in
`kernel/sched.c` of the form below.
```
aborted _current back from dead
```
This was mainly observed in Qemu. Unfortunately, Qemu SMP
platforms exhibit a real and measurable "scheduler noise"
which makes testing rather difficult.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
The `aborted _current back from dead` error may appear in this
particular test under Qemu (and in particular Qemu SMP) systems.
A small delay between `pthread_create()` and `pthread_join()`
is sufficient to mitigate the issue.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
add explicit boolean type to 'if' statement controlling expression,
consolidating it with 'stm32_exti_callback_t' (function pointer), thus
improving code readability and maintainability, complying with required
[misra-c2012-14.4] rule which states; The controlling expression of an
if statement and the controlling expression of an iteration-statement
shall have essentially Boolean type.
Found as a coding guideline violation (Rule 14.4) by static code
scanning tool.
Note: Tested on STM32L5 Nucleo-144 board (stm32l552xx).
Signed-off-by: ferar alashkar <ferar.alashkar@gmail.com>
When CCC or CF store on write is disabled and the other one is enabled,
leading to the delayed store being enabled. This cause the value of the
corresponding `n` selected option to not be stored at all.
To fix this, the checks to know if we need to store the CCC or the CF,
happening at the disconnection, are now ensuring that the CCC or the CF
are stored even if the one of them does not enable store on write.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Update `ccc_store` bsim test to remove the 'expected failure'. The issue
being fixed in the following commit.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
If XCC toolchain is clang based, enabled C11 features by
defining TOOLCHAIN_HAS_C_GENERIC and TOOLCHAIN_HAS_C_AUTO_TYPE.
Mirror the definitions in include/zephyr/toolchain/llvm.h
This is required to build Zephyr with features requiring
tagged arguments like LOG_MIPI_SYST_USE_CATALOG.
Suggested-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
change for loop iterator/counter type to unsigned int, thus matching
that of struct stm32_exti_range's len member var, complying with
required [misra-c2012-10.4] rule which states; Both operands of an
operator in which the usual arithmetic conversions are performed shall
have the same essential type category.
Found as a coding guideline violation (Rule 10.4) by static code
scanning tool.
Note: Tested on STM32L5 Nucleo-144 board (stm32l552xx).
Signed-off-by: ferar alashkar <ferar.alashkar@gmail.com>
add enclosing parentheses enforcing and clarifying precedence of
operators, thus improving code readability and maintainability,
complying with *advisory* [misra-c2012-12.1] rule which states; The
precedence of operators within expressions should be made explicit.
Found as a coding guideline recommendation (Rule 12.1) by static code
scanning tool.
Note: Tested on STM32L5 Nucleo-144 board (stm32l552xx).
Signed-off-by: ferar alashkar <ferar.alashkar@gmail.com>
Remove the lower check (BT_BAP_BASS_OP_SCAN_STOP) in
BT_BAP_BASS_VALID_OPCODE as it is always used on unsigned
variables, so no point in check if it is lower than 0.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Add check for the index in the function itself, as well as where
we call it internally, to ensure that we do not attempt to access
invalid indexes of broadcast_assistant.recv_state_handles.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
`tfm_fwu_api.c` was missing from the list of possible source files
to be exported from TF-M, which is required when
`CONFIG_TFM_PARTITION_FIRMWARE_UPDATE` is defined.
Signed-off-by: Kevin Townsend <kevin.townsend@linaro.org>
The include/zephyr/drivers/clock_control/stm32_clock_control.h header
file treats F2X, F4X and F7X as all being supported by the stmf4_clock.h
header. However, the F7 has additional clocks that are available as domain
clocks for devices (such as the stm32 uart) and these do not work with
the f4 header.
Signed-off-by: Nick Stoughton <nstoughton@logitech.com>
This fixes missing `CONFIG_*` prefix.
The `BT_HAS_PRESET_CONTROL_POINT_NOTIFIABLE` option is already guarded
with `BT_HAS_PRESET_SUPPORT`, so it has been removed from `depends on`
condition.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
This fixes regression causing compilation errors seen when the
code is built without preset support (BT_HAS_PRESET_COUNT = 0).
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Since clocks aren't declared in the devicetree for the stm32mp1
co-processor. Set it here to match the clock for the board
stm32mp157c_dk2 board setup in u-boot and the linux kernel.
This will fix the clock speed declared for timers etc.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
nvs_sector_close has not been initializing nvs_ate.part, before
writing it to flash.
Fixes#58699
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Added assert when looking up the next instance, as the caller of this
function should ensure that the index is correct before calling
discover_next_instance.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
If the minimal value of an IN_RANGE is 0, then it is
a useless check, and the cases have been modified to
not use IN_RANGE. This also fixes some coverity issues.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The check was a && but should have been an ||. Fixed by moving
the check to a new if statement.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When notify_app is called for BT_TBS_CALL_OPCODE_TERMINATE
we did a lookup on the call index, but never did a NULL check
before dereferecing it.
This does not fix the issue that the instance will always
be NULL in this case, as we have terminated the call so
we cannot possibly look up the call afterwards.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The friendly copy always assumed that the friendly name could
fit in memory, which could cause overflows. Fixed by using
utf8_lcpy as that not only ensures that the copy is truncated
to fit in memory, but also ensures that it is null terminated
and truncated in a way that supports multi-byte UTF8 characters.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The previous implementation would read from `addr->val[0]` before it was
initialized if the input string started with a colon ':'.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
send_simple_coap_request needs to return a result from previous functions
instead of success at the end of the function. Without doing so the example
may wait for a response from a coap sever when a message failed to send.
Signed-off-by: Matthew Bradbury <matt-bradbury@live.co.uk>
The DW driver used by the RP2040 boards uses a Kconfig symbol
to determine the clock speed of the board. This value was
set incorrectly by the pico board to 100MHz (instead of 125).
For the other boards, it wasn't set at all.
This commit fixes the kconfig defaults. In the future, this
value should be taken directly from the devicetree. This is
not currently possible as there is no clock control driver
for the RP2040 (see #52901).
Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
As a result of the 11a2107d991b("riscv: timer: driver revamp") commit,
gd32vf103 no longer works properly.
In the
c9c04e491e0f("soc: riscv: Add initial support for GigaDevice GD32V SoC")
that is the first commit of implementation of this SoC,
set the CPU frequency to CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC,
and riscv_machine_timer divide the clock with the value of
CONFIG_RISCV_MACHINE_TIMER_SYSTEM_CLOCK_DIVIDER.
The CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC should set the timer's clock,
so I fixed to set the config as 27MHz in this PR. Also, remove the
unnecessary CONFIG_RISCV_MACHINE_TIMER_SYSTEM_CLOCK_DIVIDER setting.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is not always the same as CPU frequency.
Referring to the `/cpus/cpu@0,clock-frequency` in DTS to determine
the CPU frequency.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
