SLLSEZ4A August 2019 – November 2019 TCAN4551-Q1
PRODUCTION DATA.
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 |
RSVD | |||||||
R | |||||||
23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |
RSVD | TDCV[6:0] | ||||||
R | R | ||||||
15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |
RSVD | PXE | RFDF | RBRS | RESI | DLEC[2:0] | ||
R | X | X | X | X | S | ||
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
BO | EW | EP | ACT[1:0] | LEC[2:0] | |||
R | R | R | R | S |
Bit | Field | Type | Reset | Description |
---|---|---|---|---|
31:24 | RSVD | R | 0x0 | Reserved |
23 | RSVD | R | 0x0 | Reserved |
22:16 | TDCV[6:0] | R | 0x0 | Transmitter Delay Compensation Value
0x00-0x7F – Position of the secondary sample point, defined by the sum of the measured delay from m_can_tx to m_can_rx and TDCR.TDCO. The SSP position is, in the data phase, the number of mtq between the start of the transmitted bit and the secondary sample point. Valid values are 0 to 127 mtq. |
15 | RSVD | R | 0 | Reserved |
14 | PXE | X | 0 | Protocol Exception Event
0 – No protocol exception event occurred since last read access 1 – Protocol exception event occurred |
13 | RFDF | X | 0 | Received a CAN FD Message
This bit is set independent of acceptance filtering 0 – Since this bit was reset by the CPU, no CAN FD message has been received 1 – Message in CAN FD format with FDF flag set has been received |
12 | RBRS | X | 0 | BRS flag of last received CAN FD Message
This bit is set together with RFDF, independent of acceptance filtering. 0 – Last received CAN FD message did not have its BRS flag set 1 – Last received CAN FD message had its BRS flag set |
11 | RESI | X | 0 | ESI flag of last received CAN FD Message
This bit is set together with RFDF, independent of acceptance filtering. 0 – Last received CAN FD message did not have its ESI flag set 1 – Last received CAN FD message had its ESI flag set |
10:8 | DLEC[2:0] | X | 0x7 | Data Phase Last Error Code
Type of last error that occurred in the data phase of a CAN FD format frame with its BRS flag set. Coding is the same as for LEC. This field will be cleared to zero when a CAN FD format frame with its BRS flag set has been transferred (reception or transmission) without error. |
7 | BO | R | 0 | Bus_Off Status
0 – The M_CAN is not Bus_Off 1 – The M_CAN is in Bus_Off state |
6 | EW | R | 0 | Warning Status
0 – Both error counters are below the Error_Warning limit of 96 1 – At least one of error counter has reached the Error_Warning limit of 96 |
5 | EP | R | 0 | Error Passive
0 – The M_CAN is in the Error_Active state. It normally takes part in bus communication and sends an active error flag when an error has been detected 1 – The M_CAN is in the Error_Passive state |
4:3 | ACT[1:0] | R | 0x0 | Activity
Monitors the module’s CAN communication state. 00 – Synchronizing - node is synchronizing on CAN communication 01 – Idle - node is neither receiver nor transmitter 10 – Receiver - node is operating as receiver 11 – Transmitter - node is operating as transmitter |
2:0 | LEC[2:0] | S | 0x7 | Last Error Code
The LEC indicates the type of the last error to occur on the CAN bus. This field will be cleared to ‘0’ when a message has been transferred (reception or transmission) without error. 0 – No Error: No error occurred since LEC has been reset by successful reception or transmission 1 – Stuff Error: More than 5 equal bits in a sequence have occurred in a part of a received message where this is not allowed. 2 – Form Error: A fixed format part of a received frame has the wrong format. 3 – AckError: The message transmitted by the M_CAN was not acknowledged by another node. 4 – Bit1Error: During the transmission of a message (with the exception of the arbitration field), the device wanted to send a recessive level (bit of logical value ‘1’), but the monitored bus value was dominant. 5 – Bit0Error: During the transmission of a message (or acknowledge bit, or active error flag, or overload flag), the device wanted to send a dominant level (data or identifier bit logical value ‘0’), but the monitored bus value was recessive. During Bus_Off recovery this status is set each time a sequence of 11 recessive bits has been monitored. This enables the CPU to monitor the proceeding of the Bus_Off recovery sequence (indicating the bus is not stuck at dominant or continuously disturbed). 6 – CRCError: The CRC check sum of a received message was incorrect. The CRC of an incoming message does not match with the CRC calculated from the received data. 7 – NoChange: Any read access to the Protocol Status Register re-initializes the LEC to ‘7’. When the LEC shows the value ‘7’, no CAN bus event was detected since the last CPU read access to the Protocol Status Register. |
NOTE
When a frame in CAN FD format has reached the data phase with BRS flag set, the next CAN event (error or valid frame) will be shown in DLEC instead of LEC. An error in a fixed stuff bit of a CAN FD CRC sequence will be shown as a Form Error, not Stuff Error
NOTE
The Bus_Off recovery sequence (see ISO 11898-1:2015) cannot be shortened by setting or resetting CCCR.INIT. If the device goes Bus_Off, it will set CCCR.INIT of its own accord, stopping all bus activities. Once CCCR.INIT has been cleared by the CPU, the device will then wait for 129 occurrences of Bus Idle (129 * 11 consecutive recessive bits) before resuming normal operation. At the end of the Bus_Off recovery sequence, the Error Management Counters will be reset. During the waiting time after the resetting of CCCR.INIT, each time a sequence of 11 recessive bits has been monitored, a Bit0Error code is written to PSR.LEC, enabling the CPU to readily checkup whether the CAN bus is stuck at dominant or continuously disturbed and to monitor the Bus_Off recovery sequence. ECR.REC is used to count these sequences.