The Xilinx CANFD driver. This driver supports the Xilinx CANFD Controller.

The CANFD Controller supports the following features:

Confirms to the ISO 11898-1, CAN 2.0A and CAN 2.0B standards.
Supports both Standard (11 bit Identifier) and Extended (29 bit Identifier) frames.
Supports Bit Rates up to 8 Mbps.
Transmit message object FIFO with a user configurable depth of up to 64 message objects.
Receive message object FIFO with a user configurable depth of up to 64 message objects.
Acceptance filtering through a user configurable number of up to 32 acceptance filters.
Loop Back mode for diagnostic applications.
Maskable Error and Status Interrupts.
Readable Error Counters.
External PHY chip required.
Backward compatiable for Legacy CAN.
Supports reception in Mailbox and Sequential Mode

The device driver supports all the features listed above, if applicable.

Driver Description

The device driver enables higher layer software (e.g., an application) to communicate to the CANFD. The driver handles transmission and reception of CAN frames, as well as configuration of the controller. The driver is simply a pass-through mechanism between a protocol stack and the CANFD. A single device driver can support multiple CANFDs.

Since the driver is a simple pass-through mechanism between a protocol stack and the CANFD, no assembly or disassembly of CANFD frames is done at the driver-level. This assumes that the protocol stack passes a correctly formatted CANFD frame to the driver for transmission, and that the driver does not validate the contents of an incoming frame

Operation Modes

The CANFD controller supports the following modes of operation:

Configuration Mode: In this mode the CAN timing parameters and Baud Rate Pre-scalar parameters can be changed. In this mode the CAN controller loses synchronization with the CAN bus and drives a constant recessive bit on the bus line. The Error Counter Register are reset. The CAN controller does not receive or transmit any messages even if there are pending transmit requests from the TX FIFO or the TX High Priority Buffer. the Storage FIFOs and the CAN configuration registers are still accessible.
Normal Mode:In Normal Mode the CAN controller participates in bus communication, by transmitting and receiving messages.
Sleep Mode: In Sleep Mode the CAN Controller does not transmit any messages. However, if any other node transmits a message, then the CAN Controller receives the transmitted message and exits from Sleep Mode. If there are new transmission requests from either the TX FIFO or the TX High Priority Buffer when the CAN Controller is in Sleep Mode, these requests are not serviced, and the CAN Controller continues to remain in Sleep Mode. Interrupts are generated when the CAN controller enters Sleep mode or Wakes up from Sleep mode.
Loop Back Mode: In Loop Back mode, the CAN controller transmits a recessive bit stream on to the CAN Bus. Any message that is transmitted is loop backed to the rx line and acknowledged. The CAN controller thus receives any message that it transmits. It does not participate in normal bus communication and does not receive any messages that are transmitted by other CAN nodes. This mode is used for diagnostic purposes.
Snoop mode:in Snoop Mode,The CAN controller transmits recessive bit stream on to CAN bus and does not participate in normal bus communication but receives messages that are transmitted by other CAN nodes.Received messages are stored based on receive ID match result. Error counters are disabled and cleared to 0. Reads to error counter register will return zero.

Buffer Alignment

It is important to note that frame buffers passed to the driver must be 32-bit aligned.

Receive Address Filtering

The device can be set to accept frames whose Identifiers match any of up to 32 filters set in the Acceptance Filter Mask/ID registers.

The incoming Identifier is masked with the bits in the Acceptance Filter Mask Register. This value is compared with the result of masking the bits in the Acceptance Filter ID Register with the Acceptance Filter Mask Register. If both these values are equal, the message will be stored in the RX FIFO.

Acceptance Filtering is performed by each of the defined acceptance filters. If the incoming identifier passes through any acceptance filter then the frame is stored in the RX FIFO.

PHY Communication

This driver does not provide any mechanism for directly programming PHY.

Interrupts

The driver has no dependencies on the interrupt controller. The driver provides an interrupt handler. User of this driver needs to provide callback functions. An interrupt handler example is available with the driver.

Virtual Memory

This driver supports Virtual Memory. The RTOS is responsible for calculating the correct device base address in Virtual Memory space and invoking function XCanFd_VmInitialize(), instead of XCanFd_Initialize(), to initialize the device at first.

Threads

This driver is not thread safe. Any needs for threads or thread mutual exclusion must be satisfied by the layer above this driver.

Device Reset

Bus Off interrupt that can occur in the device requires a device reset. The user is responsible for resetting the device and re-configuring it based on its needs (the driver does not save the current configuration). When integrating into an RTOS, these reset and re-configure obligations are taken care of by the OS adapter software if it exists for that RTOS.

Device Configuration

The device can be configured in various ways during the FPGA implementation process. Configuration parameters are stored in the xcan_g.c files. A table is defined where each entry contains configuration information for a CAN device. This information includes such things as the base address of the memory-mapped device, and the number of acceptance filters.

Asserts

Asserts are used within all Xilinx drivers to enforce constraints on argument values. Asserts can be turned off on a system-wide basis by defining, at compile time, the NDEBUG identifier. By default, asserts are turned on and it is recommended that users leave asserts on during development.

Building the driver

The XCanFd driver is composed of several source files.This allows the user to build and link only those parts of the driver that are necessary.

  Temp Change
  MODIFICATION HISTORY:

  Ver   Who  Date     Changes
  ----- ---- -------- -------------------------------------------------------
  1.0   nsk  06/04/15 First release
  1.0   nsk  15/05/15 Updated xcanfd.c for correct AFRID and AFRMSK Registers
		      Updated xcanfd.c and xcanfd.h to get configurable
		      TxBuffers in XCanFd_Config Struct and
		      XCanFd_GetFreeBuffer().
		      Modified XCANFD_BTR_TS1_MASK in xcanfd_hw.h.
		      Updated xcanfd.c while sending data when EDL is Zero.
		      Updated driver tcl file to get configurable TxBuffers.
		      (CR 861772).
  1.0	nsk  16/06/15 Updated XCanFd_Recv_Mailbox(), XCanFd_EnterMode()
		      XCanFd_GetMode() in xcanfd.c and Added new definition
		      for Register bits in xcanfd_hw.h and updated
		      XCanFd_IntrHandler() in xcanfd_intr.c as per new RTL.
		      Changes in RTL, Added new bits to MSR,SR,ISR,IER,ICR
		      Registers and modified TS2 bits in BTR and F_SJW bits
		      in F_BTR Registers.