At present, many of the NXP S32 shim drivers do not make use of
devicetree instance-based macros because the NXP S32 HAL relies on an
index-based approach, requiring knowledge of the peripheral instance
index during both compilation and runtime, and this index might not
align with the devicetree instance index.
The proposed solution in this patch eliminates this limitation by
determining the peripheral instance index during compilation
through macrobatics and defining the driver's ISR within the shim
driver itself.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Move the syscall_handler.h header, used internally only to a dedicated
internal folder that should not be used outside of Zephyr.
Signed-off-by: Anas Nashif <anas.nashif@intel.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>
Add support for CAN statistics to the SJA1000 CAN controller driver. The
hardware does not support distinguishing between being unable to transmit
dominant versus being unable to transmit recessive bits.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for CAN statistics to the Microchip MCP2515 CAN controller
driver. The hardware only supports reporting RX overruns.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add option for overriding the maximum number of wait loop iterations for
entering/leaving freeze mode. Set the default to 10000 (as opposed to a
default of 1000 used in the HAL).
Fixes: #56171
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>
Only copy frame data for non-RTR frames as RTR frames do not carry any
data. Limit the amount of data copied to the actual DLC.
Fixes: #57002
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The can_sja1000_handle_error_warning_irq() function should only attempt to
start bus-off recovery, but not wait for the result.
Fixes: #63712
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the integer arithmetic to divide first before multiply.
The muliplication of sys_clock_hw_cycles_per_sec() by ten leads
to a really big number on boards with high-speed clocking, thus
to the overflow warning, and to errors for integration tests.
Fixes: #63678
Signed-off-by: Stephan Linz <linz@li-pro.net>
Remove excessive debug logging from the SJA1000 driver backend. Logging
each register access makes generic CAN debug logging unusable.
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>
This continue PR #31270. The updated changes are:
- Updated to work with latest zephyr
- Inplace reads/writes of registers
- Batch read of RX messages when multiple messages can be read
- FIFO abstraction of RX/TEF queues
- Handle ivmif errors
- Use READ_CRC for register reads
- Use bitmasks instead of bitfield members
- Rename mcp25xxfd to mcp251xfd
- General cleanups
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.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>
Change the CAN timing calculation APIs to automatically calculate a default
(Re-)Synchronization Jump Width (SJW) value. The calculated value can be
overwritten by the caller if desired.
This allows automatically scaling the SJW according to the number of Time
Quanta (TQ) used for phase segment 2 instead of relying on a compile-time
fallback value defined in devicetree.
This reduces the can_set_timing()/can_set_timing_data() API functions to
simple setters (with validation).
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>
Switch from using DEVICE_DT_DEFINE()/DEVICE_DT_INST_DEFINE() to using
CAN_DEVICE_DT_DEFINE()/CAN_DEVICE_DT_INST_DEFINE() for remaining drivers.
This unifies CAN controller device driver initialization regardless of the
driver implementing CAN statistics support or not.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.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>
Add driver for the TI TCAN4x5x series of CAN controllers. These CAN
controllers are based on the Bosch M_CAN IP and interfaced via an SPI bus.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.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>
