The implementation of can_mcan_start() function
hides retun code of underlying function.
It makes root-cause search more difficult.
This change strives fro transparent error code
propagation to higher software layers.
Signed-off-by: Alexander Kozhinov <ak.alexander.kozhinov@gmail.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>
In some cases CAN-Bus communication may be
disturbed by other parts of SoC. For example USB
may disturb CAN communication if electircal wiring
of the board is not done properly or the system is
in development stage.
This change adds debug-prints s.t. CAN-Bus protocol
errors in arbitration or data phases can be
detected while in CAN-Bus ISR.
Signed-off-by: Alexander Kozhinov <ak.alexander.kozhinov@gmail.com>
can_mcan_send/can_mcan_get_message issued a message ram write/read even
when data length was 0. This caused some issues on systems where data
cache is enabled, because the cache invd/flushing calls present in the
mcan driver can fail if provided length is 0.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Found via static analysis. In `can_mcan_state_change_handler`, the
return value of `can_mcan_get_state` is not checked for error. In the
event of an error, both `err_cnt` and `state` are left unitialized and
accessed downstream.
The correct behavior is to return early in that case.
Signed-off-by: François Baldassari <francois@memfault.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>
Enable Transmitter Delay Compensation whenever the data phase timing
parameters allow it.
Fixes: #70447
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove broken support for Transmitter Delay Compensation from the Bosch
M_CAN backend driver.
Even if this was enabled via Kconfig, the TDC bit in the DBTP register set
during driver initialization is overwritten in can_mcan_set_timing_data(),
turning TDC off.
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>
Fix handling bus-off events in the Bosch M_CAN driver backend:
- Cancel all pending TX buffers when entering bus-off state
- Call all pending TX buffer callbacks with -ENETUNREACH when entering
bus-off
- Automatically initiate bus-off recovery if
CONFIG_CAN_AUTO_BUS_OFF_RECOVERY=y
Fixes: #68953
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>
The code is designed to handle RF0L and RF1L in
line 1, but they were being sent to line 0. Becuase
they weren't handled, the interrupts would never
be handled which locked up the chip.
Signed-off-by: Abram Early <abram.early@gmail.com>
Remove unnecessary calls to __ASSERT_NO_MSG() in CAN controller driver
timing setter callbacks. The CAN API functions can_set_timing and
can_set_timing_data() already provide run-time timing parameter validation.
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>
Add CAN stats for MCAN drivers.
Update MCAN drivers to use CAN_DEVICE_DT_INST_DEFINE
which initialises and registers CAN stats if enabled.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
"callback != NULL" is used to determine if the callback is in use.
The TX complete semaphone should only be given back after setting the
callback to NULL.
This would likely only be a race condition if the ISR is processed on a
different core to the TX call.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
The MCAN driver operates in TX queue mode (TXBC.TFQM = 1). In this mode
TXFQS.TFQPI returns the first available buffer (usually buffer zero).
Hardware is free to re-use a buffer as soon as TX completes, it does not
have to wait for the matching TX event to be processed.
If a TX completes and that TX buffer is re-used before processing the TX
event, two TX events for the same buffer occur. The first event calls the
second events TX callback, and the second event results in a NULL pointer
exception.
In a "normal" configuration, the TX event ISR will always preempt the
queuing of a TX frame to the same TX buffer.
However, this issue could occur if:
* Sending a message with ISRs temporarily disabled.
* The ISR is processed on a different core to the TX call.
The fix is to manually track which TX buffers are available, only freeing
a buffer after the TX event has been processed.
The MCAN user manual states that this is allowed:
"The application may use register TXBRP instead of the Put Index and may
place messages to any Tx Buffer without pending transmission request"
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Remove excessive debug output on Bosch M_CAN register access. This was
accidentially included in commit bbfc1f905c.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
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>
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>
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>
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>
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>
Henrik Brix Andersen
Alexander Kozhinov
Gerard Marull-Paretas
François Baldassari
Grant Ramsay
Abram Early
Kamil Serwus