Update the CAN controller drivers to solely use the sjw and sjw-data
devicetree properties for setting the initial timing when devicetree timing
parameters are specified in Time Quanta (TQ).
Any timing set via the CAN timing APIs will contain either user-provided or
automatically calculated SJW values. This includes any timing parameters
calculated from bus-speed and bus-speed-data devicetree properties.
Update the CAN controller driver tests accordingly and remove the
CAN_SJW_NO_CHANGE definition as it has lost its meaning.
Fixes: #63033
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove virtual esp32 board and replace it with the
real word boards:
- esp32_devkitc_wroom
- esp32_devkitc_wrover (with PSRAM option)
Signed-off-by: Marek Matej <marek.matej@espressif.com>
Remove the need for the can_transceiver fixture by assigning the CAN TX
and CAN RX lines to the same GPIO pin to allow for testing without a
transceiver or physical jumper.
Signed-off-by: Eric Holmberg <eric.holmberg@northriversystems.co.nz>
Change the test_set_timing_data_while_started test to actually attempt to
set the data phase timing parameters instead of attempting to set the
nominal/arbitration timing parameters.
Update test descriptions to explicitly mention data phase timing.
Fixes: #59046
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move the build-only test for the MCP2515 CAN controller driver to the
tests/drivers/build_all/can/ folder.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Test that filters are preserved when changing between CAN-FD mode and
classic CAN mode and vice versa.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use the recommended sample point of 75.0% for the data phase bitrate test @
1Mbit/s. This matches the default sample point calculated in
can_common.c:sample_point_for_bitrate().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove test for attempting to set an arbitration bitrate of
8000001 bit/s. This test belongs in the data phase timing test, where
it already present as well.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adjust the CAN IDs used for testing in order for them to match the various
can_*_filter_2 as documented in common.h.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the test definitions, frames, and filters to common.h/common.c and
reuse them between the classic CAN and CAN-FD API tests.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fold the CAN-FD specific tests into the main CAN API tests and stop
treating the CAN-FD API functionality as an add-on to CAN API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The test fails with a stack overflow on qemu_x86 when we build with
llvm. Bump the test stack a little addresses the issue.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Remove the CAN_HAS_CANFD Kconfig helper symbol in order to allow enabling
CAN-FD support in the API regardless of driver support.
Change default to CAN-FD support being disabled and have samples and tests
that require CAN-FD support turn it on. This aligns the default
configuration across CAN controller drivers regardless of their
capabilities.
The rationale behind this is that we are starting to see MCUs with multiple
CAN controllers, some CAN-FD compatible, some not (e.g. NXP i.MX RT1060 and
FPGAs). Automatically enabling CAN-FD support based on the presence of a
CAN-FD capable CAN controller leads to different application default
settings based on the CAN controller(s) in use.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use the CAN controller driver capabilities to determine if the CAN-FD
timing tests should be skipped or not. There is no need for special
handling of CONFIG_CAN_FD_MODE.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.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>
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>
The TWAI peripheral needs a connected CAN transceiver also for testing
in loopback mode.
As there is no board available with this configuration, at least make
sure the CAN API test is built in CI for esp32c3_devkitm.
Signed-off-by: Martin Jäger <martin@libre.solar>
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>
Skip the Remote Transmission Request (RTR) frame tests if the CAN
controller driver does not support RTR filters.
Fixes: #50218
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
The CAN shell test is flaky on some qemu platform (qemu_riscv64_smp in
particular), where the first test command occasionally fails as it tries
to run with the backend not initialized.
The tests for subsys/shell/shell/src/main.c have a setup delay, copying
it to the CAN shell test seems to make it work reliably.
Tested with:
./scripts/twister -v -n -M -p qemu_riscv64_smp -T tests/drivers/can/shell
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add test for the CAN shell module.
The tests execute a set of CAN shell module commands against a CAN
controller driver mock, verifies that the expected CAN controller driver
API functions are called, and that their arguments are as expected.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
It is frequent to find variable definitions like this:
```c
static const struct device *dev = DEVICE_DT_GET(...)
```
That is, module level variables that are statically initialized with a
device reference. Such value is, in most cases, never changed meaning
the variable can also be declared as const (immutable). This patch
constifies all such cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove the "z" prefix from the public CAN controller API types as this
makes them appear as internal APIs.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the SocketCAN tests from tests/drivers/can/utilities to
tests/net/socket/can to match the location of the code under test.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the SocketCAN data types and helper functions from
zephyr/drivers/can.h to zephyr/net/socket_can.h as these are not used by
the low-level CAN controller driver API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Exclude the 20kbit/s CAN timing test from running on the Espressif ESP32
TWAI driver. The TWAI does not support bitrates below 50kbit/s due to the
combination of CAN clock and prescaler range.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Add support for enabling/disabling CAN-FD frame transmission/reception at
run-time.
Fixes: #45303
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the can_mode enum to a bit field to prepare for future extensions
(CAN-FD mode, transmitter delay compensation, one-shot mode, 3-samples
mode, ...).
Rename the existing modes:
- CAN_NORMAL_MODE -> CAN_MODE_NORMAL
- CAN_SILENT_MODE -> CAN_MODE_LISTENONLY
- CAN_LOOPBACK_MODE -> CAN_MODE_LOOPBACK
These mode names align with the Linux naming for CAN control modes.
The old CAN_SILENT_LOOPBACK_MODE can be set with the bitmask
(CAN_MODE_LISTENONLY | CAN_MODE_LOOPBACK).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the CAN data phase API functions to timing_data_* for consistency:
- can_get_timing_min_data() -> can_get_timing_data_min()
- can_get_timing_max_data() -> can_get_timing_data_max()
- .timing_min_data -> timing_data_min
- .timing_max_data -> timing_data_max
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Print the CAN core clock frequency along with the device name to aid in
debugging CAN timing test case errors.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Tighten the sample point test acceptance criteria from +/- 10.0% to +/-
5.0%. This is in line with the CAN sample point criteria used by the
Linux kernel.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Do not overwrite the sample point error value as it is printed at the
very end of the test.
Fixes: 578454b78d
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add simple test of the can_set_state_change_callback() API. It is not
possible to trigger a change of state, but at least test the API call
with and without a callback function.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a build-only test for the Microchip MCP2515 SPI CAN controller
driver since no in-tree boards have this chip.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Clean up (naming, formatting) the CAN STM32-specific test cases and add
proper doxygen documentation. No functional changes.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adjust the sample point locations for the higher bitrates to match those
used in the Linux kernel. These sample points are much more likely to be
met for a wider set of CAN controllers and their timing parameter
boundaries.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Limit the CAN utilities tests to run on the native_posix/native_posix_64
boards. There is no need to run this on 400+ boards.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the CAN utilities tests to the tests/drivers/can/ directory. The
tests/subsys/canbus directory is for tests related to code located in
subsys/canbus.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Extend the CAN driver timing tests to cover data phase timing on CAN-FD
capable CAN controllers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Extend the CAN driver timing calculation test verification to cover the
sjw and prescaler values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Include a pointer to the CAN controller device for the CAN
transmit, receive, and state change callback functions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the CAN timing test to the new ztest framework. Restructure the
tests a bit to improve code readability and add doxygen documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
- Filter out the CAN controller driver tests if no zephyr,canbus chosen
node is enabled in the devicetree.
- Rename the tests to follow the general test naming scheme.
- Remove the dedicated test selection for native_posix boards
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Filter out boards without st,stm32-can compatibles enabled in their
devicetree in the stm32-specific CAN driver test.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
