Change the Bosch M_CAN ISRs to only acknowledge the IRQs handled in the
given loop iteration (and not all IRQs supported by the given ISR) and move
IRQ acknowledge to the front of the ISRs.
Fixes: #58631
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Increase the default stack size for the MCP2515 CAN controller driver from
512 to 1024 bytes.
Fixes: #58761
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Increase the default CAN controller driver initialization priority from
KERNEL_INIT_PRIORITY_DEVICE (50) to 80 to allow CAN controllers on SPI
busses have their bus initialized prior to initializing the CAN controller
driver.
The only in-bound dependency on CAN controller drivers - apart from
application level code - is the drivers/net/canbus.c driver, which already
defaults to an initialization level of 81.
Fixes: #55745
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the Bosch M_CAN header file to include/zephyr/drivers/can/can_mcan.h
for use in out-of-tree drivers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add documentation for the remaining functions, structs, and definitions in
the Bosch M_CAN header file. Fix a few mistyped Message RAM field names
along with misnamed macros and function found while adding documentation.
No functional changes.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Update the asserts to match the updated Bosch M_CAN minimum/maximum CAN
timing parameters.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The minimum/maximum CAN timing parameters for the STM32 FDCAN driver uses
the wrong values for the minimum, nominal phase segment values.
Using the static initializers fixes these and aligns them to the Bosch
M_CAN manual. The STM32G4 reference manual contains contradicting limits
for these register values.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The minimum/maximum CAN timing parameters for the STM32H7 FDCAN driver uses
the wrong values for the minimum, nominal phase segment values.
Using the static initializers fixes these and aligns them to the Bosch
M_CAN manual. The STM32H7 reference manual contains contradicting limits
for these register values.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The minimum/maximum CAN timing parameters for the Atmel SAM0 CAN driver
uses the wrong values for the minimum, nominal phase segment values. The
same goes for the maximum, nominal SJW value.
Using the static initializers fixes these and aligns them to the Bosch
M_CAN manual. The Atmel SAM C20/C21 family data sheet contains
contradicting limits for these register values.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The minimum/maximum CAN timing parameters for the Atmel SAM CAN driver uses
the wrong values for the minimum, nominal phase segment values. The same
goes for the maximum, nominal SJW value.
Using the static initializers fixes these and aligns them to both the Bosch
M_CAN manual and the Atmel SAM E70 family data sheet.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Some NXP SoC reference manuals contain a bug regarding the minimum values
for nominal phase segments. Valid Bosch M_CAN nominal phase segment
register values are 1 and up. Same goes for the maximum value for data
phase segment 2. Here, valid Bosch M_CAN register values are 0 to 31.
Using the static initializers fixes these.
Fixes: #58429
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
There is no need for iterating all the Bosch M_CAN filter elements in
Message RAM in order to find a free filter as the driver already keeps
track of assigned filters.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Restructure the Bosch M_CAN driver backend to use per-instance Message RAM
configuration.
This removes the need for a common, artificial "can" devicetree node for
SoCs with multiple Bosch M_CAN-based CAN controllers and allows for
per-instance configuration of the number of e.g. standard (11-bit) and
extended (29-bit) filter elements.
As part of the restructure, software handling of CAN filter flags was moved
from per-flags bitfields to per-filter bitfields, solving an issue when
using more than 32 standard (11-bit) filter elements or more than 16
extended (29-bit) filter elements.
Fixes: #42030, #53417
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The Bosch M_CAN Message Marker, an 8-bit field copied from Tx Buffer
elements to Tx Event FIFO elements to aid software in identifying Tx frame
status, need not be split into an index and a count, as the count is
unused.
Remove this split and replace "struct can_mcan_mm" with a simple "uint8_t".
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The Message RAM layout used by the STM32 FDCAN IPs contains a fixed number
of elements, even though the software can opt to use less standard/extended
filter elements. Change the BUILD_ASSERT() statements to reflect this.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Let the Bosch M_CAN front-end drivers supply their own Message RAM
read/write/clear functions.
This is preparation for supporting per-instance Bosch M_CAN Message RAM
layouts and for accessing Bosch M_CAN IP cores over peripheral busses.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Switch the Bosch M_CAN devicetree binding to use a bosch,mram-cfg property
for specifying the memory layout of the Bosch M_CAN Message RAM. This is
identical to the Linux kernel devicetree binding for Bosch M_CAN IP core
based CAN controllers.
This introduces an offset cell which can be used for controllers with
shared Message RAM between Bosch M_CAN instances.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Document that the Bosch M_CAN read/write register functions are allowed to
return -ENOTSUP for unsupported registers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Calling for can_stop() method was not emptying FIFOs
and tx_msgq.
Resetting TX FIFO to empty it.
Emptying tx_msgq with "ENETDOWN" return code.
Fixes#50546
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Driver was based on can_sam. SAMC21 has only 1 interrupt for one
can "output", so can interrupt has to executes two lines of
interrupts.
CAN is configured to use OSC48M clock via GLCK7. GLCK7 is set
by divider configured from dts.
Signed-off-by: Kamil Serwus <kserwus@gmail.com>
Add Kconfig guards for CONFIG_CAN_MAX_STD_ID_FILTER and
CONFIG_CAN_MAX_EXT_ID_FILTER as they only apply to the STM32 bxCAN driver.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the STM32H7 specific Kconfig overrides for setting the maximum
number of standard and extended CAN RX filters as they are unused.
The number of available standard and extended filter elements for Bosch
M_CAN can be configured via the devicetree.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move definitions of the STM32 FDCAN specific registers to the front-end
driver implementation and implement remapping of these registers to/from
the standard Bosch M_CAN registers.
Some of the STM32 FDCAN register bit fields are limited in size compared to
the Bosch M_CAN specification. This is due to hardware limitations on the
number of elements in the various sections of the Message RAM. Add build
assertions to ensure the number of elements specified do not exceed the
hardware limitations instead of using custom definitions for these fields.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move definition of the NXP LPC MCAN specific Message RAM Base Address
register (MRBA) to the front-end driver implementation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Some Bosch M_CAN IP core implementations use a fixed Message RAM
configuration, other use a fixed memory area and relative addressing,
others again have custom registers for configuring the Message RAM.
Move the responsibility for configuring the various Bosch M_CAN Message RAM
addresses to the front-end drivers. This removes some of the front-end
specific code from the backend. Provide a helper function for configuring
the most common variations.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Expose the can_mcan_read_reg()/can_mcan_write_reg() along with all the
Bosch M_CAN register definitions for use in Bosch M_CAN driver front-ends.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Let the Bosch M_CAN front-end drivers supply their own register read/write
functions.
This is preparation for handling non-standard Bosch M_CAN register layouts
directly in the front-end and for accessing Bosch M_CAN IP cores over
peripheral busses.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use sys_read32()/sys_write32() instead of volatile struct for register
access. Be consistent in using unsigned constants in register
comparisons. Use locking around register read-modify-write operations.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Regenerate/rewrite the Bosch M_CAN register field definitions using the
GENMASK() and BIT() macros.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use the FIELD_PREP() and FIELD_GET() macros instead of manual bitshifts and
masking. Be consistent in the use of register field definition macros.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the local "const struct can_mcan_config *" variables from "cfg" to
"config" to be consistent with Zephyr conventions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Get rid of the can_mcan_configure_timing() helper function as it provides
no benefit to just having the implementation split in can_mcan_set_timing()
and can_mcan_set_timing_data().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the driver initialization function to the bottom of the file to be
consistent with Zephyr conventions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Pass a pointer to the struct device for internal driver functions instead
of passing around a pointer to the register struct.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral.
CAN protocol supporting:
- CAN classic
- CAN FD
Remote transmission request is not supported as this feature is not
available on NXP S32 CANXL HAL.
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>
Remove all init functions that do nothing, and provide a `NULL` to
*DEVICE*DEFINE* macros.
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>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add documentation for the update_sampling_pnt() function and rename a few
internal variables to improve readability.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Respect the range limits of phase_seg1 when attempting to distribute ts1
between prop_seg and phase_seg1.
Even distribution may not be possible if the allowed ranges of prop_seg and
phase_seg1 are not equal.
Fixes: #55919
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Check the requested CAN timing parameters against the min/max values
supported by the driver and return an error if they are out of range.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for setting the Synchronization Jump Width (SJW) for both the
classic/arbitration phase and the CAN-FD data phase.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the can_sja1000.h header file to the public
include/zephyr/drivers/can/ include path. This allows writing out-of-tree
SJA1000 based driver front-ends.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_utils_filter_match() utility function to
can_frame_matches_filter(), move it to the public
include/zephyr/drivers/can.h header file, and add a missing mismatch for
standard (11-bit) ID frames passing extended (29-bit) filters.
This allows using the utility function in out-of-tree CAN drivers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This commit aims at updating the drivers stop function to better
follow the CAN header file which specifiec that stopping the CAN
controller should "abort any pending CAN frame transmissions".
Signed-off-by: Benjamin Björnsson <benjamin.bjornsson@gmail.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>
Remove the CAN_HAS_RX_TIMESTAMP Kconfig helper symbol in order to allow
enabling CAN RX timestamps in the API regardless of driver support.
This simplifies application prj.conf settings across board supporting/not
supporting RX timestamps considerably.
CAN drivers not supporting RX timestamps already initialize the timestamp
to 0 for received frames.
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>
Add support FD frame filter to configure type frame for
each Rx msg to receive corresponding frames (classic, FD frames).
The Bosch M_CAN driver does not support FD frame filter,
so inmplement driver to handle it in software.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
The number of extended filters can be up to 15 for MCUs like the NXP
LPC55Sxx series, so the flags don't fit into uint8_t.
Fixes#53417
Signed-off-by: Martin Jäger <martin@libre.solar>
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>
`spi_is_ready` function is being deprecated in favor of
`spi_is_ready_dt` so let's replace the old usage in the tree.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Use the new PCIe core infrastructure for looking up the BDF at runtime
based on the VID/DID values.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The can_kvaser_pci_data_##inst type was supposed to be
can_kvaser_pci_data and not can_kvaser_pci_config. This got unnoticed
because there were no struct members to pre-initialize, and a reference
to the struct was stored using a void pointer.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
A regression was introduced in ef804d8408
when the M_CAN driver was swapped to use the generic dcache API, but
cache management was not enabled on SAM devices.
Enable cache management on SAM devices when CAN_SAM is selected.
Signed-off-by: Perry Hung <perry@genrad.com>
Rename the CAN loopback driver receive function to make the code easier to
understand. Add proper check against NULL for RX callback function
pointers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for configuring CAN emulation support in QEMU. For now, the
only supported CAN controller is the single-channel Kvaser PCIcan PCI card.
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>
Linux kernels before v5.14 do not define the CANFD_FDF flag. The flag is
disregarded within the Linux kernel. It is just there for being able to
reuse the canfd_frame struct for classic CAN frames in Linux user-space
applications.
Define the CANFD_FDF flag locally if not already defined to allow compiling
against older Linux kernel headers.
See the following Linux kernel commit for further details:
02546884221279da2725e87e35348290470363d7
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>
The phys property was not considered during initialization of the
driver config, so that the transceiver was not enabled properly
in case it has an enable/standby pin.
Signed-off-by: Martin Jäger <martin@libre.solar>
Newer ESP32 series MCUs like the ESP32-C3 contain some register changes
incompatible to the original ESP32 and the SJA1000.
The additions in this commit consider these changes and fix the
incompatibilities in the TWAI front-end for the SJA1000 driver.
Signed-off-by: Martin Jäger <martin@libre.solar>
This is a preparation to use the custom implementation in ESP32 TWAI
frontend for newer ESP32 series chips like the ESP32-C3, which have
timing registers incompatible with the SJA1000.
Signed-off-by: Martin Jäger <martin@libre.solar>
Abort any pending transmissions before entering configuration mode and
notify the senders.
Poll for mode change completion instead of assuming mode changes take
immediate effect. This is needed for successfully entering configuration
mode with recently aborted transmissions.
Fixes: #50545
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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.
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 lpcxpressso55s16 board
when running in default configuration.
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.
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.
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.
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.
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.
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>
Provide a default, internal callback to CAN controller drivers
implementation of can_send() if no callback was provided by the caller.
This allows for simplifying the CAN driver implementations of can_send() as
these no longer need special handling for callback/no callback operation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The receive path for the Renesas R-Car CAN controller supports two RX
FIFOs, which are currently configured for standard 11-bit CAN ID data
frames in FIFO0, and extended 29-bit CAN ID data frames in FIFO1.
As this leaves no room for matching remote transmission request (RTR)
frames, have the driver return -ENOTSUP instead of silently accepting RTR
filters.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
With the move to start/stop functions the transceiver is not expected
to be enabled after driver initialization.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.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>
This driver provides an interface to SocketCAN interfaces of the Linux
system running a Zephyr application with the native_posix board. These
interfaces may be virtual or actual CAN buses.
Signed-off-by: Martin Jäger <martin@libre.solar>
Update the GPIO-controlled CAN transceiver driver to use the
DT_HAS_CAN_TRANSCEIVER_GPIO_ENABLED Kconfig symbol to expose the driver and
enable it by default based on devicetree.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the CAN_STM32FD_CLOCK_DIVISOR configuration option,
and add configuration via dts property clk-divider instead.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
The configurable CAN clock divider CAN_STM32FD_CLOCK_DIVISOR
was not applied during initialization, because write protection
was not disabled.
While the clock divider was not applied, it was still used in clock rate
calculation, therefore resulting in incorrect bus speed setup.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Use domain clocks if they are defined in dts.
Until now domain clock sources could be selected via kconfig.
STM32 platform now can configure domain clock sources via
clock control driver, therefore this commit makes use of it.
The configuration is shared between canfd instances, so a domain clock
has to be defined for only one instance. Otherwise, only the
configuration from the latest initialized instance will remain.
The dependency on clock source PCLK1 for CAN_STM32FD_CLOCK_DIVISOR
was removed, because the divider also divides other clocks.
Note that setting that divider does not work at all at the moment,
because the write protection is not disabled.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.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>
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>
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>
Expand the error return values reported by the CAN timing calculation
functions to be able to distinguish between an an out of range
bitrate/sample point, an unsupported bitrate, and a resulting sample point
outside the guard limit.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the check for the maximum allowed CAN bitrate to the corresponding
can_calc_timing()/can_calc_timing_data() function.
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>
Rename the mcp2515 driver internal functions to not use "zcan" to avoid
confusion after "struct can_frame" 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>
Remove the Kconfig option for configuring the maximum value of the CAN-FD
Data Length Code in order to ensure standard compliance.
Allowing users to configure the max DLC allows the user to save a number of
bytes per CAN frame in RAM, but it also renders the Zephyr CAN-FD
implementation non-compliant with the CAN-FD standard.
There are no guarantees that a Zephyr CAN-FD node will not receive a CAN
frame with a DLC higher than the Kconfig limit, which opens up for all
sorts of bugs when trying to handle received CAN-FD frames.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The previous driver implementation aimed to maximize the amount of
filters, which resulted in a fairly complex implementation.
Background: The bxCAN assigns a number to the filters in the order they
appear in the filter banks. This number is used to match messages in
the FIFO with their filter. If the scale or mode of a filter bank is
changed, all following filter numbers get an offset and the assigned
callbacks have to be shifted accordingly.
The required additional space for the shifting operations resulted in
non-deterministic behaviour and the maximum number of filters could not
be determined at compile-time, which made several tests like
tests/drivers/can/api fail.
This implementation uses a more simple but reliable approach for
filtering and and reserves fixed space for extended and standard ID
filters in the available banks (configurable via Kconfig).
The list mode is not used, which may reduce the total number of usable
filters depending on the application.
The maximum amount of filters is 14 if all filters use ext. IDs,
28 if all use std IDs and something in between if mixed IDs are used.
Also see issue #47986 for more detailed background information.
Signed-off-by: Martin Jäger <martin@libre.solar>
Namespace local functions, enums, structs and defines with stm32/STM32
to distinguish them from global CAN API.
Also rename some internal conversion functions to make their meaning
more clear and delete unused defines.
Signed-off-by: Martin Jäger <martin@libre.solar>
Add ESP32 TWAI CAN controller driver. The TWAI is register-compatible with
the NXP SJA1000 CAN controller.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
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>
Update CAN drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol to expose
the driver and enable it by default based on devicetree.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Check the frame ID type and RTR bit when comparing loopback CAN frames
against installed RX filters.
Fixes: #47904
Signed-off-by: Henrik Brix Andersen <hebad@vestas.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>
The Bosch M_CAN IP does not support RX filtering of the RTR bit, so the
driver handles this bit in software.
If a recevied frame matches a filter with RTR enabled, the RTR bit of the
frame must match that of the filter in order to be passed to the RX
callback function. If the RTR bits do not match the frame must be dropped.
Improve the readability of the the logic for determining if a frame should
be dropped and add a missing FIFO acknowledge write for dropped frames.
Fixes: #47204
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the CAN bus network driver from drivers/can to drivers/net as it
implements a network driver, not a CAN controller driver.
Use a separate Kconfig for enabling the CAN bus network driver instead of
piggybacking on the SocketCAN Kconfig. This allows for other
(e.g. out-of-tree) SocketCAN transports.
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>
Switch from using a driver-specific, compile-time devicetree one-shot
property to supporting the newly added CAN_MODE_ONE_SHOT flag for
enabling/disabling one-shot mode at run-time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fix issue #45168.
When setting high bit timing, the controller is timing
out when trying to switch from an internal mode to another.
To fix this issue, we add some delay when switching modes.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Fix issue #45169.
With this CAN controller, changing bit timing has to be done in controller
reset mode, resetting some registers to their default values.
TCR register, that is enabling loopback mode is one of these.
Because of this reset, the controller switch back from loopback
to normal mode without the test suite being notified, preventing
receiving sent frames afterwards.
To fix this issue, we are now storing useful registers values before
switching to reset mode and restoring these values in halt mode
before going back in operation mode.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
CAN1 and CAN2 share the memory for the filter banks.
This commit adds an offset for filters installed for CAN2, allowing to
use both CAN instances simultaneously.
The hardware allows to freely split the avalable 28 filters between
CAN1 and CAN2. In order to simplify the driver implementation, it only
supports an equal split of 14 filters per instance. This is the same
amount of filters as available in MCUs with only a single CAN.
Signed-off-by: Martin Jäger <martin@libre.solar>
Remove two functions which were only called from one place and did
not improve readibility of the code.
Signed-off-by: Martin Jäger <martin@libre.solar>
This commit unifies the driver initialization for can1 and can2
instances so that a single macro can be used.
Enabling the master clock for can2 as introduced in 8ab81b02 had to
be moved to devicetree in order to have the same CAN_STM32_CONFIG_INST
macro for all instances.
Signed-off-by: Martin Jäger <martin@libre.solar>
the return is missing at the end of function which causes compilation
warning and block the build on github.
"warning: control reaches end of non-void function [-Wreturn-type]
92 | }| ^"
Signed-off-by: TLIG Dhaou <dhaou.tlig-ext@st.com>
The FDCAN clock was being enabled using HAL APIs instead of the generic
clock control API.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
For devices with more than one CAN peripherals, CAN1 is the master and
its clock has to be enabled also if only CAN2 is used.
Signed-off-by: Martin Jäger <martin@libre.solar>
Assertions in can_mcan failed because the driver expects values
strictly greater than 0
Signed-off-by: Tomislav Milkovic <tomislav.milkovic95@gmail.com>
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>
Use the UPLLCK clock for the CAN controller as recommended by the Atmel SAM
E70 data sheet.
Move the configuration of the clock prescaler from Kconfig to devicetree
and limit it to the values recommended by the SAM E70 datasheet.
Fixes: #45012
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
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>
The STM32u% series of processors has a unique set of clock sources for
the FDCAN peripheral. This brings the selection in line with the
existing can_stm32fd clock selection Kconfigs.
This change was tested on a proprietary board using the STM32U5 series
which exposes the CAN pins of the SOC using a transciever on a live CAN
bus as well as on the nucleo_g474re board from ST in loopback mode.
HSE and PLL1Q tests run and all passed.
PLL2P is not currently supported by the clock drivers for STM32U5, and
as such is currently untested. When this support is added, the driver
should be able to use this clock without issue.
When changes from #42097 are merged this fix should be deprecated in
favor of using the methods outlined there.
Signed-off-by: Peter Maxwell Warasila <madmaxwell@soundcomesout.com>
Refactor the Bosch M_CAN shared driver functions to get rid of the
front-end driver wrapper functions.
This requires flipping the relationship between shared config/data
structs and front-end config/data structs. Front-end drivers can now
store a pointer to their custom config/data structs in the .custom
fields of the can_mcan_config and can_mcan_data data structures.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the private header file for the Bosch M_CAN shared driver code
from can_mcan_int.h to can_mcan_priv.h to follow the common naming
scheme.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the default initialization priority for CAN transceiver from 70 to
45 to initialize them before the CAN controllers (with default a
initialization priority of 50).
Fixes: #45219
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Do not soft-reset device when changing timing parameters as the
soft-reset will discard the configured CAN controller mode.
Fixes: #44837
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename CONFIG_CAN_STM32_CLOCK_DIVISOR to
CONFIG_CAN_STM32FD_CLOCK_DIVISOR to match driver Kconfig name.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for selecting the CAN clock source. Change previously
hardcoded value of PCLK1 to HSE.
Fixes: #44985
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Do not silently ignore attempts to set an unsupported mode. Return
-ENOTSUP instead.
Fixes: #44706
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Only add the filter ID offset for extended CAN-ID filters if the filter
was added successfully. Raise log level from info to warning if filter
addition failed but only log it once.
Fix bounds check for removing an extended CAN-ID filter.
Fixes: #44721
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Remove support for the optional API function can_get_max_filters() from
the STM32 bxCAN driver for now.
The function returns the Kconfig value for the maximum number of filters
but the true number of supported filters may be different due to the
filter nature of the STM32 bxCAN driver implementation.
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>
CAN in Automation (CiA) 301 v4.2.0 recommends a sample point location of
87.5% percent for all bitrates. However, some CAN controllers have
difficulties meeting this for higher bitrates.
Change can_set_bitrate() to use a sample point of 75.0% for bitrates
over 800 kbit/s, 80.0% for bitrates over 500 kbit/s, and 87.5% for all
other bitrates. This is in line with the sample point locations used by
the Linux kernel.
Regard a sample point error of more than +/- 5.0% as an error in setting
the bitrate. Previously, any sample rate error was accepted without
providing any feedback to the caller. This is in line with the CAN
sample point calculation criteria used by the Linux kernel.
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>
Pass a copy of outbound argument structs to the implementation functions
as recommended for Zephyr system calls.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Verify read access to the timing and timing_data parameters in
z_vrfy_can_set_timing() and pass a copy of these structs to the
implementation as recommended for Zephyr system calls.
Remove unnecessary typecasts.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The MCP2515 requires phase segment 2 to be at least 2 time quanta.
The prescaler has a 6 bit register, allowing for real-world prescaler
values between 1 and 64.
Fixes: #44484
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fix the bounds check for the data phase prescaler timing parameter. The
maximum allowed value is 0x20, not 20 decimal.
Fixes: #44483
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Take CAN_SJW_NO_CHANGE into account when bounds checking the sjw timing
parameter values.
Fixes: #44482
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>