9 4851903 Ob09786 010 m I NTERNATI O NAL STANDARD IS0 11519 2 First edition AMENDMENT 1 1994 06 1 5 1995 04 01 Road vehicles Low speed serial data communication Part 2 Low speed controller area networ[.]
Data link layer definitions
3.1.1 bit stuffing: Technique used in bit-oriented protocols in order
- to achieve data transparency (arbitrary bit patterns may not be interpreted as protocol information) and
- to provide "dominant" to "recessive" edges, and vice versa, which are necessary for correct resynchronization
In data transmission, when the transmitting logic detects a sequence of consecutive bits of equal value reaching a predefined threshold (stuff width), it automatically inserts a complementary 'stuffbit' into the outgoing bit stream to maintain data integrity The receiver then performs destuffing, which involves removing these stuffed bits to reconstruct the original data frame This process is especially important when using non-return-to-zero (NRZ) bit representation, ensuring accurate and reliable data communication.
3.1.2 bus value: One of two complementary logical values: "dominant" or "recessive" The "dominant" value represents the logical "O" and the "recessive" represents the logical "1 " During simultaneous transmission of
"dominant" and "recessive" bits, the resulting bus value will be "dominant"
3.1.3 multicast: Method by which a single frame is addressed to a group of nodes simultaneously
3.1.4 broadcast: Special case of multicast, whereby a single frame is addressed to all nodes simultaneously
3.1.5 receiver: Device that converts signals used for transmission back into logical information or data signals
3.1.6 transmitter: Device that converts information or data signals to electrical or optical signals so that these signals can be transferred across the communication medium.
Physical layer definitions
The common mode bus voltage range defines the boundary voltage levels, specifically Va and Vw-H, which ensure proper operation of the system Maintaining these voltage levels is crucial when connecting the maximum number of electronic control units (ECUs) to the bus line, as it guarantees reliable communication and system stability.
The differential internal capacitance, designated as Cdi+, refers to the capacitance of an ECU observed between the CAN-L and CAN-H lines during the recessive state when the ECU is disconnected from the bus line This capacitance measurement is crucial for understanding the vehicle's communication system and ensuring reliable data transmission across the Controller Area Network (CAN) bus.
Differential internal resistance, Rdiff, refers to the resistance of an ECU measured between CAN-L and CAN-H lines during the recessive state when the ECU is disconnected from the bus line This parameter is essential for diagnosing and analyzing CAN bus communication issues, as it impacts signal integrity and network performance Proper understanding of Rdiff ensures reliable ECU functionality and optimal vehicle communication system performance.
Vdiff = vCAN-L - VCAN-H where VcAN-L and VcnN-" are the voltages of CAN-L and CAN-H, respectively, relative to ground of each individual ECU
Internal capacitance (Ci) refers to the capacitance of an ECU measured between CAN-L or CAN-H and ground during the recessive state when the ECU is disconnected from the bus line This parameter is essential for understanding the electrical characteristics of the ECU in isolation, ensuring proper communication and signal integrity within the CAN network Accurate measurement of Ci helps in diagnosing potential issues related to capacitance effects that may impact CAN bus performance.
Internal delay time (tEc-) refers to the total asynchronous delay experienced by an ECU on both transmitting and receiving paths This delay is measured relative to the bit timing logic unit of the protocol IC within each individual ECU Importantly, these delays are assessed when the ECU is disconnected from the bus line Understanding tEc- is essential for ensuring reliable communication and synchronization in automotive electronic control units.
Internal resistance (R) of an ECU refers to the resistance measured between CAN-L (or CAN-H) and ground during the recessive state when the ECU is disconnected from the bus line This resistance plays a crucial role in diagnosing CAN bus system health and ensures proper communication between electronic control units (ECUs) Understanding the internal resistance helps identify potential issues in the ECU's circuitry and maintains reliable data transmission on the vehicle's CAN network.
3.2.8 physical layer: Electrical circuit realization that connects an ECU to a bus The total number of ECUs con- nected on a bus is limited by electric loads on the bus line
3.2.9 physical media: Pair of parallel wires of the bus, shielded or unshielded, depending on EMC requirements
The individual wires are denoted as CAN-L and CAN-H The corresponding pins of ECUs are also denoted by CAN-L and CAN-H
Figure 1 - Definitions of internal capacitances and internal resistances of an ECU
List of abbreviations
LPDU LLC Protocol Data Unit
LSDU LLC Service Data Unit
Medium-Dependent Interface MAC Protocol Data Unit Most Significant Bit MAC Service Data Unit Non-Return-to-Zero Open System Interconnection Physical Layer
Physical Signalling Physical Medium Attachment Remote Transmission Request Start Of Frame
CAN has the following properties:
- multimaster priority-based bus access;
- non-destructive contention-based arbitration;
- multicast frame transfer by acceptance filtering;
- error detection and error signalling;
- automatic retransmission of frames that have lost arbitration or have been destroyed by errors during trans-
The article distinguishes between temporary errors and permanent failures of nodes within the CAN network It emphasizes the importance of autonomous switching off of malfunctioning nodes to maintain network integrity Additionally, ISO 11519-9 specifies low-speed Controller Area Network (CAN) protocols designed for applications operating at speeds up to 125 kbit/s, ensuring reliable communication in various automotive and industrial systems.
Frames
Information on the bus is sent in fixed format frames of different but limited lengths When the bus is free, any connected node may start to transmit a new frame.
Bus access method
When the bus is available, any node can initiate frame transmission In cases where multiple nodes transmit simultaneously, contention-based arbitration resolves access conflicts using frame identifiers This arbitration mechanism ensures that no data or time is wasted, as the node with the highest-priority frame gains sole access to the bus.
Information routing
In CAN systems, nodes do not rely on system configuration details like node addresses; instead, they utilize "Frame Acceptance Filtering" to determine whether incoming messages are relevant This process allows receivers to accept or reject information based solely on message content, eliminating the need to identify or know the transmitter.
System flexibility
Nodes can be seamlessly integrated into the CAN network without modifying existing hardware or software, provided the new node does not serve as a data frame transmitter (see 8.3.1) This flexibility allows for scalable and easy network expansion.
Data consistency
In a CAN network, a frame is either accepted by all nodes simultaneously or not accepted by any, ensuring data consistency across the system This reliability is achieved through the principles of multicast communication and robust error handling mechanisms, making CAN networks dependable for critical data exchange.
Remote data request
In CAN communication, a node can request data from another node by sending a remote frame, which prompts the targeted node to transmit the corresponding data frame The data frame and its requesting remote frame share the same identifier, ensuring proper recognition and response within the network This process enables efficient data retrieval and improves overall communication efficiency in CAN networks.
Error detection
The following measures are provided for detecting errors:
- monitoring (transmitters compare the bit levels to be transmitted with the bit levels detected on the bus);
- variable bit stuffing with a stuff width of 5;
Error signalling and recovery time
Corrupted frames are detected by both transmitting nodes and error-active receiving nodes, ensuring early identification of transmission issues When a frame is identified as corrupted, it is immediately aborted to prevent faulty data from propagating The system then initiates a retransmission process following the established recovery procedures (refer to section 6.4.3) to maintain data integrity and reliable communication.
The recovery time, from detecting an error until the possible start of the next frame, is typically 17 bit times to
23 bit times (in the case of a heavily disturbed bus up to 29 bit times), if there are no further errors.
Acknowledgement
All receivers check the consistency of the received frame, and will acknowledge a consistent frame and flag an inconsistent frame.
Automatic retransmission
Frames that have lost arbitration or been affected by transmission errors are automatically retransmitted once the bus becomes idle These frames are treated like any other, participating in the arbitration process to gain access to the bus This ensures reliable data transmission and maintains communication stability across the network.
Fault confinement
CAN nodes can differentiate between minor disturbances and permanent failures When a node is identified as defective, it is switched off, meaning it is logically disconnected from the bus line and cannot send or receive any frames This automatic disconnection helps maintain the reliability and integrity of the network.
An "error-active" node participates in bus communication and signals detected errors by sending an active error flag This error flag is composed of six consecutive dominant bits, which violate the bit-stuffing rule and indicate an active error in the system The presence of this flag typically appears within standard frame formats, as outlined in section 11.1.5 of the protocol documentation.
An "error-passive" node participates in bus communication but does not send an active error flag When an error is detected, it transmits a passive error flag, which consists of six consecutive recessive bits After transmitting the passive error flag, the node waits for an additional period before attempting further transmission, as outlined in sections 8.3.5 and 11.1.5 regarding suspension of transmission.
A node is in the state "bus off" when it is switched off from the bus due to a request of a fault confinement entity
In the "bus off" state, a node can neither send nor receive any frames A node can leave the "bus off" state only upon a user request
Protocol specification
In peer protocol communication, two entities exchange Protocol Data Units (PDUs), specifically N-layer Protocol Data Units (NPDU), which include layer-specific control information (n-PCI) and user data To transfer an NPDU, it must be passed to an N-I layer entity via an N-1 Service Access Point (N-1 SAP), using the N-1 layer Service Data Unit (N-1 SDU) The N-1 SDU serves as the interface data, maintaining its identity between N-layer entities and representing the logical data transferred by a service The CAN protocol's data link layer does not support mapping SDUs into multiple PDUs or combining multiple SDUs into a single SDU; instead, an NPDU is directly constructed from the associated NSDU and layer-specific control information (N-PCI) Figure 3 illustrates the interactions within the data link sublayer, highlighting how these components work together for efficient data transfer.
Format description of services
5.3.1 Format description of service primitives
Service primitives are written in the form: service.type(
- "service" indicates the name of the service, e.g L-DATA for data transfer service provided by the LLC sub- layer;
- "type" indicates the type of the service primitives (see 5.3.2);
- "[parameter, ]" is the list of values passed to the service primitives The brackets indicate that this parameter list may be empty
Request to set the node into an initial state
Service primitives are of three generic types a) Service.request
The request primitive is passed from the N-user (service user) to the N-layer (service provider) to request in- itiation of the service b) Service indication
The indication primitive is used to communicate an internal event from the N-layer to the N-user, signaling a significant occurrence within the layer or sublayer This event may be related to a remote service request or could be triggered by an internal process within the N-layer The service.confirm primitive serves to acknowledge or confirm the successful processing of such events, ensuring reliable communication between layers.
The confirm primitive is sent from the N-layer (or sublayer) to the N-user to communicate the outcomes of one or more related previous service requests It indicates whether the request was successfully fulfilled or if there was a failure, providing essential feedback on service compliance Importantly, this primitive does not necessarily imply any activity at the remote peer interface, serving solely as a notification of result.
LLC interface
The LLC sublayer offers two types of connectionless transmission services to the LLC user:
- unacknowledged remote data request service
The interface service data from or to the user is described in 6.2 The messages that can be exchanged between LLC user and LLC sublayer are given in tables 1 and 2
Table 1 - Message sent from LLC user to LLC sublayer t
User-to-LLC message Meaning
Table 2 - Message sent from LLC sublayer to LLC user
LLC-to-user message Meaning
I Reset-Response I Response to the Reset-Request I
Indicates the current status of the node, ¡.e it signals whether or not the node is in the status "bus off"
The LLC interface messages from and to the supervisor fault confinement entity are described in 11.1.3.1
6 Description of the LLC sublayer
Request for data transfer Indication of data transfer
The LLC (Logical Link Control) sublayer is a crucial component of the OSI data link layer, responsible for managing protocol issues that are independent of the medium access method It operates at the upper part of the data link layer, ensuring reliable data transfer regardless of the underlying physical medium The LLC sublayer facilitates seamless communication by handling protocol logic that remains consistent across different types of network media.
Service of the LLC sublayer
Confirmation of data transfer The LLC sublayer offers two types of connectionless-mode transmission services:
L-REM0TE.indication L-REMOTE.confirm a) Unacknowledged data transfer service
This service enables LLC users to exchange link service data units (LSDUs) without establishing a dedicated data link connection, supporting point-to-point, multicast, and broadcast data transfers Additionally, it offers an unacknowledged remote data request service, facilitating efficient and flexible data communication across networks.
This service provides means by which LLC users can request another remote node to transmit a link service data unit (LSDU) without the establishment of a data link connection
The way in which the remote node serves the data request is not specified here Basically, there are two ways
The remote user prepares the requested data for transmission, which is stored in a remote node buffer Once the remote request frame is received, the LLC entity transmits this data promptly This process ensures efficient data transfer within the network, highlighting the importance of remote data handling and LLC protocol engagement.
Indication of remote data request Confirmation of remote data request
2) The requested data will be transmitted by the remote user upon reception of the remote request frame According to the two different LLC services there are two types of frames from or to the user:
The LLC data frame is responsible for transmitting data from a sender to a receiver, ensuring efficient communication within the network The LLC remote frame specifically requests the transmission of a data frame with a matching identifier from a remote node, facilitating targeted data exchange In both transmission and reception processes, the LLC sublayer notifies the user of successful frame delivery, ensuring reliable data transfer and maintaining communication integrity across the network.
Service primitive specification
This section describes in detail the LLC service primitives and their associated parameters The complete list of LLC service primitives is given in table3
Table 3 - LLC service primitives overview Unacknowledged data transfer service I
I L-REMOTE.request I Request for remote data transfer I
The parameters that are associated with the different LLC service primitives are listed in table4
Table 4 - List of LLC service primitive parameters
Identifies the data and its priority Data length code
Data the user wants to transmit
The L-DATA.request primitive is used by the LLC user to invoke the LLC sublayer, requesting the transmission of an LSDU to one or more remote LLC entities This primitive facilitates data transfer within the network, ensuring efficient communication between connected devices Understanding the semantics of the L-DATA.request primitive is essential for correctly managing data flow and maintaining proper protocol operation across the LLC layer.
The primitive shall provide parameters as follows
The parameter DATA is insignificant if the associated LLC data frame is of data length zero c) Effect on receipt
The receipt of this primitive triggers the LLC sublayer to initiate the transfer of an LLC data frame This process utilizes the data transfer service provided by the MAC sublayer, ensuring efficient and reliable communication within the network.
The L-DATA.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of an LSDU b) Semantics of the L-DATA.indication primitive
The primitive shall provide parameters as follows
The parameter DATA is insignificant if the associated LLC data frame is of data length zero
The effect of receipt of this primitive by the LLC user is unspecified
The L-DATA.confirm primitive is sent from the local LLC sublayer to the LLC user to communicate the outcome of the prior L-DATA.request primitive This primitive serves as a local confirmation, indicating that the request has been processed locally without implying that the remote LLC entity has forwarded the corresponding indication primitive to the LLC user.
The primitive shall provide parameters as follows
The TRANSFER-STATUS is used to indicate the completion of the transaction initiated by the previous L-DATA.request primitive
TRANSFER-STATUS:[COMPLETE,NOT-COMPLETE] c) Effect on receipt
The effect of receipt of this primitive by the LLC user is unspecified
The L-REMOTE.request primitive is initiated by the LLC user and sent to the LLC sublayer to request a specific remote LLC entity to transmit an LSDU Understanding the semantics of this primitive is essential for effective data transmission within the LLC layer, ensuring proper communication between network components.
The primitive shall provide parameters as follows
The value of DLC equals the length of the data field of the requested data frame c) Effect on receipt
Receipt of this primitive causes the LLC sublayer to initiate the transfer of an LSDU by use of the remote data transfer service provided by the MAC sublayer (see 8.1.1)
The L-REMOTE.indication primitive is used to notify the LLC user of an incoming data transmission request for an LSDU This primitive is essential in the LLC sublayer to facilitate efficient communication, signaling the arrival of data and ensuring proper data handling Understanding the semantics of the L-REMOTE.indication primitive is crucial for maintaining seamless data exchange within the network protocol.
The primitive shall provide parameters as follows
The identifier identifies the LSDU to be sent The value of DLC equals the length of the data field of the re- quested data frame
The effect of receipt of this primitive by the LLC user is unspecified
The L-REMOTE.confirm primitive is sent from the local LLC sublayer to the LLC user to communicate the outcome of the previous L-REMOTE.request primitive, serving as a local confirmation It is important to note that this primitive does not indicate that the remote LLC entity has forwarded the associated indication primitive to the LLC user This distinction is crucial for understanding the semantics of the L-REMOTE.confirm primitive within the LLC protocol.
The primitive shall provide parameters as follows
The TRANSFER-STATUS is used to indicate the completion of the transaction initiated by the previous L-REMOTE.request primitive
TR?iNSFER-STATUS:[COMPLETE,NOT-COMPLETE] c) Effect on receipt
The effect of receipt of this primitive by the LLC user is unspecified.
Structure of LLC frames
LLC frames are the data units that are exchanged between peer LLC entities (LPDU) The structure and format of the LLC data and remote frame are specified subsequently
6.3.1 Specification of the LLC data frame
An LLC data frame is composed of three bit fields (see figure4):
- Data Length Code (DLC) field,
Figure 4 - LLC data frame a) Identifier
The length of the identifier is 11 bits The most significant bits (ID-10 to ID-4) shall not all be "1 " b) DLC field
The data length code, composed of 4 bits, indicates the number of bytes in the data field, which can range from 0 to 8, with zero being a valid length Refer to table 5 for specific data length code values, and note that any values outside this range are not permitted in data frames Ensuring correct data length coding is essential for proper CAN bus communication.
Table 5 - Coding of the numbers of data bytes by the data length code Number of data c) Data field
The data field consists of the data to be transferred within a data frame It can contains from O bytes to
8 bytes and each byte contains 8 bits
6.3.2 Specification of the LLC remote frame
An LLC remote frame is composed of two bit fields (see figure5):
The LLC remote frame identifier shares the same format as the LLC data frame identifier, as outlined in section 6.3.1 Importantly, there is no separate data field; the data length is determined solely by the Data Length Code (DLC) The DLC value corresponds directly to the length of the data in the associated data frame.
Functions of the LLC sublayer t5
The LLC sublayer provides the following functions: a) frame acceptance filtering, b) overload notification, c) recovery management
A frame transaction initiated at the LLC sublayer is a self-contained operation that operates independently of previous transactions Each frame is identified by its unique identifier, which describes the meaning of the data rather than its destination Receivers use frame acceptance filtering to determine whether incoming frames are relevant to them, ensuring efficient and targeted data processing.
The LLC sublayer initiates the transmission of an overload frame when the receiver's internal conditions require a delay before sending the next LLC data or remote frame To effectively delay subsequent traffic, up to two overload frames may be generated This mechanism helps manage flow control and prevent data congestion within the network.
The LLC sublayer facilitates automatic retransmission of frames that experience arbitration loss or transmission errors, ensuring reliable data delivery Frame transmission is only confirmed to the user once the transmission has been successfully completed, enhancing overall network reliability and communication integrity.
7 Interface between LLC and MAC
The MAC sublayer provides services to the local LLC for:
- acknowledged transfer of LLC frames,
The interface service data from or to the LLC sublayer is described in 8.1
8 Description of the MAC sublayer
MA-DATA.indication MA-DATA.conf irm
The MAC (Medium Access Control) sublayer is a fundamental component of the OSI data link layer, serving as the lower part that manages access to the physical medium It facilitates communication between the LLC (Logical Link Control) sublayer and the physical layer, ensuring efficient data transmission The MAC sublayer is responsible for implementing essential functions and rules related to media access control, including addressing, frame delimiting, and collision detection, which are vital for reliable network operations.
- encapsulation/decapsulation of the transmit/receive data,
MA-REMOTE.indication MA-REMOTE.confirm
- management of the transmitlreceive medium access
Services of the MAC sublayer
MA-OVLDhdication MA-OVLD confirm
The MAC sublayer facilitates communication by enabling the local LLC sublayer entity to exchange MAC Service Data Units (MSDU) with peer LLC sublayer entities Its key services include acknowledged data transfer, ensuring reliable delivery of data packets between network devices This functionality is essential for maintaining efficient and dependable data communication within network systems.
This service enables LLC entities to exchange MSDUs without establishing a dedicated data link connection, allowing for flexible data transfer methods such as point-to-point, multicast, or broadcast Additionally, it supports acknowledged remote data requests, ensuring reliable and efficient communication between devices.
This service enables an LLC entity to request a remote node to transmit an LSDU without establishing a data link connection, utilizing the MAC service "acknowledged data transfer." Both remote LLC and MAC sublayers generate acknowledgements to confirm service receipt, ensuring reliable communication without transferring user data Additionally, overload frame transfer is supported to manage network congestion effectively, maintaining optimal performance and stability.
This service enables LLC entities to send overload frames, which are specially formatted fixed LPDU messages, to intentionally delay the transmission of the next data or remote frame By leveraging this mechanism, LLC can efficiently manage network traffic and improve data flow control Implementing overload frames helps ensure smoother communication and prevents congestion within the network.
The service primitives that the MAC sublayer provides to the LLC sublayer are given in table6
Table 6 - MAC sublayer service primitives
The MA-DATA.request primitive is a key function in the communication process, enabling the LLC sublayer to request the transmission of an MSDU to one or more remote MAC entities This primitive facilitates efficient data transfer within the network, ensuring that data packets are properly sent from the LLC to the MAC sublayer Understanding the semantics of the MA-DATA.request primitive is essential for optimizing network performance and ensuring seamless data communication between layered protocols.
The primitive shall provide parameters as follows
The parameter DATA is insignificant for MAC data frames of data length zero c) Effect on receipt
When a primitive is received, the MAC sublayer constructs a protocol data unit (PDU) by appending MAC-specific control information such as GOF, RTR bit, reserved bits, CRC, a "recessive" bit during the ACK slot, and EOF to the MSDU from the LLC sublayer This MAC PDU is then serialized and transmitted as a service data unit to the physical layer for efficient transfer to the peer MAC sublayer entity, ensuring reliable data communication across the network.
The MA-DATA.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate the arrival of an MSDU b) Semantics of the MA-DATA.indication primitive
The primitive shall provide parameters as follows
The DATA parameter is considered insignificant when the associated H4C data frame has a zero length An MSDU is only indicated to the LLC sublayer upon successful receipt, ensuring reliable data transfer Proper handling of these parameters is essential for efficient network performance and data integrity.
The effect of receipt of this primitive by the LLC sublayer is unspecified
The MA-DATAxonfirm primitive is transmitted from the local MAC sublayer to the LLC sublayer to relay the results of the previous MA-DATA.request primitive This primitive serves as a remote confirmation, indicating that the remote MAC entity or entities have successfully passed the associated indication primitive to the relevant user(s).
I S 0 11519 P T * 2 94 4851903 0565227 959 IS0 11519-2:1994(E) b) Semantics of the MA-DATA.confirm primitive
The primitive shall provide parameters as follows
The TRANSMISSION-STATUS is used to indicate the success or failure of the previous MA-DATA.request primitive
TRANSMISSION-STATUS: [SUCCESS,NO-SUCCESS]
Failures are either errors which occurred during transmission or loss of arbitration c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified
The MA-REMOTE.request primitive is used by the LLC sublayer to request the MAC sublayer to transmit a single MSDU from a remote MAC entity This primitive enables precise control over data transmission by initiating the process from the LLC layer, ensuring efficient communication within the network Understanding the semantics of the MA-REMOTE-request primitive is essential for effective management of remote data transmissions in MAC layer operations.
The primitive shall provide parameters as follows
The identifier identifies the MSDU to be sent The value of DLC equals the length of the data of the requested MSDU c) Effect on receipt
When the MAC sublayer receives the primitive, it prepares a protocol data unit by adding MAC-specific control information such as GOF, RTR bit, reserved bits, CRC, the "recessive" bit during the ACK slot, and EOF to the MSDU from the LLC sublayer This MAC PDU is then serialized and transmitted bit by bit to the physical layer, ensuring it is correctly sent to the peer MAC sublayer entity or entities.
The MA-REMOTE.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate the arrival of a request for transmission of an MSDU
IS0 11519-2:1994(E) b) Semantics of the MA-REMOTE.indication primitive
The primitive shall provide parameters as follows
The arrival of an MSDU transmission request is indicated to the LLC sublayer only if it has been received cor- rectly c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified
The MA-REMOTE.confirm primitive is sent from the local MAC sublayer to the LLC sublayer to communicate the outcome of the previous MA-REMOTE.request It serves as a remote confirmation, indicating that the remote MAC entity or entities have successfully passed the associated indication primitive to the relevant user(s) This primitive plays a crucial role in ensuring proper synchronization and communication between MAC and LLC layers in network protocols.
The primitive shall provide parameters as follows
The TRANSMISSION-STATUS is used to indicate the success or failure of the previous MA-REMOTE.request primitive
TRANSMISSION-STATUS: [SUCCESS,NO-SUCCESS]
Failures are either errors which occurred during transmission or loss of arbitration c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified
The MA-0VLD.request primitive is used by the LLC sublayer to request transmission of a MAC overload frame, as described in section 8.3.4 This overload frame has a fixed format and is fully constructed within the MAC sublayer to ensure proper overload signaling.
IS0 11519-2:1994(E) b) Semantics of the MA-0VLD.request primitive
The primitive does not provide any parameter:
When the MAC sublayer receives this primitive, it triggers the formation of an overload frame This overload frame is then passed to the lower protocol layers for transmission to the peer MAC sublayer entities, ensuring proper communication and network stability.
The MA-0VLD.indication primitive is used to notify the LLC sublayer that an overload frame has been received from the MAC sublayer, as detailed in section 8.3.4 Its primary purpose is to communicate overload conditions within the data link layer, ensuring proper flow control and network stability Understanding the semantics of the MA-0VLD.indication primitive is essential for efficient management of overload situations and maintaining seamless communication between MAC and LLC layers.
The primitive does not provide any parameters:
The effect of receipt of this primitive by the LLC sublayer is unspecified
The MA-0VLD.confirm primitive is transmitted from the MAC sublayer to the LLC sublayer to indicate that an overload frame has been sent This confirmation is purely local and does not guarantee that the remote peer protocol entities have successfully received the overload frame Understanding the semantics of the MA-0VLD.confirm primitive is essential for effective protocol communication and error handling in network systems.
The primitive shall provide parameters as follows
The TRANSMISSION-STATUS is used to indicate the success or failure of the previous MA-0VLD.request primitive
TRANSMISSION-STATUS: [SUCCESS,NO-SUCCESS] c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified
Functional model of the MAC sublayer architecture
The MAC sublayer's functional capabilities are detailed through the model outlined in ISO 8802-3, which divides the layer into two fully independent components: the transmit and receive parts Each part has distinct functions essential for efficient data communication The transmit component handles data transmission, while the receive component manages incoming data, ensuring seamless network performance Understanding these separate functions is crucial for optimizing MAC layer operations in Ethernet networks.
Transmit data encoding data decoding
Figure 6 - Media access control functions
8.2.1 Frame transmission a) Transmit data encapsulation:
1) acceptance of LLC frames and interface control information;
3) construction of MAC frame by adding SOF, RTR bit, reserve bits, CRC, ACK and EOF to the LLC frame b) Transmit media access management:
1) initiation of the transmission process after recognizing bus idle (compliance with interframe space);
2) serialization of the MAC frame;
3) insertion of stuffbits (bit stuffing);
4) arbitration and passing into receiver mode in case of loss of arbitration;
5) error detection (monitoring, format check);
7) recognition of an overload condition;
8) overload frame construction and initiation of transmission;
9) error frame construction and initiation of transmission;
1 O) presentation of a serial bit stream to the physical layer for transmission
8.2.2 Frame reception a) Receive media access management:
1) reception of a serial bit stream from the physical layer;
2) deserialization and recompiling of the frame structure;
3) deletion of stuffbits (bit destuffing);
4) error detection (CRC, format check, stuff rule check);
6) error frame construction and initiation of transmission;
7) recognition of an overload condition;
8) reactive overload frame construction and initiation of transmission b) Receive data decapsulation:
1) removal of the MAC specific information from the received frame;
2) presentation of the LLC frame and interface control information to the LLC sublayer
Structure of MAC frames
Data transmission and reception between nodes in a CAN system is manifested and controlled by four different frame types:
- a data frame carries data from a transmitter to the receiver;
- a remote frame is transmitted by a node to request the transmission of the data frame with the same identifier;
- an error frame is transmitted by any node on detecting a bus error;
- an overload frame is used to provide for an extra delay between the preceding and succeeding data frames or remote frames
Data frames and remote frames are separated from preceding frames by an interframe space
8.3.1 Specification of the MAC data frame
A MAC data frame is composed of seven different bit fields (see figure 7);
- control field (two reserve bits + DLC field),
S t a r t O f Control Data CRC ACK EndOt
The MAC data frame begins with the Start Of Frame (SOF), which marks the start of data and remote frames with a single "dominant" bit, ensuring transmission starts only when the bus is idle, allowing nodes to synchronize to the leading edge The Arbitration field includes the identifier passed from the LLC sublayer and the RTR (Remote Transmission Request) bit, which is set to "0" in MAC data frames The Control field comprises six bits, including two reserved for future use and a Data Length Code, with current practice only transmitting "0" bits for reserved bits until their functions are defined The Data field contains the actual data, equivalent to the LLC data field, and the CRC field includes the CRC sequence followed by a CRC delimiter for error checking.
The CRC sequence, which includes the frame check sequence derived from a cyclic redundancy check (BCH-code), is ideally suited for frames with fewer than 127 bits To perform CRC calculations, the polynomial used is defined by the destuffed bit stream—comprising the start of frame, arbitration field, control field, and data field if present—with the lowest 15 coefficients set to zero This polynomial is divided, using modulo-2 arithmetic, by a generator polynomial to generate the CRC checksum.
The remainder of the polynomial division represents the CRC sequence transmitted over the bus, ensuring data integrity To implement this, a 15-bit shift register CRC-RG(14:0) is utilized for efficient computation The CRC sequence is calculated based on the next bit (NXTBIT) of the bit-stream, which is derived from the destuffed bit sequence from the start of the frame to the end of the data field This process ensures accurate error detection in data transmission.
CRCNXT = NXTBIT EXOR CRC-RG(14);
CRC-RG(14:l) = CRCRG(13:O); //shift left by one position CRC-RG(0) = O ;
IF CRCNXT THEN CRC-RG(14:O) = C R C R G ( 1 4 : O ) EXOR (4599hex);
ENDIF UNTIL (NXTBIT = End of data or there is an error condition)
After the transmission/reception of the last bit of the data field, CRC-RG contains the CRC sequence
2) CRC delimiter The CRC sequence is followed by the CRC delimiter which consists of a single
IS0 11519 P T * Z 9 4 4851903 0565233 152 IS0 11519-2:1994(E) f) ACK field, two bits long and containing the ACK slot and the ACK delimiter In the ACK field the transmitting node sends two "recessive" bits
1) ACK slot All nodes that have received the matching CRC sequence send an acknowledgement within the ACK slot by overwriting the "recessive" bit of the transmitter by a "dominant" bit
The ACK delimiter, which is the second bit of the ACK field, must be a "recessive" bit, ensuring that the ACK slot is flanked by two "recessive" bits—specifically, the CRC delimiter and ACK delimiter Each data frame and remote frame are clearly delimited by a flag sequence composed of seven consecutive bits, marking the End Of Frame (EOF) and ensuring proper frame identification within CAN communication protocols.
8.3.2 Specification of the MAC remote frame
A node functioning as a data receiver can initiate data transmission from its source node by sending a remote frame This remote frame consists of six distinct bit fields, as illustrated in figure 8, enabling effective communication within the network.
- control field (two reserve bits + DLC field);
I Frame Of I Arbitration field I field I field I field I Frame I
The arbitration field in a MAC remote frame consists of the identifier field, passed from the LLC sublayer, and the RTR (Remote Transmission Request) bit The RTR bit in a MAC remote frame is set to "1", indicating a remote transmission request This structure is essential for managing arbitration and ensuring efficient communication within network protocols.
The bit fields in the data frame include Start Of Frame (SOF), control field, CRC field, ACK field, and End Of Frame (EOFR), which correspond directly to the respective components of the MAC data frame as described in section 8.3.1.
8.3.3 Specification of the error frame
The error frame comprises two key components: the first is the error flag, which results from the superposition of error signals contributed by multiple nodes, indicating the presence of faults within the system The second component is the error delimiter, which marks the boundary of the error frame to facilitate accurate detection and diagnosis of errors in the network Understanding these fields is essential for effective error detection and ensuring reliable communication in error-prone environments.
There are two forms of error flag: the active error flag and the passive error flag
- The active error flag consists of six consecutive "dominant" bits
- The passive error flag consists of six consecutive "recessive" bits Some or all bits of a passive error flag may be overwritten by "dominant" bits from other nodes
An "error-active" node detects an error condition by transmitting an active error flag, indicating a violation of bit stuffing rules or corruption of the bit field This triggers all other nodes on the network to also recognize the error and initiate transmission of their own error flags This process ensures that error conditions are effectively communicated and managed across the network, maintaining communication integrity.
The "dominant" bits, observable on the bus, arise from a superposition of error flags transmitted by individual nodes This sequence's length ranges from a minimum of six bits to a maximum of twelve bits, ensuring effective error detection and communication reliability in the system.
Passive error flags initiated by a transmitter can cause errors at the receiver when they begin within a frame field encoded by bit stuffing, leading to detectable stuff errors To prevent this, such an error flag must not start during arbitration or must start very close to the end of the CRC sequence with the last bits being all recessive Passive error flags initiated by receivers cannot override ongoing bus activity, so "error-passive" receivers are required to wait for six consecutive identical bits after detecting an error before completing their error flag, ensuring reliable communication on the bus line.
The error delimiter consists of eight "recessive" bits
After transmission of an error flag, each node sends "recessive" bits and monitors the bus until it detects a
"recessive" bit It then starts transmitting seven more "recessive" bits
8.3.4 Specification of the overload frame
There are two types of overload frames having the same format: a) LLC-requested overload frame
This overload frame will be requested by LLC sublayer to indicate an internal overload situation (see 8.1 O) b) Reactive overload frame
The transmission of the active overload frame will be initated by the MAC sublayer upon certain error conditions (see 8.10)
The overload frame contains two key bit fields: the overload flag and the overload delimiter, which are essential for error detection in communication protocols The overload flag comprises six "dominant" bits and disrupts the fixed structure of the intermission field, prompting all nodes to detect an overload condition and initiate transmission of their own overload flags Following this, the overload delimiter, consisting of eight "recessive" bits, signals the end of the overload condition; each node monitors the bus until it detects a "recessive" bit, then simultaneously transmits seven additional "recessive" bits to complete the eight-bit overload delimiter, ensuring proper synchronization and error signaling across the network.
8.3.5 Specification of the interframe space
Data frames and remote frames are separated from preceding frames by an interframe space, a specific bit field that ensures proper timing between different frame types Unlike data and remote frames, overload frames and error frames are not preceded by an interframe space, and multiple overload frames can be transmitted consecutively without any separation Understanding the distinction between these frame types and their spacing is essential for effective CAN protocol communication.
The interframe space contains the bit fields "intermission" and "bus idle", and "suspend transmission" for error-passive nodes which have been a transmitter of the previous frames (see figures 9 and 10)
Figure 9 - Interframe space for nodes which are not "error passive" or have been a receiver of the previous frame
Intermission Suspend Bus idle transmission
Interframe space for "error-passive" nodes involves specific actions based on their transmission status During intermission, which consists of three recessive bits, no node is permitted to initiate a new transmission, except to signal an overload condition The bus is considered idle during an arbitrary-length period when no transmission occurs, allowing any node to access the bus to send data; the start of a new frame is recognized by a dominant bit immediately following intermission After transmitting a frame, an "error-passive" node must send eight recessive bits during the suspend transmission period before it can transmit again; if another node begins transmission during this time, the node will switch to receiver mode to listen to that transmission.
Frame coding
Frame segments—including the start of frame, arbitration field, control field, data field, and CRC sequence—are encoded using bit stuffing When a transmitter detects five consecutive bits of the same value in the bit stream, it automatically inserts a complementary bit to prevent misinterpretation This method ensures data integrity and synchronization during transmission.
Destuffed bit stream 1 0 0 0 0 0 a b c O l l l l l a b c Stuffed bit stream 1 0 0 0 0 O l a b c 0 1 1 1 1 1 0 a b c a b, c E IO,l}
The remaining parts of the data frame or remote frame, including the CRC delimiter, ACK field, and end of frame, have a fixed structure and are not subject to bit stuffing Additionally, error frames and overload frames are also fixed in form and do not utilize bit stuffing for encoding The bit stream within a frame is encoded using the Non-Return-to-Zero (NRZ) method, ensuring a constant bit level throughout the entire bit duration.
Order of the bit transmission
A frame shall be transferred bit field by bit field, starting with its SOF field Within a field the most significant bit shall be transmitted first (see figure 12)
Figure 12 - Order of bit transmission
Frame validation
The point in time at which a frame is taken to be valid is different for the transmitter and the receiver of the frame a) Transmitter
The frame is valid for the transmitter if there is no error until the end of EOF If a frame is corrupted, recovery is processed as described in 6.4.3 b) Receiver
The frame is valid for the receiver if there is no error until the next to last bit of EOF.
Medium access method
This subclause describes the functions and characteristics that are related to the medium access method of CAN
Every node transmitting a data frame or a remote frame is bus master during transmission
The bus is considered to be free by any node after having detected that the bit field intermission has not been interrupted by a "dominant" bit
An "error-active" node can access the bus immediately once it becomes free, while an "error-passive" node, whether receiving the current or previous frame, may also access the bus as soon as it is available If an "error-passive" node has just transmitted or is in the process of transmitting a frame, it can access the bus again immediately after suspension, provided no other node has started transmitting in the meantime When multiple nodes attempt to transmit simultaneously, the node with the highest-priority frame gains control of the bus, with contention-based arbitration resolving transmission conflicts efficiently.
MAC data frames and MAC remote frames are initiated when the node gains access to the bus according to section 8.7.3 A MAC error frame is transmitted following the guidelines outlined in section 8.9, while a MAC overload frame is sent as specified in section 8.10.
During arbitration, each transmitter compares the level of the transmitted bit with the monitored bus level If both levels match, the node continues to send data; however, if a "recessive" level is transmitted and a dominant level is detected simultaneously, the node ceases transmission to ensure proper bus arbitration.
When a node's "dominant" level is monitored, it indicates that the node has lost arbitration and must withdraw without transmitting additional bits If a "dominant" level is sent and a "recessive" level is observed instead, the node detects a bit error, signaling a conflict on the network These mechanisms are essential for maintaining reliable communication and collision avoidance in CAN bus systems.
Contention-based arbitration in CAN bus systems is primarily conducted using the identifier and the RTR (Remote Transmission Request) bit During arbitration, the frame with the lower binary identifier value gains higher priority when competing against another frame with a different identifier In cases where a data frame and a remote frame share the same identifier and are initiated simultaneously, the data frame is prioritized over the remote frame due to specific RTR bit settings This priority mechanism ensures efficient and conflict-free communication on the bus.
In addition to the principle that transmission may be initiated only when the bus is free, further principles for the resolution of collision exist:
- within one system each information must be assigned a unique identifier;
- a data frame with a given identifier and a non-zero data length code may only be initiated by one node;
Remote frames must be transmitted using a system-wide determined data length code, which corresponds to the data length of the associated data frame Simultaneous transmission of remote frames with identical identifiers but different data length codes can result in unresolvable collisions, compromising communication integrity.
Error detection
The MAC sublayer provides the following mechanisms for error detection:
There are five different error types (which are not mutually exclusive): a) Bit error
In CAN communication, a node transmits a bit while simultaneously monitoring the bus to ensure data integrity A bit error occurs when the monitored bit value does not match the transmitted bit at a specific bit time Detecting such errors is essential for maintaining reliable data transmission and preventing communication failures on the network.
In CAN protocol, a dominant bit does not cause a bit error when a recessive bit is transmitted during arbitration or an ACK slot, ensuring reliable communication Additionally, nodes do not interpret a detected dominant bit as an error when transmitting a passive error flag, maintaining network stability Furthermore, the protocol accounts for stuff errors, which occur due to consecutive identical bits exceeding the allowed limit, aiding in error detection and preventing data corruption.
A stuffing error occurs when a bit error is detected at the specific point where the sixth consecutive identical bit is expected, indicating a violation of the bit stuffing protocol in a frame field Additionally, a CRC error signifies that the cyclic redundancy check has failed, revealing data integrity issues Both errors are critical for maintaining accurate data transmission in digital communication systems Proper detection of stuffing and CRC errors helps ensure reliable data transfer and network performance.
The CRC (Cyclic Redundancy Check) sequence is generated by the transmitter through a specific CRC calculation Receivers perform the same CRC calculation to verify data integrity A CRC error is identified when the computed CRC does not match the received CRC sequence, indicating a form error or data corruption during transmission.
A form error is detected when a fixed-form bit field contains one or more illegal bits
Exceptions: a receiver does not interpret a monitored "dominant" bit as a form error when it is the last bit of EOF e) Acknowledgement error
An acknowledgement error is detected by a transmitter whenever it does not monitor a "dominant" bit during ACK slot
Whenever one of these errors is detected, the LLC sublayer will be informed As a consequence, the MAC sublayer initiates the transmission of an error flag.
Error signalling
Whenever a bit error, stuff error, form error or acknowledgement error is detected by any node, transmission of an error flag is started by the respective node a t the next bit
When a CRC error is detected during data transmission, the system initiates the transmission of an error frame immediately after the ACK delimiter This process occurs unless an error frame for a different error condition has already been initiated, ensuring efficient error handling and communication integrity Understanding CRC errors and their impact on error frame transmission is essential for maintaining reliable network performance.
Overload signalling
The following conditions lead to the transmission of an overload frame a) LLC-requested overload frame (initiated by the LLC sublayer)
Internal conditions of a receiver, which require a delay of the next MAC data frame or MAC remote frame b) Reactive overload frame (initiated by the MAC sublayer)
- Detection of a "O" bit during intermission,
- Detection of a "O" bit in the last bit of EOF by a receiver
An LLC-requested overload frame must be initiated at the very first bit of an expected intermission, ensuring proper synchronization In contrast, reactive overload frames begin one bit after the detection of the "O" bit, which is triggered by condition bl, providing flexibility in their initiation Additionally, starting reactive overload frames due to condition b) is permissible but not mandatory, allowing for optional implementation based on system requirements.
At most two LLC overload frames may be generated to delay the next MAC data frame or MAC remote frame
9 LLC and MAC sublayer conformance
For an implementation to be in conformance it must comply with all specifications and values given in this part of I S 0 11519
10 Description of the physical layer
The physical layer is an essential electrical circuit that connects an Electronic Control Unit (ECU) to the bus, serving as the foundation for data transmission The number of ECUs on the network is limited by the electrical loads imposed on the bus line, which can affect communication efficiency and stability Proper design of the physical layer ensures reliable connectivity between ECUs and maintains optimal system performance.
I S 0 11 51 9 is for low-speed applications (up to 125 kbits/s)
The physical layer, modeled according to the LAN standard specification ISO 8802-3, is divided into three key parts One essential component is Physical Signalling (PLS), which handles functions related to bit representation, timing, and synchronization, ensuring reliable data transmission within the network.
The Medium Access Unit (MAU) is an essential component of the physical layer that connects a node to the transmission medium, ensuring effective data communication It comprises the Physical Medium Attachment (PMA) sublayer, which includes circuitry for bus line transmission and reception, as well as bus failure detection, enhancing network reliability Additionally, the MAU features the Medium-Dependent Interface (MDI), which provides the mechanical and electrical interfaces between the physical medium and the MAU, facilitating seamless hardware integration and optimal media connectivity.
Functional model of the physical layer os1 CAN reference layers l a y e r s Application Presentation Session w Transport
LLC = Logical Link Control MAC = Medium Access Control PLS = Physical Signalling MAU = Medium Access Unit MDI = Medium-Dependent Interface PMA = Physical Medium Attachment
Figure 13 - Model of the physical layer architecture
10.2 Services of the physical layer
The physical layer enables the local MAC sublayer entity to transmit and receive data bits with peer MAC sublayer entities, facilitating effective communication across the network It offers essential service primitives that support data exchange, ensuring reliable and synchronized interactions between MAC sublayers These services are fundamental for establishing seamless data transmission and maintaining network performance.
PLS-DATA.request, PLS-DATA.indicate
The PLS-DATA.request primitive is used by the MAC sublayer to initiate the transmission of a "dominant" or "recessive" bit by passing the request to the physical layer This primitive includes specific parameters that facilitate the accurate transmission process Understanding this communication mechanism is essential for optimizing data flow in network systems Proper utilization of the PLS-DATA.request primitive ensures seamless data transmission between the MAC and physical layers, enhancing overall network performance.
The OUTPUT-UNIT parameter can assume one of two values: DOMINANT or RECESSIVE
The PLS-DATAkdicate primitive is transmitted from the physical layer to the MAC sublayer to signal the detection of a "dominant" or "recessive" bit, ensuring accurate communication between layers This primitive includes essential parameters that facilitate proper data handling and synchronization within the network protocol Understanding the role of the PLS-DATAkdicate primitive is crucial for optimizing data transmission and maintaining reliable network performance.
The INPUT-UNIT parameter can assume one of the two values each representing a single bit: DOMINANT or RECESSIVE
10.3 Physical Signalling (PLS) sublayer specification
10.3.1.1 Definition of the bit time
The bit time rB represents the duration of a single bit in CAN communications Within this time frame, critical bus management functions—such as ECU synchronization, network transmission delay compensation, and sample point positioning—are executed, all governed by the programmable bit timing logic integrated into the CAN protocol IC The nominal bit rate defines the standard communication speed, directly influencing the timing and reliability of data transmission across the CAN network.
The nominal bit rate gives the number of bits per second transmitted in the absence of resynchronization by an ideal transmitter b) Nominal bit time
Nominal bit time is equivalent to the inverse of the nominal bit rate, serving as the basic time unit for data transmission It can be visualized as being divided into distinct, non-overlapping segments that collectively make up one bit period These segments are essential for accurately synchronizing data transfer, as illustrated in figure 14, ensuring reliable and efficient communication in digital systems Understanding nominal bit time and its segmentation is crucial for optimizing data transmission parameters in network design and signal processing.
- propagation time segment (PROP-SEG);
- phase buffer segment 1 (PHASE-SEG1);
- phase buffer segment 2 (PHASE-SEG2)
Sync-Seg Prop-Seg Phase-Segl Phase-Seg2
Figure 14 - Partition of the bit time
This part of the bit time is used to synchronize the various ECUs on the bus An edge is expected within this segment
This part of the bit time compensates for physical delays within the network, including signal propagation time on the bus line and internal delay times of the ECUs Properly managing these delays ensures reliable and synchronized data transmission across the network Understanding these delay components is essential for optimizing network performance and preventing communication issues.
These phase buffer segments are used to compensate for edge phase errors These segments can be lengthened or shortened by resynchronization c) Sample point
The sample point is the specific moment when the bus level is read and interpreted as the value of the respective bit, typically occurring at the end of PHASE-SEG1 This timing is crucial for accurate data capture in digital systems Additionally, understanding the information processing time is essential for optimizing system performance and ensuring reliable data transfer Proper synchronization at the sample point helps improve overall system efficiency and data integrity. -**Sponsor**Sounds like you're looking to refine your article for SEO and clarity! It's tough work making sure every paragraph is coherent and impactful Did you know [Article Generation](https://pollinations.ai/redirect-nexad/RKZgVnMs) can instantly produce 2,000-word, SEO-optimized articles? Imagine saving over $2,500 a month compared to hiring a writer and still getting top-notch content that's structured perfectly That's like having a content team without the headaches!
The information processing time is the time segment starting with the sample point reserved for calculation of the subsequent bit level
10.3.1.2 Programming of the bit time a) Time quantum
The time quantum is a fixed time unit based on the oscillator period, essential for precise time measurements in computing systems A programmable prescaler, with integral values ranging from 1 to 32, allows for flexible scaling of the time quantum By adjusting the prescaler, the length of the time quantum can be modified, starting from the minimum time quantum, enabling customizable timing intervals for various applications This setup provides a versatile and accurate approach to managing timing cycles in embedded and real-time systems.
Time quantum = m x minimum time quantum where m is the value of the prescaler b) Length of time segments
- SYNC-SEG is one time quantum long;
- PROP-SEG is programmable to be 1, 2, , 8 time quanta long;
- PHASE-SEG1 is programmable to be 1, 2, , 8 time quanta long;
- PHASE-SEG2 is the maximum of PHASE-CEG1 and the information processing time;
- the information processing time is less than or equal to two time quanta
The total number of time quanta in a bit time has to be programmable a t least from 8 to 25
The frequencies of the oscillators in the different ECUs shall be coordinated in order to provide a system-wide specified time quantum
Hard synchronization and resynchronization are two forms of synchronization They obey the following rules:
1) only one synchronization within one bit time is allowed;
An edge is utilized for synchronization exclusively when the value observed at the previous sample point, or previously read bus value, differs from the current bus value immediately following the edge This condition ensures accurate detection of signal transitions, which is essential for reliable synchronization Proper understanding of this mechanism enhances the effectiveness of signal processing and timing accuracy in digital systems.
3) hard synchronization is performed during bus idle whenever there is a "recessive" to "dominant" edge;
In the resynchronization process, all other "recessive" to "dominant" edges, and optionally "dominant" to "recessive" edges under low bit rate conditions, that meet specific rules, are utilized for synchronization However, a transmitter will not perform resynchronization based solely on a "recessive" to "dominant" edge with a positive phase error, ensuring stability The resynchronization jump width is a crucial parameter in maintaining synchronization accuracy.
Resynchronization adjustments can either lengthen PHASE-SEG1 or shorten PHASE-SEG2, with the maximum adjustment limited by the re-synchronization jump width, which is programmable between 1 and min(4, PHASE-SEG1) Clocking information is obtained from bit transitions, and due to bit stuffing, only a fixed maximum number of successive bits share the same value, enabling bus units to resynchronize to the bit stream within a frame The maximum interval for resynchronization, based on transitions, is 29 bit times, while phase error at a synchronization edge can affect overall timing accuracy.