NETVProtocolStack:CANImplementation

Return to [NETVProtocolStack] main page.

NETVProtocolStack - CAN Bus Implementation

• CAN BUS V2.0B IMPLEMENTATION
• CAN PROTOCOL (APPLICATION LAYER VERSION 2)
  • PRIORITY (3 bits) | TYPE (8 bits) | BOOT (2 bits) | COMMAND (8 bits) | DESTINATION (8 bits) | RTR (1 bit) | DATA LENGTH (4 bits) | DATA (0-64 bits)
  • Data Transmission on The CAN Bus
• Memory Organization of CAN Nodes
  • Reading a Variable From a Node (Module)
  • Writing a Variable to a Node (Module)
• Node (Module) Discovery on The CAN Bus
  • Required Data When Receiving CAN_EVENTS_CMD_ALIVE = 0x00

CAN BUS V2.0B IMPLEMENTATION

Complete information about the CAN bus can be found here :

• CAN-In-Automation Official Site

Figure 1 : CAN Frame

Figure1 shows the important fields of a CAN frame :

1. Start of frame. The Start of frame (SOF) is the beginning of a Data Frame or a Remote Frame. It is a single dominant bit (0). Any node can start its transmission if the bus is available. All CAN nodes can then synchronize with this bit for other transmissions.
2. Arbitration field. The Arbitration field contains a message identifier (29 bits in extended mode) and the Remote Transmission Request (RTR) bit. The RTR bit (Remote Transmission Request) is used for Remote Frames. This bit is dominant (0) in the Data Frames and recessive (1) in the Remote Frames.
3. Control field. The Control field is composed of 6 bits. The first two bits are reserved by the CAN protocol and the following 4 bits are used for the Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field. The range of the DLC is from 0 to 8, meaning that the Data Frame can contain up to 8 bytes.
4. Data field. The Data field contains up to 8 data bytes.
5. CRC field. The CRC (Cyclic Redundancy Code) field is composed of a 15 bits CRC with a CRC delimiter (1 recessive bit). This field is used to verify the integrity of received and transmitted frames. The bits used for its calculation are the SOF, Arbitration Field, Control Field and Data Field.
6. ACK field. The ACK field is composed of 2 bits : The ACK Slot and the ACK Delimiter (1 recessive bit ). The the transmitting node sends a recessive bit for the ACK Slot (0). The receiving node(s) send a dominant bit (0) during the ACK Slot to signal the reception of the CAN frame.
7. End of Frame. Each Data Frame or Remote Frame is terminated with a sequence of 7 recessive bits.

For the Application Layer (See OSI Model), we are only using CAN EXTENDED frames, i.e. 29 bits of Arbitration field. The Arbitration Field is separated into sub-fields as described in the next section.

CAN PROTOCOL (APPLICATION LAYER VERSION 2)

Separation of the Arbitration Field is shown in TABLE 1.

TABLE 1 : IntRoLab CAN Extended Frame 29 bits - Arbitration Field

PRIORITY	TYPE	BOOT	COMMAND	DESTINATION	RTR	DATA LENGTH	DATA
(3 bits)	(8 bits)	(2 bits)	(8 bits)	(8 bits)	(1 bit)	(4 bits)	(0-64 bits)
AN 29 bits ARBITRATION FIELD, EXTENDED ID (EID)

PRIORITY (3 bits) | TYPE (8 bits) | BOOT (2 bits) | COMMAND (8 bits) | DESTINATION (8 bits) | RTR (1 bit) | DATA LENGTH (4 bits) | DATA (0-64 bits)

CAN 29 bits ARBITRATION FIELD, EXTENDED ID (EID)
ADDITIONAL FRAME INFORMATION (STANDARD)

• 0 = max, 7 = min

• CAN_TYPE_NOTHING=0x00

