1
\$\begingroup\$

I have a question about LIN communication. To be sure my current knowledge is correct, I'll start here:

LIN 2.1 diagnostic basics:

The communication in a LIN diagnostics session uses frames with 8bytes payload, and in general looks like this:

TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5>
RX:  <NAD> 21 <D6> <D7> <D8>  FF   FF  FF
  • The master sends to device <NAD> a single frame (0) containing 3 data bytes <D1>...<D3>
  • The slave <NAD> replies with a first frame (1) and will send a total of 0 08 data bytes. This message holds the first data bytes <D1>...<D5>.
  • The slave <NAD> sends a continuation frame (2) numbered 1 and the last 3 data bytes <D6>...<D8>.

Now, simply speaking, both devices have two 8 byte buffers, one for TX and one for RX, and the data is transferred at predefined intervals.
Since the interval can be very fast, the same message can be transmitted several times, before the TX buffer is filled with new content. Vice versa, the same message might be received multiple times. So a real communication might look like this:

TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5> <- slave starts response
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF <- Master still sending
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5> <- slave still sending
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5>
TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5>

Question:

The master knows due to the 10 08 reply that there will be a single continuation frame, but how does it request that one? It must somehow signal the slave that the first frame was processed and it can now receive the second one.

\$\endgroup\$

2 Answers 2

Reset to default
1
\$\begingroup\$

Does the master task request the additional frame?

To answer this question, you need to remember how the LIN bus itself works:

The master task decides when and which frame shall be transferred on the bus. The slave tasks provide the data transported by each frame.

Lin 2.1 Spec, 1.1.5.1

The slave tasks cannot send any data without the master task explicitly requesting it.

How does the master task request normal frames?

A frame consists of a header (provided by the master task) and a response (provided by a slave task). The header consists of a break field and sync field followed by a frame identifier. The frame identifier uniquely defines the purpose of the frame. The slave task appointed for providing the response associated with the frame identifier transmits [the response]

Ibid, 1.1.5.2

