LIN 2.0 Connectivity on Freescale 8/16-bit MCUs Using Volcano LTP

Transcription

1 Freescale Semiconductor Application Note AN2767 Rev. 0, 11/2004 LIN 2.0 Connectivity on Freescale 8/16-bit MCUs Using Volcano LTP by: Zdenek Kaspar, Jiri Kuhn 8/16-bit Systems Engineering Roznov pod Radhostem, Czech Republic Introduction LIN (Local Interconnect Network) is a low-cost, serial communication protocol intended for use mainly in the distributed electronic systems of vehicles. LIN will be the enabling factor in implementing a hierarchical vehicle network to achieve further feature enhancement and cost reduction in vehicles. LIN cannot compete against much more sophisticated networks such as CAN (controller area network) and MOST (media-oriented system transport), or Byteflight. However, LIN s simplicity and very low module price make it ideal for applications that do not require such sophisticated networks. This document describes all the necessary how-to steps for implementing LIN 2.0 connectivity on Freescale 8/16-bit microcontroller units (MCUs) using the Volcano LIN 2.0 Target Package (LTP 2.0). It is not intended to replace either the LIN 2.0 specification package or the Volcano LTP 2.0 related documentation, but it is intended to be a brief and easy-to-read document that introduces and describes the subject of LIN 2.0 implementation. Thus, it can be read by both novices and experienced developers, who may be required to add LIN 2.0 connectivity to their applications. Freescale Semiconductor, Inc., All rights reserved.

