iCC 2015 CAN in Automation

Linux and ISO 15765-2 with CAN FD

Dr. Oliver Hartkopp, Volkswagen AG

Only two weeks after disclosure of the CAN FD main features at 13th iCC [1] the Linux
CAN community started to discuss about a seamless integration of CAN FD into the CAN
subsystem of the Linux operating system. This paper gives a comprehensive survey
about the integration, configuration and usability of CAN FD in the Linux operating
system as well as an introduction into the new ISO15765-2:2015 with CAN FD support.

With the integration of the socket-based content is the elementary data definition for
CAN support in Linux 2.6.25 [2] in April SocketCAN. The original classic CAN frame
2008 the data structures and programming data structure is defined as:
interfaces were defined and therefore fixed
in an application binary interface (ABI). struct can_frame {
canid_t can_id;
This fixed ABI implies that Linux CAN (aka
__u8 can_dlc;
SocketCAN) applications that were compiled __u8 __pad;
and linked statically for Linux in 2008 are __u8 __res0;
able to run on the latest Linux system with a __u8 __res1;
recent Linux 4.x kernel. __u8 data[8]; /*aligned*/
};
Analogue to this guaranteed binary
backward compatibility for applications the
introduction of the common CAN driver The can_id contains the CAN Identifier with
interface in Linux 2.6.31 in September 2009 additional bit values e.g. to point out a 29
fixed the way how CAN network interfaces bit identifier or RTR frames. The can_dlc
are configured in terms of bitrate and other contains the number of used bytes in the
CAN controller specific settings. data[ ] byte array. Remark: The padding and
reserved bytes have been added recently
From the perspective of CAN application to be in line with the CAN FD definitions.
programmers the formerly settled properties These extensions do not have an impact on
of up to eight bytes of payload and a single the application binary interface as the data[
bitrate to be set into the CAN controller ] was always 64 bit aligned (see linux/can.h
became uncertain. With CAN FD the known [3] for details).
CAN bitrate configuration is doubled and the
data structures to hold CAN frame contents For the CAN FD frame a separate data
are increased in size which can lead to buffer structure has been defined:
overflows when the former CAN frame data
structure is accidently used. Preserving struct canfd_frame {
canid_t can_id;
the simple and established SocketCAN
__u8 len;
programming interface under the new __u8 flags;
conditions with CAN FD is an ambitious task __u8 __res0;
which has been accomplished by the Linux __u8 __res1;
CAN community instantaneously after 13th __u8 data[64]; /*aligned*/
};
iCC.

CAN FD data structures The major differences are the introduced

flags element which holds CAN FD frame
As the associated CAN interface and the specific flags like CANFD_BRS and
timestamp of the CAN frame are provided by CANFD_ESI and the len element. The len
existing Linux programming interfaces the element shares the position with the can_
data structure which holds the CAN frame dlc element of the classic CAN frame and

05-1
iCC 2015 CAN in Automation

(still) contains the number of used bytes When CAN FD is enabled for the socket e.g.
in the data[ ] byte array. In classic CAN the read() system call can return with two
applications the can_dlc value was usually different length information:
used as plain numeric length information
as there was a 1:1 mapping from the ‘data • 16 bytes for classic CAN frames
length code’ and the data length. Using CAN • 72 bytes for CAN FD frames
FD frames the data length code mapping is
performed on the CAN driver level which Therefore the buffer which is assigned to be
makes the software adaption for CAN FD utilized by the read() system call has to be a
pretty easy. of the size of a struct canfd_frame when CAN
FD is enabled. As the CAN FD controller still
Processing length information to print CAN might receive classic CAN frames in this FD
payload data (before CAN FD support): enabled mode the struct canfd_frame might
be filled with the shorter struct can_frame
struct can_frame cframe; content. Due to the identical layout - e.g.
with the can_dlc and len element – a classic
for (i=0; i < cframe.can_dlc; i++)
printf(„%02X „, cframe.data[i]); CAN frame can be stored inside the CAN
FD frame structure. To distinguish the frame
Processing length information to print CAN type only the length information has to be
payload data (with CAN FD support): evaluated with is returned by the read()
system call:
struct canfd_frame cframe;
• 16 bytes Ò classic CAN frame
for (i=0; i < cframe.len; i++)
printf(„%02X „, cframe.data[i]); • 72 bytes Ò CAN FD frame

