The stack guard report this testcase has the stack overflow issue. To
fix the issue, slightly increse the stack size.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
The README file for led_xec sample had several formatting issues
causing it to render very poorly.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Moving from APPLICATION level to POST_KERNEL and keeping both parent and
child on the same level is causing problems, so fix this by putting them
on different priorities in POST_KERNEL.
Also, this sample runs fine in qemu, so make it the integration
platform.
Fixes#62772
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This migrates the subsys code samples to the new Sphinx code-sample
extension, making it easier to find relevant samples when browsing
API reference.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Fix missing Coded PHY implementation conditional compile
causing compile error when disabling Coded PHY support in
SoCs that have radio that support Coded PHY.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fixed pinout in adc overlays to align with board
Allowed adc driver sample
Added overlay for gpio_basic_api test support
Added overlay for i2c_api test support
Signed-off-by: Pavlo Havrylyuk <pavlo.havrylyuk@infineon.com>
Replace the BT_AUDIO_CODEC_LC3_ID macro with the
BT_HCI_CODING_FORMAT_LC3 as there is no reason to
define and use the LC3 ID different than the other
allowed codec IDs.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Demonstrate use of the Raspberry Pi Pico PIO SPI driver.
Added rpi_pico test cases to sample.yaml
Signed-off-by: Steve Boylan <stephen.boylan@beechwoods.com>
Modify the bt_bap_broadcast_source_reconfig to use the same
parameter struct as bt_bap_broadcast_source_create so that
the two are more similar, since they both set the same values.
This allow for full control of which subgroups and stream
are updated.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Try to catch issues related to platforms and HAL changes using this
basic sample. We have the same flag for a kernel test, but this is
skipped if no kernel changes are present in the PR, so we were missing
some coverage of platform related changes.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Use the new code-sample directive and roles to document the networking
samples so that they show up as "Related samples" when browsing the
various relevant networking APIs.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Use the new code-sample directive and roles to document the video
capture samples so that they show up as "Related samples" when browsing
the API documentation.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Use the defind value, BT_APPEARANCE_WEARABLE_AUDIO_DEVICE_EARBUD,
instead of the hard coded "magic numbers".
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The sample did not properly include the source
context in the advertising data.
It also set different contexts for PACS and the advertising data
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Rework RAM disk driver to be configured using devicetree and
support multiple instances.
This patch also removes a copy of the RAM disk driver,
tests/subsys/fs/fat_fs_dual_drive/src/disk_access_test_drv.c,
that was there for testing multiple disk drivers support.
Bonus: one SYS_INIT() less and a memory region can be exported to the
host.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The fuel gauge API uses separate get/set property structs to indicate what
properties are readable or writable. This lead to duplication in property
names and potential confusion for new users of the API. See issue #61818.
In addition to above, drivers already determine at runtime if a property is
supported for read or write actions.
Join the get/set fuel gauge property structs as a single struct.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
The mr_canhubk3 board enables by default an off-chip watchdog that must
be serviced to avoid triggering a reset and cannot be disabled on a
per-test basis.
The amount of data printed on this test prevents to initialize the
on-board watchdog within the expected window, causing a board reset.
Hence do not run the test on mr_canhubk3 board.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Convert the driver to a dt-based device. Also update Kconfig so that it
depends on the right compatible being enabled, initialize in POST_KERNEL
(APPLICATION should not be used for devices) and remove one redundant
include.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Introduce a helper function zephyr_nanopb_sources to generate
source files and add these to a target.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Use the new code-sample directive and roles to document the filesystem
samples so that they show up as "Related samples" when browsing the API
documentation.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add a MBOX driver wrapper around the NXP MU, simular to
the existing wrapper around the NXP S32 MRU. This allows Zephyr IPC
to work based on the MU, on a number of NXP boards.
Also update the SHA of NXP HAL to enable the Kconfig for this driver.
Signed-off-by: Yicheng Li <yichengli@google.com>
To achieve minimal power consumption, only the console (ie UART) needs
to be suspended. Note that this is a temporary workaround, UART driver
should be using device runtime PM so that this is not needed.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Wake-up from pin is already supported when configuring GPIO interrupt as
GPIO_INT_LEVEL_ACTIVE, so there's no need to resort to HAL.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