The master task requests data and controls the flow of data on the bus by sending header fields. The header field consists of a break (to unambiguously indicate the start of a frame); a sync field (to tune the transceivers to the master's clock speed); and a frame identifier (to indicate what data is being transmitted).

As soon as the frame header has been transmitted, the appropriate slave node can transmit the frame body. A normal LIN frame might look like this:

|         Header        |                              Body                                |
|  Break  | Sync |  Id  |  D0  |  D1  |  D2  |  D3  |  D4  |  D5  |  D6  |  D7  | Checksum |
============================================================================================
| <Break> | 0x55 | 0x21 | 0x01 | 0x23 | 0x45 | 0x67 | 0x89 | 0xAB | 0xCD | 0xEF |   0x1E   |
| Transmitted by master |                       Transmitted by slave                       |

How are diagnostic messages different?

The diagnostic messages are specified with the LIN transport layer in Section 3 of the Lin 2.1 spec. Diagnostic messages form a higher-level protocol that is packetized into regular LIN frames. That is, it still relies on the master transmitting headers in the normal way; but additional information is encoded into the frame body, and a single message will span multiple frames.

The most significant difference in the frames used by diagnostic messages is the role of the frame Id.

The first byte in the pay-load is used as an node address (NAD). The transport layer frames have fixed frame IDs, since the diagnostic frames are used. This means that the addressing of a node (or function) is made using the NAD.

Ibid, 3.2.1

The Service Identifier (SID) specifies the request that shall be performed by the slave node addressed... The Response Service Identifier (RSID) specifies the contents of the response.

Ibid, 3.2.1.5

All frames that carry LIN diagnostic messages will have one of two ids:

  • 0x3C - For master request frames
  • 0x3D - For slave response frames

(See Lin 2.1 Spec, 2.3.3.4)

This means that the frame id alone does not tell you what the message is, or which slave node is expected to respond. Instead the D0 byte of the frame body indicates the Node ADdress (NAD), and the SID/RSID byte (exact location varies depending on frame, exact details not relevant) indicate the purpose of the message.

Because this information is in the body of the frame, not the header, a separate header field needs to be generated for the slave to respond. The slave can't take over control of transmission after 2-4 bytes of the frame because this would break the lower-level parts of the LIN spec.

When a slave receives a master request frame (0x3C) with its own NAD in D0, it enters a new state. The node perform any actions required by the SID according to the data included in the message. It then readies its transmit buffer to reply on the next slave response frame (0x3D). If the response is longer than six bytes, it will split it across multiple frames, and continue replying on subsequent slave response frames.

Going back to your example, it becomes a lot clearer when we add the LIN protocol fields back on to the transport layer data that you provided.

|       LIN Header      |                            LIN Body                              |
|  Break  | Sync |  Id  |  D0  |  D1  |  D2  |  D3  |  D4  |  D5  |  D6  |  D7  | Checksum |
============================================================================================
| Master Request Frame  | NAD  | PCI  | SID  |  D1  |  D2  |  D3  |  D4  |  D5  |----------|
| <Break> | 0x55 | 0x3C | 0x64 | 0x06 | 0xB4 | 0x67 | 0x89 | 0xAB | 0xCD | 0xEF |   0x86   |
|                                  Transmitted by master                                   |
--------------------------------------------------------------------------------------------
| Slave Response Frame  | NAD  | PCI  | LEN  | RSID |  D1  |  D2  |  D3  |  D4  |----------|
| <Break> | 0x55 | 0x3D | 0x64 | 0x10 | 0x08 | 0xF4 | 0x89 | 0xAB | 0xCD | 0xEF |   0x9B   |
| Transmitted by master |                       Transmitted by slave                       |
--------------------------------------------------------------------------------------------
| Slave Response Frame  | NAD  | PCI  |  D5  |  D6  |  D7  |------|------|------|----------|
| <Break> | 0x55 | 0x3D | 0x64 | 0x21 | 0x01 | 0x23 | 0x45 | 0xFF | 0xFF | 0xFF |   0x11   |
| Transmitted by master |                       Transmitted by slave                       |

How does the master request the next frame?

In short: by sending the next slave response frame header.

\$\endgroup\$
3
  • \$\begingroup\$ This does not work, because "master" is not well defined here. There is a scheduler, which only sends headers including the 3C/3D again and again. The master task then fills the rest of the 3C frame, and the slave the 3D. But those tasks have no access to the scheduler, nor is the scheduler aware of the data in the frame. You can not send one 3C and request two 3D frames. As I wrote in my answer, the slave sends the first 3D frame, and then waits for the master to send the flow control frame. After, it will send the next frames automatically with the next 3C requests. \$\endgroup\$
    – sweber
    Commented Dec 17, 2018 at 21:32
  • \$\begingroup\$ Re: ISO 15765-2, According to Lin Spec 2.1 3.2.1 "Flow control is not used in LIN clusters. If the back-bone bus test equipment needs flow control PDUs, these must be generated by the master node on the back-bone side." \$\endgroup\$
    – Malacandrian
    Commented Dec 18, 2018 at 10:05
  • \$\begingroup\$ Re: isolation of the master and slave tasks within the master node, if you are working with this level of abstraction with no inter-process communication then you simply need to ensure the scheduler allows enough time between headers for processing frames. The same way you do when developing non-diagnostic schedulers. \$\endgroup\$
    – Malacandrian
    Commented Dec 18, 2018 at 10:16
0
\$\begingroup\$

So, I found it myself.

This communication follows ISO 15765-2, or, in short ISO-TP.

After receiving the first frame, one has to send a flow control frame:

TX:  <NAD> 03 <D1> <D2> <D3>  FF   FF  FF 
RX:  <NAD> 10  08  <D1> <D2> <D3> <D4> <D5>
TX:  <NAD> 30  00   00   FF   FF   FF   FF   <== Flowcontrol
RX:  <NAD> 21 <D6> <D7> <D8>  FF   FF  FF

This frame consists of

  • The <NAD>
  • 3: this is a FlowControlFrame
  • 0: Clear to send (1: Stop, 2: Oops, overrun detected, stop!)
  • 00: Number of frames to send in one go (0: Send all)
  • 00: Time in ms between frames (0: As fast as possible)

There is no further handshake between frames sent in one go. Currently, I don't know what todo when one has requested / received a limited number of frames and is now clear to receive the next, but this is not an issue for me.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.