This example points out the main change For convenience reasons these values
for application programmers when moving are defined as the ‘maximum transfer unit’
their code to (additionally) support CAN FD. (MTU) in the linux/can.h [3] include file as
Several code references how to move from CAN(FD)_MTU values:
classic CAN to CAN FD can be retrieved
from the code changes [6] in the Linux can- #define CAN_MTU (sizeof(struct can_frame))
utils package which has been adapted when #define CANFD_MTU (sizeof(struct canfd_frame))
Linux 3.6 was released in 2012. The can-utils
user space tools to send, receive, store and CAN FD driver infrastructure
replay CAN traffic can be found as source
code on GitHub [4] and as pre-compiled With Linux 3.6 the CAN data structures
package ‘can-utils’ in your preferred Ubuntu/ and the network infrastructure have been
Debian based Linux distribution [5]. extended to support CAN FD. Along with
these changes the virtual CAN driver (vcan)
CAN FD network infrastructure has been updated in a way that it could be
switched to be a classic CAN or CAN FD
Both the classic CAN frames and the CAN interface. By setting the vcan’s MTU value
FD frames are processed inside the Linux to CANFD_MTU (72) with the existing ip
network infrastructure in so called socket tool from the iproute2 package the virtual
buffers. With the introduction of CAN FD a CAN interface presents itself as a CAN FD
second type of CAN related socket buffers interface.
was created to hold the canfd_frame data
structures. While this virtual CAN driver did a good job
when testing and enhancing the new CAN
As legacy CAN applications only can cope FD infrastructure and the user tools it should
with classic CAN frames a new socket option last more than a year until the first CAN
CAN_RAW_FD_FRAMES is defined for FD hardware became available. The first
CAN_RAW sockets to enable the reception CAN FD driver that emerged in the Linux
and transmission of CAN FD frames. mainline kernel was for the Bosch M_CAN

05-2
iCC 2015 CAN in Automation

IP core version 3.0.1 (non-ISO). The driver ISO and non-ISO at configuration time. The
was included in Linux 3.18 in December attempt to modify a fixed ISO/non-ISO flag
2014 and tagged as a ‘fixed non-ISO’ leads to an invalid operation return code.
CAN FD controller later. In April 2015 the
PEAK System PCAN USB (pro) FD driver Finally the configuration of CAN FD
was released with Linux 4.0. These USB controllers became very similar to the classic
adapters can be switched to be ISO/non- CAN controllers by just adding a second
ISO at controller configuration time. bitrate set for the data bitrate and two CAN
FD specific configuration flags. The ip tool
With classic CAN the configuration was from the iproute2 package was updated
done with the ip tool from the iproute2 [7] for the release of Linux 3.15 to support
package [8] in order to specify the bitrate and the second bitrate and the CAN FD mode
additional controller specific settings like the switching. The ISO/non-ISO configuration
sampling-point, synchronization jump width, was integrated in Linux 3.19 but backported
listen-only mode, triple sampling, one-shot to Linux 3.18 to be able to tag the existing
mode, etc. M_CAN driver properly.

The bitrate can be specified with either the ISO 15765-2:2015 with CAN FD
time quanta (tq), propagation segment (prop_
seg) and phase buffer segments (phase_ The ISO 15765-2 CAN transport protocol
seg1 phase_seg2) or by providing a numeric (TP) usually creates a point-to-point data
bitrate value which is then processed by the connection using two defined CAN identifiers
bitrate calculation algorithm inside the Linux – one for each communication endpoint (e.g.
kernel. The latter needs a set of controller diagnosis equipment and engine control
specific bit timing constants that define e.g. unit). To be able to send data PDUs that
the allowed minimum and maximum values do not fit into a single CAN frame the ISO
for the time segments, bitrate prescaler, etc. PDUs are segmented using a bi-directional
segmentation protocol. This protocol is
For CAN FD these bitrate specific settings implemented using (at least) the first byte
have to be doubled to specify a second of the CAN frame payload – the so called
bitrate: The data bitrate when BRS is set. ‘protocol control identifier’ PCI.

This summarizes to these extensions: The PCI byte is defined as:

• Second bitrate infrastructure Table 1: ISO 15675-2 PCI

