ridgeracer
Pro
Posts: 1309
|
posted August 03, 2007 08:05 PM
We've taken a lot of steps forward on this project in the last few weeks. Today was a one step back day.
I finally got around to repairing what I've been calling my UK ECU. As you may remember it was the first A1 ECU I notched and I cut a little to deep and severed 11 traces on the edge of the circuit board. I also installed a BDM port plug on it so I could access the FLASH.
I hooked it up to the emulator and it ran fine after the modification. I hooked it up to the BDM port and read out its map and code. Its official version as pulled from the map is 21175-1065EU, not UK. So of course the first thing I did was write a definition for it starting with the 21175-1069US as a template as they are both A1 types. It didn't take long to write because all the maps I've defined so far were exactly the same. Not only that if you do a compare of the map values they all come back 0 difference across the board.
So you don't have to be jealous that those autobahn guys aren't getting something your not. No hidden treasure here. I haven't compared the software yet but I don't expect to find much.
So the next thing to try was to program it. There were two things I wanted to find out:
First can you program the A1s. I have never programmed an A1 before. I have notched Entropy's A1 and read his code but have not erased/reflashed it yet. The A1 and A2/B1/B2 use totally different circuit boards, not just plugs. Would it use the same programming power pin?
Second I wanted to find out can you reflash the ECU while its still connected to the harness. Since I found out you can easily swap the pins around on the connector I've wondered why not just move one of the unused diagnostic wires in the harness to the programming power pin and program through the harness? (you still have to have a ribbon cable hang off the end of the ECU BDM port).
So I attached a wire to the programming voltage pin 29 and attached the BDM while the EU was still attached to the emulator. I erased it and verified it was blank. I then reflashed it with the same map it used to have. I verified that the 'new' flash data matched the file and removed the programming power and BDM port.
I turned on the emulator and nothing. Its dead, no FI light on power up at all. No fuel pump relay, nothing. I rechecked all the connections. I reverified the maps and the software. I reflashed it. Nothing. It looks like I may have somehow 'bricked' it. Of course my mistake was trying to answer to questions at once so now I don't know whats did what. So here are the possibilities as I see it...
1) It's hacked up and patched around the programming plug and plugging it in messed something up and thats why it failed. It is a 4 layer board and I only repaired the top and bottom layers. The intermediate layers looked like grounds but maybe I missed something.
2) You shouldn't program ECUs while they are hooked up to a 'bike' (emulator). This is the only ECU I've ever flashed this way. My other two have both been flashed multiple times with just 3 wires; Power, Ground, and Programming Voltage. And I didn't brick them, I don't think.
You see the first two ecus I got were known bad. Thats why I got them. Now while they were in good enough shape to read and flash they do not run on the emulator. The one shows two coils shorted always on as soon as you turn it on. The other has one bad coil that never turns on and throws FI error codes that shut down the injectors. Of course I programmed these multiple times before I ever built the emulator but while they have problems they are not bricks.
3) You can't program A1s the way you can A2/B1/B2s. I don't know why you wouldn't be able to. Pin 29 is obviously the program power pin. If I try to erase the flash without it the software says module can't be erased.
4) Maybe this whole idea is whack. I don't think so but at moments like these the doubts creep in. Supra has the only known good before it was flashed ECU which I put a new map in but as far as I know he has yet to stick it back in the bike and see if the bike runs. I did his before the emulator so there is a possibility his is messed up too. It appeared to erase and program fine but so does my EU brick.
And this turn of events leaves me dead in the water as far as moving forward on using the emulator to quantify the ECU map values. I now have 3 ECUs that can be programmed but won't run on the emulator; 1 not at all and 2 for not more than a few seconds before errors shut them down.
That leaves me with just Entropy's ECU which has been notched but never flashed. The next obvious thing to do would be to try just a three wire flash on Entropy's A1. That would answer a lot of the above questions, one way or the other.
If time is not an issue the safe play would be to wait for supra to get back from vacation in a couple weeks and try out his ECU. If his works than we know the concept is valid at least for A2/B1/B2 ECUs and then try out Entropy's A1.
So Entropy how lucky you feeling today? 
   
