Using the LIN in Traveo II Family

About this document

Scope and purpose

This application note describes how to use Local Interconnect Network (LIN) for Traveo II family MCU. The LIN block of Traveo II supports the serial interface protocols LIN and UART. The LIN block supports the autonomous transfer of the LIN frame, to reduce CPU processing.

Associated Part Family

Traveo™ II Family CYT2/CYT3/CYT4 Series

Intended audience

This document is intended for anyone who uses the local interconnect network (LIN) driver of the Traveo II family.

General Description

LIN System Connection Diagram

The LIN protocol works on the concept of single master and multiple slaves and uses a single wire-bus for communication. Figure 1 shows the principle setup of LIN cluster with two LIN nodes.

Message Frame Format

As shown in Figure 2, LIN message frame has a:

• Header: Consisting of break field, sync field, and protected identifier (PID) field; transmitted only by the master node.
• Response: Consisting of maximum eight data fields and checksum field; transmitted by either the master node or the slave node.

See the Architecture TRM for details of the LIN message frame format.

Baud Rate Setting

The baud rate, derived from the PERI clock, can be configured for each channel individually. PERI clock is input to the LIN block via the peripheral clock divider. The baud rate is configured by the peripheral clock divider value. Furthermore, there is a fixed signal oversampling factor of 16 in the LIN channel. Therefore, the baud rate is calculated as shown in Equation 1.

Equation 1
Baud Rate = PERI clock / (16 × Divider value)

Equation 2 shows an example for the calculation of the divider setting value when PERI clock is 24 MHz and the required LIN baud rate is 20 kbps (20 kHz).

Equation 2
Divider value = PERI clock / (16 × Baud Rate) = 24 MHz / (16 × 20 kHz) = 75

See Clocking System in the Architecture TRM for details of the PERI clock, peripheral clock divider, and divider value settings.

LIN Communication Example

This section describes how to implementation of the LIN communication using the Sample Driver Library (SDL). The code snippets in this application note are part of SDL. See Other References for the SDL.

SDL has a configuration part and a driver part. The configuration part configures the parameter values for the desired operation. The driver part configures each register based on the parameter values in the configuration part. You can configure the configuration part according to your system.

As the LIN is a deterministic in principle, the LIN Master has the scheduler that is activated periodically by the reference timer and controls the bus activity. Every frame is transmitted according to the predefined slots. Each LIN frame starts with the master header.

Furthermore, LIN Master has a schedule table, which is divided into time slots. The schedule is finished, when all time slots response frames are passed. A repetition of the table is executed by retriggering the scheduler, but the master node also has the flexibility to replace the schedule table by another one.

In the schedule table, the communication type of each time slot such as frame ID, message type, data length, and type of check sum used for the response is predetermined. The message type defines the response transmitter. If there are multiple slaves, then the message type defines the slave which will transmit a response.

In LIN communication, two checksum types are supported: classic mode and enhanced mode. In classic mode, the PID field is not included in the checksum calculation, only the data fields are included in the calculation; whereas in enhanced mode, the PID field is included along with the data fields in the checksum calculation. The checksum type is can be selected using the CHECKSUM_ENHANCED bit in the LIN_CH_CTL register. See the Registers TRM for details of checksum type.

Table 1 Example of a Scheduled Table

In this example, the schedule table consists of five time slots 1 to 5.

The message type of time slot 1 is a slave response and data length are 8. Therefore, when the header is transmitted by scheduler trigger, the LIN slave transmits response data of 8 bytes to the master.

In time slot 4, there is a master response with one byte data length. The master node transmits 1 byte of data along with the header to the slave nodes.

Time slot 5 defines a slave-to-slave response. In this case, the response is only between dedicated slave nodes and the master can ignore the response.

Figure 3 shows LIN communication example between the master node and slave node as per the schedule listed in Table 1.

1. The master transmits a header with ID = 0x01 after the scheduler activation.

2. After receiving the header, the slave transmits the response of 8 bytes to the master according to schedule table (time slot 1).

3. When the master receives the response, the frame in time slot 1 is completed and the master waits for the next scheduler activation.

4. When scheduler is activated, the master transmits the header with ID = 0x02.

5. The master transmits a response of 8 bytes to the slave after transmitting header (time slot 2) and the master waits for the next scheduler activation.

6. This operation procedure is repeated until the last time slot 5.

7. After the operation of time slot 5 is completed, the next time the scheduler is activated starting with time slot 1.

LIN Message Transfer