• Enable/Disable CAN FD mode PCI function nibble bit value
• Configure ISO/non-ISO mode SF Single Frame 0 0000xxxx
FF First Frame 1 0001xxxx
When the CAN FD mode is to be enabled
the data bitrate has to be specified and it CF Consecutive Frame 2 0010xxxx
has to be greater or equal to the arbitration FC Flow Control 3 0011xxxx
bitrate which is placed in the first bitrate
infrastructure known from classic CAN. The While SF, FF and CF are sending PDU
CAN FD mode setting changes the CAN data from node A to node B the FC is a
interface MTU to CAN_MTU or CANFD_ communication entity that is sent from
MTU accordingly. node B to node A in order to throttle the
communication flow according to the
Depending on the CAN FD controller recipients (node B) needs.
capabilities the ISO/non-ISO mode can be
specified by the ip tool or it is fixed with the When the content of the PDU fits into a
controller. E.g. the M_CAN IP version 3.0.1 is single frame the SF frame is generated.
fixed to non-ISO, which cannot be changed Simplified the PDU content has to be 7 or
at configuration time. On the other hand the less bytes on classic CAN as one byte is
PEAK USB FD adapters can switch between always consumed by the PCI byte.

05-3
iCC 2015 CAN in Automation

When the content of the PDU does not While CF and FC frames are not really
fit into a single CAN frame a FF frame is affected by the increased CAN frame length,
generated which contains the PCI byte, the possible PDU length of up to 63 bytes
length information and some first data bytes cannot be described in the four length bits
of the PDU. When node B is able to receive available in the SF PCI byte.
the advertised number of bytes it answers
with a FC frame to get more segmented data To be able to discuss different CAN frame
in the form of CF frames. payload sizes the ‘link layer data length’
Due to the mandatory PCI byte which (LL_DL) has been introduced into the ISO
consumes at least one byte from each CAN document. As long as the LL_DL is 8 bytes
frame payload the protocol overhead is – as known from classic CAN – the new ISO
equal or greater than 12.5% in classic CAN TP PDU segmentation concept behaves
setups with 8 bytes per frame. exactly like the former specification of ISO
TP.
With CAN FD up to 64 bytes of payload can
be transmitted inside a CAN frame. This When the LL_DL is defined to be greater
moves the lower limit of overhead for ISO than 8 bytes (12, 16, 20, .., 64) the length
TP to 1/64 = 0,015625 ~ 1.6%. Even if we information in the SF frame PCI is set to
always need to add the standard overhead of zero and the length information is stored
the CAN Identifier, control fields and CRC in in the following byte (Byte 1). Setting the
both cases this is a huge improvement which length information in the SF PCI byte to
can be even extended when using a higher zero is a protocol violation in the former ISO
bitrate in the data section (BRS enabled). 15765-2 specification which makes older
implementations ignoring these SF frames.
With the knowledge from his own ISO15765- On the other side this concept reduces
2 [10] implementation for Linux and the CAN the maximum possible SF PDU size to
FD changes in Linux the author initiated the LL_DL – 2 bytes (e.g. 62 bytes for CAN FD
adaption of ISO TP for CAN FD at DIN/ISO frames with 64 bytes).
committee in early 2013. As the Linux kernel
was already supporting CAN FD at that time As the configured LL_DL value is unknown on
the changes of the existing classic CAN the receiver side, the receiver automatically
implementation assisted the conceptual adapts to the sender LL_DL depending
work. Whenever a concept was discussed on the frame length of the FF frame when
the public available implementation [9] gave starting a segmented communication.
an indication of the expectable complexity of
that approach. Another enhancement of the FF definition
is basically not CAN FD dependent. The
Table 2: ISO 15675-2 PCI for classic CAN 12 bits for the FF length information allows
PCI B[0] B[1] B[2] B[3] B[4] PDU sizes of up to 4095 bytes. To be able to
SF 0000 LLLL data data data data transfer larger PDUs (e.g. for measurement
FF 0001 LLLL LLLLLLLL data data data
data, configuration data, bootloader update,
etc.) a similar concept as known from the
CF 0010 NNNN data data data data
SF length was developed: By setting the
FC 0011 FFFF Blocksize STm n.a. n.a.
former FF length information to zero, the
(Formatting: All tables are cut after byte 4) sender indicates that the length information
is available in the following 4 bytes. This
• LLLL : PDU length information allows PDU sizes up to 2³²-1 bytes (~4GB).
• NNNN : sequence number When the new receiving implementation
• FFFF : flow status information detects this former protocol violation it takes
• Blocksize : 0 .. 15 (0 = disabled) the next four bytes and can receive the
• STm : Separation Time minimum ‘jumbo’ PDU with more than 4095 bytes –
• data : PDU payload data even in classic CAN setups.
• n.a. : not assigned
• B[x] : byte x in CAN frame payload

