Functional Description
MPC5200B Users Guide, Rev. 1
Freescale Semiconductor 20-37
20.8.6.1 IFR Types Supported by the BDLC module
SAE J1850 defines four distinct types of IFR. The first (and most basic) IFR is Type 0, or no IFR. IFR types 1, 2 & 3 are each made up of one
or more bytes and, depending upon the type used, may be followed by a CRC byte. The BDLC module is designed to allow the user to transmit
and receive all types of SAE J1850 IFRs, but only the network framing/error checking/bus acquisition duties are performed by the BDLC
module. The user is responsible for determining the type of IFR to be transmitted, the number of retries to be made (if allowed), and the
allowable number of bytes to be transmitted.
• IFR Type 0: No Response
The most basic type of IFR is no IFR. The Type 0 IFR, as defined in SAE J1850, is no response. The EOD and EOF symbols follow
directly after the CRC byte at the end of the message frame being transmitted. This type of IFR is, of course, inherently supported
by the BDLC module with no additional user intervention required.
• IFR Type 1: Single Byte from a Single Responder
SAE J1850 defines the Type 1 IFR as a single byte from a single receiver. This type of IFR is used to acknowledge to the transmitter
that the message frame was transmitted successfully on the network, and that at least one receiver received it correctly. A Type 1
IFR generally consists of the physical node ID of the receiver responding to the message, with no CRC byte appended. This type of
response is used for Broadcast-type messages, where there may be several intended receivers for a message but the transmitter only
wants to know that at least one node received it. In this case, all receivers will begin transmitting their node ID following the EOD.
Since all nodes on an SAE J1850 network have a unique node ID, if multiple nodes begin transmitting their node ID simultaneously,
arbitration takes place. The node with the highest priority (lowest value) ID wins this arbitration process, and that node’s ID makes
up the IFR. No retries are attempted by the nodes which lose arbitration during a Type 1 IFR transmission.
A Type 1 IFR can also be used as a response to a physically addressed message, where the only intended receiver is the one which
responds. In this case, no arbitration would take place during the IFR transmission, but the resulting IFR would still consist of a
single byte.
• IFR Type 2: Single Byte from Multiple Responders
The Type 2 IFR, as defined in SAE J1850, is a series of single bytes, each transmitted by a different responder. This IFR type not
only acknowledges to the transmitter that the message was transmitted successfully, but also reveals which receivers actually
received the message. As with the Type 1 IFR, no CRC byte is appended to the end of a Type 2 IFR.
This IFR type is typically used with Function-type messages, where the original transmitter may need to know which nodes actually
received the message. The basic difference between this type of IFR and the Type 1 IFR is that the nodes which lose arbitration
while attempting to transmit their node ID during a Type 2 IFR wait until the byte which wins arbitration is transmitted and then
again attempt to transmit their node ID onto the bus. The result is a series of node IDs, one from each receiver of the original
message.
• IFR Type 3: Multiple Bytes from a Single Responder
The last type of IFR defined by SAE J1850 is the Type 3 IFR. This IFR type consists of one or more bytes from a single responder.
This type of IFR is used to return data to the original transmitter within the original message frame. This type of IFR may or may
not have a CRC byte appended to it.
The Type 3 IFR is typically used with Function Read-type or Function Query-type messages, where the original transmitter is
requesting data from the intended receiver. The node requesting the data transmits the initial portion of the message, and the
intended receiver responds by transmitting the desired data in an IFR. In most cases, the original message requiring a Type 3 IFR
is addressed to one particular node, so no arbitration should take place during the IFR portion of the message.
20.8.6.2 BDLC IFR Transmit Control Bits
The BDLC module has three bits which are used to control the transmission of an In-Frame Response. These bits, all located in BDLC Control
Register 2, are TSIFR, TMIFR1 and TMIFR0. Each is used in conjunction with the TEOD bit to transmit one of three IFR types defined in
SAE J1850. What follows is a brief description of each bit.
Because each of the bits used for transmitting an IFR with the BDLC module is used to transmit a particular type of IFR, only one bit should
be set by the CPU at a time. However, should more than one of these bits get set at one time, a priority encoding scheme is used to determine
which type of IFR is sent. This scheme prevents unpredictable operation caused by conflicting signals to the BDLC module. Table20-20
illustrates which IFR bit will actually be acted upon by the BDLC module should multiple IFR bits get set at the same time.
NOTE
As with transmitted messages, IFRs transmitted by the BDLC module will also be received by the
BDLC module. For a description of how IFR bytes received by the BDLC module should be handled,
refer to Section 20.8.7, Receiving An In-Frame Response (IFR).