Sorry my bad english.
This is my ECU. Toyota Hilux Surf 2LT-E. CPU is D151802-9991.
Is there any information on the 42pins CPU?
This is my ECU. Toyota Hilux Surf 2LT-E. CPU is D151802-9991.
Is there any information on the 42pins CPU?
3P's TCCS Disassembly/Analysis
- Thread starter 3p141592654
- Start date
I have not pulled the code out of the 42 pin MCU, but all indications from others who have are that is shares the same architecture and instruction set as the 64 pin version. There is an incomplete pinout of the 42 pin chip on Toyota Wiki http://toyota.kgbconsulting.ca/wiki/Pinout_42_pin
Obviously, with fewer pins some IO capability is lost, and this would affect some of the IO registers that are available in the 64 pin version. Obtaining further information will require some experimentation.
Obviously, with fewer pins some IO capability is lost, and this would affect some of the IO registers that are available in the 64 pin version. Obtaining further information will require some experimentation.
Have you found out how to beat fuel cut? I am not sure how Hz affects semiconductors and what is needed to stop it.
Yes, I know where in the code they check for fuel cut, RPM cut, and so on. My problem right now is getting my extender board to work reliably. Damn thing is being a pain in the butt.
How about now? I want to run the larger 1UZFE meter with the screw in, and raised overboost cut with slightly leaner mixture than Toyota delivered 9.7:1 under load. You have no consideration for my feelings. 
I keep delaying a piggyback because I want to avoid that route.
I keep delaying a piggyback because I want to avoid that route.
Yeah, me too!
This project is being worked pretty hard, but has been slow going. If its any consolation, it works some of the time, but that's not good enough to make it usable in the field, and tracking down the problem has been very tough.
---------- Post added at 04:36 PM ---------- Previous post was at 04:34 PM ----------
I don't know much about the 1J ECU. Is it a two processor design like the 2J? And what kind of map do you need? There is work underway to map out the I/O for the dual processor MR2 ECU, but I'm not sure how relevant that is for the 1J.
This project is being worked pretty hard, but has been slow going. If its any consolation, it works some of the time, but that's not good enough to make it usable in the field, and tracking down the problem has been very tough.
Nick M;1603538 said:
---------- Post added at 04:36 PM ---------- Previous post was at 04:34 PM ----------
I don't know much about the 1J ECU. Is it a two processor design like the 2J? And what kind of map do you need? There is work underway to map out the I/O for the dual processor MR2 ECU, but I'm not sure how relevant that is for the 1J.
lom51;1603566 said:
I loaded this code into IDA and it looks like typical ECU code form Toyota. Without knowing how the sensors and such are mapped to the MCU ports on a 1J ECU, it is hard to proceed further.
The data file you sent is a little weird in that it has 32770 bytes of data, but the first 20482 bytes are junk and can be discarded. It is designed for a 16kB processor, which is one of the later versions. It probably runs at 16MHz too. The code entry point address is 0xC005.
The data file you sent is a little weird in that it has 32770 bytes of data, but the first 20482 bytes are junk and can be discarded. It is designed for a 16kB processor, which is one of the later versions. It probably runs at 16MHz too. The code entry point address is 0xC005.
lom51;1603566 said:
Folks
QUIT with the I needs.
Jon is working hard along with the rest of the group on this. They don't need any more presure than what they have. Let them do thier work!
Any other posts asking to look at any other ECU and I will start whacking posts and handing out infractions!
QUIT with the I needs.
Jon is working hard along with the rest of the group on this. They don't need any more presure than what they have. Let them do thier work!
Any other posts asking to look at any other ECU and I will start whacking posts and handing out infractions!
We have received (dis)honorable mention in the IMOK mudfest.
http://www.imoc.co.uk/forums/viewtopic.php?t=75023&postdays=0&postorder=asc&start=480
Thanks for your patience. Last night the board was working reliably. There is light at the end of the tunnel.
http://www.imoc.co.uk/forums/viewtopic.php?t=75023&postdays=0&postorder=asc&start=480
Thanks for your patience. Last night the board was working reliably. There is light at the end of the tunnel.
This is the 7MGTE ECU running in external mode on the FLASH board. The code is being run in SRAM, so it can be changed on the fly. All the tables, etc. can be changed in real time. A nice GUI to do that is being worked on, but is not ready yet.
[video=youtube;4SSAQbanRZw]http://www.youtube.com/watch?v=4SSAQbanRZw[/video]
In the video, the ECU data in RAM is being interrogated from a PC connected to the board via USB. Data rate is 4.8-6kb/s. The first 16 bit number is the ECU timer, then some data registers, and the last 16 bit number is the code serial number 1332.
[video=youtube;LHjOJvRx8WE]http://www.youtube.com/watch?v=LHjOJvRx8WE[/video]
[video=youtube;4SSAQbanRZw]http://www.youtube.com/watch?v=4SSAQbanRZw[/video]
In the video, the ECU data in RAM is being interrogated from a PC connected to the board via USB. Data rate is 4.8-6kb/s. The first 16 bit number is the ECU timer, then some data registers, and the last 16 bit number is the code serial number 1332.
[video=youtube;LHjOJvRx8WE]http://www.youtube.com/watch?v=LHjOJvRx8WE[/video]
Last edited:
The ECU permits one 16 bit read from RAM every 2.1ms (7.5kB/s). That is the best that you can do without rewriting the ECU diagnostics code. The serial port is running at 1 Mb/s, so more could theoretically be extracted, but would need to be careful since it is shared with the ADC.
darrylp;1621396 said:
That's a very good point actually, I don't think anyone has yet looked in to using the 'spare' data bus cycles for reading the RAM.
It should theoretically be possible for a 2nd processor to read from/write to the RAM when the Denso MCU isn't using the data bus. A memory access cycle only uses the data bus for half of the cycle, which would allow time to sneak in another access before the Denso MCU needs to use the data bus again.
It would certainly need a larger CPLD though as the current design is pushing the limits of the CPLD being used.
The RAM is internal to the CPU, making reads on alternate cycles not an option. Would have to shadow the RAM to an external chip to do this. Given that portions of the internal RAM are retained during engine shutdown, this would be some work to implement. If throughput becomes an issue it may make more sense to add some code in the ECU to improve diagnostic bandwidth.
The daughter board should work on the GE. The only reason it might not is that early GE ECUs are single board and thinner, and the daughter board might not fit.
The ECU hardware between the GE and GTE is completely different, so a firmware change will not swap between the two.
It does seem possible to swap between M/T and A/T with only a firmware change for the GTE. The GE is even easier, you just need to add a resistor.
The ECU hardware between the GE and GTE is completely different, so a firmware change will not swap between the two.
It does seem possible to swap between M/T and A/T with only a firmware change for the GTE. The GE is even easier, you just need to add a resistor.