05-4
iCC 2015 CAN in Automation

Table 3 and Table 4 depict the PCI changes of the CAN FD implementation a single new
for the extended length information in SF socket option CAN_ISOTP_LL_OPTS has
and FF frames. been introduced to configure the link layer.
The data structure to configure the link layer
Table 3: SF PCI for LL_DL > 8 options is defined in [11] as
PCI B[0] B[1] B[2] B[3] B[4]
struct can_isotp_ll_options {
SF 0000 0000 LLLLLLLL data data data
__u8 mtu;
__u8 tx_dl;
Table 4: FF PCI for PDU length > 4095 __u8 tx_flags;
PCI B[0] B[1] B[2] B[3] B[4] B[5] };
FF 0001 0000 0 Len Len Len Len
The element mtu specifies the generated
and accepted CAN frame type. As described
The length information is presented in high- above the mtu can take values of either
byte first order as known from the former FF CAN_MTU (16) to handle classic CAN
length information. frames or CANFD_MTU (72) to work with
CAN FD frames only.
A useful aspect of CAN FD enabled ISO The tx_dl element specifies the LL_DL
TP communication is the fact that classic value for generated CAN (FD) frames as the
CAN frames and CAN FD do not interfere protocol stack adapts to in incoming LL_DL
in a CAN FD enabled setup. This means (rx_dl) automatically. The valid values for
that the CAN architect may assign two tx_dl are specified by valid CAN FD data
CAN identifiers for the communication with lengths beginning with eight:
classic CAN frames – and he may assign 8, 12, 16, 20, 24, 32, 48, 64
the identical(!) CAN identifiers for a CAN FD N.B. when the mtu is set to CAN_MTU only
enabled communication. As classic CAN a tx_dl value of eight is allowed.
and CAN FD frames distinguish on the wire Finally the tx_flags element content is set
two independent ISO TP communications into the flags element of the canfd_frame
can be performed on the CAN bus in this structure at frame creation time to configure
way. the CANFD_BRS setting for this socket.

Finally the introduction of CAN FD frames in ISO 15765-2:2015 CAN FD performance

ISO 15765-2 leads to a mandatory padding
in the case that the PDU payload doesn’t fit While the ISO TP implementation for
exactly into the CAN FD frame payload. In CAN FD hypothesized an increased
such cases the rest of the CAN FD frame performance in calculations and on the
shall be filled with 0xCC byte values as virtual CAN interfaces the tests on real CAN
recommended by Bosch. The 0xCC data FD hardware were awaited eagerly. With
content allows the minimum of alternating Linux 4.0 the driver for the PEAK USB FD
bus level changes (EMI friendly) without the was available in a stable operating system
need to insert stuff bits. environment where it made sense to take
measurements with the latest ISO 15765-
ISO 15765-2:2015 with Linux 2:2015 implementation.

While sending ISO TP PDUs in Linux is just With a set of shell scripts the existing ISO
about opening a socket and read/write PDU TP command line tools have been arranged
data to the given file handle the configuration in a way that classic CAN and different CAN
of ISO TP communication is done by so FD based communication setups can be
called socket options. brought into meaningful relation.
These socket options are passed to the
socket at creation time to specify values The setup consists of two Linux PCs each
like block size (BS), STmin, extended with an USB FD adapter connected to each
addressing parameters or padding other with a terminated twisted pair CAN
configurations. To be able to take advantage line.

05-5
iCC 2015 CAN in Automation