• CAN_TYPE_EMERGENCY=0x01
• CAN_TYPE_ACTUATOR_HIGH_PRIORITY=0x02
• CAN_TYPE_SENSOR_HIGH_PRIORITY=0x04
• CAN_TYPE_ACTUATOR_LOW_PRIORITY=0x08
• CAN_TYPE_SENSOR_LOW_PRIORITY=0x10
• CAN_TYPE_REQUEST_DATA=0x20
• CAN_TYPE_USER=0x40
• CAN_TYPE_EVENTS=0x80

• CAN_TYPE_EVERYTHING=0xFF

• bit 0 -> 1 = READ, 0 = WRITE

• bit 1 -> 1 = EEPROM, 0 = RAM

• [0,255] Custom to application

• [0,254] Module Address

• 255 = Broadcast

• 1 = Remote transmission

• 0 = Standard

• [0,8]

• Custom to application

Data Transmission on The CAN Bus

• Transmission on the bus starts from the PRIORITY field to the DATA field.
• The CAN protocol uses a shared medium for transmission, priority of transmission is arbitrated. 0 is the dominant bit. If two CAN nodes try to send a frame simultaneously, the first writing a dominant bit "0" will win the bus. The "waiting" module will try to transmit its frame as soon as the bus is free. Arbitration will again occur at this time.
• The RTR field is used to make a request of N (0 to 8) bytes. When RTR = 1, we set the DATA_LENGTH field to = N bytes. Note that no data will be transmitted during the request (when RTR = 1) in the DATA field. The node that will answer the request will set RTR=0 and fill the DATA field.
• The order of IntRoLab's arbitration fields are carefully selected to maximize the control of frame's priority when transmitting on the bus.
• The BOOT field has two usage  :
• CAN Bus Bootloader (programming a module on the bus)
• Reading / Writing module variables when TYPE = CAN_TYPE_REQUEST_DATA.

Memory Organization of CAN Nodes

TABLE 2 shows how the memory is organized in each module on the bus. The idea here is to use a contiguous memory region that we will call DATA_FLOW_TABLE and map a data structure to it, where all important variables from a module are mapped. The maximum size of the contiguous memory region is fixed at 256 bytes, this is caused by the COMMAND field in the protocol representing the memory offset of the variable and allowing 8 bits. In reality, there is 2 tables of 256 bytes, one for each memory type (RAM or EEPROM). Simply put, RAM variables are volatile and EEPROM variables are used for configuration of the module and are permanent. Reading and Writing variables exemples are presented in the next section. Note that variables cannot be more than 8 bytes, since the maximum payload of a CAN frame in the DATA field is 8 bytes.

TABLE 2 - Memory Mapping of DATA_FLOW_TABLE

Structure de données DATA_FLOW_TABLE

Name Type Offset Size

Variable1
uint8/sint8
0
1 byte

Variable2
uint16/sint16
1
2 bytes

Variable3
uint32/sint32
3
4 bytes

Variable4
float
7
4 bytes

Variable5
double
11
8 bytes

