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>
This commit updates the C++ test to include the recently introduced
device headers to ensure that they are C++-compatible.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
Moves a .h file added outside of the zephyr include folder to be
within the zephyr include folder.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This header provides original BOOT_MAX_ALIGN definition.
This definition is used directly on indirectly by the code this
patch modifies.
Let's use it instead of copy from mcuboot.h
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Extracted common function for erase the image trailer which
decrease code size and increase legibility.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Inappropriate page was erased during test as its absolute offset was
calculated with omission of the the fixed-partition offset to which
it belongs.
fixes#48115
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
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>
This commit changes some tests from using zassert_equal to validate
the pointers to using the zassert_is_null and zassert_not_null.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
Adds a simple mcumgr test which checks that the os_mgmt echo commmand
works and responds with the correct data.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Add missing assert after polling for the dummy shell backend to be ready.
Fixes: 491f4dd701
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
