Update the sample.tmpl file so that it encourages people to use the new
:zephyr:code-sample: directive.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Enable these tests only for H7 and if DMA is not enabled, as
running them with DMA would require modifying the dmamux
configuration in devicetree to move half-words instead of
bytes.
Signed-off-by: Daniel Gaston Ochoa <dgastonochoa@gmail.com>
LOG_LEVEL > LOG_LEVEL_OFF guards were protecting a couple of function
declarations. These functions were being used without taking this fact
into consideration. These guards are now applied around the stack_stats()
function only.
Signed-off-by: Diogo Correia <diogo.correia@fraunhofer.pt>
In this board, there are eight PWM channels from
EMIOS 0 CH0 --> EMIOS 0 CH7 that can be used to
generate PWM pulse to outside of the board.
Moreover, there are three RGB leds that can use
PWM pins for blinking, faded leds
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
This introduces PWM driver with supporting PWM output
APIs based on NXP S32 EMIOS peripheral. This supports
three mode: OPWFMB, OPWMCB and OPWMB.
OPWFMB uses internal counter, the new period and duty
cycle takes effect immediately.
OPWMCB and OPWMB use external counter as timebase, changing
PWM period at runtime will impact to all channels share the
same timebase. Also the new period and duty cycle take effect
in next period boundary of the timebase
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
This PR adds a misc driver for NXP S32 eMIOS peripheral.
eMIOS provides multiple unified channels (UCs), there are
several channels can be used as reference timebase
(master bus) for other channels. At this time, the
driver does initialize global configuration for eMIOS
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
This commit improves the usage of the bus pipe (connected
to UART) to only open it when the modem is actually
powered and ready, not when leaving the idle state. This
ensures the pipe is flushed before sending the init script,
and re-enables the UART driver if it is disabled due to
errors.
While building a test platform based on the nRF9160 and a
Quectel BG95, it was discovered that the nRF9160 correctly
throws UART errors if the RX is enabled while the UART RX
line is low (which was due to the modem being powered
down).
The improvements should also help help remove the
"<wrn> modem_chat: receive buffer overrun" warning which
would occur during startup as the pipe was opened, but
nothing was receiving the data, causing the buffer to
overflow.
Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
The backend currently returns the pipe closed event immediately
after calling uart_rx_disable() which is not the correct behavior.
the pipe closed event should be called when the UART_RX_DISABLED
event is raised by the UART driver.
With this fix, back-to-back open/close/open... will work as
expected, where before the second open would often fail since
the UART was not actually disabled yet.
Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
LinkServer is NXP's tool to flash and debug on MCU's.
This patch expands support for LinkServer to MIMXRT1170.
There is one limitation with flashing and debugging the SoC's seciond
core (COrtex M4) that will be addressed with a future submission.
Signed-off-by: Yves Vandervennet <yves.vandervennet@nxp.com>
Remove ifdef around `srcs` and let linker exclude it when Opcode
Aggregator Client model is not enabled.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
If the bonding information has been cleared before pairing had a chance
to complete (probably by the application), indicate this by setting an
appropriate log message.
Also check that keys exist before calling `bt_keys_store`.
Fixes#59788 and #61465
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Update TF-M version with fix for build with shared boot data enabled,
i.e. CONFIG_TFM_MCUBOOT_DATA_SHARING=y.
Regression from: 485fa940aa
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Add support for device power management. When the sensor
is not powered, the fetch function will fail. When the
sensor is not connected to a power domain, it will behave
as usual.
Signed-off-by: Albert Jakieła <aja@semihalf.com>
RISC-V Spec requires minimum alignment of trap handling code to be
dependent from MTVEC.BASE field size. Minimum alignment for RISC-V
platforms is 4 bytes, but maximum is platform or application-specific.
Currently there is no common approach to align the trap handling
code for RISC-V and some platforms use custom wrappers to align
_isr_wrapper properly.
This change introduces a generic solution,
CONFIG_RISCV_TRAP_HANDLER_ALIGNMENT configuration option which sets
the alignment of a RISC-V trap handling code.
The existing custom solutions for some platforms remain operational,
since the default alignment is set to minimal possible (4 bytes)
and will be overloaded by potentially larger alignment of custom solutions.
Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
Added devicetree and Kconfig for EFR32MG12P433F1024GM68, needed for
the BRD4170A radio board by Silicon Labs.
Signed-off-by: Warren Buffer <warren.buffer78@gmail.com>
Adjust the order in which image-specific `sysbuild.cmake` files are
iteratively included by sysbuild.
This is motivated by the introduction of `sysbuild_add_dependencies()`.
In the following example:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
the `my_sample` image is expected to be added before this function is
called. Success depends not only on the placement of the call, but on
the order in which new images are added, which itself is influenced by
the order in which `sysbuild.cmake` files are included. This last order
can be tweaked to make the "dependencies" feature more user-friendly.
This is done by rewriting the internal `sysbuild.cmake` processing loop
into a new, general purpose function - `sysbuild_add_subdirectory()` -
which is a wrapper for `add_subdirectory(<source_dir>)` that recursively
includes `sysbuild.cmake` files for all images found in `<source_dir>`.
With the new function, all images that are expected to be found in a
given `<source_dir>` are guaranteed to be added around the same time.
This wasn't the case with the old processing loop, because the image-
specific `sysbuild.cmake` files (where "sub-images" could be defined)
were left to be processed at the very end.
Below is the initial order in which sysbuild will add all images.
Note: the order of Zephyr modules (from 1 to n) is well-defined.
1. Main application (aka DEFAULT_IMAGE)
2. MCUboot (optional)
3. All images added via these directories:
3.1. <module-1>.sysbuild-cmake
3.2. <module-2>.sysbuild-cmake
...
3.n. <module-n>.sysbuild-cmake
4. All images added via these files:
4.1. ${BOARD_DIR}/sysbuild.cmake
4.2. ${APP_DIR}/sysbuild.cmake (aka sub-images of DEFAULT_IMAGE)
These images are intended to be sorted for the users' convenience, from
most to least important in the build system, or least to most dependent
on other images for configuration (potentially).
Finally, the use of `sysbuild_add_subdirectory()` requires updating the
directory structure in sysbuild:
./images
- All images should belong here. The `DEFAULT_IMAGE` should be the
first and only image at the top level, so that it gets added first
and its sub-images get added last.
./images/bootloader
- Moved from ./bootloader.
./images/boards
- Adds images from the board-specific `sysbuild.cmake` file.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This variable was originally provided for two indended purposes:
* Let users manually add a new image in a desired order in the list.
* Let users set build-only images, which are excluded from the list.
Given the recent additions of the `sysbuild_add_dependencies()` function
and the `BUILD_ONLY` parameter, `IMAGES` should be considered obsolete.
Furthermore, the list of images added to sysbuild should be updated
automatically when calling `ExternalZephyrProject_Add()`. This is now
possible by using a GLOBAL property internal to sysbuild.
With that, the `IMAGES` variable can be removed. Its existing usage for
image ordering is replaced with `sysbuild_add_dependencies()` treewide.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes#53650
The existing solution for image ordering involves the `IMAGES` variable,
which sysbuild originally provided to let users manually add a new image
in a desired order. This isn't very flexible for the following reasons:
* The order in which `IMAGES` is updated across multiple modules and
`sysbuild.cmake` files is not well defined.
* Having a single variable means that the same order is used for both
configuration and flashing. Usually, there is no reason for the
flashing order to be the same as the configuration order.
Introduce the `sysbuild_add_dependencies()` function for more fine-tuned
ordering of images. It makes one image depend on other images in either
configuration or flashing order. Its usage is similar to the standard
CMake function `add_dependencies()`, but with an extra parameter to
distinguish between two types of dependencies:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
sysbuild_add_dependencies(FLASH my_sample sample_c sample_d)
CONFIGURE dependencies determine the order in which sysbuild configures
(runs CMake for) the individual images. This is useful if there is some
information from one application's build which needs to be available to
another application.
FLASH dependencies control the sequence of images used by `west flash`.
This could be used if a specific flashing order is required by an SoC,
a runner, or something else. Note that these dependencies are not valid
for images specified as `BUILD_ONLY`.
The internal `sysbuild_images_order()` function is responsible for
assembling two sorted lists of images based on the added dependencies,
with the help of `topological_sort()`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This function performs topological sorting of CMake targets. Its initial
use case in Zephyr will be for implementing sysbuild image dependencies,
i.e., specifying an image order for CMake configuration and flashing.
Sourced from a comment on PR #57884 (anchor: #discussion_r1206807021)
Authored-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
All generic drivers, ie, emulators/SPI/I2C based devices, were defined
in app.overlay, meaning the overlay is picked by all builds. However,
what was defined in app.overlay was only used by the native_posix build.
This will save some CI time, as generic drivers were being built more
than strictly necessary.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
`CONFIG_BT_L2CAP_TX_MTU` drives the maximum supported MTU on a Bluetooth
connection, but the SPI backend also imposes its own hidden limits.
Display a warning if a value is chosen that can result in failures to
send. This is done here instead of as a range on `BT_L2CAP_TX_MTU` as
ranges on that symbol are already defined in terms of software features,
which would conflict with this check.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This should increase the coverage of the testsuite.py module
up to 100%.
Some tests have been commented out, as the code tested there is
incorrect. Thus the real increase is 99%.
Signed-off-by: Lukasz Mrugala <lukaszx.mrugala@intel.com>
This fixes bt_audio_codec_cfg_get_chan_allocation_val return value that
shall be 0 in case of success.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