In the SDL, to support different message types such as transmission and reception of header/response, the handling of the LIN master or LIN slave operation mode is implicitly done by following commands:

• LIN_CMD_TX_HEADER: This command is used by the master to transmit the header.
• LIN_CMD_TX_RESPONSE: This command is used by the master or a slave to transmit a response.
• LIN_CMD_RX_RESPONSE: This command is used by the master or a slave to receive a response.

These commands are configured corresponding to the message type in Table 1. For details, see section 4 and section 5.

Event Generation

The LIN block generates interrupt events such as transmission completion, reception completion, and error detection. Each LIN channel has its dedicated interrupt signal and its own interrupt registers: LIN_CH_INTR, LIN_CH_INTR_SET, LIN_CH_INTR_MASK, and LIN_CH_INTR_MASKED. In this implementation example, INTR_MASK controls interrupt generation, and the LIN_CH_CMD.INTR_MASKD register checks the interrupt source.

The related interrupt registers have a bit corresponding to these events. The software can control the generation of events by setting or clearing the corresponding bits.

See the Architecture TRM and Registers TRM for details of events and each interrupt register.

Example of Master Operation

This section shows an example implementation of a LIN Master using Table 1. In the SDL, you can manage the state machine using commands. Figure 4 shows the operation of LIN Master state machine.

LIN Master state machine has the following four states.

• LIN_STATE_IDLE: This is the default state after initialization. This state is entered when the LIN Master IRQ handler is completed.
• LIN_STATE_TX_HEADER_RX_RESPONSE: This is the state when the message type is a slave response. The master sends a header and waits for a response from the slave.
• LIN_STATE_TX_HEADER_TX_RESPONSE: This is the state when the message type is a master response. The master sends a header and a response to the slave.
• LIN_STATE_TX_HEADER: This is the state when the message type is slave-to-slave. The master sends only a header.

The software determines the state according to the message type of the schedule table, and sets the command sequence according to the current state.

Table 4 Correspondence of Message Type, State, and Command Sequence Settings in LIN Master Node

The following is an example of initialization and interrupt control to execute these processes.

LIN Master Initialization

Figure 5 shows the flow example for LIN Master Initialization.

(1) Initialize LIN Master.

(2) Enable LIN Channel.

Software enables the external LIN transceiver after port setting is completed. This example does not control the external LIN transceiver because LIN_CH_CTL0.AUTO_EN is set to “0” in step 4 of this setup procedure. In this case, the software can control the EN-pin via the register bit TX_RX_STATUS.EN_OUT. If the LIN_EN_OUT pin for this deployed channel is not available on the MCU, EN-pin on the transceiver can be also controlled by a normal GPIO output.

(3) Initialize software state machine.

Set current state to lin_state=LIN_STATE_IDLE.

(4) Start the timer for starting the scheduler.

The communication starts automatically when the scheduler starts by this setting.

For details for clock setting, port setting, and Interrupt Controller setting, see the Architecture TRM and Registers TRM.

Use Case

This section describes a use case of LIN Master Initialization with the following parameters.

• Master/Slave Node : Master Node
• LIN Instance : LINO_CHO
• Baud Rate : 19231 Hz

Configuration and Example

Table 5 lists the parameters of the configuration part in SDL for LIN Master Initialization.

Code Listing 1 demonstrates an example program to initialize the LIN Master in the configuration part.

Code Listing 1 demonstrates an example program to initialize the LIN Master in the configuration part.

Code Listing 2 demonstrates an example of SchedulerInit.

Code Listing 3 demonstrates an example program to configure LIN in the driver part.

The following description will help you understand the register notation of the driver part of SDL:

• pstcLin->unCTL0 is the LINx_CHy_CTL0 register mentioned in the Registers TRM. Other registers are also described in the same manner. 'x' signifies LIN instance number, 'y' is the channel number.
• Performance improvement measures: To improve the performance of setting a register, the SDL writes a complete 32-bit data to the register. Each bit field is generated in advance in a bit-writable buffer and written to the register as the final 32-bit data.
• See "cyip_lin.h" under hdr/rev_x/ip for more information on the union and structure representation of registers.

Example of LIN Communication of LIN Master

When the LIN communication starts, the interrupt activates the master scheduler handler. Figure 6 shows example of how the master schedule handler works.

The following is the application software operation for the scheduler:

• (0) The timer IRQ activates the master schedule handler on the LIN Master.
• (1) Initializes the current pending state by configuring LIN_CH_CTLO.ENABLE to “0”. All non-retained MMIO registers (for example, the LIN_CH_STAUS, LIN_CH_CMD, and LIN_CH_INTR registers) are reset to default values by setting LIN_CH_CTLO to “0”. See the Registers TRM for details of the registers to be initialized.
• (2) Re-enables the LIN channel.
• (3) Checks the message type of the next frame. This is the message type specified in the current scheduler. If the message type is slave response or master response, it will configure the data length of the response field ((3)-1) and the checksum type ((3)-2) accordingly.
• (4) Write the PID field of the header. LIN_CH_PID_CHECKSUM.PID[7]is parity [1], LIN_CH_PID_CHECKSUM.PID [6] is parity [0], and LIN_CH_PID_CHECKSUM.PID[5:0] is ID. Software needs to calculate the PID field parity bits P[1] and P[0]. Parity is calculated as follows: P[0] = (ID[4] ^ ID[2] ^ ID[1] ^ ID[0]) P[1] = ! (ID[5] ^ ID[4] ^ ID[3] ^ ID[1]) In case of Master Response: The LIN master writes the response data of the required data length into the data register (DATA 0/1).(4)-1
• (5) The LIN_CH_INTR_MASK register enables the event interrupt according to the cases: A) Slave-to-Slave Response: Configure the TX_HEADER_DONE to “1” Configure the error detection bit to “1”. B) Slave Response: Configure the RX_RESPONSE_DONE to “1” Configure the error detection bit to “1”. C) Master Response: Configure the TX_RESPONSE_DONE to “1” Configure the error detection bit to “1”. It is necessary to set the required error detection bit depending on the system.
• (6) Set the state according to the current message type: A) Slave-to-slave Response: Configure the lin_state to LIN_STATE_TX_HEADER B) Slave Response: Configure the lin_state to LIN_STATE_TX_HEADER_RX_RESPONSE C) Master Response: Configure the lin_state to LIN_STATE_TX_HEADER_TX_RESPONSE
• (7) Set the command sequence according to the lin_state for each case: A) Slave-to-slave Response: Configure the LIN_CH_CMD.TX_HEADER to “1” B) Slave Response: Configure the LIN_CH_CMD.TX_HEADER to “1” Configure the LIN_CH_CMD.RX_RESPONSE to “1” C) Master Response: Configure the LIN_CH_CMD.TX_HEADER to “1” Configure the LIN_CH_CMD.TX_RESPONSE to “1” (a response is transmitted after the transmission of the header)
• (8) Set the message type for the next scheduler activation according to Table 1.
• (9) Returns from the scheduler (timer interrupt) and waits for the occurrence of the configured LIN interrupt as shown in Table 2.

Use Case

This section describes an example of determining the message type and performing LIN Master Communication.

• Master/Slave Node : Master Node
• LIN Instance : LINO_CHO
• Communication Operation : See Table 1 and Section 4.

Configuration and Example

Table 6 lists the parameters of the configuration part in SDL for LIN Communication (LIN Master)

Code Listing 4 demonstrates an example program to communicate LIN in the configuration part.

Example of LIN Master Interrupt Handling

When an interrupt set by the scheduler occurs, LIN Master IRQ handler is activated. Figure 7 shows example to how the LIN Master IRQ handler works.

The following is the application software operation for the LIN master IRQ handler:

• (0) LIN IRQ activates the LIN Master IRQ handler.
• (1) Acquire interrupt information from LIN_CH_MASKED register.
• (2) Clear all accepted interrupt.
• (3) Disable all interrupt to prevent occurrence of different interrupt during interrupt handling.
• (4) Check if an error occurred. If yes, go to (4)-1.
• (4)-1 Clear the currently pending state by LIN_CH_CTL0.ENABLE being set to “0”, and delete the state in the hardware internal state machine and the software state machine. After that, execute error handling.
• (5) When no communication error is detected, check the current state (lin_state) of the software state machine, which is decided by the scheduler handler (6) in Figure 6. If current state is not LIN_STATE_TX_HEADER_RX_RESPONSE, go to (9).
• (6) If current state is LIN_STATE_TX_HEADER_RX_RESPONSE, get the condition of LIN_CH_CMD.RX_RESPONSE and LIN_CH_STATUS.RX_BUSY.
• (7) Check the bit fields of LIN_CH_CMD.RX_RESPONSE and LIN_CH_STATUS.RX_BUSY. The hardware sets LIN_CH_CMD.RX_RESPONSE to "0" on successful completion of the legal command sequences (not set to "0" when an error is detected) and LIN_CH_STATUS.RX_BUSY to “0” on successful completion of previous commands or when an error is detected. Therefore, reception is completed successfully, when both the bits are set to "0". If LIN_CH_CMD.RX_RESPONSE or LIN_CH_STATUS.RX_BUSY is “1”, reception is not completed correctly. In this case, go to (4)-1.
• (8) Read the received data from DATA0 and DATA1 registers.
• (9) Set the state to LIN_STATE_IDLE.
• (10) Leave LIN Master IRQ handler, and wait for the next scheduler activation.

