Implementation of CAN-FD in STM32 devices

The STM32 devices defined in Table 1 embed an FDCAN peripheral that supports the CAN-FD protocol according to ISO 11898-12015. Most STM32 devices support more than one instance of CAN. Refer to the product datasheet for the number of instances available on a specific device.

The range of features and functionalities offered by the Flexible Data-rate Controller Area Network (FDCAN) feature in STM32 devices is dependent on the specific implementation of the device.

To fully understand the implementation and the capabilities of the FDCAN feature, refer to the product reference manual. The rest of this document will delve deeper into the advanced functionality of the FDCAN, referred to as the FDCAN superset.

The features of the FDCAN on STM32 devices are listed below:

• Compliant with CAN protocol version 2.0 part A, B and ISO 11898-1: 2015, -4
• Accessible 10-Kbyte RAM memory to allocate up to 2560 words
• Improved acceptance filtering
• Two configurable receive FIFOs
• Up to 64 dedicated receive buffers
• Separate signaling on reception of high priority messages
• Up to 32 dedicated transmit buffers
• Configurable transmit FIFO and transmit queue
• Configurable transmit event FIFO
• Clock calibration unit
• Transceiver delay compensation

The figure below illustrates the FDCAN block diagram.

All transmitted and received messages are stored in the CAN message RAM. During CAN message RAM initialization, the user must define where to store the 11-bit filter, the 29-bit filter, the received messages and the messages to transmission.

The quantity of data bytes per message must be configured to determine the memory space that is required per message. The increase of the payload on CAN-FD results in more efficient memory usage and allows more messages to be stored in the allocated memory space.

A dedicated RAM reserved to FDCAN on STM32 devices is used to allocate up to 2560 words of 32 bits. This reserved RAM space makes the CPU more efficient.

As illustrate in the figure below, the CAN message RAM is split into four different sections:

• section filtering (11-bit filter, 29-bit filter)
• section reception (Rx FIFO 0, Rx FIFO 1, Rx Buffer)
• section transmission (Tx event FIFO, Tx Buffers)
• section trigger memory (Trigger memory)

All sections of the FDCAN peripheral can be configured by the user. The sum of all elements of all sections must not be exceed the total CAN message RAM size. This RAM provides increased flexibility and performance by enabling the possibility to eliminate unused sections and to expand sufficient memory for the other sections.

The configured elements of each section are allocated in a dynamic and successive way in the CAN message RAM according to the order presented in above figure; however in order to avoid the risk of exceeding the RAM and for reliability reasons, a specific own start and end address is not assigned to each section.

The specific bits fields for control for reception are filter index, accepted non-matching frame, and Rx timestamp. The specific bits fields for transmission are message marker and event FIFO control bit.

The number of 32-bit words allocated for each element whatever Tx buffer, Tx FIFO, Tx queue or in Rx buffer are calculated to reserve:

• Header information (two reserved 32-bit-words) to allocate the identifier, the DLC field, the bits of control and the specific transmission/reception bits fields
• Data (the number of 32-bit words sufficient) to contain the number of bytes per data field

The formula below determines the number of 32-bit words allocated for each element:

Element size (in words) = Header information (2 words) + Data (data field/4)

where data field is the number of data bytes per message.

The necessary “element” size depending on data field range is detailed in the table below.

An example for efficient use of the CAN message RAM is illustrated in the figure below. This example assumes an application where the FDCAN peripheral is configured:

• to send 32 messages with dedicated Tx buffer (each message contains 8 bytes in the data field)
• to have 128 11-bit filters for acceptance of the messages
• to receive 64 messages where each message contains 64 bytes in data field in dedicated Rx buffers
• to receive 64 messages where each message contains 64 bytes in data field in Rx FIFO 0

In this example, the allocation in the RAM is done in the following order:

1. Allocate 128 words in the section ID-11bits.
2. Reserve 1152 words for the reception of the elements in the section Rx FIFO 0.
3. Reserve 1152 words for the reception of the elements in the section Rx buffer.
4. Reserve 128 words for the elements sent in Tx buffer.

Thanks to the dynamic allocation and by not making any allocation for unused sections, the whole memory size of the RAM is used efficiently: all the 2560 words are allocated in this application.

Most STM32 devices support more than one FDCAN instance to meet all the application requirements (refer to the product datasheet for the number of instances).

In this context, it is important to say that the RAM is shared between the different instances. The user can divide the RAM on the various instances (each instance size is chosen by indicating its start offset address).

