3P's TCCS Disassembly/Analysis

[apath_e]

...Yet another random post having to do with this....

The Techtom / Mines "daughterboard" for the 7MGTE ecu appears to be nothing more than a board with a eprom socket, processor socket (the GOOD ones seem to have the processor crystal on the daughterboard itself), and a FPGA/CPLD programmable logic chip.

Like on the rom reader board, when the "CE" pin in enabled on the eprom, the logic chip switches the inputs/outputs to the eprom pins; whereas when the "CE" pin goes low, it switches those pins back to the ecu logic..

Pretty simple concept - "Technosquare" sells a empty "TOY-47" (I believe that is the part #) for the SDIP64 toyota processors..

Contacted them and got 2 prices....

Board with scramble logic chip (seems to just change the data pin order of the eprom) - $550 - NO EPROM, NO MAPS, NO NOTHING!!

Board with no-scramble logic chip - $850 - Once again, NO EPROM, NO MAPS

Seems to be a bit much for nothing!

And, the MR2 "Datalogger" appears to be nothing more than a PIC / Atmel microcontroller wired to certain I/O pins on the main processor using the PIC / Atmel A/D converters and UART to output that data to a PC

Some of the guys over at MAMEWorld, seem to have this type of mask rom type SDIP64 processor down pat....
I guess the guys over at Williams really liked these processors....
The mask rom can be directly dumped much like a eprom, just with a few hoops to jump through..

There are eprom writers (the $2000+ type) that can deal with this mask-rom setup by just dropping it into the reader

Somthing to do with timing on the I/E and /EN pins puts this type of processor into an actual "eprom" mode; clock stopped, no commands will execute, and rom acts just like a eprom...

I highly doubt my willem programmer will be able to handle this...

With the datasheet from the "knock" processor, and being able to easily dump that one, one source of attack on the mighty Denso could very well be emulating the knock controller... and seeing just what commands it will accept..

I have 2 raw 7MGTE processors, and 2 bench ecus ready for abuse...
After seeing this thread last night, I dug them out and dusted 'em off; since it really looks like everyone involved wants to come to the same end result without paying the $$$ these companies want for a 20-year old ecu!

3P, Brutus; mad props for getting down to the dirty with these!!

I've never had a car that I couldn't mod the ecu to my liking - I really don't want this to be the first!


Another random thought (sorry, i'm ADHD)

When I was doing my whole 240sx thing, there was a tuner out of OZ that created a FULLY, real-time programmable daughterboard (Google: BiKiRom) for the 240sx ecu - FULL consult (Nissan OE ecu protocol) datalogging, PC GUI software w/3d maps, real-time editing / updating, rev limiters, boost functions (for the SR20DET), and a whole lot more - FOR $350!!!

Now, only if the 7MGTE ecu actually produced an actual datastream, something like that could be possible.... I don't get why I can plug into a 85 Toyota pickup, and get a complete datastream, the MKII produces one too... but; lord forbid the MKIII could even think of one.... Not even with OEM Toyota scan tools, Launch X431, Mastertech, OTC Genisys, Snap-On Solus, Snap-On Modus..... I've tried EVERYTHING to get an actual datastream from the diagnostic port.... no luck.... For a "Supercar" like the MKIII supra, you would think a datastream would exist....

Enough babbling... off to work....

Attachment: Fujitsu datasheet for 42-pin "Denso" Ecu Processors

 

[3p141592654]

ap: For the reader board that Kashi designed, the EEPROM address 0000h maps to 8000h in the processor address space. Thus, the top of the EEPROM address 7FFFh maps to the processor FFFFh, and is where you would place the interrupt vectors.

By the way, the knock processor uses the same instruction set as the main processor, and is not an Intel 87c51. The main processor has some elements of the 6800 architecture, but the instruction sets are completely different and even the registers don't completely match. Also, I/O capabilities of the Denso part are much richer than what you can get on any 68xx chip of that era.

 

[3p141592654]

Technosquare sells the Techtom line. The CPLD in that board is no easy thing to duplicate. With the Denso MCU in external mode you lose ports A and B, and need to emulate them in external logic. That is what the CPLD chip does, and it requires some fairly intricate VHDL code to do it. The scrambling function is to protect Techtoms IP, although Jeremy Ross says it was simple to break. My guess would be a simple XOR cipher with a fixed key.

 

[jetjock]

6800, 8751....sorry, wrong on both counts.

"I've tried EVERYTHING to get an actual datastream from the diagnostic port"

I'm confused. Why would you try so hard to get data from a place it's obviously not present to begin with?
Yes, I know Vf is more than it appears to be but there's still nothing to be had from it's background signal.

Jon: I haven't forgotten. I'll get to it...

 

[nikwal]

the Denso MCU in external mode you lose ports A and B, and need to emulate them in external logic. That is what the CPLD chip does, and it requires some fairly intricate VHDL code to do it.

I guess the really hard part is figuring out exactly how that logic works.. VHDL is cool.. I've been reading a book:"VHDL for dummies" .But simple l74-alike logic seems easy to implement in a vhdl. I did play around a little with quartus pro4, one could select four modes as I remember: C, vhdl ,some other strange language and "simple" logic..

(ps. I had no luck in 7mgte ecu with either of the three pins, regardning the egr- :-( )

 

[nikwal]

It makes me wonder what else the ECU uses for EGR operation besides the resistor identifying different maps for use. Were you able to verify with a GTE ECU? It looks like nikwal didn't have much luck with it.

Could'nt spot any difference no, but some other person might have better luck (I measured the voltage out from the ecu to the vsv while revving the engine.. )

so if I understood the translated datasheet, address 0x0 to 0x2f becomes external through address/data? Does that mean that ALL registers 0-2f have to be simulated with external logic for example port c and the timer things an such? that would indeed need a kind of complicated program..

 

[3p141592654]

The I/O registers remain except for port A and B. Those ports get replaced by the address and data lines so there needs to be external logic to add back the port functionality (DDRA, DDRB, PORTA, PORTB, PORTAL). Everything else remains the same.

Due to the cooperation of an MR2 user, who is reversing the 2nd gen MR2 which is similar to the MKIV Supra ECU, we have some VHDL code coming together for the I/O extender. Should be testing it very shortly.

 

[Brutus]

Attachment: Fujitsu datasheet for 42-pin "Denso" Ecu Processors

Looks like you've put the wrong file as attachment.
This one will interest me, cause I have lots of 3SGE ECUs with that kind of processor as main CPU.

Can you post it again, please?

Regarding the 7MGTE ECUs, if someone is ready to provide one, I won't be able to send it back, because I will strip it from all its components to make route tracing easier.

 

[nikwal]

Having grown up with a little bit of assembler on the c64 and amiga500,although on the c64 and in school it was'nt really assembler but machine code typed in by data statements, 68000assembler is really quite interresting too but as I remember, there were some pretty freakish god damn ways of writing some commands..
, I pretty much cant resist looking at the code just for fun(I love this shit) the code is really pretty cool..
I was looking a bit at the code at fc10, map reading
I'll have to look at it again probably but at a first glance it looks like it searches for a level of acc:a at the address of y , then normalizes it at that point.

I have a question, was looking at fb62(some calculation(interpolation?????)) there it is two 16bit push'es. In what order does the lsb or msb end up on the stack?? I am just assuming that if pushing a 16bit to the stack it splits up and increases the sp by two?

thanxs /nw

 

[3p141592654]

FC10h is the start of a subroutine that computes y0 = func(x0) from table of (x,y) pairs and linearly interpolates between points.

The output is to 2 byte accuracy in the D register. The LSB of that register is the fractional representation of the interpolation normalized to 256 (i.e. rB/256). The MSB is the closest integer value of the interpolation. The table base address is stored in register Y. Register A is the input value of x0, and afterwards is the MSB of the interpolated result.

For values of x outside the map, the end values of the table are clamped.

This processor is Big Endian. If we push rD=1234h on the stack starting at 1BFh, we would get the following

[01BE]=12 <-SP at end of operation
[01BF]=34

Stack pointer points to the last byte written and is decreased. Usually it is placed at or near the top of RAM.


FB62h is another subroutine, this time a multi-byte multiplication of rD*rY with
the 2-word result stored in (rY, rD)
rY contains the most significant word
rD contains the least significant word

Note that this code is a fine example of production hand optimized code that is designed to be fast and to save code space. It is often near impossible to figure out what is going on without actually emulating the code.

 

[3p141592654]

I am sold out of reader boards! I would never have believed the interest would have been this high when I started, but that is the current status!

We will probably run more but not for while as a redesigned daughterboard would need to be completed first.

 

[rotor3]

I built a small tool that aids in scanning for 3D maps;

 

[bfr1992t]

Nice work! Certainly looks like the fuel map and the dip in the middle are the typical highway cruise cells. Any chance you can find the "breakpoints" for all three axis? Perhaps with a live ECU and simulating inputs?

Speaking of which, have any of you come up with a way to simulate the CPS?

 

[3p141592654]

Quite a bit going on behind the scenes here. Jon Sole, a UK MR2 owner has been working with me to move this project along. He has recently demonstrated his 3SGTE ECU working with external ROM using a bunch of technology recently developed:

1) Firmware (VHDL code) has been written for an FPGA chip to allow the Denso 64pin MCU to run in external mode using the code in EEPROM memory. This uses a 1st gen EPROM board I taped out about a year ago and has some issues, but he did drive to work without incident although getting home proved to be tougher . Another spin of this board is in progress.

2) Code for an ATMEL MCU has been written allowing diagnostic comm with the ECU and supports a USB interface to a PC. The PC app is very crude right now, but the basics are demonstrated; commands can be issued to read any memory value out during ECU operation. This ATMEL chip is being built in to the next EPROM board in design.

3) As part of the new board design, we are working on an architecture that will allow the ECU to run in RAM, thereby allowing real time tuning of the maps.