Use Case

This section describes an example in which the LIN Master Handler determines the interrupt factor, clears the interrupt factor, and executes the processing for current state.

• System Interrupt source : LINCHO (IDX: 69)
• Mapped to CPU Interrupt : IRQ3
• CPU Interrupt Priority :3
• Communication Operation : See Table 1 and Section 4.

Configuration and Example

Table 7 lists the parameters of the configuration part in SDL for LIN Master Interrupt Handler.

Code Listing 13 demonstrates an example program to interrupt LIN in the configuration part.

Example of Slave Operation

This section shows an example implementation of the LIN Slave. The LIN Slave transmits or receives information depending on the schedule table from the LIN protocol analyzer that acts like a master. LIN Slave IRQ Handler includes a table; see Table 8 for an example of message frame ID processing and this information is used in Figure 11. The LIN Slave receives the header from the LIN master. Upon receiving the header, the response field corresponding to the received PID will be transmitted or received as shown in Table 8. To support these different message types, the handling of the LIN Slave operation is implicitly done by command sequences, as listed in the “LIN Slave Command Sequence” table in the Architecture TRM.

In this example, the software manages the configuration of command sequences using a state machine. Figure 8 shows the state machine for the LIN Slave. The arrows from T0 to T6 are the triggers for state transition.

LIN slave state machine has following four states:

• LIN_STATE_IDLE: This is the default state after initialization. The slave is neither receiving nor transmitting any information on the LIN bus.
• LIN_STATE_RX_HEADER: This is the state when the slave is ready for permanent LIN break detection. The slave is waiting for a successful header reception.
• LIN_STATE_RX_RESPONSE: This is the state when the message type is a master response. The slave waits for a response from the master.
• LIN_STATE_TX_RESPONSE: This is the state when the message type is a slave response. The slave sends a response to the master. If the message type is slave-to-slave, the slave sends a response to the other slave.

The software determines the state according to the message type of Table 8 and sets the command sequence according to the current state. Table 9 shows the relationship between message type, states, and command sequence.

The following is an example of initialization and interrupt control to execute these processes.

LIN Slave Initialization

Figure 9 shows the flow example for LIN Slave Initialization.

(1) Initialize LIN Slave.

(2) Enable LIN Channel.

Software enables the external LIN transceiver after port setting is completed. This LIN example does not control the external LIN transceiver because LIN_CH_CTL0.AUTO_EN is set to “0” in (1) of this setup procedure. In this case, the software can control the EN-pin via the register bit TX_RX_STATUS.EN_OUT. If the LIN_EN_OUT pin for this deployed channel is not available on the MCU, the EN-pin on the transceiver can be also controlled by a normal GPIO output.

(3) Initialize the software state machine.

Set the current state to lin_state=LIN_STATE_IDLE.

For details for Clock setting, port setting, and Interrupt Controller setting, see the Architecture TRM and Registers TRM.

Use Case

This section describes a use case of LIN Slave Initialization with the following parameters.

• Master/Slave Node: Slave Node
• LIN Instance : LINO_CHO
• Baud Rate : 19231 Hz

Configuration and Example

Table 10 lists the parameters of the configuration part in SDL for LIN Master Initialization.

Code Listing 17 demonstrates an example program to initialize LIN Slave in the configuration part.

Example of LIN Slave Interrupt Handling

When an interrupt is set by header from master, LIN Slave IRQ handler is activated. Figure 10 shows an example of how the LIN Slave IRQ handler works. This flow is used in Code Listing 18.

For the LIN Slave IRQ handler, the application software operation is as follows.

