Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: TD5 OBD2 Reversing

  1. #1
    Join Date
    Jun 2015
    Location
    Darwin, NT
    Posts
    58
    Total Downloaded
    0

    TD5 OBD2 Reversing

    Hi guys,
    Been doing some homework recently on the TD5 and its OBD functionality.

    I am aware that the TD5 uses non-standard calls, but I am wondering if anyone has seen or done any work on reverse engineering this?
    I want to hook up my laptop and display and log live data. I know that Lynx is available and various other tools, but I am looking to write more functionality into what I display and log with my own sofware. There is alot of OBD and CAN hardware available to sniff this information and fairly cheap.

    Looking back on a few threads - OffTrack seemed to be on the right track and did some extensive work. I have also found a few other pages on the net, but they are more targetting fuel map changing etc.

    I am a PC engineer by day, but just want to know if I am going down a rabbit hole with a dead-end or if anyone else would be keen to give it a shot as well?

    Cheers,
    DFender

  2. #2
    Join Date
    Feb 2011
    Location
    Brunswick, Victoria
    Posts
    3,778
    Total Downloaded
    0
    It's certainly possible and has been done by a few people.

    The Td5 uses a ISO14230 protocol, so the documentation for that gets you a long way down the path. ISO14230 defines the communication and the framework which supports the manufacturer specific requests. The manufacturer specific information is not documented.

    The biggest issue is the security key and response needed to access the diagnostics. You can establish a connection to the ECU without this key and response but you can't access anything useful.

    What I've ended up with is a mess of PIC32 C code that interfaces with the ECU using a L9637 driver chip. I've used a Fubarino SD development board, but have blown away the Arduino firmware and use it as a bare metal PIC32. I've also had a small piggyback pcb made - it needs revising as there were a load of mistakes - which carries a small display, switch, L9637 chip, regulator, and a K-type thermocouple interface. The thermocouple chip used was a bad choice as it needs cold junction compensation done in software. I'll pick something else for the next revision.

    At this stage the comms and logging are pretty robust. It took a while to get there as running code on the bench and in the vehicle are quite different.

    I had bugs where the code was running fine on the bench but would stop communicating intermittently in the D2. I eventually tracked it down to the occasional message that had a checksum didn't match the contents. It looked like one byte was getting corrupted during transmission. Once I found that I realised the code wasn't handling failed checksums properly. It was verifying the checksum but basically aborting when a checksum failed so altering the behaviour to resend the request fixed the issue.

    Basically the closer you follow the error handling and timing from ISO14230 the more robust the comms. The Td5 appears to follow the draft standard from 1997/8 rather than the offical 1999 version.

    The ECU doesn't seem to care too much about interbyte timing that is specified in the standard, and doesn't check for it in the code. I've tried it with and without the 5ms space between bytes when sending and it doesn't really make any appreciable difference. I think the theory is it reduces the workload on the ECU when running.

    cheers
    Paul

  3. #3
    Join Date
    Jun 2015
    Location
    Darwin, NT
    Posts
    58
    Total Downloaded
    0
    Unreal information OffTrack. Was almost starting to give up thinking no one was interested in this sort of stuff!

    Have shot you a PM!

  4. #4
    Join Date
    Oct 2011
    Location
    Fremantle WA
    Posts
    3,742
    Total Downloaded
    0
    HI Paul and welcome back - you have been missed! Cheers
    MY16 D4 TDV6 - with a little Cambo magic for towing "The Brick"
    MY95 RRC LSE Vogue Softdash "Bessie" (turning circle comparable to QE II) with MY99 TD5 and 4HP24 transplants. Back home Nov 22 after a magic overhaul by Chivalry
    SADLY SOLD MY04 D2a TD5 auto Classic and MY10 D4 2.7 both with lots of goodies

  5. #5
    Join Date
    May 2003
    Location
    On The Road
    Posts
    29,829
    Total Downloaded
    0
    Welcome back Paul
    "How long since you've visited The Good Oil?"

    '93 V8 Rossi
    '97 to '07. sold.
    '01 V8 D2
    '06 to 10. written off.
    '03 4.6 V8 HSE D2a with Tornado ECM
    '10 to '21
    '16.5 RRS SDV8
    '21 to Infinity and Beyond!


    1988 Isuzu Bus. V10 15L NA Diesel
    Home is where you park it..

    [IMG][/IMG]

  6. #6
    Join Date
    Feb 2011
    Location
    Brunswick, Victoria
    Posts
    3,778
    Total Downloaded
    0
    Thanks for the welcomes

    ISO14230 - the fundamentals

    Note: everything you need to understand the protocol is in parts 2 & 3 of the ISO14230 documentation. Googling for 14230-2 and 14230-3 will turn up something useful. The Swedish (SSF) versions of the standard are freely available but not quite as good as the 1996 draft ISO standards.

    The documentation is a bit daunting so hopeful these posts will shed a little light on how it applies in the real world.


    This is really low level but it's really essential if you are going to build an app from scratch rather than "Monkey See, Monkey Do" with a sniffer.

    This information is covered in detail in Part 2 of the standard.

    Each message sent over the protocol is wrapped in a header of variable length, and followed by a checksum.



    The Fmt byte is included in every message, while the Tgt, Src, Len bytes depend on the message format - specified by fmt.

    FMT is a single byte, divided into 2 sections: 2 bits for address and the remaining 6 bits for length.



    The address bits describe the addressing mode used in the message and the length give the number of data bytes - that is excluding the header and checksum.

    For the initial message to the ECU the tester uses physical addressing mode.

    To make this a little more meaningful the address bytes are bits 7 and 6 of a byte. I've highlighted the 8 bits on the calculator, and with physical mode, and none of the length bits set the FMT header the has a hex value of 0x80.



    In practice you never have a zero length message, but under some conditions the length bits are set to zero.

    This screen capture shows the functional addressed message from the tester to td5 ECU.
    This is done with the standards compliant 5ms (actually slightly under) interbyte timing I mentioned in the previous post.



    You can see the fmt byte in this message is set to 0x81.

    Looking at how this maps out in terms of bits you can see that the two address bits are set to 10, and the length bits are set to 000001.



    The length header tells us that this message has a single SID or data byte.
    Note that the logic analyser capture above shows a complete message with five bytes in total.

    Referring back to the first image we see that the final byte is always a checksum which is the sum of all the non-checksum bytes.
    Ion this example it is the sum of 0x81 + 0x13 + 0xF9 + 0x81.

    Fire up a hex calculator and add them together and you get 0x20E while the checksum is 0x0E.
    The checksum uses only the lowest byte of the sum - this is known as a Modulo 256 checksum.

    Next post I'll cover the address bytes in a bit more detail.
    Attached Images Attached Images

  7. #7
    Join Date
    Feb 2011
    Location
    Brunswick, Victoria
    Posts
    3,778
    Total Downloaded
    0
    Continued...

    The address bits 0x80 indicate at the message includes TarGeT and SouRCe addresses. The Target Address is the recipient of the message and the Source Address is that of the sender. As illustrated in the first image in the previous post the FMT byte is followed by the TGT then SRC bytes.

    Breaking the logic analyser capture from previous down, we have:
    FMT: 0x81 ; indicates address mode and length.
    TGT: 0x13 ; target address for the Td5 ECU
    SRC: 0xF9 ; tester address which can be in a small range for general diagnostics
    DATA: 0x81
    CKSUM: 0x0E ; lowest 8 bits of 16 bit checksum aka Modulo 256

    So what does this all mean?
    The first data byte is always a Service ID or SID.
    The SID 0x81 corresponds with a startCommunications Request and the format for a message of this type is defined as:
    FMT 0x81
    TGT xx
    SRC xx
    DATA/SID: 0x81
    CKSUM xx

    I've cheated slightly as the startCommunications Resquest must be preceded by either a fast or 5 baud initialisation that wakes the ECU for communication.



    To perform the fast initialisation the diagnostic line is held line idle state - which is high// battery volt - for time Tidle.
    This is required to be at least 300ms after the ECU starts up.
    Then the diagnostic line is brought low for TiniL (25ms +/- 1ms), then high for 25ms +/-1 ms before the startCommunications Request message is sent.

    This is capture illustrates the fast init 25ms low 25ms high sequence followed by startCommunications Request and the startCommunications Response from the ECU.



    The startComms Request is same as previous post.

    The startComms Response shows some interesting details...


    The FMT byte in the ECU response is 0x03indicating that the address mode is now 0 0, or "no address information", and the message length is 3 bytes.



    This indicates the message does not use the TGT and SRC addresses in the message header.
    The format for the response message is:
    FMT byte
    startCommunications Positive Response Service Id
    KeyByte 1
    KeyByte 2
    Checksum

    Positive response service ID's are always the Service Request Id + 0x40. for e.g. 0x81 + 0x41 = 0xC1.

    The key bytes serve to define the protocol to be used for following communications.
    Table 5 of Part 2 of the ISO14230 has the complete breakdown of possible combinations.

    0x8F 0x57 indicates that messages will use a 1 byte FMT header with an optional additional length byte.
    This defines how all diagnostic communications in this session should be formatted.

    The additional length byte is used when the message is 64 bytes or longer. This is required because the largest number that can be represented by the 6 bits of the length portion of the FMT is 63. If the message is longer than 63 bytes the length bits of the FMT header are set to , so a "no address information" mode message with more than 63bytes will have a FMT header of 0x00.
    Attached Images Attached Images

  8. #8
    Join Date
    Feb 2004
    Location
    Williams West Aust
    Posts
    20,998
    Total Downloaded
    0
    Hi Paul.
    Great to see you have returned.
    There will be a lot of D2 owners that would appreciate "The D2 Brainstrust" being back online.
    ENJOY
    Andrew
    DISCOVERY IS TO BE DISOWNED
    Midlife Crisis.Im going to get stuck into mine early and ENJOY it.
    Snow White MY14 TDV6 D4
    Alotta Fagina MY14 CAT 12M Motor Grader
    2003 Stacer 525 Sea Master Sport
    I made the 1 millionth AULRO post

  9. #9
    Join Date
    Jun 2015
    Location
    Darwin, NT
    Posts
    58
    Total Downloaded
    0
    Haven't been on in a few days Paul. Thanks very much for your posts - really good information to start with. Will spend some time really going over it.

    Cheers

  10. #10
    Join Date
    Aug 2016
    Location
    Queensland
    Posts
    116
    Total Downloaded
    0
    Hmmm.... From reading these very detailed posts I'm getting the impression that my naive hope that a cheap odb reader with wifi and a iOS app are not going to be much use when it arrives in the mail.

    I'm mainly interested in reading live data to ensure while towing that all is ok... I will await my mail and your posts to see how we go.

    Good luck to you in your endeavours to grapple with this.

Page 1 of 2 12 LastLast

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search AULRO.com ONLY!
Search All the Web!