enable dma on rt1170 and rt1160 evk, since edma driver has been updated
to place TCD pools in correct location
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
if DMA support is not present, LPUART driver will not compile when async
API support is required. Skip test cases when dma support is not present
and LPUART driver is enabled.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
add nxp,loopback mode to boards with LPUART. This will enable testing
the UART async api without a physical loopback connection.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
NXP LPUART IP supports loopback mode, where TX is internally connected
to RX input. Allow setting loopback mode up via the "nxp,loopback" dts
property.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
SOCs using the EDMA IP that supported caching must locate EDMA transfer
control descriptors (TCDs) in non cacheable memory. For M7 cores, this
can simply use the "nocache" section. For M4 cores, where the nocache
section does not exist, the chosen SRAM section must be a tightly
coupled memory block which cannot be cached. Add a note to all boards
with M4 SOCs that support caching explaining this issue, and enable EDMA
driver to locate TCDs in SRAM.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
LPUART driver should use shared ISR for all possible use cases,
including ASYNC API, so that multiple features requiring ISR can be
enabled simultaneously.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
There is errata clarification (Errata ID:18700)
about subscriptions on fixed group addresses.
It is possible to subscribe models on non primary elements
on any fixed group address except all nodes address.
Devices should be able to receive messages on fixed addresses
even if they do not support the feature
to which the fixed group address belongs.
Signed-off-by: Aleksandr Khromykh <Aleksandr.Khromykh@nordicsemi.no>
This commit adds audio dmic to the boards dts and a regulator
to enable the microphone VDD and L/R pin.
Signed-off-by: Benjamin Björnsson <benjamin.bjornsson@gmail.com>
- add an overlay file for the bbc_microbit board with specification
of GPIO that should be used as the PWM output to buzzer
- update a PWM related macro in the microbit specific code to refer
to PWM channel instead of pin
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- add `channel-gpios` property with GPIO assignment for the used PWM
channel to the `sw_pwm` node
- replace ambiguous "pin 21" in the sample's README with "pin P19"
that uses notation from the official micro:bit documentation and
is consistent with this pin number within the edge_connector node
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- add `channel-gpios` property with GPIO assignments for PWM channels
to `sw_pwm` nodes
- update PWM related macros to refer to channels instead of pins
- remove no longer needed inclusion of boards/arm/bbc_microbit/board.h
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Align the board dts with the recent changes in the "nordic,nrf-sw-pwm"
binding (remove the no longer existing `channel-count` property) and
add a node representing the edge connector for convenient referring
to SoC pins connected to it.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
... and "nordic,nrf-sw-pwm" binding:
- add `channel-gpios` property with GPIO assignments for PWM channels
to `sw_pwm` nodes
- use channel indexes instead of pin numbers in `pwms` properties that
define PWM LEDs
- add the period and flags cells to `pwms` properties in all PWM LED
definitions; use the commonly used period of 20 ms (giving 50 Hz)
as a default setting
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
... and "nordic,nrf-pwm" binding:
- use channel indexes instead of pin numbers in `pwms` properties that
define PWM LEDs
- add the period and flags cells to `pwms` properties in all PWM LED
definitions; use the commonly used period of 20 ms (giving 50 Hz)
as a default setting
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
... to align with what is used in most other PWM bindings.
Update PWM nodes in SoC .dtsi files accordingly.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add support for inverting of PWM channel outputs in the pwm_nrf5_sw
driver by properly handling the `PWM_POLARITY_INVERTED` flag.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Align with other PWM drivers and treat the `pwm` parameter (described
ambiguously as "PWM pin") of the `pwm_pin_set_cycles` function as a PWM
channel, not an SoC pin. This will also make the driver consistent with
the `pwm-cells` property definition in the "nordic,nrf-sw-pwm" binding
and with related `DT_PWMS_*` macros.
The change described above requires also providing a way to specify
SoC pins that are to be assigned to the PWM channels. Hence, the commit
introduces in the "nordic,nrf-sw-pwm" binding the `channel-gpios`
property that replaces the `channel-count` one.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add support for inverting of PWM channel outputs in the pwm_nrfx driver
by properly handling the `PWM_POLARITY_INVERTED` flag.
The dts properties that were used so far for inverting of the outputs
("nordic,invert" and "chX-inverted") are kept as they are needed for
setting of the initial polarity, i.e. for setting the inactive state
of the outputs before any PWM signal generation is requested for them.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Align with other PWM drivers and treat the `pwm` parameter (described
ambiguously as "PWM pin") of the `pwm_pin_set_cycles` function as a PWM
channel, not an SoC pin. This will also make the driver consistent with
the `pwm-cells` property definition in the "nordic,nrf-pwm" binding
and with related `DT_PWMS_*` macros.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Increase the default TX stack size for BT_CTLR && BT_LL_SW_SPLIT,
as we have seen applications/samples nearing and even reaching
the stack size, causing stack overflows. This is especially
true if CONFIG_FPU=y which takes 96 bytes of the TX stack.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Fix assert on LL BIG terminate call before BIG sync is
established. Assert was caused due to duplicate calls to
release stream contexts, once in LL BIG terminate function
then when releasing the HCI BIG sync failed to be
established node rx was being released.
Use iso_broadcast and iso_receive samples, power cycle the
iso_broadcast device when iso_receive sample is waiting for
BIG sync to be established, iso_receive sample will perform
a BIG sync terminate that leads to the assert.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
At some recent point, directory <zephyr-root>/include was moved to
<zephyr-root>/include/zephyr. However, links from documentation to
Zephyr source on Github were not updated. Update them now.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
This extends the samples to build for C++ using the same code.
This shows MIPI Sys-T can work C++ too.
The change to main.c regarding to the struct log_msg_ids is
simply that the compiler errored out complaining the members
must be initialized the same order as the declaration.
Also C++ dislikes a string literal being assigned to char*,
so assign them to const char* instead.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Handle PECI command PING properly, also get Write FCS Byte as a check.
Now it is possible to perform a PECI Ping without crashing the bus or
blocking it for subsequent PECI transactions.
It is also possible to check whether the Ping was sucessful
or not with the Write FCS Byte.
Signed-off-by: Johannes Meister <johannes.meister@kontron.com>
This is a follow-up to commit f4a0ddd8af.
Since the yellow LED and the SCK line of spi2 use the same pin
(P0.13), they cannot be used together. Consequently, the pin
should not be assigned to the same PWM instance as other pins
that drive LEDs, as the limitation of usage would apply to the
whole PWM instance (it acquires all the pins assigned to it on
initialization of the PWM driver, regardless of whether the PWM
signal is eventually generated on particular outputs or not).
Use a separate PWM instance (disabled by default) for driving
the yellow LED. Don't use the "nordic,invert" property for that
PWM, as the yellow LED is active high.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commit f4a0ddd8af.
According to the schematic, the LED connected to the P1.09 pin is
active high. Therefore, the PWM1 instance that is configured to drive
the LED should not use the "nordic,invert" property.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
STM32H7 series offer alias addresses to access some registers that could
be accessed by the M4 core on dual core variants.
For instance RCC_AHB3ENR could be accessed at following offsets:
- 0x0D4: Accessible from both cores
- 0x134: Accessible from C1 (M7) core
- 0x194: Accessible from C2 (M4) core (if any)
For most single core H7 variants, the two first addresses were accessible,
but for some others (stm32h7ax/stm32h7bx), only the 'C1 accessible'
was available.
This fact used to be hidden by the use of LL API to access these registers,
providing the required abstraction (an mainly using the first alias
when possible to simplify implementation).
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Rework test_*_freq to test HCLK freq instead of SYSCLK one, as it is not
correct to compare CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC with SYSCLK.
Additionally, add a test to verify use of AHB prescaler.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Instead of computing hclk freq use for flash latency setting after
setting the PLLs, do it right at the beginning of the function.
Indeed, first step of PLL configuration is to switch back sysclock
to HSI source (in case it was initially PLL).
In that case, flash latency is theoretically set in consistency with PLL
driver hclk. So we should "measure" hclk freq at that step rather than
once sysclock is back on HSI.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Instead of testing SysClockFreq setting, we should instead check HCLK
setting which is the real zephyr CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC
counterpart (core clock freq) and takes AHB prescaler setting into
account.
Additionally, update one test configuration to explicitly verify AHB
prescaler is correctly taken into account by clock driver.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is the actual hclk freq (ie core clock);
Remove use of intermediate new_hclk_freq to fix and simplify code.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Rework bindings documentation to clearly illustrate the role of ahb
(and cpu1) prescaler which defines the actual core clock frequency,
and not only a bus frequency.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use enum to describe the range of allowed MSI values.
This will help to detect configuration issues earlier.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Remove L0 and L1 targets from "sysclksrc_msi_48" test case as this
MSI range 11 is not an allowed value on these series.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Some specific F1 variants don't handle flash latency.
Put flash latency dealing code under dedicated switch.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
According to board documentation: "By default System
clock is driven by the MSI clock at 48MHz."
This is in line with rcc node dts configuration:
&rcc {
[...]
clocks = <&clk_msi>;
[...]
};
Though pll node is currently enabled, which is not in line with
current dts clocks description scheme and results to compilation
issue in clock_control driver.
Remove pll node configuration to fix this.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