• DATA_FLOW_TABLE[0] = Variable1
• DATA_FLOW_TABLE[1-2| = Variable2
• DATA_FLOW_TABLE[3-6] = Variable3
• DATA_FLOW_TABLE[7-10| = Variable4
• DATA_FLOW_TABLE[11-18] = Variable5

Reading a Variable From a Node (Module)

To read a variable, we need to send the following CAN Extended Frame on the bus :

• PRIORITY= [0,7]
• TYPE = CAN_TYPE_REQUEST_DATA (0x20)
• BOOT = READ, EEPROM or RAM depending on variable
• COMMAND = Memory offset of the variable
• DESTINATION = Module address [0,254]
• RTR = 1 Transmission request
• DATA LENGTH = Number of bytes to read depending on variable byte size
• DATA = Empty, will not be transmitted

The CAN Destination Node will answer the request like this :

• PRIORITY= [0,7]
• TYPE = CAN_TYPE_REQUEST_DATA (0x20)
• BOOT = READ, EEPROM or RAM depending on variable
• COMMAND = Memory offset of the variable
• DESTINATION = Module address [0,254]
• RTR = 0 Normal Frame
• DATA LENGTH = Number of bytes to be transmitted depending on variable byte size
• DATA = Variable binary data, max 8 bytes, Little Endian

Writing a Variable to a Node (Module)

To write a variable, we need to send the following CAN Extended Frame on the bus :

• PRIORITY= [0,7]
• TYPE = CAN_TYPE_REQUEST_DATA (0x20)
• BOOT = WRITE, EEPROM or RAM depending on variable
• COMMAND = Memory offset of the variable
• DESTINATION = Module address [0,254]
• RTR = 0 Normal Frame
• DATA LENGTH = Number of bytes to write depending on variable byte size
• DATA = Variable binary data

Node (Module) Discovery on The CAN Bus

To discover modules on the CAN bus, a special broadcast frame is sent :

TABLE 3 : IntRoLab CAN Frame - Alive Request

PRIORITY (3 bits) TYPE (8 bits) BOOT (2 bits) COMMAND (8 bits) DESTINATION (8 bits) RTR (1 bit) DATA LENGTH (4 bits) DATA (0-64 bits)

CAN 29 bits ARBITRATION FIELD, EXTENDED ID (EID)
ADDITIONAL FRAME INFORMATION (STANDARD)

0 = max

• CAN_TYPE_EVENTS=0x80

• Don't care

• CAN_EVENTS_CMD_ALIVE=0x00

• 255 = Broadcast

• 1 = Remote transmission request

• 8

• Empty when RTR=1
  Each module will answer the message like this :

TABLE 4 : IntRoLab CAN Frame - Alive Request Answer

PRIORITY (3 bits) TYPE (8 bits) BOOT (2 bits) COMMAND (8 bits) DESTINATION (8 bits) RTR (1 bit) DATA LENGTH (4 bits) DATA (0-64 bits)

CAN 29 bits ARBITRATION FIELD, EXTENDED ID (EID)
ADDITIONAL FRAME INFORMATION (STANDARD)

0 = max

• CAN_TYPE_EVENTS=0x80

• Don't care

• CAN_EVENTS_CMD_ALIVE=0x00

• Module address on the bus [0-254]

• 0 = Standard message

• 8

• DATA[0] = Module State

• DATA[1] = Project ID
• DATA[2] = Module ID
• DATA[3] = Code Version
• DATA[4] = Table Version
• DATA[5] = Boot Delay
• DATA[6] = Device ID (LSB)
• DATA[7] = Device ID (MSB)
  The DATA[0-7] field Is explained in the next section.

Required Data When Receiving CAN_EVENTS_CMD_ALIVE = 0x00

• DATA[0] = Module State The module state can have the following values :
  • BOOT_IDLE=0x0A. The node is ready to receive its firmware over the CAN bus.
  • BOOT_PROGRAM_FLASH=0x01. The node is programming its flash memory.
  • BOOT_PROGRAM_EEPROM=0x02. The node is programming its EEPROM memory.
  • BOOT_NORMAL=0x05. The node is in normal operation.
• DATA[1] = Project ID. The user-defined project identification number. This is used by the [NetworkViewer] to determine the variable "profile" to load.
• DATA[2] = Module ID.The module address on the bus.
• DATA[3] = Code Version.The user-defined code version of the module.
• DATA[4] = Table Version.The CAN protocol version. Right now, we are supporting only protocol version 2.
• DATA[5] = Boot Delay.The bootloader delay at reset. After the delay, will start normal operation if node contains a usable firmware.
• DATA[6] = Device ID (LSB).The device ID LSB. This corresponds to Microchip Device ID. This is used to determine memory mapping when updating the firmware.
• DATA[7] = Device ID (MSB). The device ID LSB. This corresponds to Microchip Device ID. This is used to determine memory mapping when updating the firmware.