
TSS461C
13
Rev. D (22 Feb 01)
All the bits in the command field are automatically handled by the TSS461C, so the user need not to be concerned for
the encoding and decoding of these. The command bits transmitted on the VAN bus are calculated from the current
status of the active message.
After the command field comes the data field. This is just a sequence of bytes transmitted MSB first. In the VAN
standard the maximum message length is set to 28 bytes, but the TSS461C handles messages up to 30 bytes.
The next field is the FCS field. This field is a 15 bit CRC checksum defined by the following generator polynomial
g(x) of order 15:
g(x) = x
15
+x
11
+x
10
+x
9
+x
8
+x
7
+x
4
+x
3
+x
2
+1
The division is done with a rest initialized to 0x7FFF, and an inversion of the CRC bits is performed before
transmission.
However, since the CRC is calculated automatically from the identifier, command and data fields by the TSS461C,
it need not concern the user of the circuit. When the frame check sequence has been transmitted, the transmitting
module must transmit an End Of Data (EOD) sequence, followed by the ACKnowledge field (ACK) and the End Of
Frame sequence (EOF) to terminate the transfer.
VAN BUS
SEQUENCE
VAN BUS
SEQUENCE
NUMBER OF
PRESCALED
CLOCKS
POSITIVE ACKNOWLEDGE
ABSENT ACKNOWLEDGE
0
8
16
24
32
Figure 12. Acknowledge Sequences.
7.3. Frame Examples
The frames transmitted on the VAN bus are generated by several modules, each supplying different parts of the
message. Figure 13. through Figure 16. show the four frame types specified in the VAN standard, and what module
is generating the different fields.
The most straightforward frame is the normal data frame in Figure 13. Like all other frames it is initiated with a
SOF sequence. This sequence is generated by a bus master (not shown in figure).
During this frame there is basically only one module transmitting with the only exception beeing the
acknowledgement, generated by the receiving module if requested in the RAK bit.
The reply request frame with immediate reply in Figure 14. is the only frame in which a slave module can transmit
data by filling it into the appropriate field.
The only difference for the frame on the bus is that the R/W bit has changed state compared to the normal frame.
This is a higly interactive frame where a bus master generates the SOF and the initiator generates the identifier,
the three first bits of the command, and the acknowledge. The RTR bit, the data field, the frame check, the EOD
and the EOF are all generated by the replying module.
The reply request frame with deferred reply in Figure 15. is basically the same frame as the reply request frame
with immediate reply, but since the requested module does not generate the RTR bit the requesting module will
continue with the frame check, the EOD and the EOF.
During this frame the requested module will only generate the acknowledge, and only if this was requested by the
initiator through the RAK bit.
Finally the deferred reply frame in Figure 16. which is sent when a module has prepared a reply for a reply request
that has been received earlier.
This frame very closely mimicks the normal data frame with the only exception beeing the R/W bit that has changed
state.