Calculate and set a proper Transceiver Delay Compensation Offset (TDCO)
based on FlexCAN FD timing.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the "bus_speed" and "bus_speed_data" fields of struct
can_driver_config to "bitrate" and "bitrate_data" to match the
corresponding devicetree properties and the terminology used in the rest of
the CAN subsystem API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove unnecessary asserts from various CAN controller drivers. These
asserts are all covered by the common CAN subsystem API implementations.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for specifying the minimum bitrate supported by a CAN
controller in CAN_DT_DRIVER_CONFIG_GET() and
CAN_DT_DRIVER_CONFIG_INST_GET().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Since all CAN controllers drivers seem to support automatic recovery (for
any future drivers for hardware without this hardware capability this can
easily be implemented in the driver), change the Zephyr CAN controller API
policy to:
- Always enable automatic bus recovery upon driver initialization,
regardless of Kconfig options. Since CAN controllers are initialized in
"stopped" state, no unwanted bus-off recovery will be started at this
point.
- Invert and rename the Kconfig CONFIG_CAN_AUTO_BUS_OFF_RECOVERY, which is
enabled by default, to CONFIG_CAN_MANUAL_RECOVERY_MODE, which is disabled
by default. Enabling CONFIG_CAN_MANUAL_RECOVERY_MODE=y enables support
for the can_recover() API function and a new manual recovery mode (see
next bullet). Keeping this guarded by Kconfig allows keeping the flash
footprint down for applications not using manual bus-off recovery.
- Introduce a new CAN controller operational mode
CAN_MODE_MANUAL_RECOVERY. Support for this is only enabled if
CONFIG_CAN_MANUAL_RECOVERY_MODE=y. Having this as a mode allows
applications to inquire whether the CAN controller supports manual
recovery mode via the can_get_capabilities() API function and either fail
or rely on automatic recovery - and it allows CAN controller drivers not
supporting manual recovery mode to fail early in can_set_mode() during
application startup instead of failing when can_recover() is called at a
later point in time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Propagate the current CAN controller operation mode to the CAN transceiver
when enabling it.
Some more advanced CAN transceivers, especially those supporting Partial
Networking (CAN PN), require knowledge of the intended CAN operation mode
(e.g. normal mode vs. listen-only mode).
This commit simply prepares the CAN transceiver API for supporting such CAN
transceivers, although no in-tree drivers require this information yet.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
A growing number of CAN controllers do not have support for individual RX
hardware filters based on the Remote Transmission Request (RTR) bit. This
leads to various work-arounds on the driver level mixing hardware and
software filtering.
As the use of RTR frames is discouraged by CAN in Automation (CiA) - and
not even supported by newer standards, e.g. CAN FD - this often leads to
unnecessary overhead, added complexity, and worst-case to non-portable
behavior between various CAN controller drivers.
Instead, move to a simpler approach where the ability to accept/reject RTR
frames is globally configured via Kconfig. By default, all incoming RTR
frames are rejected at the driver level, a setting which can be supported
in hardware by most in-tree CAN controllers drivers.
Legacy applications or protocol implementations, where RTR reception is
required, can now select CONFIG_CAN_ACCEPT_RTR to accept incoming RTR
frames matching added CAN filters. These applications or protocols will
need to distinguish between RTR and data frames in their respective CAN RX
frame handling routines.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the CAN_FILTER_FDF flag for filtering on classic CAN/CAN FD frames
as it is not supported natively by any known CAN controller.
Applications can still filter on classic CAN/CAN FD frames in their receive
callback functions as needed.
Fixes: #64554
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Unify spelling of CAN Flexible Data-rate abbreviation to "CAN FD" instead
of "CAN-FD". The former aligns with the CAN in Automation (CiA)
recommendation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the CAN controller driver implementations for the
can_remove_rx_filter() API call to be consistent in their validation of the
supplied filter_id.
Fixes: #64398
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Only copy frame data for non-RTR frames as RTR frames do not carry any
data. The limitation of how much data to copy is currently handled in the
NXP HAL.
Fixes: #57002
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Fix the assignment of initial CAN bus timing parameters for the CAN-FD data
phase.
Fixes: #62979
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In case CAN-FD mode is not enabled the mcux flexcan driver supports
CAN_MODE_3_SAMPLES.
This has been removed inadvertently while adding can-fd support.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Each CAN instance of S32K344 has different maximum number
of message buffers, depends on payload. Add kconfig that
defines maximum number of message buffers for concurrent
active instances and update driver to compatible
support S32k344.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
The MCUX platform always uses pinctrl, there's no need to keep extra
macrology around pinctrl. Also updated driver's Kconfig options to
`select PINCTRL` (note that some already did).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Rename the nxp,kinetis-flexcan devicetree compatible to nxp,flexcan as it
is not specific to the NXP Kinetis series.
This is preparation for adding a nxp,flexcan-fd binding.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fix handling of failed NXP FlexCAN RX mailbox reads. Instead of re-enabling
the RX MB in the ISR, we need to handle a failed RX MB read (e.g. due to a
busy MB bit).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Since the FLEXCAN_TransferSendNonBlocking() function has
read-modify-write operations on global resources, then
if interrupts are enabled and/or if there is more than
one thread with a different priority, threads with
a lower priority can overwrite global resource changes
made by higher priority threads.
Fixes#52673.
Signed-off-by: Mikhail Siomin <victorovich.01@mail.ru>
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>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Abort any pending transmissions before entering freeze mode and notify the
senders.
Fixes: #50545
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Given the recent change to the CAN controller can_send() API wrapper,
assume that a callback is always provided at the driver level.
This saves approximately 500 bytes of SRAM on the frdm_k64f board, while on
the mimxrt1024_evk board the saving is approximately 2.5 kbytes of SRAM,
both when running in default configuration.
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>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Change the error code for can_send() when the CAN controller is in bus off
state from -ENETDOWN to -ENETUNREACH.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_state enumerations to contain the word STATE to make their
meaning more clear:
- CAN_ERROR_ACTIVE => CAN_STATE_ERROR_ACTIVE
- CAN_ERROR_WARNING => CAN_STATE_ERROR_WARNING
- CAN_ERROR_PASSIVE => CAN_STATE_ERROR_PASSIVE
- CAN_BUS_OFF => CAN_STATE_BUS_OFF
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the NXP FlexCAN driver internal functions and macros to not use
"zcan", "zframe", and "zfilter" to avoid confusion after "struct can_frame"
and "struct can_filter" renaming.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
MISRA C:2012 Rule 14.4 (The controlling expression of an if statement
and the controlling expression of an iteration-statement shall have
essentially Boolean type.)
Use `do { ... } while (false)' instead of `do { ... } while (0)'.
Use comparisons with zero instead of implicitly testing integers.
The commit is a subset of the original auditable-branch commit:
5d02614e34a86b549c7707d3d9f0984bc3a5f22a
Signed-off-by: Simon Hein <SHein@baumer.com>
When installing a RX filter, the driver uses "filter->rtr &
filter->rtr_mask" for setting the filter mask. It should just be using
filter->rtr_mask, otherwise filters for non-RTR frames will match RTR
frames as well.
When transmitting a RTR frame, the hardware automatically switches the
mailbox used for TX to RX in order to receive the reply. This, however,
does not match the Zephyr CAN driver model, where mailboxes are dedicated
to either RX or TX. Attempting to reuse the TX mailbox (which was
automatically switched to an RX mailbox by the hardware) fails on the first
call, after which the mailbox is reset and can be reused for TX. To
overcome this, the driver must abort the RX mailbox operation when the
hardware performs the TX to RX switch.
Fixes: #47902
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add API function for getting the supported capabilities of a CAN
controller. This allows for writing portable CAN applications.
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>
In order to bring consistency in-tree, migrate all drivers 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>
Commit a50b69dfb7 introduced a work-around
for FlexCAN errata 5461 and 5829, but neglegted to take the RX mailbox
offset into account when calculating maximum number of mailboxes
allocated for RX/TX.
Fixes: #44724
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Only initialize the FlexCAN IP core once since initialzing it has the
side effect of resetting the IP core and thus clearing previous settings
such as RX filters.
Fixes: #44680
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the code for socket instanciation from each driver
to a generic driver, that makes an instance of a socketCAN
net device for the chosen node.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