4) LordDigital on Supramania has agreed to send me his TechTom ECU so that I can read out the maps and figure out what Techtom really changes in the code. This will require descrambling the Techtom chip, but that is believed to be doable.

So stay tuned, this project is moving much faster than expected with many thanks to Jon Sole.

 

[rotor3]

Wow thats quite the update!

Another spin of this board is in progress.

What issues are you having? I'm not an EE by any means but since the chip is motorola based (right?).. couldnt you design an adapter for a motorola programmer? (ie: http://www.telwis.pl/product_info.php/products_id/71/language/en) ...or does it not work that way?

 

[3p141592654]

The main issue we have is that the CPLD I/O expander chip needs more than 100mA of current at startup, which is more than the ECU power supply can handle, causing it to shutdown the entire ECU. We are putting a separate 5V supply on the board so that the ECU power supply is not loaded.

Here is a picture of the ECU reader board, with the IO expander board plugged into it, and an ATMEL USB microprocessor connected to it. Software in the ATMEL allows a program running on a PC to interrogate the ECU RAM data. The PC interface is modern USB. I'll post up a short video showing how much data we can capture. Basically we can read 2 bytes of RAM every 4ms, or about 4kb/s. This is about the same data rate as OBD2, but this is more flexible because we can choose to read a fast changing variable such as RPM every 4ms. OBD2 doesn't let you pick and choose data to read and so it updates about every 200ms.

 