|
entropy
Moderator
Posts: 8671
|
posted August 04, 2007 12:38 AM
RR
I am ALWAYS feeling lucky, ignorance is bliss!! GO FOR IT! 
____________
This moderator uses moderation in moderation
|
supra5677
Pro
Posts: 1279
|
posted August 04, 2007 12:41 AM
good question are you feeling lucky today 
|
ridgeracer
Pro
Posts: 1309
|
posted August 04, 2007 08:58 AM
 Edited By: ridgeracer on 4 Aug 2007 10:07
Well I did some more testing....
Oh, hey Supra, buddy, what are you doing in this thread? Your supposed to be on vacation. You should be enjoying yourself not reading stupid threads about bricking ECUs. You can do that at home. I don't want to see you in here till you get back.
OK?
Later.
Adios.
No really everything is fine Go away.
Is he gone?
Nice guy. To bad some moron bricked his ECU!!! 
I've messed around with 6 different ECUs and I started reading back over my notes and realized that I had never actually flashed my A2 ECU. So I hooked it up to the emulator and powered it up. FI light comes on for two seconds, fuel pump relay for 4. It has the #3 coil out and I can push my little diagnostic button and read FI codes out of it.
So I unhooked it from the emulator and did a 3 wire flash on it. The the programming software shows that everything is fine. You erase it it comes back blank. You flash it everything goes ok. You verify (compare the source file to the flash bank) and it all looks ok. Then I hooked it up to the emulator again and you can guess what happened next.
Its dead. No FI light, no fuel pump, no diagnostic codes. :\
I would bet good money that Supra's ECU is in the same condition.
While this may seem like calamity I'm pretty sure its just a small set back. Really, its only a flesh wound. I have an educated guess as to what is going on.
While the BDM port can directly read CPU registers, RAM, and Flash ROM it can only directly write to the RAM. In order to flash the chip you have to download a small flash program to the RAM and then execute it. To do this you would have to redirect the boot registers so the CPU executes your flash code instead of the normal ECU code.
In layman's terms it's like how your PC normally boots off the hard drive but you can have it boot off the floppy drive or the CD-ROM when you want to install an operating system. I think whats happened to the ECUs is the equivalent of having installed an new OS on the hard drive but the PC keeps trying to boot off the floppy even though there is no disk in there.
I do not believe that the 'bricked' ECUs are physically damaged or the condition is irreversible
The PROG16z programming software comes with a unique programming algorithm for each cpu type. I just need to go thru it line by line to see what its actually doing to the CPU start up registers and then use the BDM port to explore the non functioning CPUs and see what it forgot to change back. Then modify the programming algorithm to leave the ECU in a standard boot configuration when it exits.
Since the PROG16z works thru the BDM port and I have the same access it does if it screwed up the ECU I should be able to unscrew it. I just need to figure out where to stick the screw driver as it were.
Or, I could be full of shit. Time will tell. In the mean time Entropy your ECU will be sitting safely on my shelf. While practice does make perfect right now I'm 3 for 3 on killing ECUs so I don't really need to make yours number 4.
|
entropy
Moderator
Posts: 8671
|
posted August 04, 2007 09:44 AM
RR,
You posts always make my day, no matter what, you are optimistically pressing ahead; Obsessive Compulsive Disorder at its finest! 
RR-OCD (aka Horatio H Hornblower) says: "Damn the torpedos, FULL SPEED AHEAD!!!"
____________
This moderator uses moderation in moderation
|
ridgeracer
Pro
Posts: 1309
|
posted August 05, 2007 09:46 PM
Everything is good.
I sent an email off to P&E Micro tech support, the manufacturer of the BDM interface and Prog16z software, this morning about the above problem and I actually got a reply back. On a Sunday no less. Now thats customer service.
It turns out when you bulk erase any of the flash banks you also erase the corresponding EEPROM control registers. So I copied the control block values out of entropy's working ECU and flashed it into the control registers of one of the bricked ECU and it now works again.
It adds an extra step to the flash process but the bottom line is it works. I had myself worried there for a minute.
BTW in the end all you will have to do is type a single word command and it will erase and reprogram the ecu. The Prog16z software comes with a scripted version that allows you to automate the process for a manufacturing environment.
|
supra5677
Pro
Posts: 1279
|
posted August 05, 2007 10:13 PM
did you find anything different in the 1065 ECU? BTW spent the day at the beach don't worry
|
ridgeracer
Pro
Posts: 1309
|
posted August 06, 2007 05:13 AM
No on the 21175-1065EU. As far as I can tell the ignition and fuel maps are all exactly the same.
|
ridgeracer
Pro
Posts: 1309
|
posted August 06, 2007 04:26 PM
Great success today!!!
I reprogrammed my 21175-1065EU A1 ECU with a control block and unbricked it. I hooked it up to the emulator and ran it up to redline. The injectors cut out between 11550 and 11700.
I hooked it up to the BDM port while it was on the emulator, leaving the always on battery lead connected all the time. I powered the programming voltage via the diagnostic power connections. Configured this way...
I downloaded the map
converted it from .s19 to .bin
opened it in Enginuity
cleared the checkbox in the rpm limiter window
saved the file
converted the file from .bin back to .s19
programmed it into the ECU
Turned OFF the 'Key'
removed the BDM plug
Turned ON the 'Key'
'Started' the bike/emulator
I was able to run it all the way up to 15,000 rpm (the emulator limit) without the fuel or ignition cutting out.
And I was able to program it while it was on the 'bike'.
I would of liked to have checked the Speed Limiter 'switch' too but the only fully functional ECUs I have right now are A1s which don't have the speed restriction. I will try it out though when supra sends me his B1 to reprogram.
I think the thing to do now is to write a batch file or script to make the process easier for the non-technical. What I envision are two simple commands GetMap and FlashMap.
GETMAP filename
will download the map and automatically convert it to a format usable by Enginuity and save it to a file using the name in filename.
FLASHMAP filename
will convert an Enginuity type .bin file to a format usable by Prog16z and automatically take all the steps to burn it into the ECU.
I also need to document how to power the programming voltage off the wire harness.
|
supra5677
Pro
Posts: 1279
|
posted August 06, 2007 05:39 PM
congrats sir... the piston speed calculator at a 55.4mm stroke gives 4,536.66 FPM at 12,500 rpms.. spinnning the motor past 4,500 fpm usually isn't safe.. so 12,500 will be the most I spin mine..
|
supra5677
Pro
Posts: 1279
|
posted August 06, 2007 05:42 PM
of course a stock R1 with its short 53.9mm stroke and 13,750 red line spins moves up its piston speed to 4863FPM, but I guess its designed for that...
|
neil-z750
Parking Attendant
Posts: 1
|
posted August 07, 2007 03:47 AM
Kawasaki Z750 ECU Protocol??
I was reading with interest your activities with your Kawasaki and wondered if you could help me..
I am trying to connect a Scantool to my 2004 Kawasaki Z750 but it doesnt appear to talk. I am using the ELM327 interpreter Chip with software from scantool.net
If I talk to it with a Terminal program and set the protocol to ISO9141 I see "INIT ... ERROR"
I have done a buffer dump of the ELM327 and it confirms that I have not received anything back from the ECU.
The Kawasaki has a Denso ECU with a 4 pin diagnostic connetor under the seat. The diagnostic connector pins are as follows: (As described in the Mantainance Handbook)
1/ +12volts
2/ Gnd
3/ Self-diagnosis Terminal. If this pin is grounded the ECU will give Blink Codes.
4/ External Diagnosis System Signal. This is connected to terminal 46 on the ECU, and when measured with a multimeter shows approx 7.5 volts at rest.
I am assuming the ECU is talking ISO9141 as it only has a "single wire" for diagnositics and is sitting at 7.5 volts at rest. (Maybe not the correct assumption). I did try VPM which is also single wire interface but had NO success.
The ELM327 has a number of programmable options for ISO/KWP. I have tried all combinations including:
- ISO,KWP slow,KWP slow
- setting ISO interface baud rate to 9600 (Default is 10400)
- Changing the int. address from 33 to 30,03 (just guessing here really)
- Disabling Keyword checking
- Bypassing Init
I know the ELM327 is working OK as I have connected it to 2 cars. a Holden Astra (CAN) and Nissan X-Trial running ISO and can get Sensor/DTC info from them.
Is the Kawasaki really ISO9141? or it running a different Baud rate?
Any Ideas.
regards Neil..
|
ridgeracer
Pro
Posts: 1309
|
posted August 07, 2007 06:56 AM
The ECUs I've been working with have the same 4 wire diagnostic connector. The wires are identified in the manual as:
Power Source for External Diagnosis
Ground for External Diagnosis
Switch Displaying Diagnosis (short to ground for blink codes)
Output Signal for External Diagnosis
When I first started this project I approached it the same way. There has to be some way to talk to this thing through the wire harness. But I came at this problem not as an experienced car tuner (I wouldn't know a an ELM327 from a Larch) but as an experienced embedded systems designer. I opened up the ECU, identified the CPU, found which CPU pins were serial comm ports and started to trace them toward the connector.
What I found was more than 20 resistors and semiconductors in that circuit had not been installed at the factory. And having this BDM port that I knew I could use to access the flash I gave up on serial communications.
However, I have downloaded all the code from the ecu and if I remember correctly even though there is no hardware to support it there was still a bunch of serial coms software in there. In that code should be the baud rate setting my ECU was running at and all the handshaking query/response info needed to identify the protocol used. I never looked at it in depth after I gave up on the serial approach.
Second in checking my notes it seems I never actually bothered to finish tracing out the circuit with the missing parts to see if it actually went to the Diagnostic output pin or one of the many pins marked 'unused' . Also I just checked my diagnostic pin out with the ECU powered up and it has 10 volts on it. Not what you would expect from something connected to a circuit missing all its parts.
Now you have me curious. What I will do is trace back my Output Signal for External Diagnosis System pin and see where it takes me.
All I can say is I'm going to feel like a real idiot for pounding on the back door all these months if I find the front door open
|
supra5677
Pro
Posts: 1279
|
posted August 07, 2007 09:11 AM
I thought you said you weren't going to try to communicate through the harness....
curiosity killed the cat
|
ridgeracer
Pro
Posts: 1309
|
posted August 07, 2007 03:16 PM
I checked out the Diagnostic Output pin and what do you know, it actually has components installed. See partial schematic here...
http://www.bikeland.info/pdf/ecu/21175-1089_diagnostic.pdf
The Diagnostic Out is actually driven by a cpu serial port pin, TXDB, via a couple of transistors. However the Diagnostic input is a simple digital input pulled high to 5V. The parts for the input are also 300 series were as the serial parts are all 800 series.
So were does the port B's RXD pin go? It turns out its another of the used 'unused' pins like the Program Voltage pin. As you can see in the schematic its set up to convert +/- 12V to 5V, a 232 input. However none of those parts are stuffed either.
So they left some kind of serial output channel but no serial input.
I took a preliminary at the software and found the following;
On power up port B is configured as 600 baud, 1 start, 8 data, 1 stop, no parity. It is put in a sleep mode with the Receive channel enabled set for wake on receive data. Of course with no receive channel parts it isn't ever going to wake up.
If it did wake up it switches to 19,200 baud and enables the Transmit side.
I can't rule out that there is some combination of pulses on the diagnostic switch input that would make it start dumping data, but I didn't see it.
It occurs to me that maybe what your supposed to do is pull out the diagnostic pin 21 from the ECU connector and move it over to the correct 'unused' pin when you want to interface with the ECU. Given what I found out about the ease with which you can swap ECU pins (see up thread) it would take all of 30 seconds to do.
Given what I found in the ZX-12 ECU I would make an educated guess about yours that.
a) They didn't stuff the parts and thats why it doesn't work.
b) They did stuff the parts but they routed the serial in to an unused pin and the blink wire is just a blink wire, not a dual blink wire and serial in. You'll need to move a wire at the ECU connector to get your 4 wire connector to work.
c) It communicates at 19,200 baud n,8,1
Hope that helps
|
ridgeracer
Pro
Posts: 1309
|
posted August 10, 2007 12:45 PM
Over the last day or so I have had no less than three people PM me about modifying their ECUs and wanting to know what I would charge for this service.
While I've always said I was not in this for the money I also don't have the time to modify an unlimited number of ECUs. What I have decided to do is apply the Open Source Business Model to this project. In other words I have (and will continue to do so) put all the information about how to program the ECUs openly into the public domain. What I will charge for is a service to do what any of you could do yourself but would rather pay someone to do because you don't have the time or equipment to do it yourself.
I would notch the ECU and install a connector. Also I would provide the items you can't buy off-the-shelf such as the BDM to ECU adapter cable and programming voltage circuit. Also I would include a CD-ROM with all the latest documentation and how-to information as well as a copy of your ECUs map.
Obviously I can't use this site to sell my services so as soon as I work out the details and put up a website I let you all know.
|
entropy
Moderator
Posts: 8671
|
posted August 14, 2007 04:23 AM
RR,
how is your "labor of love" (aka obsession) coming along????
____________
This moderator uses moderation in moderation
|
ridgeracer
Pro
Posts: 1309
|
posted August 18, 2007 07:30 AM
I think of it more as escapism than obsession. As my house has been invaded by giggling teens on summer vacation and their frequent slumber partying friends my leisure activities seem to come down to either watching reruns of Hanna Montana or retreating to my fortress of solitude and working on the ecu.
But I digress....
Currently I am doing some project housekeeping like updating my notes and documenting how to do all this stuff and parts lists and locations for parts etc. Also I am working on a website to post all this info so anyone can find how to build or where to buy everything you need.
Also as soon as I get a stock 4Mhz crystal in the mail I'm going to un-timebase-modifiy Supra's ECU and burn some custom maps into it changing the ignition, RPM limit and air-map usuable range.
Entropy:
Are you ready for your ECU to be sent back? Any changes you want me to make to it first?
As for general research I will be testing the RPM limit adjust on supra's unit after that the next thing on my list to figure out is the A/B map switching feature. Specifically can you switch maps while the bike is running (for things like NOS) or do you need to shut sown the bike first? I figured this would be a good way to go because it would make my other testing and measurement on the emulator easier if I could switch back and forth between an unmodified and modified map.
|
Texas12R
Zone Head
Posts: 545
|
posted August 19, 2007 05:56 AM
Just curious, but do you plan on "looking" at any of the 32 bit ecu's ?
I'm sure those of us with the milder " refined" 05 would like to know.
|
ridgeracer
Pro
Posts: 1309
|
posted August 20, 2007 07:21 AM
The later model ZX-12 uses the same basic ECU as the ZX-10, ZX-6, ZX-14 and some euro models. It is not only a 32 bit it is an entirely different animal using an Hitachi CPU, not a Motorola. Supra got a ZX-10 to me that I opened up and looked at long enough to figure out it is totally different.
I'm not saying it isn't re-programmable. In fact given that they make a Race KIT ECU for these bikes that is programmable suggest that there is a way to communicate with them built in. But they have no BDM port and what I have figure out for the older 16bit in no way, shape, or form applies to the 32 bits.
To figure out the 32bit secret is starting over from square one. Of course it also promises a much bigger pay off. If we could find the secret of reprogramming one of them I'm pretty sure it would apply across the whole new model line.
|
ridgeracer
Pro
Posts: 1309
|
posted August 21, 2007 12:06 PM
Edited By: ridgeracer on 21 Aug 2007 13:07
I have an updated definition file with more accurate RPM values. The RPM values on the side of the maps have always bothered me because they were not nice round numbers. Then up thread neil-z750 asked me about baud rates and I couldn't calculate any that made sense. To make a long story short I found that if I used a system clock setting of 32MHz I not only get nice looking RPM values but perfect baud rates so I'm going with 32Mhz.
I had previously calculated 24.5MHz using the data sheet information for a mc68hc16R1 cpu but obviously while the ECU cpu is 99% compatible there are some subtle differences.
Here is an example of the new map values. BTW using the new info the absolute max allowable RPM is 12,700 rpm and the RPM limiter is set at 11,700 exactly.
Here is the latest definition for the Enginuity software.
http://www.bikeland.info/downloads/ecu/zzr_defs_007.zip
|
entropy
Moderator
Posts: 8671
|
posted August 23, 2007 05:27 AM
quote:
Entropy:
Are you ready for your ECU to be sent back? Any changes you want me to make to it first?
RR,
I just fired up my motor with the latest tweaks and will put it on the dyno in a week or so with no other changes (i.e. use current ECU) so that i have apples to apples.
After the Texas Mile in Oct, i'll be pulling the head to re-bore the tappet wells out another .020" cause the last guy did a sloppy job, too loose :grrrrrrrrr.
Bottom line is that I am still VERY interested in pursuing tuning via direct ECU map mods but i am not in a rush to do it until i get this stuff sorted out. Prolly Nov.
Thanks for you keeping after this project!!!!
Waaaaaaaaayyyyyyyyyyyyyy Cool!!!!
____________
This moderator uses moderation in moderation
|
ridgeracer
Pro
Posts: 1309
|
posted August 27, 2007 08:45 AM
People have been asking me about changing the ECU map to remove the 2nd and 3rd gear restriction. Apparently we 'know' this restriction exists because the Nikko G-Pack claims to remove it.
Well I've looked through the software and I did find a section where a series of base fuel variables t are loaded with values depending on whether the bike is in 2nd, 3rd, or other gear. However the tables these variables are loaded from are all the same, i.e. there is no restriction. There could be if the you made the numbers in the 2nd gear table different from the 'other' gears table but in the maps I looked at , A1 US, A1 EU, B1/B2 US the numbers are all the same.
Now Nikko Racing is in France where their bikes are known to be more restrictive. I'm guessing the 2nd / 3rd gear restrictions are specific to their ECUs only. There could still be something I missed but unless someone has evidence more concrete than ad copy that the US model bikes are restricted in 2nd and 3rd I'm not going to spend any more time on this subject.
|
supra5677
Pro
Posts: 1279
|
posted August 28, 2007 12:03 PM
Nos 1290 posted this a/f leaned out in gears 2-3. Even though you didn't find this in the code change mine anyway.. 12.8 to 1 vs 13.6 to 1. Nos 1290 what country are you in?
supra
|
PetriK
Parking Attendant
Posts: 30
|
posted September 02, 2007 12:26 PM
Edited By: PetriK on 2 Sep 2007 13:31
First of all - this thread is excellent source of information for anyone who is seriously interested in tuning motorcycle engines. E.g. the standard igntion map is really a piece of gold !
Then a wild quess about the diagnostics protocol ...
quote:
I am assuming the ECU is talking ISO9141 as it only has a "single wire" for diagnositics and is sitting at 7.5 volts at rest. (Maybe not the correct assumption). I did try VPM which is also single wire interface but had NO success.
I would guess that this is pre ODB ECU, and hence a different protocol is used. As Denso is widely used for cars too, and this question rang a bell in my mind about something I was involved few years back. Have a look of the following, its not going to be exactly the same but depending on the SIO part of the ECU code it may give a hint or two. (Personally I doubt that denso would have bothered to rewrite SIO subroutines for different enginemakers - even though the engine parameters will vary - but this is just a guess without having seen the documented idapro code.
http://www.plmsdevelopments.com/images_ms/Consult_Protocol_&_Commands_Issue_6.pdf
|
|
|
HOME
NEW TOPIC