An example of a CAN message RAM using multiple FDCAN instances is illustrated in the figure below. This example assumes that the user divides the CAN message RAM into two instances: the size of the first instance is the double of the second instance.

The FDCAN peripheral offers the possibility to configure two sets of acceptance filters: one for standard identifiers and one for extended identifiers to store or reject received messages. Up to 128 filter elements can be configured for 11-bit standard IDs and up to 64 filter elements can be configured for 29-bit extended IDs.

The start address of 11-bit filter section is configured via the FLSSA[13:0] bits in the FDCAN_SIDFC register and the 29-bit filter section is configured via the FLESA[13:0] in the FDCAN_XIDFC register.

The figure below shows a section of the CAN message RAM with the number of filter elements and their start addresses.

These filters can be assigned to the Rx FIFO 0/1 or to the dedicated Rx buffers. When the FDCAN performs acceptance filtering, it always starts at filter element #0 and proceeds through the filter list to find a matching element. Acceptance filtering stops at the first matching element and the following filter elements are not evaluated for this message. Therefore, the sequence of configured filter elements has a significant impact on the performance of the filtering process.

The user chooses to enable or disable each filter element, and can configure each element for acceptance or rejection filtering. Each filter element can be configured as:

• Range filter: the filter matches for all messages with an identifier in the range defined by two IDs.
• Filter for dedicated IDs: the filter can be configured to match for one or two specific identifiers.
• Classic bit mask filter: to match groups of identifiers by masking bits of a received identifier. The first ID configured is used as message ID filter, the second ID is used as filter mask. Each zero bit at the filter mask masks out the corresponding bit position of the configured ID filter.

The FDCAN can notify the user when a high priority message is received. This notifications can be used to monitor the status of incoming high-priority messages and to enable fast access to these elements.

The FDCAN detects a high-priority message with help of a message filter. A filter element provides the following settings related to high-priority messages:

• Set priority and store in FIFO 0/1 if filter matches: if this message filter matches, the FDCAN informs about the high-priority message arrival and stores the element in Rx FIFO 0/1.
• Set priority if filter matches: if this message filter matches, the FDCAN notifies about the high-priority message arrival but does not store the element.

The following flow chart explains the global mechanism of an acceptance filter.

Two Rx FIFO can be configured in the CAN message RAM. Each Rx FIFO section can store up to 64 elements. Each element is stored in one Rx FIFO element.

The size of a Rx FIFO element can be configured via the FDCAN_RXESC register for each Rx FIFO individually. The Rx FIFO element size defines how many data field bytes of a received element can be stored. The size of an Rx FIFO element is defined by the formula specified in RAM organization.

Header information contains the identifier, DLC field, control bits and the bits fields (filter index, accepted non-matching frame, Rx timestamp).

After the configuration of the element size via the F1DS[2:0] field in the FDCAN_RXESC register, the number of elements and the start address of Rx FIFO 1 must be configured respectively via the F1S[6:0] and F1SA[13:0] fields in the FDCAN_RXF1C register.

The figure below shows the Rx FIFO section on the CAN message RAM with the number of elements that can supported and the start address for each section.

The start address of an Rx FIFO is the address of the first word of the first Rx FIFO element. Received elements that pass the acceptance filtering are stored in the appropriate Rx FIFO based on the matching filter element.

If the Rx FIFO is full, the newly arriving element can be handled according to two different modes:

• Blocking mode: this is the default operation mode of the Rx FIFO, no further elements are written to the Rx FIFO until at least one element has been read out.
• Overwrite mode: The new element accepted in the Rx FIFO overwrites the oldest element in the Rx FIFO and the put and get index of the FIFO are incremented by one.

To read an element from an Rx FIFO, the CPU has to perform the following steps:

1. Read the register FDCAN_RXF1S to know the status of the Rx FIFO.
2. Calculate the address of the oldest element in the RAM as with the following formula:

   Oldest element address = CAN_message_RAM_base_address + FDCAN_RXF1C.F1SA (start address) + FDCAN_RXF1S.F1GI (get Index) x Rx FIFO_element_size.

3. Read the element from the calculated address.

After the CPU has read an element or a sequence of elements from the Rx FIFO, it must acknowledge the read. After acknowledgement, the FDCAN can reuse the corresponding Rx FIFO buffer for a new element. To acknowledge one or more elements, the CPU must write the buffer index of the last element read from Rx FIFO to FDCAN_RXF1A register. As a consequence, the FDCAN updates the FIFO fill level and the get index.

