Says "1026REV=1MILE" on the speedometer face, and I believe there are 4 pulses per rev from the encoder in the speedometer.
3P's TCCS Disassembly/Analysis
- Thread starter 3p141592654
- Start date
Thanks for the info. Do you know if it is 4 edge transitions per rev, or 4 pulses (8 edge transitions)?
3p141592654;1170442 said:
Sounds like it is 4 pulses (8 transitions)
http://www.supramania.com/forums/showpost.php?p=465285&postcount=40
I have had the MCU connected to my logic analyzer and now have a better handle on the serial communications used by the ECU.
Briefly, the internal serial bus runs at 1 MHz, and is used to communicate between various chips. It uses the well known start bit, 8 data, parity bit, and 1 stop bit. Pin SOUT0 is connected to the ADC and the external diagnostics connection. SOUT1 is connected to chips MF165 (failsafe control) and C4822j (function unknown).
For the SOUT0 channel, the parity bit is used as an address and indicates if the data is for the ADC (parity=1) or is diagnostic data (parity=0). Very tricky of them to use it this way. The SSD register is used to control both the parity bit value and SOUT0 and SOUT1 channel select. SMRC is used to set the bus speed (1 MHz ECU, but set at only 9.6kHz for our reader board).
Looking at the code, the ECU sends a one byte command to the A/D converter that apparently selects the channel to send (data is then sent to the MCU using the ASR0 input as a pulse width modulated signal). There appears to be 8 channels available and 12 bits of resolution. Channel 6 is used for offset correction.
The code for reading diagnostic data is located at ROM address FAB4. This code looks for an incoming data byte on the serial bus, and if it exists , uses its value as the RAM address from which to fetch 16 bits of data. So this allows for very flexible access to any RAM value as the ECU is running. Since there is a gap in memory from 30h to 3Fh, commands here have special functions. Issuing a 3Fh command requests the software version number for example. There is also code for dumping the entire ROM contents out. I don't understand the details of that part yet.
Since 1 MHz is way too fast for a PC serial connection, I have bought a UART/USB chip and plan to prototype a circuit to attempt to communicate to the ECU and extract diagnostic info.
Briefly, the internal serial bus runs at 1 MHz, and is used to communicate between various chips. It uses the well known start bit, 8 data, parity bit, and 1 stop bit. Pin SOUT0 is connected to the ADC and the external diagnostics connection. SOUT1 is connected to chips MF165 (failsafe control) and C4822j (function unknown).
For the SOUT0 channel, the parity bit is used as an address and indicates if the data is for the ADC (parity=1) or is diagnostic data (parity=0). Very tricky of them to use it this way. The SSD register is used to control both the parity bit value and SOUT0 and SOUT1 channel select. SMRC is used to set the bus speed (1 MHz ECU, but set at only 9.6kHz for our reader board).
Looking at the code, the ECU sends a one byte command to the A/D converter that apparently selects the channel to send (data is then sent to the MCU using the ASR0 input as a pulse width modulated signal). There appears to be 8 channels available and 12 bits of resolution. Channel 6 is used for offset correction.
The code for reading diagnostic data is located at ROM address FAB4. This code looks for an incoming data byte on the serial bus, and if it exists , uses its value as the RAM address from which to fetch 16 bits of data. So this allows for very flexible access to any RAM value as the ECU is running. Since there is a gap in memory from 30h to 3Fh, commands here have special functions. Issuing a 3Fh command requests the software version number for example. There is also code for dumping the entire ROM contents out. I don't understand the details of that part yet.
Since 1 MHz is way too fast for a PC serial connection, I have bought a UART/USB chip and plan to prototype a circuit to attempt to communicate to the ECU and extract diagnostic info.
Of course. It allows real time access to the entire RAM space of the processor. That means you access the complete engine model. For example, you could grab the raw pulse length from the last speed sensor reading, or the last 4 averaged values, or the running average value, and so on for any other computation it is making. The MIL values stored in RAM can be read directly, same with all the status flags, and the inputs from the sensors. Very flexible.
No error checking on any data buses in the ECU, including the serial buses. This is pretty typical for an MCU like this. There are RAM read/write test routines in the code, as well as a ROM checksum.
No error checking on any data buses in the ECU, including the serial buses. This is pretty typical for an MCU like this. There are RAM read/write test routines in the code, as well as a ROM checksum.
Just found this interesting ECU which is a piggy back ECU running external RAM/ROM
looks like an OEM but hard to say as can be copied to like OEM.
http://www.toymods.net/forums/showthread.php?t=43434
any ideas ?
looks like an OEM but hard to say as can be copied to like OEM.
http://www.toymods.net/forums/showthread.php?t=43434
any ideas ?
That's pretty interesting. But it is not a 7433 chip, so most of what we know wouldn't apply I suspect. Jeremy Ross would know a lot more since he has worked with the 4AGE ECU.
Did you get your 64 SDIP socket yet? That part is hard to find. I just bought a bunch of them since I'm worried next time I look they will be all gone.
Did you get your 64 SDIP socket yet? That part is hard to find. I just bought a bunch of them since I'm worried next time I look they will be all gone.
Just a few Questions.
1) the D151801 has 12K ROM is that 12Kbits or 12KBytes?
2) The numbering 7433 on the CPU, are we sure this is the cpu type, has I have done many searches & posted on CPU web sites requesting information but come up blank.
3) is there a mode on the 7433 where you can run both internal & external ROM, I didnt see one.
Christmas is tomorrow but not IC sockets, And no one will be working today so will have to wait a few more weeks, till after newyears now.
Merry Christmas and Happy new year to ALL
1) the D151801 has 12K ROM is that 12Kbits or 12KBytes?
2) The numbering 7433 on the CPU, are we sure this is the cpu type, has I have done many searches & posted on CPU web sites requesting information but come up blank.
3) is there a mode on the 7433 where you can run both internal & external ROM, I didnt see one.
Christmas is tomorrow but not IC sockets, And no one will be working today so will have to wait a few more weeks, till after newyears now.
Merry Christmas and Happy new year to ALL
It has 12kBytes of internal ROM.
7433 as the MCU type comes from Jeremy Ross. He has told me that the D151801 part number covers a variety of processor architectures. Given his depth of experience, I defer to him on this.
Yes, you can access the internal ROM as well as external, that is the trick used to read out the internal code! The trick is whether or not the MCU uses the internal interrupt addresses or the external, as that will decide what code gets run on startup.
7433 as the MCU type comes from Jeremy Ross. He has told me that the D151801 part number covers a variety of processor architectures. Given his depth of experience, I defer to him on this.
Yes, you can access the internal ROM as well as external, that is the trick used to read out the internal code! The trick is whether or not the MCU uses the internal interrupt addresses or the external, as that will decide what code gets run on startup.
Last edited:
Gee, I knew my old 6800 assembly knowledge would come in handy for something.
Sounds like a fun project, I'll have to dig deeper into it when I have some free time.
Sounds like a fun project, I'll have to dig deeper into it when I have some free time.
Just found another emulator this one is for a 1G-GT ecu and needs a special cover to fit over the board,
The item was sold before I could request a copy of the proms & better pictures of the chips used.
http://cgi.ebay.com/ebaymotors/ws/e...h=008&sspagename=STRK%3AMEWA:IT&viewitem=
The item was sold before I could request a copy of the proms & better pictures of the chips used.
http://cgi.ebay.com/ebaymotors/ws/e...h=008&sspagename=STRK%3AMEWA:IT&viewitem=
Looks alot like the early Mines ECUs.
I've had some success communicating to the ECU using the Reader board at 1MHz over a USB-UART chip. Still fighting some glitches but I can get data back and forth. Getting close to being able to suck out real time data from our ECUs.
I've had some success communicating to the ECU using the Reader board at 1MHz over a USB-UART chip. Still fighting some glitches but I can get data back and forth. Getting close to being able to suck out real time data from our ECUs.
To give you an idea for some of the tricks in the ECU, here is a piece of seemingly incomprehensible code for reading in data from Port C (IDL, DFG/LP, TE1, HT, AC, STA, OX1 and IGSW).
Port C is address $28h, and the processed data is stored in RAM variable $4Fh.
ROM:F6CA ld a, $28h ; Port C Data Register
ROM:F6CC xor a, #11000011b ; PC0 = IDL ; PC1 = DFG/LP; PC6 = OX; PC7 = IGSW
ROM:F6CE push a
ROM:F6CF mov a, b
ROM:F6D0 xor a, $4Fh ; Initially zero on _RESET
ROM:F6D2 and a, $50h ; snapshot of xor'd Port C from last read
ROM:F6D4 and b, $4Fh
ROM:F6D6 add a, b
ROM:F6D7 st a, $4Fh
ROM:F6D9 pull b
ROM:F6DA st b, $50h
Turns out the algorithm is doing two simple things. First, the mask #11000011h just inverts the value for the bits with a 1, and those with a 0 are left alone. So input IDL, DFG/LP, OX1, and IGSW are inverted.
The second, and more tricky thing, is that the code requires that the input from Port C be the same for two readings before the value in $4Fh is changed. Its a form of averaging or glitch removal.
Port C is address $28h, and the processed data is stored in RAM variable $4Fh.
ROM:F6CA ld a, $28h ; Port C Data Register
ROM:F6CC xor a, #11000011b ; PC0 = IDL ; PC1 = DFG/LP; PC6 = OX; PC7 = IGSW
ROM:F6CE push a
ROM:F6CF mov a, b
ROM:F6D0 xor a, $4Fh ; Initially zero on _RESET
ROM:F6D2 and a, $50h ; snapshot of xor'd Port C from last read
ROM:F6D4 and b, $4Fh
ROM:F6D6 add a, b
ROM:F6D7 st a, $4Fh
ROM:F6D9 pull b
ROM:F6DA st b, $50h
Turns out the algorithm is doing two simple things. First, the mask #11000011h just inverts the value for the bits with a 1, and those with a 0 are left alone. So input IDL, DFG/LP, OX1, and IGSW are inverted.
The second, and more tricky thing, is that the code requires that the input from Port C be the same for two readings before the value in $4Fh is changed. Its a form of averaging or glitch removal.
A status update really. We have fully reversed the ECU hardware now, thanks mainly to Henri (Brutus), and have mapped all the ECU inputs to the respective MCU pins. The only remaining input issue is to map the ADC channels to the ECU inputs (we now know ch0 is AFM and ch6 is TPS, and think ch4 is THW).
We understand now how the ECU uses logic flags to run separate code for different applications. For example, the only difference between the M/T and A/T 7MGE ECUs is the addition of a 100 ohm resistor in R607. R607 pulls the MCU input SIN2 low (logic 0) and that triggers the ECU code to run some parts differently.
Chances are this also applies to the GTE ECU, so all those people who swap their autos for R154s can also swap their ECU code to run the correct M/T routines with a simple resistor delete. We'll verify this later when we get into the GTE ECU.
More to come...
We understand now how the ECU uses logic flags to run separate code for different applications. For example, the only difference between the M/T and A/T 7MGE ECUs is the addition of a 100 ohm resistor in R607. R607 pulls the MCU input SIN2 low (logic 0) and that triggers the ECU code to run some parts differently.
Chances are this also applies to the GTE ECU, so all those people who swap their autos for R154s can also swap their ECU code to run the correct M/T routines with a simple resistor delete. We'll verify this later when we get into the GTE ECU.
More to come...