Starting with commit b9b43a0eb772a464bba13833d11e3a31fbf4e09e, printk()
messages are handled by the logging subsystem. This can cause trouble
in watchdog related samples if the deferred logging mode is used (and
currently it is by default), because those samples are ended by a reset
and some messages may not get a chance to be outputted.
Since the same problem concerns also the ordinary logging messages that
may be produced during execution of the samples, this commit fixes it
by switching to the immediate logging mode, not by just disabling the
LOG_PRINTK option.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Added configuration which allows to test the sample using SPI_NOR
driver instead of NRF_QSPI driver.
SPI_NOR driver is generic, so nice to add possibility to check
how it is working.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Add a sample program demonstrating the LED driver for Microchip's
XEC microcontrollers. The sample can be built for MEC152x and
MEC172x.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
Remove regulator-fixed-sync specialization, create a single driver that
is always synchronous. The asynchronous part is rarely/never used, so
let's keep things simple for now.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Enable counter alarm sample on s32z270dc2_r52 boards, using the first
System Timer Module instance.
Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
integration_platforms help us control what get built/executed in CI and
for each PR submitted. They do not filter out platforms, instead they
just minimize the amount of builds/testing for a particular
tests/sample.
Tests still run on all supported platforms when not in integration mode.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This adds the support jedec configuration to run
the jedec sample application. So target boards can display
the content of the octo-NOR flash
of the stm32u585 and stm32l562 or stm32h735 disco boards.
The sfdp-bfp table is provided as example (overlay file),
to run this sample on the stm32l562e_dk platform.
It has to be defined in the deviceTree "in cases were runtime
retrieval of SFDP data is not desired."
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Moving the SDFP table property from the sample to the device tree
of the stm32l562e_dk disco kit.
The MX52lm51245 Nor octoflash mounted on this boarddoes not
provide its own internal SFDP parameters.
With this patch, the SFDP table is given by the board DTS.
So that the stm32 ospi driver can initialized the NOR octoflash
correctly with the parameter from that property instead of
relying on the nor octoflash.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This adds the support jedec configuration to run
the jedec sample application. So target boards can display
the content of the octo-NOR flash
of the stm32u585 and stm32l562 or stm32h735 disco boards.
The sfdp-bfp table is provided as example (overlay file),
to run this sample on the stm32l562e_dk platform.
It has to be defined in the deviceTree "in cases were runtime
retrieval of SFDP data is not desired."
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Adds the dma transfer for the octoSPI on NOR octo Flash
of the b_u585i_iot02a disco kit.
The channel for the GPDMA is 0-15 (0-7 for DMA1, 8-15 for DMA2)
The channel 12 to 15 are used for GPDMA transfers
to/from external memories.
The request is 41 for the OCTOSPI2.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Both `drivers/flash/flash_shell.c` and
`samples/drivers/flash_shell/src/main.c` provide a flash shell
utility called `flash`.
Rename the latter to disambiguate.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Remove the EEPROM shell overlay from the EEPROM driver sample as this was
only introduced as a build test for the EEPROM shell. This is now done in
tests/drivers/eeprom/shell.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Many driver samples or tests only had 'drivers' as the tag, without a
tag indicating what driver that is exactly, so add some missing tags.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When running a flash read command on the flash shell, the hexdump
prints came out incorrect. There was a space missing between the
ninth element and its preceding "|", and a redundant newline.
This commit fixes this issue.
Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
The most of the wwdg peripherals requires a reduced apb clock
to pass the sample.drivers.watchdog.stm32_wwdg testcase.
This apb1 prescaler is added to the overlay file
for that particular clock.
Specific overlay for the stm32h7 family because of the APB1
bus clock named d2ppre1.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add ADC driver sample overlays + update features in doc + metadata for TI
CC13x2/CC26x2 based boards (cc1352r_sensortag, cc1352r1_launchxl,
cc26x2r1_launchxl).
Signed-off-by: Stancu Florin <niflostancu@gmail.com>
Skip all CAN controller tests utilizing CAN loopback mode for the
kvaser,pcican CAN controller card as emulated in QEMU.
QEMU emulation of the SJA1000 CAN controller backend does not yet support
the SJA1000 Self Reception Request command which is required for proper
loopback operation.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Use printf() instead of printk() for printing sample output. According to
the documentation Zephyr printk() and friends are for printing kernel debug
messages.
With printf() instead of printk() the CAN counter sample passes twister
test execution on native_posix and native_posix_64.
Fixes: #50570
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Now that IPM drivers are enabled based on devicetree we can
remove any cases of them getting enabled by Kconfig, *defconfig*,
and *.conf files.
We need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
The can_frame and can_filter structs support a number of different flags
(standard/extended CAN ID type, Remote Transmission Request, CAN-FD format,
Bit Rate Switch, ...). Each of these flags is represented as a discrete bit
in the given structure.
This design pattern requires every user of these structs to initialize all
of these flags to either 0 or 1, which does not scale well for future flag
additions.
Some of these flags have associated enumerations to be used for assignment,
some do not. CAN drivers and protocols tend to rely on the logical value of
the flag instead of using the enumeration, leading to a very fragile
API. The enumerations are used inconsistently between the can_frame and
can_filter structures, which further complicates the API.
Instead, convert these flags to bitfields with separate flag definitions
for the can_frame and can_filter structures. This API allows for future
extensions without having to revisit existing users of the two
structures. Furthermore, this allows driver to easily check for unsupported
flags in the respective API calls.
As this change leads to the "id_mask" field of the can_filter to be the
only mask present in that structure, rename it to "mask" for simplicity.
Fixes: #50776
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Exclude Arduino Portenta H7 because the flash driver isn't
supported yet on the M4 core.
Signed-off-by: Benjamin Björnsson <benjamin.bjornsson@gmail.com>
Add support for boards that implement GD32 SoC.
Overlay file for longan_nano_lite enables FWDGT.
Add WDT_FEED_INTERVAL to make adjustable
the execution cycle of wdt_feed().
And also, make waiting for the WDT_FEED_INTERVAL period
for the watchdog window opens at the start of the test.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
The .yaml file states that CAN is supported, but the basic sample
application samples/drivers/can/counter cannot be compiled without
additional configuration.
The loopback driver does not require any additional steps like the
linux SocketCAN driver, so it is safe to enable it by default and
get rid of the many overlay files in the tests.
ISO-TP tests and the counter sample are excluded via .yaml from
twister tests because of timing issues.
Signed-off-by: Martin Jäger <martin@libre.solar>
Apparently the URLs for these old products have been moved to under
"old2020" without any redirects ...
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The "Grove Base Shield" seems to be no longer listed in the Seeed
website, so its link is replaced with that of the "Base Shield V2",
which is the successor of the "Grove Base Shield."
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The "RGB LED strips: an overview" link no longer works and there is no
direct replacement, so there is no point in listing this document in
the references anymore.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
This commit fixes the outdated link to the "Chronodot" product page.
It seems "macetech" no longer lists the older versions of this product
with DS3231, so the link has been replaced with the one from Adafruit.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The twister docs specify that `platform_allow` should only be used
if applications can only possibly run on the specified platforms. This
is not the case for these applications, which should be able to run on
any board with LoRa support.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Up until now, the Zephyr CAN controller drivers set a default bitrate (or
timing) specified via devicetree and start the CAN controller in their
respective driver initialization functions.
This is fine for CAN nodes using only one fixed bitrate, but if the bitrate
is set by the user (e.g. via a DIP-switch or other HMI which is very
common), the CAN driver will still initialise with the default
bitrate/timing at boot and use this until the application has determined
the requested bitrate/timing and set it using
can_set_bitrate()/can_set_timing().
During this period, the CAN node will potentially destroy valid CAN frames
on the CAN bus (which is using the soon-to-be-set-by-the-application
bitrate) by sending error frames. This causes interruptions to the ongoing
CAN bus traffic when a Zephyr-based CAN node connected to the bus is
(re-)booted.
Instead, require all configuration (setting bitrate, timing, or mode) to
take place when the CAN controller is stopped. This maps nicely to entering
"reset mode" (called "configuration mode" or "freeze mode" for some CAN
controller implementations) when stopping and exiting this mode when
starting the CAN controller.
Fixes: #45304
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add the flash channel support by implementing the controller attached
flash sharing APIs, including flash_read, flash_write, and flash_erase.
For flash_read, the max data payload the module can support is 64 bytes
in one transaction.
For flash_write, the max data payload the module can support is 16
bytes in one transaction.
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Adds the dma transfer for the octoSPI on NOR octo Flash
of the stm32h7b3i and stm32h735g disco kits.
The channel for the MDMA is 0-15.
The MDMA request is 0x16 for the OCTOSPI1 fifo threshold
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Adds the dma transfer for the octoSPI on NOR octo Flash
of the stm32l562e_dk disco kit.
The channel for the DMAMUX is 0-15 (0-7 for DMA1, 8-15 for DMA2)
The DMAMUX request is 41 for the OCTOSPI.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
After add zephyr,flash-controller property, most gd32 boards support
flash_shell sample.
gd32vf103c_starter and gd32vf103v_eval only have 32KB SRAM, so we
should reduce CONFIG_HEAP_MEM_POOL_SIZE to 8KB.
gd32f350r_eval only have 16KB driver, exclude from flash_shell sample.
Signed-off-by: HaiLong Yang <hailong.yang@brainco.cn>
In a Controller Area Network a babbling node is a node continuously (and
usually erroneously) transmitting CAN frames with identical - often high -
priority. This constant babbling blocks CAN bus access for any CAN frame
with lower priority as these frames will loose the bus arbitration.
Being able to simulate a babbling CAN node is useful when examining the
behavior of other nodes on the same CAN bus when they constantly loose bus
arbitration.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