The following chart presents a simplified operation of Rx FIFO.

The FDCAN supports up to 64 dedicated Rx buffers. Each dedicated Rx buffer can store one element.

The size of a dedicated Rx buffer can be configured via the FDCAN_RXESC register. The Rx buffer size defines how many data field bytes of a received element can be stored. The size of a dedicated Rx buffer is defined by the formula described in RAM organization.

After the configuration of the element size via the RBDS[2:0] field in the FDCAN_RXESC register, the start address must be configured via the RBSA[13:0] field in the FDCAN_RXBC register.

The figure below shows the Rx buffer section on the CAN message RAM with the maximum number of dedicated Rx buffer elements that can be supported and the start address.

When an element is stored in a dedicated Rx buffer, the FDCAN sets the interrupt flag via the DRX bit in the FDCAN_IR register and the corresponding bit in the new data flag FDCAN_NDAT1 or FDCAN_NDAT2 registers. When bits are set in FDCAN_NDAT1/2, the respective Rx buffer is locked (not overwritten by a new element) and the corresponding filter does not match. After reading the element, the CPU has to reset the corresponding bit in FDCAN_NDAT1/2, in order to unlock the respective Rx buffer.

Example for the relative configuration of Rx buffer number to the Rx buffer index

In order to configure a filter element to reference an Rx buffer index 60, at least 61 Rx buffers must be configured.

Note:

The user must choose the best configuration to avoid wasting the RAM.

The figure below presents a flowchart to simplify the operation of Rx buffer.

As presented in the previous section, the FDCAN has two mechanisms: either a dedicated Rx buffer or Rx FIFO 0/1 can be configured to store a received element.

The differences between a dedicated Rx buffer and an Rx FIFO are described in the table below.

By using a Tx event FIFO, the CPU gets the following information about the sent elements:

• in which order the elements were transmitted
• the local time when the frame was transmitted for each element

The FDCAN provides a Tx event FIFO. The use of this Tx event FIFO is optional. After the FDCAN successfully transmitted an element on the CAN bus, it can store the message ID and the timestamp in a Tx event FIFO element. A Tx event FIFO element is a data structure that stores information about transmitted messages. The Tx event FIFO can be configured via the FDCAN_TXEFC register (Tx event FIFO configuration). The FIFO can store a maximum of up to 32 elements.

The following figure shows an example of a CAN message RAM where the Tx event FIFO elements are stored and the EFSA[13:0] field contains the start address.

The address of a Tx event FIFO element in the CAN message RAM, is determined by the formula below:

Tx event FIFO element address = CAN_message_RAM_base_address + FDCAN_TXEFC.EFSA (start address) + FDCAN_TXEFS.EFGI (get index) x Tx_event_FIFO_element_size

To link a Tx event to a Tx event FIFO element, the message marker from the transmitted Tx buffer is copied into the Tx event FIFO element.

Events are stored in Tx event FIFO only if the EFC bit (store Tx events) in the Tx buffer element, equals 1.

When the Tx event FIFO is full, no further elements are written to the Tx event FIFO until at least one element is read out and the Tx event FIFO get index is incremented. If a Tx event occurs while the Tx event FIFO is full, this event is discarded. To avoid a Tx event FIFO overflow, the Tx event FIFO watermark can be used.

After the CPU read an element or a sequence of elements from the Tx event FIFO, the CPU must acknowledge the read. Therefore, it writes the index of the last element read from Tx event FIFO via the EFAI[4:0] field in the FDCAN_TXEFA register.

For a module to transmit an element, the element is formed within the defined memory space and the transmission is initiated. The transmitted elements are stored in the Tx buffer section where the user can choose the mechanism to be used: a dedicated Tx buffer and/or Tx queue or Tx FIFO.

Up to 32 elements are supported by the FDCAN. Each element stores the identifier, the DLC, the control bits (ESI, XTD, RTR, BRS, FDF), the data field, the bits field message marker and the event FIFO control bit of only one message.

The allocation on the RAM is done in the following order: if dedicated Tx buffers are used by the application, then they are allocated before the Tx FIFO and Tx queue. The user can choose only Tx queue or Tx FIFO in the same application: a combination of them is not supported by the FDCAN.

As indicated in the figure below, the start address of Tx buffer section is configured via the TBSA[13:0] field in the FDCAN_TXBC register.

Note:

As indicated in the previous section, the allocation in the RAM is made in a dynamic and successive way so if the user does not configure a dedicated Tx buffer mechanism. The Tx buffer section contains only the configured Tx queue or Tx FIFO and it is stored in the start section address.