2 Freescale LIN Portfolio Freescale LIN Portfolio Freescale offers a wide variety of MCUs and other LIN related products, such as: 8/16-bit MCUs for both LIN slave and master implementations HC08 HCS12 HCS12X 32-bit MCUs for LIN master implementations MPC55xx MAC71xx Analog Product Group products, including LIN physical layers, LIN/CAN SBC (System Basis Chip), and IDC (Intelligent Distribution Control) devices For the latest information on these products, please visit A dedicated LIN web page can be found at This provides product information, application notes, design tools, links, etc. related to all LIN products. LIN 1.3 drivers for many Freescale MCUs can be downloaded free of charge from this site. (Note that, although these drivers are fully functional, they are not supported by the Volcano LIN Tool Chain (page 3). Main Changes from LIN 1.3 to LIN 2.0 After the LIN 1.3 specification was released, the LIN Consortium decided to make a major revision step to meet the new requirements of the automotive industry. This major revision includes the following changes. (For more detailed information, see Reference [1].) The LIN API (as part of the LIN specification Reference [1]) is made mandatory for all nodes programmed in C language. An enhanced checksum has been added (including the protected identifier byte). A new frame type and signal type have been defined, allowing sporadic frames and byte array signals to be used. A node capability language has been specified to enable off-the-shelf slave node support. Node configuration commands have been added and are mandatory (resolution of conflicting frames). Diagnostics and diagnostic API have added. The goto_sleep and the wake_up signals have been separated. In spite of the new features, it is possible to connect a LIN 1.3 enabled slave node to a LIN 2.0 master node. In this configuration, the enhanced checksum, configuration and diagnostic features, and automatic baud rate detection are not required by the master node. The inverse configuration, that is, a LIN 1.3 master node with a LIN 2.0 slave node, is not allowed. 2 Freescale Semiconductor

3 LIN 2.0 Spec Package Overview LIN 2.0 Spec Package Overview The LIN 2.0 Spec Package consists of the following specifications. (For more detailed information, see Reference [1]). The LIN Physical Layer Specification describes the physical layer, including bit rate and clock tolerances. The LIN Protocol Specification describes the data link layer. The LIN Diagnostic and Configuration Specification describes the service that can be layered on top of the data link layer to provide for diagnostic messages and node configuration. The LIN API Specification describes the interface between the network and the application program, including the diagnostic module. The LIN Configuration Language Specification describes the format of the LIN description file, which is used to configure the complete network and serve as a common interface between the OEM and the suppliers of the different network nodes, as well as an input to development and analysis tools. The *.ldf extension is used for the LIN configuration language specification files. The LIN Node Capability Language Specification describes a format used to describe off-theshelf slave nodes that can be used with a plug-and-play tool to automatically create LIN description files. LIN node capability language specification files use the.ncf extension. Volcano LIN Tool Chain Implementing LIN 2.0 connectivity can be simplified by using LIN development tools, such as the Volcano LIN 2.0 development tool chain, the concept of which is shown in Figure 1. Volcano Automotive Group ( is a company offering a complete suite of development tools and embedded software for LIN network implementation. Freescale Semiconductor 3

4 Volcano LIN Tool Chain Figure 1. VCT LIN Development Tool Chain The VCT LIN 2.0 development tool chain comprises the following. Node Capability Language Specification File (NCF File) contains node dependent information, which can be used by the LIN Network Architect for the automated LIN description file creation. Communication Design Tool (LNA - LIN Network Architect) enables a high level design view for a set of networks or clusters, and provides the LIN Configuration Description File for a particular LIN cluster. LIN Configuration Description File (LDF File) contains information on the nodes, cluster configuration, and scheduling tables. As the structure of this file is completely outlined in the LIN specification, it can be created by the user or it can be generated by the high level LIN Network Architect tool. Target Hardware Information can be divided into two subsets. Configuration File (.cfg) includes hardware details about the SCI used (such as the SCI register address base, address of used input/output pins). Node Private File (.prv) links the LDF and CFG files together. 4 Freescale Semiconductor

5 Volcano LTP 2.0 NOTE The.cfg file is a subset of the.prv file and is included into the.prv file via the #include directive. The content of this file could be placed into the.prv file directly. LIN Configuration Tools is a PC based tool; it uses Target Hardware Information and LDF files as inputs and generates two files (called l_gen.h and l_gen.c), which should be directly added to the application. LIN Bus-Analyzer, LIN Bus-Emulator the LINspector can be used for passive monitoring of the LIN bus, emulation of any number of nodes, and for LIN protocol error injection. ECU Application Code contains the user defined application. The process of including the VCT LTP 2.0 to standard Metrowerks CodeWarrior structure is described in VCT LTP 2.0 in Application (page 10). LIN Library is a precompiled library with LIN driver implementation for a specific hardware target. Volcano LTP 2.0 NOTE Unless stated otherwise, all information applies to the slave nodes and the master node. The Volcano LIN Target Package 2.0 driver provides a solution for implementing LIN 2.0 connectivity on Freescale MCUs. As can be seen in Figure 1, it is an integral part of the Volcano development tool chain. A VCT LTP 2.0 driver exists for both the Metrowerks CodeWarrior and the Cosmic development environments, for the following MCU types (as of September 2004). S12C32 (16-bit MCU) and HC08GZ60 (8-bit MCU) for LIN master functionality HC08GR60A, HC08EY16, HC08QL4, and HC08QY4 MCU (all 8-bit MCUs) for LIN slave functionality There are also plans to include the S12X device. The LTP can be ordered directly from VCT at The LTP can be ordered from VCT by from sales@vct.se. VCT also offers evaluation licenses for the LTP. For LTP related technical questions, please contact support@vct.se. LIN Description File This section provides a summary of the LIN Description File features. For more detailed information, please refer to Reference [1] and Reference [2]. Freescale Semiconductor 5

6 Volcano LTP 2.0 LIN Protocol Definition The LIN Description File can be divided into several parts, the first part being the LIN Protocol Definition. LIN_protocol_version = "2.0"; LIN_language_version = "2.0"; LIN_speed = 15.6 kbps; LIN_protocol_version and LIN_language_version describe the LIN protocol version used. LIN_speed defines the LIN bus speed (in the range 1.0 kbps to 20.0 kbps). Nodes The next section, Nodes, describes all nodes connected to the cluster. Nodes Master: master, 5ms, 1ms; Slaves: EY16, QY4, GR60A, QL4; The first line defines the master node name, the master time base, and master jitter time (both in ms). The second line lists by name all slaves connected to the LIN cluster. Signal Definitions After the node definitions, the Signal Definitions are usually defined. Signals info resolving_done data_20 data_ey16_resp_error... : 8, 0x00, master, EY16, QY4, QL4, GR60A; : 1, 0x00, master, EY16, QY4, QL4, GR60A; : 8, 0x00, EY16, master; : 1, 0x00, EY16, master; Each line defines a signal with: A signal name (which must be unique within the signal identifier set) A number defining the signal length, which can be from one to sixteen bits for a scalar signal, or a multiple of eight (up to 64) for byte array signals A number representing the initial value of the signal The publisher node name One or more subscriber node names For detailed information on the Diagnostic_signals and Diagnostic_frames sections, see Reference [1]. 6 Freescale Semiconductor

7 Volcano LTP 2.0 Frames In the Frames section, all frames used in the cluster are defined, including the frames properties: Frames EY16_20: 0x20, EY16, 2 data_20, 0; data_ey16_resp_error, 9;... All frame names must be unique within both the frame identifier set and the following frame ID (which in this example is set to 0x20 1 ). The second parameter listed in the frame name line, the publisher node name, should be defined in Nodes (page 6). The final parameter describes the frame length in bytes. All signals related to the specific frame are enclosed within the braces. The number stated after the signal name represents the signal offset. Node Attributes The main area where the nodes are described completely is in the Node Attributes section. Node_attributes EY16 LIN_protocol = "2.0"; configured_nad = 0x40; product_id = 0x0004, 0x0020, 1; response_error = data_ey16_resp_error; P2_min = 20 ms; ST_min = 20 ms; configurable_frames global_info = 0x0050; resolving = 0x0060; EY16_20 = 0x1000;... The LIN_protocol variable contains the version of the LIN bus used by the node. The configured_nad specifies the diagnostic address; this is used in the automatic conflict resolving procedure, as well as in all diagnostic and configuration functions, to identify the node. For this reason, it is a unique number within the cluster. The product_id is a mandatory part of the node configuration; it consists of the supplier ID 2, the function ID 3, and the variant ID The frame IDs are stated without the checksum bit. 2. The supplier ID is assigned by the LIN consortium. For Freescale, it is 0x0004; for Freescale, the 0x000B supplier ID is reserved. Freescale Semiconductor 7

8 Volcano LTP 2.0 The response_error identifies the signal name used for LIN error reporting, and must be defined in the signal section. The time value P2_min defines the minimum time for a slave to prepare its response to a master request frame. The ST_min time defines the minimum time between two slave response frames. In configurable_frames, part of the node properties section, all frames subsistent to the node are listed (received as well as provided by the node). Schedule Table Last, but not least, is the Schedule table section. Schedule_tables sch_conflict_resolving AssignNAD 0x3A, 0x40, 0x000B, 0x0020 SlaveResp AssignFrameId EY16, global_info SlaveResp normal_mode global_info EY16_20 MasterReq SlaveResp delay 20 ms; delay 20 ms; delay 20 ms; delay 20 ms; delay 20 ms; delay 20 ms; delay 20 ms; delay 20 ms; The schedule table is the key property of the LIN protocol as a deterministic system. Schedule tables make it possible to assure that the bus will never be overloaded. It is also the key component to guarantee the periodicity of the signals. In this example, two schedule tables are defined. The first one, for conflict resolving, must be called after a master reset, to resolve any possible conflicts and to assign the frame IDs to the connected nodes. The second one is used in the normal run mode. In the first schedule table, there is an example of changing the NAD property on run. In this case, the NAD of the node with supplier ID 0x0004 (Freescale), function ID 0x0020 and NAD 0x3A, will be changed to 0x40. The AssignFrameId function is used to assign the frame to the node. To provide the master node with the slave response, the AssignFrameId and the AssignNAD frames should be followed by the SlaveResp frame. In the second schedule table, there is an example of the cluster normal running mode. 3. The function ID is assigned by the supplier; in this case 0x0020 was chosen. 4. The variant ID must be changed whenever the product is changed, but with an unaltered function. 8 Freescale Semiconductor

9 Volcano LTP 2.0 Every command in each defined schedule table must be followed by the delay time, which specifies the duration of the frame slot. This delay time must be longer than the maximum allowed frame transfer time, and should be a multiple of the master node time base. LIN Node Private File This file links the Target Configuration File (page 10) and the LIN Description File (page 5) together. LIN_private_file; LIN_protocol_version = "2.0"; LIN_language_version = "2.0"; concurrency_safety = LTP; network "demo_net" node EY16; file "demo_net.ldf"; original_nad = 0x3A; supports_user_defined_diagnostic; flag res_done latches signal resolving_done; interface "i1" connects to demo_net; [include "uart.cfg"] The first two lines specify the LIN bus version used by the node. The next line, concurrency_safety, determines which part (either LIN LTP or application) has priority for peripheral access. The variable node defines the node name. The variable file defines the subsistent LIN Description File (page 5). The original_nad sets the initial NAD and can be changed on run, as is described in the Schedule Table (page 8). If the LIN 2.0 User Defined Diagnostics (page 13) features are required, the supports_user_defined_diagnostic key word should be declared after the original_nad. If the LIN Configuration Tool finds the supports_user_defined_diagnostic key word, it generates the necessary signal read and write calls to allow direct access to the diagnostic frames using the signal API (see Reference [2] for details). The subsequent line defines the signal flag. The first name stated after the flag key word (res_done in this case) is the name of the signal flag. The second identifier must refer to a signal either declared in Signal Definitions (page 6), or renamed within the private file. This line can be repeated for as many signal flags as needed. The last section consists of the interface name (i1 in this case) and the Target Configuration File (page 10). For more details about the LIN Node Private File, see Reference [2] and Reference [4]. Freescale Semiconductor 9

10 Volcano LTP 2.0 Target Configuration File Finally, the Target Configuration File file comes into the LIN Configuration Tool (it is included through the [include uart.cfg] directive into the.prv file): uart "hc08esci" clock_frequency_khz= 2000; sci_register_base= 0x09; port_ddr_addr= 0x0c; port_io_addr= 0x08; rx_pin_offset= 1; tx_pin_offset= 0; The first variable after the name of the UART (hc08esci in this case) is the clock_frequency. It defines the SCI module input clock frequency in khz. The next line, sci_register_base, points to the SCI register base address. Similarly, port_ddr_addr is the address of the data direction register where the SCI output pin is situated, and port_io_addr is the address of the data register for the SCI output pin. The final two lines describe the offset of the SCI receive and transmit pins. VCT LTP 2.0 in Application The VCT LTP 2.0, apart from the example application, contains a driver set consisting of the following components. lin.h header file (linking together the l_types.h, l_core.h, l_target.h and l_gen.h header files) lin.lib LIN core library target.c and targer.h (providing the LIN target specified information for the LIN driver) interrupt_handles.c file takes care of mapping the LIN required interrupts (available for some targets only) l_gen.h and l_gen.c files (generated by the LIN Configuration Tools; see Volcano LIN Tool Chain (page 3) for details) ld2_api.h, ld2_core.h, ld2_master, ld2_slave, ld3cooked_api.h, ld3cooked_core.h, ld3raw_api.h and ld3raw_core.h header files to enable the configuration and diagnostic functions of the VCT LTP 2.0 To add LIN functionality to a Metrowerks CodeWarrior based application: The target.h and lin.h header files should be included in the application file (e.g. slave.c). The l_gen.c, target.c and interrupt_handler.c (if applicable) should be included in the Metrowerks CodeWarrior Project Tree (see Figure 2). The lin.lib library should be included in the Metrowerks CodeWarrior Project Tree (see Figure 2). The path to the directory where the VCT LTP 2.0 is stored should be added to the Metrowerks CW Access Path. An example of a LIN 2.0 enabled Metrowerks CW Project Tree can be seen in Figure Freescale Semiconductor

11 Volcano LTP 2.0 Figure 2. Metrowerks CodeWarrior Project Tree LIN Initialization Before transmitting LIN frames after an MCU reset or a LIN communication shutdown, the LIN interface must be initialized. This initialization consists of the following command sequence: init_target (); /* Initialize non-lin hardware */ result = l_sys_init (); /* Initialize LIN system component */ check (result); l_ifc_init_i1 (); /* Initialize the interface */ ENABLE_INTS(); /* Turn on interrupts */ result = l_ifc_connect_i1 (); /* Connect driver to I/O pins */ check (result); The check(result) function is used to check the result of the LIN API functions call, and provides the necessary steps when the result is different from the value 0x00. Freescale Semiconductor 11

12 Volcano LTP 2.0 Signal Naming Convention Once the LIN initialization is carried out (as described in the previous section), the use of the VCT LTP is very familiar. All LIN related signal read or write keep to the following simple naming convention, as described in the Application Program Interface part of the LIN specification (all letters should be in lower case, and each part is separated by an underscore). To indicate LIN related signals, each name starts with l (lower case L). The next part is the signal type definition 1, either bool for boolean values, u8 for 8-bit unsigned signals, or u16 for 16-bit unsigned signals. The next part determines whether signal can either be read (rd) or written (wr) by the node. The same signal can be written on the provider side and read on the subscriber side. The last part belongs to the signal name, as is defined in the Signal Definitions (page 6) section of the LIN Description File (page 5). An example of a write API call could be: l_bool_wr_resolving_done(1); This line will write the value 1 into the resolving_done LIN boolean signal. The exact timing of the signal transmission on the LIN bus depends on the Schedule Table (page 8). Node LIN Related Functions Node LIN related functions can be divided into two kinds: Writing and reading LIN signals Schedule table management 2 Here are some examples of writing and reading LIN signals: l_u8_wr_info(0xaa); messages[0] = l_u8_rd_data_20(); In the first line, the info signal content is set to the value 0xAA. In the second line, the messages[0] buffer is filled by the data_20 signal value. An example of the schedule table management could be: l_sch_set_i1(sch_conflict_resolving, 0); /* start conflict resolving */ while (l_sch_tick_i1()!= 1) /* one round */ busy_wait_until_next_period(); l_sch_set_i1 (normal_mode,0); This example shows the transition between the sch_conflict_resolving and normal_mode schedule tables. To apply the schedule table the l_sch_set_i1 3 command is issued. The first parameter of this function is the name of the desired schedule table, the second is the starting entry point in that table. The 1. Intimately bound up with the signal length in Signal Definitions (page 6). 2. Applicable to the master node only. 3. The i1 is the interface name as is described in LIN Node Private File (page 9). 12 Freescale Semiconductor

13 Volcano LTP 2.0 The l_sch_tick_i1 function returns the next schedule table entry number, so that here the while() condition ensures the changeover of tables on the schedule table begins. The busy_wait_until_next_period() is a user function providing the delay, which is one LIN schedule table period long. LIN 2.0 User Defined Diagnostics To enable the user defined diagnostics: The supports_user_defined_diagnostic key word must be stated in LIN Node Private File (page 9). Master request and Slave response frames transmission commands should be included in the Schedule Table (page 8), to a desired schedule table position where the user defined diagnostics are required. Because the Master Request (0x3c) and Slave Response (0x3d) frame types are utilized for user defined diagnostic transmission, the user defined diagnostic frames transmitted from the master node to the slave nodes (Master Requests) must all have the first data byte in the range 0x80 to 0xFF. Here is an example of using user defined diagnostics usage. Slave node 1 l_u8_wr_slaverespb0_demo_net(0x81); /* set the slave response */... if (l_flg_tst_res_done()) /* conflict resolving done flag set? */ l_u8_wr_slaverespb0_demo_net(0x80); /* yes, clear the slave response */ l_flg_clr_res_done(); /* clear the flag */ Master node if (l_u8_rd_slaverespb0_demo_net() == 0x81) /* new node detected? */ NewNode();... Low Power Mode, Shutting Down the LIN Communication To introduce the MCU low power modes, the goto_sleep and wake_up 2 commands were defined within the LIN specification. Transition between the normal running mode and the low power mode is different for master and slave nodes. Master Node The master node provides one simple command for entering the low power mode: 1. A Slave Response frame is transmitted each time the appropriate buffer write command is issued, and a Slave Response entry is defined in the processing schedule table. 2. The wake_up signal on the master side can be replaced by any ordinary frame header since the break will act as a wake_up pulse. Freescale Semiconductor 13

14 Volcano LTP 2.0 l_ifc_goto_sleep_i1(); The i1 is the interface name as was described in the LIN Node Private File (page 9). Transition between the low power mode and the normal running mode on the master node side consists of the following steps: if ((l_ifc_read_status_i1() & 0x0010) == L_WAKEUP_REQUEST) l_ifc_init_i1(); /* Initialize the interface */ l_ifc_connect_i1(); /* Connect driver to I/O pins */ l_sch_set_i1(sch_conflict_resolving, 0); /* start conflict resolving */ while (l_sch_tick_i1()!= 1) /* one round */ busy_wait_until_next_period(); l_sch_set_i1(normal_mode,0); The l_ifc_read_status_i1() function, among others, returns information on the wake_up signal received. This information is stored in bit 4 of the l_ifc_read_status_i1 returned value, so the L_WAKEUP_REQUEST symbolic macro is equal to the value 0x10. If this condition is true (the wake_up request has been received), the LIN interface is initialized and connected, and the conflict resolving schedule table is applied. After the conflict resolving phase, the LIN cluster switches to the normal running mode. Slave Node The situation on the slave side is exactly the opposite. To detect the goto_sleep request the l_ifc_read_status() function is utilized: if ((l_ifc_read_status_i1() & 0x0008)== L_SLEEP_REQUEST)... Information about the goto_sleep request is stored on bit 3 of the l_if_read_status_i1 returned value, so the L_SLEEP_REQUEST symbolic macro is equal to the value 0x08. System behavior after the goto_sleep request depends on the type of application. There are two possible ways to reduce the power consumption of the system. The LIN interface can be switched to the low power mode via its enable pin, and the system switchable voltage regulator can be turned off to completely shut down the MCU. The MCU can be switched to its wait or stop mode. To wake up the cluster from sleep mode, the slave should issue the following command: l_ifc_wakeup_i1(); The i1 is the interface name as was described in LIN Node Private File (page 9). Before the wake_up signal is transmitted, the slave LIN interface should be initialized and connected, and, according to the LIN specification, the LIN cluster should be in sleep mode. 14 Freescale Semiconductor

15 The system behavior after the wake_up signal is received depends on the status of the MCU. Application Example If the MCU was turned off via the system voltage regulator shut down, it can be turned on only via the voltage regulator power up. If the MCU was switched to the wait or stop mode, depending on the system configuration two scenarios are possible. If the LIN interface is not in low power mode, the MCU can be notified about the LIN bus activity via the SCI interrupt. If the LIN interface was previously switched to the low power mode, the MCU can be notified about the LIN bus activity via the IRQ interrupt. Application Example The example application 1 demonstrating the Freescale LIN 2.0 capability is based on the AN2573/D application note, which deals with the LINKits LIN evaluation boards (see Reference [7]). However, it has been adapted to meet the LIN 2.0 specification and to utilize the Volcano LIN Target Package (VCT LTP 2.0). As the VCT LTP 2.0 is strongly schedule oriented, the following feature of the application described in AN2573/D was not included. Multiple identical slave nodes are not supported, thus the slave application supports only one frame ID per slave MCU type (see Table 1). As multiple frames per node are not supported in the application, the frame IDs were slightly modified. New frame ID assignments, as well as the configured NAD, can be seen in Table 1: Table 1 The LIN Frame ID Slave (by MCU type) Frame ID Protected Frame ID Configured NAD EY16 0x20 0x20 0x40 QY4 0x18 0xD8 0x41 QL4 0x10 0x50 0x42 GR60A 0x28 0xA8 0x43 Key Features As the example application comes from AN2573, it is not described in detail here. Only the key features and changes are described in this section; it is recommended that the reader first study AN Example applications are based on the following LTP versions: LTP20_1_0_1 (for MC9S12C32), LTP20_1_1_1 (for MC68HC908GZ60), LTP20_1_4_0 (for MC68HC908EY16), LTP20_1_2_1 (for MC68HC908QY4) Freescale Semiconductor 15

16 Application Example Slave Node Application The example application comprises two parts. The first one is the slave application. With respect to the original application, the following changes were made. As multiple frames per slave node are not supported, the ReadButton() function has been modified and does not support long button press detection. For the same reason, the LedDisplay() and the LinResponse() have been modified. Now the LedDisplay() function displays only sent data, and the LinResponse() function works with only one assigned frame ID (shown in Table 1). The slave node application was unified as much as possible to allow easy migration to different MCUs. This is done through the board.h file, where all hardware dependent features are defined, such as the GPIO ports, where the switch and LEDs are connected, and the position of the LIN interface enable pin. The final two notable features are: Low power mode. The goto_sleep command reception is handled as is described in Low Power Mode, Shutting Down the LIN Communication (page 13). After the goto_sleep command is received, the voltage regulator is turned off and the MCU is shut down. The same sequence is processed when no LIN bus activity is detected for a period greater than four seconds. The on-run connection capability of the slave nodes. This is handled via the LIN 2.0 User Defined Diagnostics (page 13), using the frame transmitted at the end of the conflict_resolving schedule table 1. If the slave was reset or recently connected after a conflict_resolving schedule table pass, it responds to a master request (via the SlaveResponse frame), and this response causes the conflict_resolving schedule to be applied in the master node. Note, however, that this method works correctly only when one node is connected at a time; otherwise a LIN bus collision occurs. Master Node Application To meet the LIN 2.0 specification and fulfil the single frame ID per slave node concept, the master node application was modified more than the slave nodes. As the functions used to read the frame buffer contain the frame name (as described in Signal Naming Convention (page 12)), it is not possible to use one message buffer for all frames published by the master node. Key features of the master node application are: Detection of slave node no longer responding. This is handled via the l_ifc_read_status_i1() function, which, among others, contains the last frame protected identity (frame ID including the checksum) of the last detected and processed frame by the node, and the successfully transferred flag, which is set when the last processed frame was transferred without error 2. To enable subsequent actions, a list of active nodes is implemented in the master node application 3. If a slave node is lost, the LED strip is displayed and the relevant flag in the active node list is cleared. 1. The resolving_done signal in the resolving frame is used for this purpose. 2. It is necessary to keep in mind, that calling the l_ifc_read_status_i1() function without any frame transfer in between returns zero on the second call. 3. After reset, or before each schedule_resolving run, the active node list is set, so that the initial condition is that all slave nodes are connected to the cluster. 16 Freescale Semiconductor

17 Application Example New slave node connection detection. As described in Slave Node Application (page 16), the resolving_done signal in the resolving frame is used to inform the slave nodes that the conflict_resolving schedule table has completed. If a slave node does not receive this information (this node having been recently reset or powered-up), it responds to the SlaveResponse header. When the master receives this SlaveResponse, it sets the active node list for all nodes and reenters the conflict_resolving schedule table to assign frame IDs to the slave nodes. Low power mode. The LIN low power mode can be controlled also by the master node. If the switch on the LINKit master board is turned on, the master node sends the goto_sleep command to the LIN bus and the strip is displayed on the LEDs. To show information from the currently connected slave nodes on the LINKit master board LEDs, the real time interrupt (on S12 LINKits master board) or the time base module interrupt (on GZ60 LINKits master board) is used. Freescale Semiconductor 17

18 References References 1. LIN Specification Package, Revision 2.0, 23 September Private File Grammar Specification LIN 2.0 Implementation, Rev. C Volcano Communications Technologies, 14 October Test Report for LTP 2.0 HC908GZ60, Rev. A Volcano Communications Technologies, 15 October LTP Target Library Notes for HC908GZ60 Metrowerks CodeWarrior 2.1.1, Rev. C Volcano Communications Technologies, 16 October User s Guide for LTP 2.0, Rev. D Volcano Communications Technologies, 31 October LIN Specification Package, Revision 1.3, 12 December LINkits LIN Evaluation Boards, Freescale document number: AN LTP 2.0 Target Library Notes for MC9S12C32 Metrowerks CodeWarrior 2.0, Rev. C, Volcano Communications Technologies, 14 October Test Report for LTP 2.0 MC9S12C32, Rev. C Volcano Communications Technologies, 14 October LTP Target Library Notes for MC68HC908EY16 Metrowerks CodeWarrior 2.2.1, Rev. B Volcano Communications Technologies, 31 October Test Report for LTP 2.0 MC68HC908EY16, Rev. A Volcano Communications Technologies, 31 October LTP Target Library Notes for MC68HC908QY4 Metrowerks CodeWarrior 3.0, Rev. C Volcano Communications Technologies, 21 November Test Report for LTP 2.0 MC68HC908QY4, Rev. B Volcano Communications Technologies, 21 November Freescale Semiconductor

19 Acronyms Acronyms API CAN CFG ECU ID IDC ISR LCFG LIN LNA LTP MCU NAD PRV SBC SCI UART VCT Application Program Interface Controller Area Network Target Hardware Configuration File Electronic Control Unit Identifier Intelligent Distribution Control Interrupt Service Routine LIN Configuration Tools Local Interconnect Network LIN Network Architect LIN Target Package Microcontroller Unit Node Address for Diagnostic Private File System Basis Chip Serial Communications Interface Universal Asynchronous Receiver and Transmitter Volcano Communications Technologies Freescale Semiconductor 19

20 How to Reach Us: USA/Europe/Locations not listed: Freescale Semiconductor Literature Distribution P.O. Box 5405, Denver, Colorado or Japan: Freescale Semiconductor Japan Ltd. ARCO Tower 15F 1-8-1, Shimo-Meguro, Meguro-ku, Tokyo , Japan or Asia/Pacific: Freescale Semiconductor H.K. Ltd. 2 Dai King Street Tai Po Industrial Estate Tai Po, N.T. Hong Kong Learn More: For more information about Freescale Semiconductor products, please visit Information in this document is provided solely to enable system and software implementers to use Freescale Semiconductor products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits or integrated circuits based on the information in this document. Freescale Semiconductor reserves the right to make changes without further notice to any products herein. Freescale Semiconductor makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does Freescale Semiconductor assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. Typical parameters which may be provided in Freescale Semiconductor data sheets and/or specifications can and do vary in different applications and actual performance may vary over time. All operating parameters, including Typicals must be validated for each customer application by customer s technical experts. Freescale Semiconductor does not convey any license under its patent rights nor the rights of others. Freescale Semiconductor products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the Freescale Semiconductor product could create a situation where personal injury or death may occur. Should Buyer purchase or use Freescale Semiconductor products for any such unintended or unauthorized application, Buyer shall indemnify and hold Freescale Semiconductor and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that Freescale Semiconductor was negligent regarding the design or manufacture of the part. Freescale and the Freescale logo are trademarks of Freescale Semiconductor, Inc. CodeWarrior is a registered trademark of MetroWerks, Inc., a wholly owned subsidiary of Freescale Semiconductor, Inc. Metrowerks and the Metrowerks logo are registered trademarks of Metrowerks, Inc., a wholly owned subsidiary of Freescale Semiconductor, Inc. LNA, LINspector, and LTP are trademarks of Volcano Communications Technologies AB. All other product or service names are the property of their respective owners. Freescale Semiconductor, Inc AN2767 Rev. 0, 11/2004