
Initialization/Application Information
MC68HC908QL4  MC68HC908QL3  MC68HC908QL2 Data Sheet, Rev. 4
Freescale Semiconductor
157
checksum on the first data byte. Using CHKMOD in this way allows the SLIC to receive messages with 
either method of data consistency check and change on a frame-by-frame basis. If a system uses both 
types of data consistency checking methods, the software must simply change the setting of this bit based 
on the identifier of each message. If the network only uses one type of check, CHKMOD can be set as a 
constant value in the user’s code. If CHKMOD is not written on each frame, care must be taken not to 
accidentally modify the bit when writing the data length and TXGO bits. This is especially true if using C 
code without carefully inspecting the output of the compiler and assembler.
The control bits and data length code are contained in one register, allowing the user to maximize the 
efficiency of the identifier processing by writing a single byte value to indicate the nature of the message 
frame. This allows very efficient identifier processing code, which is important in a command frame, as 
the master node can be sending data immediately following the identifier byte which might be as little as 
one byte in length. The SLIC module uses a separate internal storage area for the incoming data bytes, 
so there is no danger of losing incoming data, but the user should spend as little time as possible within 
the ISR to ensure that the application or other ISRs are able to use the majority of the CPU bandwidth.
The identifier must be processed in a maximum of 2 byte times on the LIN bus to ensure that the ISR 
completes before the checksum would be received for the shortest possible message. This should be 
easily achievable, as the only operations required are to read SLCID and look up the checksum method, 
data length, and command/request state of that identifier, then write that value to the SLCDLC. This can 
be easily streamlined in code with a lookup table of identifiers and corresponding SLCDLC bytes.
NOTE
Once the ID is decoded for a message header and a length code written to 
SLCDLC, the SLIC is expecting that number of bytes to be received.  If the 
SLIC module doesn't receive the number of bytes indicated in the SLCDLC 
register, it will continue to look for data bytes.  If another message header 
begins, a byte framing error will trigger on the break symbol of that second 
message.   The second message will still properly generate an ID received 
interrupt, but the byte framing error prior to this is an indication to the 
application that the previous message was not properly handled and should 
be discarded.
14.9.8.2  Extended Command Message Frames
Handling of extended frames is very similar to handling of standard frames, providing that the length is 
less than or equal to 64 bytes. Because the SLIC module can only receive 8 bytes at a time, the receive 
buffer must be emptied periodically for long message frames. This is not standard LIN operation, and is 
likely only to be used for downloading calibration data or reprogramming FLASH devices in a factory or 
service facility, so the added steps required for processing are not as critical to performance. During these 
types of operations, the application code is likely very limited in scope and special adjustments can be 
made to compensate for added message processing time.
For extended command frames, the data length is still written one time at the time the identifier is 
decoded, along with the TXGO and CHKMOD bits. When this is done, a software counter must also be 
initialized to keep track of how many bytes are expected to be received in the message frame. The ISR 
completes, clearing the SLCF flag, and resumes application execution. The SLIC will generate an 
interrupt, if unmasked, after 8 bytes are received or an error is detected. At this interrupt, the SLCSV will 
indicate an error condition (in case of byte framing error, idle bus) or that the receive buffer is full. If the 
data is successfully received, the user must then empty the buffer by reading SLCD7-SLCD0 and then 
subtract 8 from the software byte count. When this software counter reaches 8 or fewer, the remaining