[3p141592654]

I've pulled the data from LordDigital's Techtom ECU. The data is encrypted (as we knew) but the encryption looks like it might be as simple as just scrambling the address lines. More to come on this one shortly.

 

[3p141592654]

Binaries for the Techtom scrambled ROM and for a 7M-GTE A/T gray plug ECU are on Assembla for anyone who wants to explore.

 

[3p141592654]

Jon Sole and I have descrambled the Techtom data and can now compare directly the differences between a Techtom ECU and the stock ECU. A quick glance shows that there is not a whole lot changed. I'll post up more data on this as we dig into the GTE code.

The scrambling techniques is pretty straightforward and only applied to the lowest 8 bits of the data address. The actual data is not scrambled. The address bits are first swapped around, and then XOR'd with a seed value, in this case AAh (which is probably different for each vendor).

Since I had both the original Toyota code, and the scrambled code I was able to hook the Techtom to my logic analyzer and watch the address and data fetches from the EEPROM as the ECU booted up. Comparing to the flow of the stock Toyota code it was possible to make an excel spreadsheet of scrambled addresses and matching stock addresses. Since the second address fetched after a reboot is FFFFh, we can exploit a so-called plaintext attack on the XOR cipher to get the XOR seed directly by XORing the scrambled and stock addresses together. Untangling the bit swaps is harder, but Jon Sole came up with a nice approach. For each address bit he found a pair of unscrambled addresses that differ by one bit, and then found the corresponding scrambled addresses with XOR pattern applied, doing an XOR of both address pairs gives the mapping.

To convert from Toyota ROM address to TechTom ROM address, first swap the bits (0->4, 1->2, 2->5, 3->1 etc) than apply XOR AAh. The descrambled rom is posted on Assembla. The swap table is below.

The value of for the XOR seed (AAh in this case) is likely to be vendor dependent. The swapped bits could also be vendor dependent, but with only one to look at we cannot tell.

Toyota TechTom Tech Tom
Address Address Reverse
Bit Scrambling Scrambling
0 4 5
1 2 3
2 5 1
3 1 7
4 6 0
5 0 2
6 7 4
7 3 6

The ECu on the operating table, and the resulting data capture on the analyzer

 

[3p141592654]

As far as I can tell, there is no "fuel map" per se. The ECU computes the VE of the engine from RPM and AFM, and applies some small temp corrections and fuel trims to compute the fuel duration. It does not need a large 3D table to do this, because the AFM provides enough data to do the job directly. There are also corrections for battery voltage and transient throttle events computed from the TPS.

I'm still exploring the code, so I may revise this later, but from what I know so far the above is correct.