3P's TCCS Disassembly/Analysis

[3p141592654]

Henri,

Looks like you've had a productive weekend!

I will do a little detective work on the 8C opcode. Just from poking around it would seem that it appears correct, i.e. not inconsistent with adjacent opcodes.

Consider

7C PULL A
8C Comparison x – #
9C Comparison x – M[op.2]
AC Comparison x – M[x/y + #]

also
7D Pull B
8D Comparison y – #
9D Comparison y – M[op.2]
AD Comparison y – M[x/y + #]

One thought that has bothered me for some time is that given code and data are mixed randomly in the ROM, it is possible that the disassembler could get out of sync with the actual code, since it treats everything including data as code.

This is one reason I am working on getting IDA running, as it is smart enough to follow the execution sequence, and allows data to be blocked out interactively as well.

 

[3p141592654]

Played around a bit with the code and it can be reinterpreted using a different starting address, for example,

00f6e8 a935 cmp d, x + 0x35
00f6ea 59 cmpz b
00f6eb 018c77 jsr 0x8c77
00f6ee 73 reti
00f6ef 400a bra 0x26fb
00f6f1 7573 clrb bit3, $_ASR0NL
00f6f3 72a9 clr $0xa9

but that looks even more illogical. I will run a few test codes on the extracted processor to see if I can confirm the 8C opcode function.

 

[Brutus]

One thought that has bothered me for some time is that given code and data are mixed randomly in the ROM, it is possible that the disassembler could get out of sync with the actual code, since it treats everything including data as code.

As you can check with the new version, I've put many comments ";code" before each executable part. I removed the fake code generated on the map bytes, and for each ";code" section, I've checked the first address is called somewhere. So hopefully nothing should be out of sync in the disassembled code.

This is one reason I am working on getting IDA running, as it is smart enough to follow the execution sequence, and allows data to be blocked out interactively as well.

I gave a try to IDA, but didn't manage to have it disassemble using custom instruction set. Is that what you're struggling with?

 

[3p141592654]

I wrote a small test for the 8C opcode. It seems to work exactly as advertised, namely a test for register x against an immediate value. Here is the code I used:.

; start of test code
800f 8e122f ld x, #0x122f ; load x with test value
8012 8c122f cmp x, #0x122f ; compare to value 0x122f (should be equal)
8015 4609 bne j1 ; if not equal, jump to j1
8017 8f80a0 ld y, #0x80a0 ; pointer to "1 okay" string
801a 018059 jsr 0x8059 ; call printf at 0x8059 to dump to terminal
801d 038026 jmp 0x8026 ; jump to test2

LABEL:j1
8020 8f80a9 ld y, #0x80a9 ; pointer to "1 bad" string
8023 018059 jsr 0x8059 ; call printf at 0x8059 to dump to terminal

LABEL:Test2
8026 8e122f ld x, #0x122f ; load x with test value
8029 8c122e cmp x, #0x122e ; compare to value 0x122e (should be not equal)
802c 4609 bne j2 ; if not equal, jump to j1
802e 8f80b1 ld y, #0x80ba ; pointer to "2 bad" string
8031 018059 jsr 0x8059 ; call printf at 0x8059 to dump to terminal
8034 03803d jmp 0x803d ; jump to end

LABEL:j2
8037 8f80ba ld y, #0x80b1 ; pointer to "2 okay" string
803a 018059 jsr 0x8059 ; call printf at 0x8059 to dump to terminal

LABEL:end
803d 8f80d4 ld y, #0x80d4 ; stream out done
8040 6117 bsr 0x8059 ;printf
8042 40fe bra 0x8045 ; halt


and the resulting output to the terminal

Toshiba 8X test Code v1.0
1 okay
2 okay

done.

 

[3p141592654]

Yes, I am writing a module for the Denso processor. Its alot of work because of the large number of instructions with this processor (255).

I gave a try to IDA, but didn't manage to have it disassemble using custom instruction set. Is that what you're struggling with?

 

[Brutus]

I wrote a small test for the 8C opcode. It seems to work exactly as advertised, namely a test for register x against an immediate value.

...

done.[/B]
[/I]

Smart test, Jon! :icon_bigg

So it looks like that the disassembler did it's work well.
In that case this code is really tricky:

f6dc 371f12 tbbc b.0, $_OMODE, 0xf6f1
f6df 33ffd1 ld #0xff, $0xd1
f6e2 797aa9 cmp #0x7a, $0xa9
f6e5 4406 bcc 0xf6ed
f6e7 76a9 inc $0xa9
f6e9 355901 tbbs b.2, $_ASR2L, 0xf6ed
f6ec 8c7773 cmp x, #0x7773 ; Executed only in the case no branch to 0xf6ed occurs before
f6ed 7773 setb bit3, $_ASR0NL ; Executed only in the case a branch to 0xf6ed is done
f6ef 400a bra 0xf6fb
f6f1 7573 clrb bit3, $_ASR0NL

Since they use a "branch always" after the compare opcode, maybe the 8c byte is only there to "neutralize" the next two bytes and avoid to put a branch or a jump instruction that would "cost" more than one byte.

Does that sound right?

 

[3p141592654]

The code doesn't make sense to me. The cmp operation appears to be useless. Could have accomplished the same thing with 3 nops. It's also puzzling that its checking _OMODE.

 

[Brutus]

The code doesn't make sense to me. The cmp operation appears to be useless. Could have accomplished the same thing with 3 nops. It's also puzzling that its checking _OMODE.

I think you went too fast in reading my previous post, Jon.
Take care that the "cmp x, #0x7773" command and the the "setb bit3, $_ASR0NL" command are coded in the same memory space.

In the first case, the Program Counter reaches address 0xf6ec and executes the "cmp x, #0x7773" command, which has no effect.
Second case, if one of the tests at 0xf6e5 or 0xf6e9 succeed, the PC reaches 0xf6ed, and executes the "setb bit3, $_ASR0NL" command instead.

That's weird, but this can be a way to save a few bytes of memory from time to time in assembly programming and avoid another branch instruction.
We must keep in mind this program has been designed by a team of developpers. One or two persons are likely responsible for programming a functional part, and they are asked to design the most efficient code regarding speed and memory occupancy.

Concerning the _OMODE tests, don't you think this can be used to switch special modes inside the program (test mode, datalogging or whatever)?
Only the three first bits of OMODE are used by the processor, and the program makes tests for other bits as well, which let us think it is used for some other purpose as well.

 

[Gunnar]

I soldered together my board too and i am waiting for a 7m-gte ecu i bought.
I'll probably need some help in the procedure used to read the processor file once i desoldered it (software used on pc etc).

 

[3p141592654]

Gunnar, for Windows, just use Hyperterminal with hardware flow control, 9600,8, none,1 . Should be all you need to get going.

Henri, I see your point now, I did miss the code overlap. With 12kB, they must have been under some pressure to write very tight code. The weird thing is that it would seem if they had used tbbc instead of tbbs they could have saved a byte and not needed the overlapped code at all.

I agree about _OMODE, although they do test b.0 in that piece of code which is internal/external mode. More mysteries.

I think we need to create RAM and I/O maps and start labeling things with their actual function. Perhaps we can just add it to the top section of the asm document.

We have alot still to learn :aigo:

 

[Gunnar]

Anyone have an idea yet about the checksum routine used?
I have been looking at bmw motronic files (end 1980's to middle 1990's) the last week and they just use a totalisation 16 bit lohi checksum calculation wich is added at the end of the block.
Hopefully the toyota engineers used the same thing in their ecu.

 

[Brutus]

Henri, I see your point now, I did miss the code overlap. With 12kB, they must have been under some pressure to write very tight code. The weird thing is that it would seem if they had used tbbc instead of tbbs they could have saved a byte and not needed the overlapped code at all.

You're right, that's really strange they didn't use tbbc.

I agree about _OMODE, although they do test b.0 in that piece of code which is internal/external mode. More mysteries.

This could make sense, since external mode is certainly used for testing.

I think we need to create RAM and I/O maps and start labeling things with their actual function. Perhaps we can just add it to the top section of the asm document.

Good idea, I'll modify this when I'll have a moment.

We have alot still to learn :aigo:

Yes indeed...

Anyone have an idea yet about the checksum routine used?
I have been looking at bmw motronic files (end 1980's to middle 1990's) the last week and they just use a totalisation 16 bit lohi checksum calculation wich is added at the end of the block.
Hopefully the toyota engineers used the same thing in their ecu.

What checksum are you talking about? Since the CPU is ROM only, maybe they don't use any checksum at all?

 

[3p141592654]

I haven't found any checksum routine yet. I thought it should be the first thing executed from a reboot. According to Ross there is a ROM checksum and a double pass RAM test (write all 1's, then write all 0's) in the 3SGTE ECUs of the same vintage.

 

[Gunnar]

My ecu came in today, i just removed the chip from it.
What a pain in the ass those things are, i used hot air to pull it off and now i still have to go about cleaning up all the legs.

The markings on the CPU are : D151801-8750 and below that 7433-1137

 

[3p141592654]

Although not much has been posted lately, there has been good progress.

I have been able to write a Denso module for the free version 4.9 of IDA. I was told the free version did not support custom processors, but apparently that was bad advice. This is now definitely the disassembler to use, and I recommend it over the basic ones from Kashi or Toshi.

Send me a PM if you want the IDA processor module files for the Denso 8x.

I have also got the Table Driven Assembler (TASM) by Speech Technology Inc. working so we have an assembler as well. Still doing some QA to make sure it generates clean code, then I'll make the opcode table available for everyone.

Its been slow tedious work, but we finally have a good tool set for working with this proprietary processor.

 

[3p141592654]

Gunnnar, that's a different rev from what we have been working with (D151801-3920).

It will be interesting to see the differences.

The markings on the CPU are : D151801-8750 and below that 7433-1137

 

[3p141592654]

A little tidbit... the D151801-xxxx part number is used for multiple different Toyota ECU families. There is another marking underneath and it must read 7433-XXXX to be a member of the 12kB 8-bit MCUs as used for the Supra.

I have been studying the interrupt operation by writing test code. Very tedious work. It looks like the Kashi descriptions for the I/O registers may not be completely accurate.

I have posted an IDA idb file on assembla.com. Start with this file if you are studying the code using IDA.

 

[auto351]

3P, Good work.
I have a 1G ECU and it has the following markings D151801-9730
and below this we have 7433-1161, which would lead me to think its the same CPU just a different production batch?

I am interested to extract the code from this to see if it follows the same coding as the 7M.

Do you have any PCBs left?
Is there room on the PCB to fit ZIP socket?

Manuel

 

[3p141592654]

Yes, there is room for a ZIP if you plug the zip into a standard socket on the board. Otherwise, there is a good chance it will foul against the 74A573 chip.

Brutus and I have been making good progress pulling the code apart and understanding the MCU details. We will need to summarize things once we get a little farther along.

 

[3p141592654]

Does anyone know the "pulses per mile" for the speed sensor?