Dedicated Tx buffers

The number of dedicated Tx buffers are configured via the NTDB[5:0] field in the FDCAN_TXBC register. Each dedicated Tx buffer is configured with a specific identifier to store only one element. The transmission is requested by an add request via the FDCAN_TXBAR register. The requested messages arbitrate externally with messages on the CAN bus, and are sent out according to the lowest identifier (highest priority).

The memory requirements for the dedicated Tx buffers depend on the Tx buffer element size. The Tx buffer element size defines the number of data bytes belonging to a Tx buffer.

The address of a dedicated Tx buffer in the CAN message RAM is calculated using the formula below:

Dedicated Tx buffer address = CAN_message_RAM_base_address + FDCAN_TXBC[TBSA] (start address) + Tx_buffer_index x Tx_buffer_element_size

The following flow chart is used to simplify the operation of a transmission with the Tx buffer mechanism.

Note:

If multiple dedicated Tx buffers are configured with the same ID, the Tx buffer with the first transmission request is transmitted first.

Tx FIFO

The Tx FIFO operation is configured by writing 0 to the TFQM bit in FDCAN_TXBC. The elements stored in the Tx FIFO are transmitted starting with the element referenced by the get index via the TFG1[4:0] field in FDCAN_TXFQS. After each transmission, the get index is incremented cyclically until the Tx FIFO buffer is empty.

The Tx FIFO enables the transmission of elements in the order these elements have been written to the Tx FIFO. The transmission is independent of the priority of the respective identifiers because the first/oldest element in the FIFO is sent out first.

The FDCAN calculates the Tx FIFO buffer free level via the TFFL[5:0] field in FDCAN_TXFQS as a difference between get and put index (get and set index two mechanism increments each transaction to indicate the next buffer position on the RAM to read or write element). This value indicates the number of available (free) Tx FIFO elements.

New transmit elements must be written to the Tx FIFO starting with the Tx buffer referenced by the put index indicated via the TFAQPI[4:0] field in FDCAN_TXFQS.

The address of the next free Tx FIFO buffer in the CAN message RAM is calculated with the below formula:

Next free Tx FIFO buffer address = CAN_message_RAM_base_address + FDCAN_TXBC.TBSA (start address) + FDCAN_TXFQS.TFQPI (put Index) x Tx_FIFO_element_size

The following flow chart shows a simplified operation of the transmission with Tx FIFO mechanism.

Tx queue

Tx queue operation is configured by writing 1 to the TFQM bit in FDCAN_TXBC. The elements stored in the Tx queue are transmitted starting with the Tx queue buffer with the lowest Identifier (highest priority).

In contrast to dedicated Tx buffers, the position on the RAM is automatically and dynamically managed so the message identifier is not fixed to a predefined Tx buffer index.

New messages have to be written to the Tx queue buffer referenced by the put index. An add request cyclically increments the put index to the next free Tx queue buffer. The fact that Tx queue is full is indicated by the TFQF bit set to 1 in FDCAN_TXFQS. No further element must be written to the Tx queue until at least one of the requested elements is sent out or a pending transmission request is cancelled.

The memory requirements for the Tx queue buffer depend on the number of data bytes belonging to Tx queue element.

The address of a next available free Tx queue buffer in the CAN message RAM can be calculated by the following formula:

Next free Tx queue buffer address = CAN_message_RAM_base_address + FDCAN_TXBC.TBSA (start address) + FDCAN_TXFQS.TFQPI (put index) x Tx_Buffer_element_size

The following flow chart shows a simplified operation of the transmission with Tx queue mechanism.

Mixed configuration: dedicated Tx buffers and Tx FIFO

The Tx buffer section of the CAN message RAM can be configured with a mixed configuration, where the Tx buffers section in the CAN message RAM is subdivided into a set of dedicated Tx buffers and a Tx FIFO.

The number of dedicated Tx buffers is configured via NDTB[5:0] in FDCAN_TXBC. The number of Tx buffers assigned to the Tx FIFO is configured via TFQS[5:0] in FDCAN_TXBC.

The Tx handler scans all the dedicated Tx buffers with an activated transmission request and the oldest pending Tx FIFO buffer referenced by the get index. The buffer with the lowest identifier gets the highest priority and is transmitted next.

A use case using a mixed dedicated Tx buffer and a Tx FIFO is illustrated in the figure below.

