3P's TCCS Disassembly/Analysis
- Thread starter 3p141592654
- Start date
I'm looking for the same IC for decaping, this time without damaging the DIE.
PS: no mask rom, looks like a PROM (OTP ?)
PS: no mask rom, looks like a PROM (OTP ?)
Oups, made a mistake with DENSO P/N and DIE observation
The main MCU, supposed to be an Hitachi 8x labelled as follow (from a Toyota MR2):
D151802-4800
7433-1380
1B2524
The second MCU dedicated fro knock and lambda sensor:
D 151802-2860
572 130M
9046 Z44
Here is the logo:
Here is the complete manufacturer's name and maybe the year:
The partnumber !
And a random marking, maybe the mask version:
Sorry for the dirt on the DIE !
The main MCU, supposed to be an Hitachi 8x labelled as follow (from a Toyota MR2):
D151802-4800
7433-1380
1B2524
The second MCU dedicated fro knock and lambda sensor:
D 151802-2860
572 130M
9046 Z44
Here is the logo:
Here is the complete manufacturer's name and maybe the year:
The partnumber !
And a random marking, maybe the mask version:
Sorry for the dirt on the DIE !
Great job! Looks like it's an enhanced 4-bit serie of Fujitsu MCUs. It has ADC, timers, USART.
The following pinout seems to be similar with sDIP42 D151803-4151 (knock-DSP from 1G-FE ECU).
Xin,Xout, power lines match. ADC power lines are different. Need more investigations.
The following pinout seems to be similar with sDIP42 D151803-4151 (knock-DSP from 1G-FE ECU).
Xin,Xout, power lines match. ADC power lines are different. Need more investigations.
Last edited:
Off course I contacted Fujitsu but they told me they sold the Mcu division who is now hold by Cypress, but cypress couldn't help me because it's too old and also made under fujitsu management...
Nice! I think the S G S are pad labels (G is usually used for ground). Looks like a wafer probable test port or process control monitor to me. Thank for confirming that the knock sensor is a Fujitsu part.
If someone could provide an IC (even broken) I will be so happy ! There is a hope to find the exact partnumber !
Unfortunately it looks like I binned the PCB. I do have a knock sensor IC from a dead 3VZ-FE ECU, the IC part number is D151802-8860. I also have a faulty main MCU from a later MR2 ECU, part number D151803-9651 if you'd like to look at that as well.JonS;2061741 said:
Nutton, are you looking for the knock sensor or the main processor? I have several of each type from different ECUs.
Ideally the main chip so I can try to find the exact partnumber, logo, manufacturer anything to confirm the identity of the chip.
But any chip is welcome and especially all masked rom, like the knock chip, because bits are hardwired on the silicium and can easily be read by a software analysing pictures, the firmware can be dumped by automated visual process.
But any chip is welcome and especially all masked rom, like the knock chip, because bits are hardwired on the silicium and can easily be read by a software analysing pictures, the firmware can be dumped by automated visual process.
Ok, so just have to ask real quick. Pardon me for not reading all 700+ posts.
Is there any info or any progress being made on the 3S-GE engine's ECU? That is the NA engine in the Celica ST165 and ST185.
The Ecu's got the DIP40 packaged CPU, and i've always wanted to dump the content of the rom and make a daughterboard with external DIP28 27C256 that will allow me to use the Ostrich 2.0 emulator and tune the software for wilder cams etc.
Is there a known way of doing this? Is it similar to what you have been doing? Cuz i take it that this only concerns supra ECU's?
Is there any info or any progress being made on the 3S-GE engine's ECU? That is the NA engine in the Celica ST165 and ST185.
The Ecu's got the DIP40 packaged CPU, and i've always wanted to dump the content of the rom and make a daughterboard with external DIP28 27C256 that will allow me to use the Ostrich 2.0 emulator and tune the software for wilder cams etc.
Is there a known way of doing this? Is it similar to what you have been doing? Cuz i take it that this only concerns supra ECU's?
JonS;2063204 said:
Yeah sorry, DIP42. I didn't quite remember.
Are there any memory dumps available from a 3S-GE DIP42 CPU?
I'm currently working on a daughterboard for a "lesser brother" of sDIP64/PLCC68 D8X, namely D8X-42 (DIP42/PLCC44). I decided to use ATMega128A instead of CPLD and some SRAM to use ROM emulators/upload firmware from ATMega.
I got a simple question on the IRP signal functionality. In ancient 3Y-EU ECU (MC6801-based) IGF signal was examined by a special register, responsible for handshake protocol. A rising-edge signal on a special pin sets bit in a register. Until MCU reads this register, that bit stays active. If IGF won't come, the bit would not be set and MCU reports an error code.
A more advanced D8X-42-based 3Y-EU ECU has IGF signal wired to, presumably, IRP (or IRL?) signal that probably have similar function. But, in case of D8X-42, it triggers latch of PORTA data into PORTAL, right?
I got a simple question on the IRP signal functionality. In ancient 3Y-EU ECU (MC6801-based) IGF signal was examined by a special register, responsible for handshake protocol. A rising-edge signal on a special pin sets bit in a register. Until MCU reads this register, that bit stays active. If IGF won't come, the bit would not be set and MCU reports an error code.
A more advanced D8X-42-based 3Y-EU ECU has IGF signal wired to, presumably, IRP (or IRL?) signal that probably have similar function. But, in case of D8X-42, it triggers latch of PORTA data into PORTAL, right?
I have not seen port A used for IGF. For 7M ECUs, IRP- is used for IGF input. It triggers IRQL. No connection to Port A that I have seen.
Is there a chance to get one of your ECUs for a '88 Supra?From my point of view there is 2 possibilities:
1: Extracting the stock firmware for deep analysis (decompiling, binary->assembly language->any high-level language like C->state-machine graph), I made a couple of reverse engineering on competitor's products (when working for automotive industry) like smart electronic actuator (manifold actuator, water valve, active air box etc...) and also on my personal ECU (Nissan P10 and Nissan P11GT) but never the whole ECU but just a part (anti-theft, diagnosis protocol, etc...).
Once done the control law is ported to a new and modern architecture, but the job must be done for each firmware !
2: Duplicating the MCU logic to a FPGA for example, but coupled with modern flash memory or nvsram for real-time (on-the-fly) modification. MCU are so simple and basic that this could be possible to do on a "small" low-power FPGA. The now called soft-MCU will run the stock firmware and take place in stock ECU keeping the all signals conditionner and actuators driver.
But in both case a datasheet is necessary and this is where it suck so hard !
I prefer the second because the hard job is done once and then compatible for almost all ECU !
1: Extracting the stock firmware for deep analysis (decompiling, binary->assembly language->any high-level language like C->state-machine graph), I made a couple of reverse engineering on competitor's products (when working for automotive industry) like smart electronic actuator (manifold actuator, water valve, active air box etc...) and also on my personal ECU (Nissan P10 and Nissan P11GT) but never the whole ECU but just a part (anti-theft, diagnosis protocol, etc...).
Once done the control law is ported to a new and modern architecture, but the job must be done for each firmware !
2: Duplicating the MCU logic to a FPGA for example, but coupled with modern flash memory or nvsram for real-time (on-the-fly) modification. MCU are so simple and basic that this could be possible to do on a "small" low-power FPGA. The now called soft-MCU will run the stock firmware and take place in stock ECU keeping the all signals conditionner and actuators driver.
But in both case a datasheet is necessary and this is where it suck so hard !
I prefer the second because the hard job is done once and then compatible for almost all ECU !