The Python dependencies specific to building the documentation were
recently removed from the common requirements. Point users to the
documentation generation instructions and provide details on installing
the doc specific dependencies.
Signed-off-by: Keith Short <keithshort@google.com>
Fixed several comments that were not proper Doxygen ones, causing
documentation for this file to be incomplete.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Added a few missing brief descriptions + fixed existing ones
to use proper Javadoc-style comments.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
When IEEE 802.15.4 maintainership was updated in ec98555f42 the L2 part
was missed. Proposes to assign both L1 and L2 to the same persons.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
During testing it was found that if the partition type was displayed as
msdos it could not be detected correctly, so this partition type
determination was added.
Signed-off-by: Yuchao Guo <yuchao.guo@hoorii.io>
According to the mesh 1.1 spec, section 4.4.14.1: “. The access layer
security on the On-Demand Private Proxy Client model shall use the
device key of the node supporting the On-Demand Private Proxy
Server model.“
This commit alters the API and implementation to reflect this.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
This splits defines to a separate file, which are commonly needed
by out-of-tree projects whereby the full MCUmgr include cannot be
used due to undefined types being used.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
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>
Keith Short