In this example, the elements are transmitted in the following order (assuming that all dedicated Tx buffers requests are enabled):

1. Tx buffer 3 (identifier = 1: it is the highest priority between all other dedicated Tx buffers and it has a higher priority than the oldest pending Tx FIFO: Tx buffer 7)
2. Tx buffer 0 (identifier = 3: it is the highest priority between all other dedicated Tx buffers and it has higher priority than the oldest pending Tx FIFO: Tx buffer 7)
3. Tx buffer 7 (because it is the oldest pending Tx FIFO with identifier =4 and has higher priority between all dedicated Tx buffers)
4. Tx buffer 8 (because it is the oldest pending Tx FIFO with identifier =2 and has the highest priority between all dedicated Tx buffers)
5. Tx buffer 4 (identifier = 8: it has the highest priority between all other dedicated Tx buffers and the Tx FIFO is empty)
6. Tx buffer 2 (identifier = 12: it has the highest priority between all other dedicated Tx buffers and the Tx FIFO is empty)
7. Tx buffer 1 (identifier = 15: it has the highest priority between all other dedicated Tx buffers and the Tx FIFO is empty)
8. Tx buffer 5 (because it is the only pending dedicated Tx buffer)

Mixed configuration: dedicated Tx buffers and Tx queue

The Tx buffer section of the CAN message RAM can be configured with a mixed configuration where the Tx buffers section in the CAN message RAM is subdivided into a set of dedicated Tx buffers and a Tx queue.

The number of dedicated Tx buffers is configured via NDTB[5:0] in FDCAN_TXBC and the number of Tx queue buffers is configured via TFQS[5:0] in FDCAN_TXBC.

The Tx handler scans all the dedicated Tx buffers with activated transmission request and the Tx queue buffers. The buffer with the lowest identifier gets the highest priority and is transmitted next.

A use case using a mixed dedicated Tx buffer and a Tx queue is illustrated in the figure below.

In this example, the messages are transmitted in the following order (assuming that all dedicated Tx buffers request are enabled):

1. Tx buffer 3 (identifier = 1: it is the highest priority between all other Tx buffers)
2. Tx buffer 8 (identifier = 2: it is the highest priority between all other Tx buffers)
3. Tx buffer 0 (identifier = 3: it is the highest priority between all other Tx buffers)
4. Tx buffer 7 (identifier = 4: it is the highest priority between all other Tx buffers)
5. Tx buffer 4 (identifier = 8: it is the highest priority between all other Tx buffers)
6. Tx buffer 2 (identifier = 12: it is the highest priority between all other Tx buffers)
7. Tx buffer 1 (identifier = 15: it is the highest priority between all other Tx buffers)
8. Tx buffer 5 (because it is the only pending Tx buffer)

Note:

The mixed configuration with Tx FIFO and Tx queue is not supported.

Within the operation mode of a FDCAN, several test modes are available besides the normal operation. There test modes must be used for production tests or self-test only and for the calibration unit.

The TEST bit in FDCAN_CCCR must be set to 1 to enable a write access to the FDCAN test register and the configuration of test modes and functions.

The FDCAN works in one of the following modes:

• Restricted-operation mode
• Bus-monitoring mode
• External loop-back mode
• Internal loop-back mode

In restricted-operation mode, the FDCAN is able:

• to receive data frames
• to receive remote frames
• to give acknowledge to valid frames

This mode does not support:

• data frames sending
• remote frames sending
• active error frames or overload frames sending

The FDCAN is set in the restricted-operation mode via the ASM bit in FDCAN_CCCR.

The restricted-operation mode is automatically entered when the Tx handler is not able to read data from the CAN message RAM on time or when the clock calibration is active.

In this mode, the application tests different bit rates and leaves the restricted-operation mode after the application received a valid frame.

The following figure illustrates the connection of FDCAN_TX and FDCAN_RX pins in restricted-operation mode.

In order to analyze the traffic on the bus without affecting it by the transmission of dominant bits, the user can set the FDCAN in bus‑monitoring mode via the MON bit in FDCAN_CCCR.

In bus-monitoring mode, the FDCAN is able:

• to receive valid data frames
• to receive valid remote frames

This mode does not support:

• transmission start
• acknowledge to valid frames (difference versus the restricted-operation mode)

In the bus-monitoring mode, the FDCAN only sends recessive bits on the bus. The figure below shows the connection of FDCAN_TX and FDCAN_RX pins in bus-monitoring mode.