• (0) The LIN slave IRQ handler is activated by LIN IRQ.
• (1) Acquire interrupt information from LIN_CH_MASKED register.
• (2) Clear all interrupt flags for initialized interrupt status.
• (3) Check the occurrence of communication error. If an error is detected, then go to (6)-2.
• (4) When there is no communication error, check the current state (lin_state) in the state machine. If current state is LIN_STATE_RX_HEADER, go to (5). If current state is not LIN_STATE_RX_HEADER, go to (7).
• (5) Get the received PID value from LIN_CH_PID_CHECKSUM.PID.
• (6) Check the current ID. If the current ID is not in Table 8, go to (6)-2. If the ID is present in Table 8, go to (6)-1.
• (6)-1 Go to (0) in Figure 11.
• (6)-2 Clear the currently pending state by setting LIN_CH_CTLO.ENABLE to “0” and delete the state in the hardware internal state machine and the software state machine. After that, run to the appropriate fail operation depending on the system.
• (7) Check the current state (lin_state) in state machine. If current state is LIN_STATE_TX_RESPONSE, go to (8). If not, go to (10).
• (8) Check the condition of INTR.RX_RESPONSE_DONE. Hardware configures LIN_CH_INTR.RX_RESPONSE_DONE to “1”, when a frame response (data fields and checksum field) is received (the CMD.RX_RESPONSE is completed). If LIN_CH_INTR.RX_RESPONSE_DONE is “0”, there is no data collision. Go to (12). If LIN_CH_INTR.RX_RESPONSE_DONE is “1”, data collision occurs. Go to (9).
• (9) Run the data collision operation depending on the system and go to (12).
• (10) Check the current state (lin_state) in state machine. If current state is LIN_STATE_RX_RESPONSE, go to (11). If not, go to (15).
• (11) Read the reception data from DATA0 and DATA1.
• (12) Configure the state to LIN_STATE_RX_HEADER.
• (13) Enable event interrupt by the LIN_CH_INTR_MASK register. Configure RX_HEADER_DONE to “1”. Configure RX_RESPONSE_DONE to “1”. Configure the error detection bit to “1”. It is necessary to Configure the required error detection bit depending on the system.
• (14) Configure the Command Sequence Configure LIN_CH_CMD.RX_HEADER to “1”. Configure LIN_CH_CMD.RX_RESPONSE to “1”.
• (15) Return from LIN slave IRQ handler and wait for the occurrence of the configured LIN interrupt as Table 2.

Figure 11 shows how the message type and checksum type operations are performed. This flow is used in the case of jumping from (6) -1 in Figure 10 and in Code Listing 20.

Glossary

Related Documents

The following are the Traveo™ II family series datasheets and Technical Reference Manuals. Contact Technical Support to obtain these documents.

• Device datasheet
  • CYT2B7 Datasheet 32-Bit Arm® Cortex-M4F Microcontroller Traveo™ II Family
  • CYT2B9 Datasheet 32-Bit Arm® Cortex-M4F Microcontroller Traveo™ II Family
  • CYT4BF Datasheet 32-Bit Arm® Cortex-M7 Microcontroller Traveo™ II Family
  • CYT4DN Datasheet 32-Bit Arm® Cortex®-M7 Microcontroller Traveo™ II Family
  • CYT3BB/4BB Datasheet 32-Bit Arm® Cortex-M7 Microcontroller Traveo™ II Family
• Body Controller Entry Family
  • Traveo™ II Automotive Body Controller Entry Family Architecture Technical Reference Manual (TRM)
  • Traveo™ II Automotive Body Controller Entry Registers Technical Reference Manual (TRM) for CYT2B7
  • Traveo™ II Automotive Body Controller Entry Registers Technical Reference Manual (TRM) for CYT2B9
• Body Controller High Family
  • Traveo™ II Automotive Body Controller High Family Architecture Technical Reference Manual (TRM)
  • Traveo™ II Automotive Body Controller High Registers Technical Reference Manual (TRM) for CYT4BF
  • Traveo™ II Automotive Body Controller High Registers Technical Reference Manual (TRM) for CYT3BB/4BB
• Cluster 2D Family
  • Traveo™ II Automotive Cluster 2D Family Architecture Technical Reference Manual (TRM)
  • Traveo™ II Automotive Cluster 2D Registers Technical Reference Manual (TRM)

Other References

Infineon provides the Sample Driver Library (SDL) including startup as sample software to access various peripherals. SDL also serves as a reference to customers for drivers that are not covered by the official AUTOSAR products. The SDL cannot be used for production purposes because it does not qualify to any automotive standards. The code snippets in this application note are part of the SDL. Contact Technical Support to obtain the SDL.

Revision history