DIY ECU remap project....
14 August 2002, 12:29 AM
#91
Scooby Newbie
Join Date: Jul 2002
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
Dangle an offset !!! Where is the fun in that ?
Think of how pleased with yourself you will be if you find it. Then you just need to find the 2D table that controls the 'Fuel Cut %' (to stop you melting your turbo and sending the impellor down the exhaust!) the single bit option that converts the 'Neutral Switch' input into 'ALS Enable' and thats it....ALS on a standard ECU !!!
Think of how pleased with yourself you will be if you find it. Then you just need to find the 2D table that controls the 'Fuel Cut %' (to stop you melting your turbo and sending the impellor down the exhaust!) the single bit option that converts the 'Neutral Switch' input into 'ALS Enable' and thats it....ALS on a standard ECU !!!
14 August 2002, 12:33 AM
#92
Scooby Regular
Join Date: Nov 2001
Location: Leeds - It was 562.4bhp@28psi on Optimax, How much closer to 600 with race fuel and a bigger turbo?
Posts: 15,239
Likes: 0
Received 1 Like
on
1 Post
hmm... i doubt ill find it..
but Im going to see if I can convert a td05 to a rollerbearing turbo.. with a big compressor wheel
David
but Im going to see if I can convert a td05 to a rollerbearing turbo.. with a big compressor wheel
David
14 August 2002, 12:46 AM
#93
Scooby Newbie
Join Date: Jul 2002
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
It is tricky to find. I only found it because I have built a trace system that tells me where the ECU is reading/writing to. I noticed that it kept reading an are that was all 'FF' which seemed silly. Cut a long story short - I changed the values and found that it did nothing. Then I found two bytes that set several 'options', one of which is the ALS enable bit. This allows the value in the table to take effect.
I think you'll find it hard without some form of emulator or trace system. What methods are you guys using ?
Andy
I think you'll find it hard without some form of emulator or trace system. What methods are you guys using ?
Andy
14 August 2002, 08:39 AM
#94
Scooby Regular
Join Date: Nov 2001
Location: Leeds - It was 562.4bhp@28psi on Optimax, How much closer to 600 with race fuel and a bigger turbo?
Posts: 15,239
Likes: 0
Received 1 Like
on
1 Post
you say you built a trace system?? What was involved with that?? Were you watching memory access on an external rom / emulator??
David
David
14 August 2002, 08:48 AM
#95
Cheers for thee-mail Steve but I had a play last night with the memory dump code that Paul supplied, and if you change a few of his timings you can get more than 1 byte out at a time.
I was just playing but managed to get over 300 bytes out at one point.
The Byte count value that gets sent to the ECU doesn't seem to do anything as I set it to 78,8000,FF and then 78,8000,01 and they both worked the same.
The early ECU seems to output as many bytes as it can in the timeout period you define.
So I'm going to set the timeout period to a value that allows me to output 16bytes at a time, then I shall be able to capture a line of data per read (I may increase this amount once I get it set-up). To do this I will need to set the read time period to about 160mS. This captures 16 or 17 bytes, so the Serial Read will only store 16 and ignore any others.
I also intend to setup some vitual buttons that allow dumping of set area's i.e Boost, Duty Cycle, Fuel-Cut etc...etc...
After that it will be select monitor time....
Select Monitor Question.....
Do we have the locations of all the variables, other than what is on the tsukuba web site. Are the Post97 addresses in the same order but just different locations ?
Is the ECU Error Code logged the same as that 'Flashed' using the Check Engine light i.e Flashed Code 42, will be stored as 42.
I was just playing but managed to get over 300 bytes out at one point.
The Byte count value that gets sent to the ECU doesn't seem to do anything as I set it to 78,8000,FF and then 78,8000,01 and they both worked the same.
The early ECU seems to output as many bytes as it can in the timeout period you define.
So I'm going to set the timeout period to a value that allows me to output 16bytes at a time, then I shall be able to capture a line of data per read (I may increase this amount once I get it set-up). To do this I will need to set the read time period to about 160mS. This captures 16 or 17 bytes, so the Serial Read will only store 16 and ignore any others.
I also intend to setup some vitual buttons that allow dumping of set area's i.e Boost, Duty Cycle, Fuel-Cut etc...etc...
After that it will be select monitor time....
Select Monitor Question.....
Do we have the locations of all the variables, other than what is on the tsukuba web site. Are the Post97 addresses in the same order but just different locations ?
Is the ECU Error Code logged the same as that 'Flashed' using the Check Engine light i.e Flashed Code 42, will be stored as 42.
14 August 2002, 09:49 AM
#96
Scott,
Sorry I didn't really explain what I did, but it looks like the penny has dropped!
If you look at the main sequence in the loop you can see it send a 12h after a wait and the main read command, this is just to stop too much crap building up in the buffer, which made things easy.
I am sure that it can be setup so that in one of the main waits, it reads the data in the buffer from the previous read or something.
Andy@TEG,
Hints, carrots etc are okay, but often useless! Obviously I don't expect you to give up your work for free, but please don't tease us. I would like to know a little more about your trace system, as it's something that the romemulators offer. I can also run the cu code on a software simulator, trouble is I think I need to learn about interupts etc so I can provide it with some input.
Paul
Sorry I didn't really explain what I did, but it looks like the penny has dropped!
If you look at the main sequence in the loop you can see it send a 12h after a wait and the main read command, this is just to stop too much crap building up in the buffer, which made things easy.
I am sure that it can be setup so that in one of the main waits, it reads the data in the buffer from the previous read or something.
Andy@TEG,
Hints, carrots etc are okay, but often useless! Obviously I don't expect you to give up your work for free, but please don't tease us. I would like to know a little more about your trace system, as it's something that the romemulators offer. I can also run the cu code on a software simulator, trouble is I think I need to learn about interupts etc so I can provide it with some input.
Paul
14 August 2002, 10:15 AM
#97
Paul,
Noticd the '12' to stop the transmission....
Now that I have caught up with a bit of background reading on the required command sequence I can see exactly what it's doing.
I want to try and dump the data as fast as the baud rate will allow, and want to try and limit the amount of start and stop commands used as I beleive this is were errors are likely to occur.
I have started to modify a version of your Labview code that will output larger blocks of data. It will also reset/flush the RS232 port at the start of each read loop, therefore getting rid of any buffered data.
The Jap site reckons that the last byte of the read command defines 'Options'. Although it doesn't seem to make any difference, so I may well leave it out.
Noticd the '12' to stop the transmission....
Now that I have caught up with a bit of background reading on the required command sequence I can see exactly what it's doing.
I want to try and dump the data as fast as the baud rate will allow, and want to try and limit the amount of start and stop commands used as I beleive this is were errors are likely to occur.
I have started to modify a version of your Labview code that will output larger blocks of data. It will also reset/flush the RS232 port at the start of each read loop, therefore getting rid of any buffered data.
The Jap site reckons that the last byte of the read command defines 'Options'. Although it doesn't seem to make any difference, so I may well leave it out.
14 August 2002, 10:36 AM
#98
If you look at the code, I have modified the serial read vi to check the amount of data in the buffer and read all of it, thus clearing it. If you don't send the stop, it will be filling up again even as you empty it. The problem is then; how do you check the data is good? I compare the address received to the address requested. It becomes very hard to pick out the address received if you have a continuous stream of data.
I think what I have done gives 100% reliability of rom dumps, if not, at least you know about it. This becomes less of an issue for reading engine parameters, as a dirty read isn't gonna mess everything up.
The 96 ecu is going to be slow anyway, the biggest time is spent waiting for the read command to get to the ecu and waiting for the recieved info to reach the PC serial buffer. These times will not change and and mean that you are only going to be able to get a minor speed up from removing the stop sends.
This is something I did try BTW, but it wasn't reliable. I think I tried just sending the read requests without the stops, and reading the buffer, as a read request will overwrite the previous one anyway, but you have no control over whether the ECU will stop the previous send half way through. SO you might get some data back which ends in half the address only.
If you want to speed up the dumping process, figure out if the ecu can send and recieve simulateously, so you can send a read while the data is recieved. If the ecu will continue with the previous data send until the new read request is recieved in full, there is about a 50% speed up to be had.
Paul
I think what I have done gives 100% reliability of rom dumps, if not, at least you know about it. This becomes less of an issue for reading engine parameters, as a dirty read isn't gonna mess everything up.
The 96 ecu is going to be slow anyway, the biggest time is spent waiting for the read command to get to the ecu and waiting for the recieved info to reach the PC serial buffer. These times will not change and and mean that you are only going to be able to get a minor speed up from removing the stop sends.
This is something I did try BTW, but it wasn't reliable. I think I tried just sending the read requests without the stops, and reading the buffer, as a read request will overwrite the previous one anyway, but you have no control over whether the ECU will stop the previous send half way through. SO you might get some data back which ends in half the address only.
If you want to speed up the dumping process, figure out if the ecu can send and recieve simulateously, so you can send a read while the data is recieved. If the ecu will continue with the previous data send until the new read request is recieved in full, there is about a 50% speed up to be had.
Paul
14 August 2002, 09:02 PM
#99
Scooby Newbie
Join Date: Jul 2002
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
Paul
You're right I guess - me dropping hints like that isn't a lot of use, I just thought that I'd let you know that there is loads off stuff in the 96 ECUs that you don't see unless you look really hard!
I'm sort of in an akward position here - I make my living by doing the sort of thing that you guys are doing. So on the one hand I don't want to give the game away (I've spent ages working on this) but then I'm an engineer - and I like to help people along. One of my worries is that I don't know what you all intend to do with the info once you get it all worked out. And also even if you don't intend to use it for commercial use, anyone could be reading this thread - do you see my problem ??
That aside - the trace sytem I made just watches the address,data and RD/WR lines etc and stores the address, the data and the direction whenever it sees a read or write and writes them to a local RAM. When I'm finished doing whatever I'm looking at on the ECU, I push a button on my trace unit and it uploads what it has in RAM to my PC (uses a serial link running at 38.4K) where I have some VB that shows me a) where is the program going b) what is being read/written. It's not very complicated, it uses a 68HC11, some IO buffers and a 8M RAM stick from an old PC !!
I'm also using a really smart EPROM Emulator called a 'multiROM', 3 laptops & my normal PC, a PIC based engine simulator (generates the crank/cam signals) two digital storage scopes, a few pushbuttons/switches to simulate power steering switch etc. about a dozen LEDs for outputs and a load of pots for the boost pressure TPS etc - oh yeah - and a shed load of wire everywhere !!
All this is sat in the workshop - not in a car. This is why I've manged to crack just about everything in the box ! (I think)
How are you doing it ?
Andy
You're right I guess - me dropping hints like that isn't a lot of use, I just thought that I'd let you know that there is loads off stuff in the 96 ECUs that you don't see unless you look really hard!
I'm sort of in an akward position here - I make my living by doing the sort of thing that you guys are doing. So on the one hand I don't want to give the game away (I've spent ages working on this) but then I'm an engineer - and I like to help people along. One of my worries is that I don't know what you all intend to do with the info once you get it all worked out. And also even if you don't intend to use it for commercial use, anyone could be reading this thread - do you see my problem ??
That aside - the trace sytem I made just watches the address,data and RD/WR lines etc and stores the address, the data and the direction whenever it sees a read or write and writes them to a local RAM. When I'm finished doing whatever I'm looking at on the ECU, I push a button on my trace unit and it uploads what it has in RAM to my PC (uses a serial link running at 38.4K) where I have some VB that shows me a) where is the program going b) what is being read/written. It's not very complicated, it uses a 68HC11, some IO buffers and a 8M RAM stick from an old PC !!
I'm also using a really smart EPROM Emulator called a 'multiROM', 3 laptops & my normal PC, a PIC based engine simulator (generates the crank/cam signals) two digital storage scopes, a few pushbuttons/switches to simulate power steering switch etc. about a dozen LEDs for outputs and a load of pots for the boost pressure TPS etc - oh yeah - and a shed load of wire everywhere !!
All this is sat in the workshop - not in a car. This is why I've manged to crack just about everything in the box ! (I think)
How are you doing it ?
Andy
14 August 2002, 09:04 PM
#100
Spent a while modifying the code so that I could output larger blocks of data, and thought it was all working well. Dumping each line of code i.e 8000, 8010 etc..etc...
Until I checked the data coming out as it didn't seem right.
The 18 bytes of data that it gives me (including address) go something like this.....
8000 2800 8028 8000 2880 2800 8000 etc....etc....
It seems to read :
The Address - As expected
First Byte - As expected
Address LSB - Not as expected
Address MSB - Not as expected
first Byte - Not as expected
And the pattern just repeats for each line 8000, 8010 etc...etc..
I then went back to Pauls code and increased the timings and the same pattern was seen. So I'm not sure exactly what the ECU is doing after it's output 1 byte of data.
I have a copy of Scoobyducks code which I will try tommorrow and see if that will output more than 1 byte at a time(has to wait till tommorrow, as it's on my work drive at the moment).
Until I checked the data coming out as it didn't seem right.
The 18 bytes of data that it gives me (including address) go something like this.....
8000 2800 8028 8000 2880 2800 8000 etc....etc....
It seems to read :
The Address - As expected
First Byte - As expected
Address LSB - Not as expected
Address MSB - Not as expected
first Byte - Not as expected
And the pattern just repeats for each line 8000, 8010 etc...etc..
I then went back to Pauls code and increased the timings and the same pattern was seen. So I'm not sure exactly what the ECU is doing after it's output 1 byte of data.
I have a copy of Scoobyducks code which I will try tommorrow and see if that will output more than 1 byte at a time(has to wait till tommorrow, as it's on my work drive at the moment).
14 August 2002, 09:40 PM
#101
something like this.....
8000 2800 8028 8000 2880 2800 8000 etc....etc....
8000 2800 8028 8000 2880 2800 8000 etc....etc....
I think you need to look more closely at what's going on in my VI.
When I wrote the program I used a serial port debugger to monitor what was going on, so I could see the raw data from the ecu.
As far as I can tell the 4 byte of the send command does nothing on the pre 97 ecu. I could send anything in that bytes (and I did) and all I got was:
Address MSB
Address LSB
DATA
DATA (again)
DATA (again)
and so on.
Looking at your stream, I think you have really screwed it! I reakon you must be resending the read command each time, so you recieve the 1st 3 bytes okay, but you might be sending the next read command half way through recieving some data, so it gets cut off.
Try this:
Send 78h MSBh LSBh 00h outside a loop, right after init'ing the serial port, then just read the serial buffer in the loop.
I really have been and done most of what you are trying, and i spent hours doing it. You will definitely learn how the thing works, but i don't think there's much more to be had functionality wise.
Paul
14 August 2002, 10:55 PM
#103
Scooby Regular
Join Date: Jun 1999
Posts: 685
Likes: 0
Received 0 Likes
on
0 Posts
Hi Scott,
This is probably what is intended. The protocol isn't normally used to acquire ROMs - normally it's used to retrieve diagnostic data.
So if you wanted to monitor boost pressure for example, you would request that, and the ECU would then send that data back repetitively, so you get it as often as possible.
Perhaps you have stumbled across another retieval method - different from what Paul's seen.
Cheers
Steve
[Edited by StephenDone - 8/14/2002 10:57:35 PM]
This is probably what is intended. The protocol isn't normally used to acquire ROMs - normally it's used to retrieve diagnostic data.
So if you wanted to monitor boost pressure for example, you would request that, and the ECU would then send that data back repetitively, so you get it as often as possible.
Perhaps you have stumbled across another retieval method - different from what Paul's seen.
Cheers
Steve
[Edited by StephenDone - 8/14/2002 10:57:35 PM]
14 August 2002, 11:08 PM
#104
Scooby Regular
iTrader: (1)
Join Date: Oct 2001
Location: South East
Posts: 1,300
Likes: 0
Received 0 Likes
on
0 Posts
Steve,
I think Scott & Paul are trying to do the same thing - read the maps and code from the ECU using the select protocol - which appears to be able to read ALL RAM & ROM addresses!
but unfortunatly I think Scotts car / laptop / himself appears to be on a different planet !
(no change then! )
Steve
I think Scott & Paul are trying to do the same thing - read the maps and code from the ECU using the select protocol - which appears to be able to read ALL RAM & ROM addresses!
but unfortunatly I think Scotts car / laptop / himself appears to be on a different planet !
(no change then! )Steve
14 August 2002, 11:34 PM
#105
I think so s'duck.
Stephen,
we have already succeeded in reading the entire rom address space through the select port, that's how I got my standard legacy map to modify it.
Do you currently have restrictions on the address space you can read? I would guess the new ecus boot up and download program from flash, yes?
Paul
Stephen,
we have already succeeded in reading the entire rom address space through the select port, that's how I got my standard legacy map to modify it.
Do you currently have restrictions on the address space you can read? I would guess the new ecus boot up and download program from flash, yes?
Paul
15 August 2002, 12:07 AM
#106
Scooby Regular
Join Date: Jun 1999
Posts: 685
Likes: 0
Received 0 Likes
on
0 Posts
Scott says he has altered some of the timings parameters, so he may be requesting data in a different way to you. I understand you already have the ROM, I was simply trying to justify the response that Scott was getting from his ECU.
Regs.
Steve
Regs.
Steve
15 August 2002, 08:22 AM
#107
No Paul I havn't screwed it up.
Your program does the same if you increse the 'miiliseconds to wait after read send' to 160ms. You get the same response i.e Address, Data, then screwed address/data.
Yeh your right we can dump out the entire MAP, but I'm just trying to see if there's a way to speed things up.
Currently we are reading each byte individually whereas Scoobyduck can read 127byte in one go.
It took bloody ages to download my MY94 map and it's not something that I want to sit around waiting about 30mins for, especially when the ignition needs to be on or the engine running.
Your program does the same if you increse the 'miiliseconds to wait after read send' to 160ms. You get the same response i.e Address, Data, then screwed address/data.
Yeh your right we can dump out the entire MAP, but I'm just trying to see if there's a way to speed things up.
Currently we are reading each byte individually whereas Scoobyduck can read 127byte in one go.
It took bloody ages to download my MY94 map and it's not something that I want to sit around waiting about 30mins for, especially when the ignition needs to be on or the engine running.
15 August 2002, 12:19 PM
#112
Scooby Regular
iTrader: (1)
Join Date: Oct 2001
Location: South East
Posts: 1,300
Likes: 0
Received 0 Likes
on
0 Posts
Scott / Paul,
yep - the one thing that's different with my car is the 97 ecu. the 4th bytes deffinatly does what it's ment to (according to all found specs so far). apart from you can only get 127 bytes back at anyone go. any more than that & it doesnt repeat the data - AHHH... light bulb .. but does it actually dump the requested data?? (need to try that!)
If I do a read byte - STOP loop I'll be looking at exactly the same time as you to d/load.
the only use I'm thinking of for this would be to allow the laptop to 'grap a map' and display it - more of a gismo than anything.
Paul's right - once the ecu dump of maps & code are done once - you dont need to do it again. you might want to dump a specific map - but they're relatively small areas (ish)
If you manage to try my code Scott, I think that'll prove it once and for all . the pre97 ecu's 4 byte does squat ! (but must be there!)
Steve
yep - the one thing that's different with my car is the 97 ecu. the 4th bytes deffinatly does what it's ment to (according to all found specs so far). apart from you can only get 127 bytes back at anyone go. any more than that & it doesnt repeat the data - AHHH... light bulb .. but does it actually dump the requested data?? (need to try that!)
If I do a read byte - STOP loop I'll be looking at exactly the same time as you to d/load.
the only use I'm thinking of for this would be to allow the laptop to 'grap a map' and display it - more of a gismo than anything.
Paul's right - once the ecu dump of maps & code are done once - you dont need to do it again. you might want to dump a specific map - but they're relatively small areas (ish)
If you manage to try my code Scott, I think that'll prove it once and for all . the pre97 ecu's 4 byte does squat ! (but must be there!)
Steve
15 August 2002, 10:10 PM
#114
Scooby Regular
iTrader: (1)
Join Date: Oct 2001
Location: South East
Posts: 1,300
Likes: 0
Received 0 Likes
on
0 Posts
DOH !
that means that my multi-monitor wont work on pre97's ! bummer!
& also means code / map retreival & multiple monitor of engine parameters is harder!
oh well!
Steve
that means that my multi-monitor wont work on pre97's ! bummer!
& also means code / map retreival & multiple monitor of engine parameters is harder!
oh well!
Steve
18 August 2002, 04:48 PM
#115
Okay,
I finally got round to writing the select monitor read today. Based very roughly on the thing that dumps the entire rom contents, i was successfully monitoring 4 addresses, and I could see the changes when I fiddled, confirming the addresses on the Kashima's page are correct for pre 97 ecus.
Next step is make it useable, and introduce the correct number scaling etc.
Scott, I will send the vi once I get it off the machine, it's very simple, just has a for loop that goes through 4 address.
paul
I finally got round to writing the select monitor read today. Based very roughly on the thing that dumps the entire rom contents, i was successfully monitoring 4 addresses, and I could see the changes when I fiddled, confirming the addresses on the Kashima's page are correct for pre 97 ecus.
Next step is make it useable, and introduce the correct number scaling etc.
Scott, I will send the vi once I get it off the machine, it's very simple, just has a for loop that goes through 4 address.
paul
19 August 2002, 09:21 AM
#116
Paul,
Can you save my version in Labveiw 5.0.x. Do this by seecting 'Save with Options' then check the '5.0.x' box. It will create a new folder with all files converted.
Cheers....
It wll save me having to copy from one machins to an un-networked machine, converting then copying back.
P.S No sign of the Application builder on the CD
Can you save my version in Labveiw 5.0.x. Do this by seecting 'Save with Options' then check the '5.0.x' box. It will create a new folder with all files converted.
Cheers....
It wll save me having to copy from one machins to an un-networked machine, converting then copying back.
P.S No sign of the Application builder on the CD
20 August 2002, 03:47 PM
#119
Hmm, product. That's a tough one.
If anyone actually has a pre 97 car, and they are considering an ecu/dawes/unichip/link or whatever, email Scott or myself an let us know what you would like to see.
The Tek 2 from Ecutek seems popular, and for the most part, effective. With the pre96 cars you are limited to about 290hp by the standard injectors/fuel pressure. The MAP sensor topping out at about 17.5psi doesn't help either.
I would also be interested to hear from anyone that is conifident or crazy enough to just get the parts and make the changes themselves!
Paul
If anyone actually has a pre 97 car, and they are considering an ecu/dawes/unichip/link or whatever, email Scott or myself an let us know what you would like to see.
The Tek 2 from Ecutek seems popular, and for the most part, effective. With the pre96 cars you are limited to about 290hp by the standard injectors/fuel pressure. The MAP sensor topping out at about 17.5psi doesn't help either.
I would also be interested to hear from anyone that is conifident or crazy enough to just get the parts and make the changes themselves!
Paul
20 August 2002, 03:53 PM
#120
We need to get those PCB's ordered Paul.....
I have plenty of guinea pigs down my way ready to plug them in, but at present am in danger of running out ot Hardware.
I have 3 boards built.
One for me and the other 2 are already assigned to fellow owners.
Is Dave on Holiday, as I thought he was ordering the next batch ??
I have plenty of guinea pigs down my way ready to plug them in, but at present am in danger of running out ot Hardware.
I have 3 boards built.
One for me and the other 2 are already assigned to fellow owners.
Is Dave on Holiday, as I thought he was ordering the next batch ??