Throwing down the gauntlet against Toyota's ECU
09-19-07, 03:05 PM
#16
We are currently attempting to figure out what Microcontroller the Denso D151802 actually is. Its challenging in that there is NO information about this chip.
And I've come to the conclusion that its a part number (since the latter 4 digits like a - 2360 postfix are a rom-version) that they sourced from someone else and put their RTOS on it (real-time operating system).
If we can find out what chip it was, we can get the appropriate hardware. The look of the chip is strikingly similar to the Motorola MC68HC000P8 which is a 68k variant. http://www.cpu-collection.de/?tn=0&l...90&l2=Motorola
The chip is a DIP-64, which makes it a bit newer than the older DIP-40 68k hardware. I keep seeing info crop up about it not being a real motorola since the instruction encoding is different than standard 68k. I hope that is wrong.
Its identity is important because that allows us to scan the chip. I've already come up with a solution for making it easy to swap out the chip, but we have to run a scan tool on it and find out where all of the map data is scanned from, understand where the different data tables are located, and then modify appropriately with a newer implementation that will allow us to use actual flash-memory so it can be programmed very quickly.
I've got a lot of software development experience, but for those of you that do have C/C++/C#/VB/etc experience, we're going to need you eventually
I plan on using .Net on this puppy because I plan on designing a network interface into the software for a variety of reasons, and I've already got a lot of code that will do that. Plus I just like .Net 
And I've come to the conclusion that its a part number (since the latter 4 digits like a - 2360 postfix are a rom-version) that they sourced from someone else and put their RTOS on it (real-time operating system).
If we can find out what chip it was, we can get the appropriate hardware. The look of the chip is strikingly similar to the Motorola MC68HC000P8 which is a 68k variant. http://www.cpu-collection.de/?tn=0&l...90&l2=Motorola
The chip is a DIP-64, which makes it a bit newer than the older DIP-40 68k hardware. I keep seeing info crop up about it not being a real motorola since the instruction encoding is different than standard 68k. I hope that is wrong.
Its identity is important because that allows us to scan the chip. I've already come up with a solution for making it easy to swap out the chip, but we have to run a scan tool on it and find out where all of the map data is scanned from, understand where the different data tables are located, and then modify appropriately with a newer implementation that will allow us to use actual flash-memory so it can be programmed very quickly.
I've got a lot of software development experience, but for those of you that do have C/C++/C#/VB/etc experience, we're going to need you eventually
I plan on using .Net on this puppy because I plan on designing a network interface into the software for a variety of reasons, and I've already got a lot of code that will do that. Plus I just like .Net
09-20-07, 09:29 AM
#21
CCC-TT, if this was just computer programming, I would have finished it in just a few minutes. The complexity of the problem is that Toyota does not have a typical memory chip that one can modify like other cars do. Their microprocessors are actual "computer on a chip" microcontrollers that have internal memory. This memory is read-only and can only be accessed with compatible hardware.
We may have found the details we need to construct a rom dump of the Toyota chip; which is a Toshiba unit, btw.
The complexity of the problem is that Toyota does not have a typical memory chip that one can modify like other cars do. Their microprocessors are actual "computer on a chip" microcontrollers that have internal memory. This memory is read-only and can only be accessed with compatible hardware. We may have found the details we need to construct a rom dump of the Toyota chip; which is a Toshiba unit, btw.
Last edited by Bean; 09-20-07 at 09:38 AM.
09-20-07, 06:53 PM
#24
Well with the setup we've got under research, its not going to use eeprom; it will use flash.
I've got some intimate knowledge of socket-based programming (especially under windows) and hardware access; and I think I can make this thing remotely tunable; might be nice for the tuner who cant be there but can read the O2, rpms, etc all datalogged along with dynofigures (dyno files are very small)
I've got some intimate knowledge of socket-based programming (especially under windows) and hardware access; and I think I can make this thing remotely tunable; might be nice for the tuner who cant be there but can read the O2, rpms, etc all datalogged along with dynofigures (dyno files are very small)
09-23-07, 02:34 PM
#26
Driver
Join Date: Jun 2005
Location: OK
Posts: 180
Likes: 0
Received 0 Likes
on
0 Posts
Just a heads up though its gonna be at least a year before anything remotely workable would be completed.
There is a lot of work ahead but for anyone serious about helping please sign up here.
http://www.clubna-t.com/forums/showt...9447#post29447
There is a lot of work ahead but for anyone serious about helping please sign up here.
http://www.clubna-t.com/forums/showt...9447#post29447
Thread
Thread Starter
Forum
Replies
Last Post
aristo1987
GS - 3rd Gen (2006-2011)
8
12-06-16 11:59 AM
audioqueso
Performance
2
11-19-16 11:40 PM
GeorgeNVA
LS - 1st and 2nd Gen (1990-2000)
4
07-29-15 01:22 AM
