Diagnostic interface CDIF/1

PROTOCOL DESCRIPTION

8 October 2002

Version 1.0.00

Draft under construction

© 2002, Sebcio Łastowski, Gdańsk, PL

http://xmv6.mud.pl

I . Physical connection

All the data between CDIF and computer are transmitted by RS232 standard serial link using 9600 8N1 format. No flow control is used. CDIF have 8 bytes of transmit buffer and 8 bytes of receive buffer.

II. Protocol basics

Communication is done by simple “command-response” method. Generally all of the communication is done by this way except of asynchronous responses.

II. 1 – Command structure

              Commands are used to perform some defined tasks by CDIF, for example measuring voltage on active input or reading fault codes. They’re sent from computer to CDIF and have following format:

              [commandbyte] – for commands without parameters

                            Example:

                                          [00h] – Abort & Go Ready

              [commandbyte][parameterbyte1]… – for any other commands

                            Example:

                                          [40h][00h] – Set Active Analog Input (set Vbatt input)

II. 2 – Response structure

              Responses are sent back to the computer. In most cases they are the statuses of operation performed in response to last sent command but they may also contain data like measured voltages, waveforms etc. Responses have following structure:

              [commandbyte][statusbyte] – for dataless responses

                            Example:

                                          [00h][00h] – Abort & Go Ready, status OK

              [commandbyte][statusbyte][databyte1]… - for responses containing data

                            Example:

[41h][00h][00h][C2h] – Read Active Analog Input, status OK, input Vbatt, voltage 12V

              NOTE – [commandbyte] defines to which command CDIF answers.

II. 3 – Asynchronous response structure

              Asynchronous responses are not associated with specific commands but they are sent in response to some events like buttons, condition occurences or notifications. They are always one byte long and they hexadecimal values starts from F0h.

                            Example:

                                          [F1h] – “F2” Button Pressed

II. 4 – Communication example

              Assume that we want to measure battery voltage. Battery voltage is measured with no need to use any other cable than cable that powers CDIF. Battery voltage is internally connected to input “0” of A/D section of A/D/A converter.

              First, we have to select input that we want to set for measurement. From four inputs (or channels), first is connected to the supply of CDIF and measures battery voltage, last three are accessible at MDS socket. Let’s do it:

              Command >                            [40h][00h] Set Active Analog Input to input 00h (Vbatt)

              Answer>                            [40h][00h] Set Active Analog Input, status OK

              After selection of active analog input all we have to do is to measure voltage on active analog input:

              Command>                            [41h] Read Active Analog Input

Answer>              [41h][00h][00h][C2h] Read Active Analog Input, status OK, voltage at input 00h (Vbatt) is 12V (C2h)

II. 5 – Statuses

              Every answer have status byte which tells how execution of command passed. It is important to know that if command will be incorrectly used answer may be sent before computer finish sending data, especially with long commands. In this case parameters sent after CDIF response may be understood as commands and CDIF behavior bay be unpredictable. So it is to developer that communication handler will be written with care.

              Example of such condition is presented below:

Command>              [67h][00h][00h][00h][05h] Generate PWM on LO Output with tON=0ms, tOFF=0.5ms

Response>              [67h][03h] Generate PWM on LO Output, status Parameter Out of Range

              Response>                            [00h][00h] Abort & Go Ready, status OK

              Response>                            [05h][00h] Request Finish Notification for TBO, status OK

              In this case user sends to the CDIF command 67h with incorrect parameter – both parameters must not be zero so after third byte CDIF responses with “Parameter Out of Range” status and goes back into idle mode. Fourth and fifth bytes are received into buffer and then interpreted as commands (in this context) – in turn command 00h and command 05h.

II. 5.1 – OK [00h]

              This status byte indicates that execution of command has passed correctly.

II. 5.2 – Error [01h]

              This status byte indicates that an error occurred during command execution.

II. 5.3 – Not Implemented [02h]

              This status byte is sent in response to unknown or not implemented command.

II. 5.4 – Parameter Out of Range [03h]

This status byte is sent in response to command of which at least one parameters is incorrect.

II. 5.5 – Busy [04h]

              This status byte is sent in response to command which execution cannot be done because internal resources needed for command execution are busy.

II. 5.6 – Execution In Progress [05h]

              Not implemented yet.

II. 5.7 – Timed Out [06h]

              This status byte is sent in response to command that has been timed out, for example when reading fault codes and diagnosed  ECU didn’t responded in correct time.

II. 5.8 – No Background Operation [07h]

              This status byte is sent in response to command that requested Timed Background Operation (TBO) status or command Set TBO Finish Notify Flag [05h].