The timestamps are taken from the receiving Table 7: Test 100µs STmin 0.5/4 Mbit/s
node to make sure the entire PDU hit the CAN LL_DL BRS secs Bytes/s
CAN bus. The test applications transferred classic 8 - 1,460 20.547
and received a PDU of 30.000 bytes with an FD 8 no 1,749 17.162
arbitration bitrate of 500 kbit/s and different
FD 8 yes 1,166 25.751
values for data bitrates (2/4/8 Mbit/s). The
FD 16 no 1,086 27.649
separation time minimum (STmin) was set
to either 500µs or 100µs. As the test values FD 16 yes 0,545 55.045
for 500µs did not differ substantially for FD 32 no 0,792 37.878
different data bitrates only a single table for FD 32 yes 0,265 113.207
the 500µs measurement is depicted below. FD 64 no 0,614 48.859
To have a realistic and safe transport the FD 64 yes 0,163 185.185
block size was set to its maximum of 15.
Table 8: Test 100µs STmin 0.5/8 Mbit/s
Table 5: Test 500µs STmin 0.5/2 Mbit/s CAN LL_DL BRS secs Bytes/s
CAN LL_DL BRS secs Bytes/s classic 8 - 1,462 20.533
classic 8 - 2,926 10.256 FD 8 no 1,752 17.133
FD 8 no 2,933 10.228 FD 8 yes 1,150 26.109
FD 8 yes 2,915 10.295 FD 16 no 1,085 27.649
FD 16 no 1,380 21.754 FD 16 yes 0,545 55.147
FD 16 yes 1,351 22.205 FD 32 no 0,792 37.878
FD 32 no 0,791 37.926 FD 32 yes 0,266 113.207
FD 32 yes 0,662 45.385 FD 64 no 0,614 48.939
FD 64 no 0,625 48.000 FD 64 yes 0,131 230.769
FD 64 yes 0,329 91.463
With the relatively short STmin of 100µs the
As the separation time was 500µs there PDU data throughput can be increased by
could be seen no effect when increasing factor 11 (230.769 / 20.533) – even with a
the data bitrate. At higher data bitrates the configured block size of 15 which requires
CAN bus had to handle fewer loads but bus the receiving node to acknowledge every
load was not the value we wanted to pay 15th CF frame. Without bitrate setting (BRS)
attention at in this setup. the benefit of 64 byte CAN frames reduces
to factor 2.5 due to the better overhead ratio.
Table 6: Test 100µs STmin 0.5/2 Mbit/s Finally the measurements points out that
CAN LL_DL BRS secs Bytes/s using CAN FD without BRS and with LL_DL
classic 8 - 1,460 20.562 of 8 preforms worse than classic CAN. As
FD 8 no 1,750 17.152
CAN FD introduces additional control bits,
an increased CRC field size and a stuff bit
FD 8 yes 1,172 25.597
counter in the latest ISO implementation this
FD 16 no 1,085 27.649
performance reduction was expected.
FD 16 yes 0,548 54.744
FD 32 no 0,793 37.878 Summary
FD 32 yes 0,330 91.185
FD 64 no 0,614 48.859 The new CAN FD protocol doesn’t only break
FD 64 yes 0,225 133.333 the compatibility to classic CAN on the wire
– it also breaks programming interfaces and
extends configuration options by introducing
new bitrates and payload lengths. This
paper gives an insight how programming
interfaces have been altered in Linux in
an evolutionary way without putting the
existing application programming concept
into question. Some of the presented ideas

05-6
iCC 2015 CAN in Automation

may be reused in other embedded setups References

– some may be too Linux specific to do so. [1] 13th iCC 2012 – Paper Hartwich (Bosch)
By today CAN FD is fully supported by http://www.can-cia.org/fileadmin/resources/
Linux and by the provided tools to handle documents/proceedings/2012_hartwich.pdf
[2] http://git.kernel.org/cgit/linux/kernel/git/tor-
and configure CAN FD specific content
valds/linux.git
and functionalities. Together with the free
[3] http://git.kernel.org/cgit/linux/kernel/git/tor-
ISO15765-2:2015 implementation Linux is valds/linux.git/tree/include/uapi/linux/can.h
recommended as a stable and sustainable [4] https://github.com/linux-can/can-utils
testing and product platform for future CAN [5] https://packages.debian.org/stable/can-
FD applications. utils
[6] https://github.com/linux-can/can-utils/
commit/e7631bd7f94804962e48cde2e7de-
37370c31a8b8
Dr. Oliver Hartkopp [7] http://git.kernel.org/cgit/linux/kernel/git/
shemminger/iproute2.git/
Volkswagen AG
[8] https://packages.debian.org/stable/iproute2
Brieffach 1777
[9] https://github.com/hartkopp/can-isotp-mo-
DE-38436 Wolfsburg dules
Tel. +49 5361 9 36244 [10] ISO 15765-2:2011 document http://
[email protected] www.iso.org/iso/catalogue_detail.
http://www.volkswagenag.com htm?csnumber=54499
[11] https://github.com/hartkopp/can-isotp-mo-
dules/blob/master/include/socketcan/can/
isotp.h

05-7