This mode is provided for hardware self-test. The user can set the FDCAN in external loop-back mode by writing 1 to the LBCK bit in FDCAN_TEST and by writing 0 to the MON bit in FDCAN_CCCR. The FDCAN treats its own transmitted messages as received messages and stores them if they pass the acceptance filtering in Rx FIFO.

In order to be independent from the external stimulation, the FDCAN ignores acknowledge errors (recessive bit sampled in the acknowledge slot). The FDCAN performs an internal feedback from its “transmit” output to its “receive” input.

The following figure shows the connection of FDCAN_TX and FDCAN_RX pins in external loop‑back mode.

This mode is provided for hardware self-test. The user can set the FDCAN in internal loop-back mode via by writing 1 to the LBCK bit in FDCAN_TEST and by writing 1 to the MON bit in FDCAN_CCCR.

The FDCAN can be tested without affecting a running CAN system connected to the FDCAN_TX and FDCAN_RX pins. FDCAN_RX pin is disconnected from the FDCAN and FDCAN_TX pin is held recessive.

The figure below shows the connection of FDCAN_TX and FDCAN_RX pin in internal loop-back mode.

At the sample point, all transmitters check whether the previously transmitted bit is sampled correctly. This mechanism is needed to check for problems and to detect other node error frames. Since the transmitter sees its own transmitted bits delayed by the transceiver loop delay, this delay sets a lower limit to the TSEG1 as shown in the figure below (time segment before sample point), that is also an upper limit to the data bit rate. This is the reason why the transceiver delay compensation mechanism (TDC) was introduced.

In order to compensate this loop delay when checking for bit errors, a secondary sample-point (SSP) is defined. Instead of being done at the sample point, the transmitted bits are checked at the SSP. The result of that check is stored until the next sample point is reached.

An SSP is generated for each bit transmitted in the data phase. Transceiver asymmetry and ringing on the bus have to be considered for the SSP position, but there is no clock tolerance, since the transceiver monitors its own bit stream.

The transceiver delay compensation is enabled by writing 1 to the TDC bit in FDCAN_DBTP. The measurement starts within each transmitted FDCAN frame before the beginning of the data phase (at the falling edge of the FDF bit to bit res). The measurement stops when this edge is seen at the “receive” input pin FDCAN_RX of the transmitter. The resolution of this measurement is 1 mtq (minimum time quantum).

The following figure presents the measurement of loop delay.

The SSP position is defined as the sum of the measured delays from the FDCAN_TX pin to the FDCAN_RX pin, plus the transmitter delay compensation offset as configured via the TDCO[6:0] field in FDCAN_TDCR.

The value of a transmitted bit is stored until its SSP is reached, then it is compared with the actually received bit value, as in figure below, that shows a transmitted bit sequence A to K and a received bit sequence AR to KR, together with a sequence of SSPs from SSPA to SSPK. The received bit BR is checked at SSPB by comparing it with the delayed bit B1. The position of SSPB is at a specific time after the start of the transmitted bit B. This specific time is the sum of the measured transceiver delay and the configured SSP offset.

The next part of this document explains the clock calibration unit with a description of its utility and operation.

The FDCAN supports the clock calibration unit (CCU) feature. This feature allows a user to calibrate a FDCAN receiver (device) by a FDCAN transmitter (host). For example, when the FDCAN device communicates with the newest bitrate of the host.

This feature allows the user to add a new instance in the bus and the existence of the bitrate is unknown. It is also useful when the FDCAN receiver does not have a precise quartz (can cause an error on time).

The clock calibration unit is initialized via the FDCAN_CCU_CCFG register, that can be written only when both CCE and INIT bits are set to 1 in FDCAN_CCCR.

The CCU is only possible when the FDCAN operates in CAN 2.0 mode.

The clock calibration is bypassed when BCC = 1 in FDCAN_CCU_CCFG. The following figure shows the bypass operation.

The CCU operates only when the FDCAN bitrate is between 125 Kbit/s and 1 Mbit/s.

The calibration of fdcan_tq_ck (time quanta clock) via CAN messages is performed by adapting a clock divider that generates the CAN protocol time quantum, tq, from the fdcan_ker_ck clock.

Calibration of the state machine

The calibration of the functional state machine is illustrated below.

This example presents a use case to calibrate an FDCAN device (receiver) by an FDCAN host (transmitter). The following flow chart illustrates the steps through the FDCAN device before calibrating.

After the calibration passed successfully, the FDCAN device becomes ready for reception and transmission messages with the new FDCAN host bitrate.