+ Reply to Thread
Page 1 of 67 123451151 ... LastLast
Results 1 to 10 of 661

Thread: 3P's TCCS Disassembly/Analysis

  1. #1
    90T
    3p141592654's Avatar
    Join Date
    Oct 2005
    Location
    Thousand Oaks, CA
    Posts
    3,165

    Default 3P's TCCS Disassembly/Analysis

    It's remarkable that after nearly 20 years the Toyota Computer Control System (TCCS) engine management computer used for the 7M remains a mystery as far as the public domain is concerned. Partly, this is because it uses a proprietary Denso microprocessor with zero official documentation available outside of Toyota, and also because the 12kB of ROM code is burned into the microprocessor itself making extraction a major effort, and also preventing any code changes without adding a complex daughter board to allow the processor to run with external memory.

    Although several commercial companies cracked it (Techtom, Mines) they kept everything secret and in the case of Techtom even went as far as to encrypt their own code to discourage reverse engineering.

    One Japanese site run by H. Kashima has published significant information on the microprocessor architecture, including schematic and layout of a nice board to read the code burned into the microprocessor. He also developed a disassembler for the processor, and has put together a datasheet for the chip pinout, register and memory structure, and so on. Probably because it is written in Japanese, and also because Kashi decided to sell his disassembler and processor datasheet rather than make them public domain, not too many have taken advantage of his hard work in this area.

    Recently, Jeremy Ross a guy who hangs out on the UK MR2 forum IMOCUK, has developed a very nice daughter board and software to allow real time data logging and updating of the code tables in the MR2 Gen 1 and 2 ECUs, which are essentially identical to the 7M ECUs of the same vintage. However, Jeremy keeps most of his info to himself, and obviously has plans to sell his ECU kits, so once again nothing gets disclosed publicly.

    Against this backdrop of secrecy, there is one glimmer of hope, which is a Canadian based Toyota ECU Wiki. Although not exactly a hotbed of activity, it does have some of Kashi’s stuff translated to English, and also a public domain disassembler for the micro written in Perl.

    So, the purpose of this thread will be to read out and analyze the code embedded in these ECUs, and to analyze and publish the various fuel/ignition maps and algorithms used by the 7M ECU.

    Acknowledgements:
    A couple of people on the forums have helped me out by donating ECUs, and or getting them to me at way below market value.

    S383mmber1 (William) gave me a 7MGE M/T ECU. This is an early ECU with only a single circuit board inside. As such, it is probably the best place to start as it is the simplest to analyze.

    Supraholics (Miguel) sent me two ECUs including a grey plug 7MGTE M/T ECU for shipping only. This is going to be my first mule for testing things out.
    Last edited by 3p141592654; June 2nd, 2008 at 06:44 PM.

  2. #2
    90T
    3p141592654's Avatar
    Join Date
    Oct 2005
    Location
    Thousand Oaks, CA
    Posts
    3,165

    Default Re: 3P's TCCS Disassembly/Analysis

    Okay, we start with Williams 7M-GE M/T ECU. First step was to build the ECU reader, which closely follows the one published by Kashi.

    I swapped a few components that I couldn't find here in the U.S., but otherwise it is the same. The schematic is attached as a thumbnail to this post. I had about 6 reader printed circuit boards fabricated, so anyone interested can buy one from me.

    The reader board uses its own code burned into the 28C256 EEPROM on the board to run the microprocessor. It works by running the micro in a hybrid mode, where it can access both internal and external memory at the same time. A simple serial port interface connects to hyperterminal on a windows PC, and the code is dumped out on the terminal where it can be saved to a file. Kashi supplies a crippled demo copy of the assembly code he used to extract the ECU ROM. With an evening's work tracing his code, it turns out a simple change to one line of demo code is all that is needed to allow the extraction of the entire 12kB stored in the ROM.

    Once the code is out, you can run a disassembler to convert it to assembler. Then comes the real challenge, interpreting the assembler to understand how the code controls the engine, discovering and analyzing the built-in maps, and learning how the various engine sensors and controls interface to the micro.

    By the way, Jeremy Ross has discovered a high-speed data-logging feature hidden in the code that Toyota used during development. Every variable in the system can be read out up to 200 times a second with 16 bit accuracy. Explaining how to access this datalogger will be one of the first things tackled in this thread.

    Below find a photo of the ECU reader board assembled and loaded with the target ECU, a D151801-3920 from William's ECU. Also, a schematic of the reader board, and hopefully the extracted binary code if I can figure out how to attach it to this post.




    Attached Files Attached Files

  3. #3
    90T
    3p141592654's Avatar
    Join Date
    Oct 2005
    Location
    Thousand Oaks, CA
    Posts
    3,165

    Default Re: 3P's TCCS Disassembly/Analysis

    It's a good question, and ultimately depends on how much time I can spend doing this.

    First priority is to disseminate info on how these ECUs calculate engine operating parameters, and to publish the 7M ignition/fuel maps.

    I already have a daughter board fabricated that will allow me to run the processor from code in an external EEPROM. This allows things like fuel-cut, AFM scaling, ignition maps and so on to be modified. But the process is clunky, you need to FLASH and swap the memory chip to make any changes. Its basically what Mines and Techtom offered back in the day.

    Ultimately, I would like to go down the path of Jeremy Ross and work out a way to do real time changes to the maps. That will take some effort as you need to run the code in RAM, and write the software to do datalogging and map tweaking from a laptop. It's my goal, but it's a ways off right now.

    I have little interest in making a business out of any of this. I have a real job so I see this as more of a hobby. Some things I may decide to sell if there is interest, such as pcb boards as they can be expensive and time consuming to have fabricated and I have a bunch of extras sitting around.

  4. #4
    Lurker
    Brutus's Avatar
    Join Date
    Jun 2008
    Location
    Vosgian mountains, France
    Posts
    32

    Default Re: 3P's TCCS Disassembly/Analysis

    Hello,

    First of all 3p141592654, thanks a lot for releasing this binary file.
    This is a great job you've done extracting it!

    The file is 12Ko and doesn't cover the whole 64Ko address space.
    If I read the address map on the Toyota wiki (thanks to Greg Kunyavsky for this), it tells us about the D151801 memory map that there's 12ko of ROM memory.

    I dissasembled the file using the Perl program (written by Greg Kunyavsky again).
    Seeing the addresses started at 0x0000, I decided to make it start at 0xE000, which is the starting address of the ROM inside the CPU.
    This file is attached to this post.

    If we take a look at the memory map again, we can see that the reset vector is stored at 0xFFFE.
    The reset vector is used when the chip is powered on or reset to lead the CPU to the beginning of the program.
    This 16bit address leads us to 0xF053

    I have to get used to this processor mnemonics but if read the first instructions at 0xF053 while looking at the memory map at the same time:

    ld #0x7, $0x1F // Sets the five least significant bit of the SMR register to 1
    di // Disable interrupts
    ld #0xD, $0x20 // inits the timer comparison LSB with the port A data (?)
    ld #0xF, $0x0 // inits the timer comparison #3 with the port A direction status (?)
    ld #0x40, $0x22// Sets the first byte of the RAM with the port B data
    ld #0xFF, $0x1 // Sets the last byte of the RAM with the port B direction status


    I still don't know the exact purpose of these inits, but looking at this, we can see that these instructions are matching correctly and that this looks like what the begining of a program in assembly often looks like.
    By the way, if we try to take a look at the instructions before 0xF053, we see no logic at all from one instruction to another, which leads me into thinking this is some data space that is used for ignition, fuel map or whatever.

    3p141592654, if you still have one of these TCCS reader PCB, I would be glad to buy one (or even better, two of them since my soldering skills are average, to say the least).
    Attached Files Attached Files
    Last edited by Brutus; June 17th, 2008 at 05:32 PM.

  5. #5
    90T
    3p141592654's Avatar
    Join Date
    Oct 2005
    Location
    Thousand Oaks, CA
    Posts
    3,165

    Default Re: 3P's TCCS Disassembly/Analysis

    Good work Brutus, nice to know I'm not the only one with some disassembler skills. A much delayed tapeout for a IC amplifier project I am working on plus last week spent in Atlanta at the IEEE microwave symposium is keeping me from pursuing this project lately, but I will pick it back up in a few weeks.

    I have slightly different interpretation of the start code, using some of the data I know about the lower bytes of the CPU (my addressing is off, as you noted, but easily fixed-up).

    Note that #0x07 means load immediate, so for the first instruction $_OMODE=0x07 rather than a memory reference i.e. it is not $_OMODE=[0x07]

    Also note, that for no good reason the operands are swapped for immediate loads. All other "load" instructions are op.1=op.2, so that is probably why you got confused. This inconsistency is a quirk carried over from the Motorola 6800 assembler, proving bad ideas never die I guess!

    ; reset vector
    002053 33071f ld #0x07, $_OMODE ; run internal mode
    002056 05 di ; disable interrupts
    002057 330d20 ld #0x0d, $_PORTA ; set port A o/p bits
    00205a 330f00 ld #0x0f, $_DDRA ; configure i/p bits Port A
    00205d 334022 ld #0x40, $_PORTB ; set port B o/p bits
    002060 33ff01 ld #0xff, $_DDRB ; configure i/p bits Port B


    I'm still struggling to get IDA running right, but that will help alot compared to trying to do this with a simple disassembler. I also need to better understand the mapping of the ports, timers, edge sensors, and so on to the actual engine sensors/actuators. That takes a lot of circuit tracing on the ECU board, and is very painful.

    I have extra boards, and I think I have extra parts as well if you want to buy a kit.
    Last edited by 3p141592654; June 20th, 2008 at 07:22 PM.

  6. #6
    Grumpy Old Man
    IJ.'s Avatar
    Join Date
    Mar 2005
    Location
    I come from a land down under
    Posts
    39,349

    Default Re: 3P's TCCS Disassembly/Analysis

    3P: Will you have any way of writing to the ECU?

  7. #7
    90T
    3p141592654's Avatar
    Join Date
    Oct 2005
    Location
    Thousand Oaks, CA
    Posts
    3,165

    Default Re: 3P's TCCS Disassembly/Analysis

    Ian, as it stands we are just pulling apart the code and learning how things work. We need to isolate the maps and figure out the algorithms they use before we can move to the next step of plotting the maps and deciding what to change.

    I have a very simple board made that can be used to run new code stored in an EEPROM, and bypass the stuff burned into the factory ECU. That would allow changes to be made, but its not very practical to tune this way since you have to physically swap the EEPROM each time. I also want to get access to the ECU real time data so that we can start doing logging. The logging software is all still there, just need to add the interface to a laptop like others have done fro the MR2.

    Longer term I want to be able to run the code in RAM so that changes to the maps can be done via lap top interface. That's still way off in the future for now.

    Shaeff, thanks for the offer. Right now I'm more time limited than $ limited, but I appreciate your offer and those from a few others as well. This is a great community.

  8. #8
    Grumpy Old Man
    IJ.'s Avatar
    Join Date
    Mar 2005
    Location
    I come from a land down under
    Posts
    39,349

    Default Re: 3P's TCCS Disassembly/Analysis

    3P: Much respect very very cool stuff
    (I bet you have a hat with a propellor on it somewhere)

  9. #9
    creepy-ass cracka
    jetjock's Avatar
    Join Date
    Jul 2005
    Location
    Redacted per Title 18 USC Section 798
    Posts
    9,121
    Blog Entries
    2

    Default Re: 3P's TCCS Disassembly/Analysis

    Interesting stuff Jon. Even though I've been there using a different approach (MDS system) I'll be watching

  10. #10
    Lurker
    Brutus's Avatar
    Join Date
    Jun 2008
    Location
    Vosgian mountains, France
    Posts
    32

    Thumbs up Re: 3P's TCCS Disassembly/Analysis

    Quote Originally Posted by 3p141592654 View Post
    Note that #0x07 means load immediate, so for the first instruction $_OMODE=0x07 rather than a memory reference i.e. it is not $_OMODE=[0x07]

    Also note, that for no good reason the operands are swapped for immediate loads. All other "load" instructions are op.1=op.2, so that is probably why you got confused. This inconsistency is a quirk carried over from the Motorola 6800 assembler, proving bad ideas never die I guess!
    Thanks for correcting about this opcode (I think you meant #0x33), the code looks muuuuuuuuuuch more logic now!

    Quote Originally Posted by 3p141592654 View Post
    I'm still struggling to get IDA running right, but that will help alot compared to trying to do this with a simple disassembler.
    I've never used IDA before. I will try to use it if understanding the program gets too tough.

    Quote Originally Posted by 3p141592654 View Post
    I also need to better understand the mapping of the ports, timers, edge sensors, and so on to the actual engine sensors/actuators. That takes a lot of circuit tracing on the ECU board, and is very painful.
    I've done a lot of work on 42pins D151801 ECUs regarding circuit tracing, including the decoding of the AD converter signals that are sent to the main processor. I have also had run these ECUs running out of the car.
    I confirm circuit tracing is a painful job, almost impossible without removing all the components of the ECU.
    I'm sure I can be of good help regarding this, since I can now recognize some components and figure out their use in many old style Toyota ECUs quite fast.

    All analog sensors go to the ADC, and are sent to the CPU via two lines.
    Digital sensors go to the CPU via a voltage converter/protecting (vertical) IC.
    The actuators (all digital), are sent from the CPU to an amplifying IC (set of Darlington Transistors).
    The injectors have their own triggering IC, which is fed by the CPU via less lines than injectors.

    I don't know really for the ignition, as the ECU I worked on used only one ignition coil.

    I will bring home a 7MGTE ECU next week-end to look at this.

    Quote Originally Posted by 3p141592654 View Post
    I have extra boards, and I think I have extra parts as well if you want to buy a kit.
    Great!
    If you get the hand on those parts, this will save me the time to buy them.
    Just PM me your paypal account if you have one and the price you want for this, keeping in mind the postage price to France.

    I will post my findings when I get some.
    Last edited by Brutus; June 23rd, 2008 at 02:45 PM.

+ Reply to Thread
Page 1 of 67 123451151 ... LastLast

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
Links monetized by VigLink