posted August 12, 2006 01:09 PM
I'm sorry it's been awhile since I posted. Didn't mean to keep any of you in suspense (except you blueford ) but actually I don't have much to report.
The short version is I still have not found the smoking gun, i.e. the proof that the ECU is field programmable. While all the evidence still points that way, and I haven't found anything to disprove it, I have yet to find the EEPROM programming code. The main reason is that I've been busy.
The longer version is that while I didn't find any programming code I did find jumps and calls to address space where there is no code. So it seems obvious I don't have all the code. Now this CPU's memory management unit allows any block of address space to be designated as Program Space Memory or Data Space Memory. I searched all the Program Space and copied all the code I found. It seems that there must also be executable code in the Data Space.
The next things I have to do are search and copy all the Data Space Memory. It's actually the same physical memory space the MMU just handles it differently. All the code I have now I got using the Breakpoint Debug Mode (BDM) port command RPMEM (Read Program Mem). I just need to rewrite my stuff to use the RDMEM (Read Data Mem) command. That is the easy part. The harder part is actually getting all the code. Last time it took me a good day, at least 8 hours, to do.
You see the first time instead of spending a week writing a fully automated program where all I had to do was click a button to get the data I put together a jury rigged collection of existing software and hardware I had on hand to just 'get'er done'. The method I used requires a lot of hand editing of captured text data files then running them through some conversion programs and cut and pasting those results into a single file and converting that to S19 format. Its crude and labor intensive but I got the code in a couple days where I still would have been writing and testing the 'automated' version.
The problem is I haven't had a free day to work on this since the 4th of July weekend. I promised my wife we would go camping this summer so I spent one weekend doing that. I promised myself last year, last two years actually that I would repaint the house so I spent a weekend with a pressure washer prepping the house only to find out I will probably have to re-side the whole thing instead. So I'm shopping around for a home improvement loan. My son is taking drivers Ed this summer and I have to spend 50 hours of dual time with him before he can get his license. My wife also decided she is tired of riding two up so I've been teaching her how to ride my '82 GPz 550 at the local abandoned K-mart parking lot. She was doing real good and was ready to do the MSF Basic rider course last weekend but that Friday she found out a friend of hers partner, who is a choke setter was killed in a logging accident when a tree being dragged up the hill came lose and rolled down the hill and hit him in the head. The guy was 36 and between them they have 4 kids. My wife said she was ok but 24 hours later in the middle of the MSF course she suddenly forgot how to take off from a stand still without stalling the bike and broke down in tears and couldn't finish the day. I think she was suffering from some kind of delayed shock. His memorial service is today. Then I have to work the rest of the weekend to finish a job by Monday for a client because Wednesday we leave on the train to go back to the Midwest for a family reunion at my sister's. That pretty much takes care of August...
But eventually the nights will get longer and the weather will turn cold and wet and cracking ECU code will be a welcome vacation from my summer 'vacation'
posted August 12, 2006 07:59 PM
Edited By: capt10ed on 12 Aug 2006 21:01
It's always difficult to lose a friend especially one so young. Offer you wife my condolences.
Keep up the GREAT WORK!!
____________
2014 Loring AFB 14 runs over 200mph
with a best of 208.1 in 1.5 miles
and 204.5 in the mile.
posted August 15, 2006 10:40 AM
thank for the update.....condolences to your wife.....its hard...i know.....
____________
2005 ZX-12R,Arata Full Ti, PC3,Gillis
Rearsets,Muzzy Velocity Stacks,BMC
Race filters.One Crazy 12
posted August 16, 2006 07:05 PM
RR - you aren't getting paid for contributing here.
The way I look at it is any well thought out info posted (like this thread) is a gift to all of those that are interested.
I've been putting my 12 back together for over a year now and yep, I understand what you mean that there is always stuff popping up to the surface that takes priority.
Take care of family and friends first. Those of us that are truly interested will be here as you have time to continue.
GPz 550 eh?
Man, that takes me back.
My first brand new bike was an '82 GPz 750.
As Lou Reed said "I love that gpz so much, you know that I could kiss her".
posted August 29, 2006 01:11 PM
UPDATE: I spent Sunday afternoon and last night working on the ECU. I rewrote my software to examine the Data Space Memory as well as the Program Space memory and I found all the same code I found before.
So here is where we stand. The ECU has a CPU with flash memory and the capability of reprogramming its own flash in circuit. We have the CPUs Flash Program Voltage Enable pin connected to the external connectors and a bunch of other pins labeled unused or memory input in the manual that are connected internally. The Flash Voltage pin is one of these. I also have all the ECU code and map data.
What I can't find in the code are any instructions that access the flash control registers. To write or erase any Flash these registers need to be accessed.
This may sound like bad news but it just means we are not going to be handed this on a silver platter. We really lucked out finding a BDM (Breakpoint Debug Mode) port on the board as it made pulling out all the code pretty easy. I guess I was hoping our luck would hold and I would find a great big sign in the code that said "reprogram ECU here". No such luck
So where to go from here?
It is not uncommon for Motorola CPUs to use a bootstrap loader program. This is a program that is loaded into RAM and executed and is used to program the Flash. If you think about it you can't be running your flash programming code out of flash memory space when you need to first erase that space to reprogram it. The program would erase itself before it ever got around to reprogramming.
The CPU used by the ECU has more than one bank of Flash. In such a configuration you could have code in bank 1 erase and reprogram bank 2 or vice versa. Still it may have been designed such that the external 'memory input' pins actually load a FLASH programmer program into RAM that is then executed. Of course that kind of code would be much harder to find than code that accesses the Flash control registers. There is nothing that would make such code standout. It reads some port pins and writes data to RAM. You could go through a substantial part of the 28,000 bytes of code before you find it.
Having been able to download all the code so easily I thought the quickest way to find all the answers would be in the software. Not having found any easy answers there I think I will now attack the code from a hardware angle. The next step will be to trace out all the main connector pins that are 'unused' or memory input' and find out where they end up and/or how they interface with the CPU. As I track each one down to the CPU I can then quickly search the CPU code to see what the software does with that pin. If in fact these pins are used to program the ECU this should lead me to that code. It will definitely be faster than going through all 28,000 bytes of code.
Of course there is another possibility. Other Motorola CPUs have a built in Monitor ROM. This is factory installed code that loads a bootstrap loader and allows you to program the Flash. When you power up and reset the CPU it goes into its normal mode and executes any code found in flash. But if you pull these pins low, and those pins high during reset it starts up in Monitor Mode for programming.
When I first uncovered the ECU circuit board I got all excited about finding the BDM port that I never researched the Monitor ROM aspects of this CPU which would have been my only avenue of attack if there were no BDM port.
The ECU CPU is some kind of Motorola CPU16 hybrid. It has the package pinout of a MC68HC916R1 but the internal flash configuration of a MC68HC916Y3.
This would be a pure internet search for information data sheets or application notes on programming these CPUs.
You can expect more frequent updates for awhile. Summer may be officially over after Labor Day but mine is pretty much over now.
posted August 29, 2006 01:35 PM
Big progress. Thanks for the update. Not that it would matter much, but from code I've been exposed to...if it has an L (lower case) in the filename separated by dashes and in the middle, it normally meant that it runs from flash. If it has an m or an mz separate by dashes, it means runs from ram and is unzipped to ram (simply stored in flash).
Bootstrap (and the way you are talking, you already know this), is used different dependent upon runs from flash or runs from ram. If runs from flash, you have to drop down to boot mode to reprogram flash. If runs from ram, bootstrap is simply a boot loader that is used in the boot process.
I haven't messed with this crap in a long time. If this doesn't help, please ignore.
posted August 29, 2006 01:38 PM
Ahhh....dual bank flash in a runs from flash system, I don't know - I always had to drop to boot mode to reprogram flash.
posted August 30, 2006 08:34 AM
UPDATE: OK, now I'm getting a little worried.
In the shop manual for the ZX-12 ECU where the ECU terminals are listed terminals 15,16,24,25, and 34 are designated Input Signal to Memory. It was seeing those terminals that first made me wonder if the ECU was reprogrammable. These terminals are all wired to the connector that is used to make the ECU read out the FI error codes. I've always dreamed of how that connector could be used to interface a laptop to the ECU.
As I talked about in my last post I am tracing out terminals I suspect could be used in reprogramming to find leads into the software I've downloaded from the ECU. Being methodical I started with 15.
I traced it out on the board. It has a 5100 ohm pullup resistor to 5V and a 10k resistor in series between the terminal and CPU pin 38. Now assuming I actually have the right pinout diagram for the CPU, it hasn't failed me yet, this pin is PortB bit6.
Referencing the user manual for the CPU (68HC916R1UM.pdf) we find that Port B data register is located at address $FFFA0B. I fire up my little BDM port and examine that address; it returns 0xDC. Considering bit 6 has a pullup on it so far so good. I ground terminal 15 and re-read the address now it says 0x9C. For those of you who can't do the binary conversion in your head.
11011100 with pin 15 at 5v
10011100 with pin 15 at ground
bit6 (the bits are 7-0) went to 0 when I grounded terminal 15. I also found that terminal 16 is bit7 of the same port. Right about then I'm feeling pretty good. I once again proved that the CPU pinout I'm using and the datasheet are valid and that I can use my BDM setup to monitor ports in realtime.
Now for the payoff; A quick search of the software to see what it does with these 'Input Signal for Memory' terminals. So what do I find?
NOTHING, nada, zip, zilch
Not a single line of code, not a LDAA, BCLR or BSET, OR or AND nothing that accesses byte $FFFA0B in any addressing mode, extended, indexed or otherwise. As this is a 16bit CPU and $FFFA0B is an odd address I also searched for any code accessing the WORD $FFFA0A (The first 8 bits are PortA the last 8 bits PortB) Nothing using the data from PortB.
Wait it gets worse. The other 3 Input Signals to Memory are ANALOG INPUTS! They go thru a resistor bias network with a bypass cap and end up at a 74HC4051 which is an 8 channel analog multiplexer. I don't know why they are analog but I do know I never heard of anyone trying to program a flash via a multiplexed analog line.
On my checklist of why I believe the ECU is reprogrammable I now have to scratch out: BECAUSE THE MANUAL SHOWS THE ECU HAS FIVE LINES MARKED INPUT SIGNAL TO MEMORY.
To quote the Black Knight from the Monty Python's Holy Grail, "It's only a flesh wound"
Actually I need some help. I loaned my manual out to a friend and I don't remember which color wire gets shorted to ground to make the ECU read out the FI codes. Could some one look that up for me and post it?
Which ever wire it is should lead me to a section of the software that flashes the FI LED. If it turns out to be a wire connected to terminal 15 or 16 then I will know that I don't have all the code. If its one of the analog lines I will trace the 74HC4051 channel select lines back to the CPU and find where in the software the channels are selected. That in turn had better lead me to software that flashes the FI LED or again it would be proof I don't have all the code.
I am kind of curious to see what, if anything, besides the FI error codes these analog inputs are used for.
posted September 01, 2006 07:49 AM
Edited By: fish_antlers on 3 Dec 2006 18:46
Thanks for the help Droid.
UPDATE:
I really don't think I have all the code. I have 28,000+ bytes of coherent disassembled code, not counting the map data which is another 16k, but it can't be all the code.
Here is why I say that.
Wed. morning I needed the wire color that droid gave me Thu afternoon. I got tired of waiting so I went ahead and traced out the 3 analog terminals 24, 25, and 34. Here is a schematic
The three lines go into the 74hc4051 analog multiplexer the output of which goes to an Analog input of the CPU, as you would expect, and the channel select lines go to 3 consecutive digital ports, PE1-3 again as expected.
Now in the software you would expect to see these bits of PortE set to outputs in the data direction register, sequenced at some point to scan and select one of the analog channels and then the Analog channel 7 result to be read.
What did I find in the code? Nothing....again. I found a line that sets bit 6 of port E to an output but no writes to port E. And most surprising of all no access of the CPU A/D converter module. Not just the AN7 port that I was looking for but no access of any kind at all, not to configure, not to read result data from any channel.
Now given that the ECU has all kinds of analog inputs like the TPS and pressure sensors and no other obvious A/D converter on the board there is only one explanation. I don't have all the code.
Then when Droid told me the Yellow wire was the FI diagnostic wire I realized that I had confused the 4 wire diagnostic plug with the 8 wire shorting plug. I quickly traced it down and found that internally the yellow wire goes to the same Port B as terminals 15, 16. The same port I posted about earlier that I could find no code on. We know this wire does something so again the only conclusion is I'm missing code.
I look at this as good news bad news. The bad news of course is I don't have all the code. The good news is it explains why I haven't found what I hoped to find in regards to reprogramming the flash like access to the flash control register and any code using the Input to Memory lines.
I have all the code I can find but there are several possibilities:
1) The code I wrote has a bug in it that prevents it from correctly sending addresses over the Breakpoint Debug Mode (BDM) port.
I wrote the code to find and download software. It found some code and downloaded it correctly. So it works, right? Maybe my find routine is screwed up but my download isn't. I think I will change my strategy. Instead of searching the chip for code and then downloading what I find I will download the entire 1 MB address space and search the download for code.
2) The BDM port can not access the entire memory space. I may be using the BDM correctly but it can't do what I want. If this is the case I will do a write / readback test of the entire memory space to locate and measure the size of the RAM areas. If this works I will write a small program that will bit bang out the entire memory space and download my program to RAM and execute it. In other words do it from the inside out instead of the outside in
But being as it is Labor Day weekend it will probably have to wait until next weekend.
In the meantime I have a something for you all to ponder.
On the back of the circuit board around the main connectors there are silk-screened labels for most of the terminals like TACO (tachometer), GP6 (gear position 6) KILL (kill switch) etc.
For the 5 'Input Signal to Memory' lines I've been tracing down the labels are: (refer back to the pdf file link above)
COS1
COS2
COV1
COV2
COV3
The two COS are digital inputs, The three COV are analog inputs. S is for Signal? V is for Voltage? The manual shows that some models of ECU have a shorting plug installed that short COV3 to ground and some do not.
My question is does COS and COV ring any bells for any of you out there?
posted September 02, 2006 06:04 AM
Last night while watching TV I suddenly had a Homer Simpson moment
My forehead still hurts.
I don't need to go search for the lost code. The FLASH modules each have a control registers set that besides controlling the programming also specifies a base address setting. All I have to do is ask the CPU where its FLASH is by reading all the base address registers.
While doing that I found that the second Flash Module is 32K of flash addressed to 0000:0000. The jumps and function calls to 'nowhere' I found in the code I do have are all with in that space. It also would make a contiguous 64k block of code when combined with the code I already found that starts at 0000:8000
The most interesting thing I found though was that this module is set to come out of Reset with its configuration STOP bit enabled. In other words it is disabled and unreadable that is why it appears invisible to the BDM port. I also found the RAM to be disabled.
I did find code that turns them both back on but only after it tests for a certain hardware state. I need to either duplicate that state or figure out some way to change that bit. The BDM port does also have write commands as well as read commands so it may just be easier to rewrite my BDM software and try to change the bit directly.
I look at this as good news. There is more code. I know where it is and what I have to do to get it.
I probably could have figured this out sooner if I had read more of the 500 page CPU user's manual than I did before I started this part of the project. But you know how it is, whoever reads the manual first?
quote:A quick search of the software to see what it does with these 'Input Signal for Memory' terminals. So what do I find?
NOTHING, nada, zip, zilch
an obvious possibility (which unfortunately doesn't make it easier to find), but it's quite possible the code stores an offset to the terminals in question (to be added to a base address).
posted September 03, 2006 06:28 AM
I contsantly follow post to see what is happening. But I have to ask WHEN you finally crack the code, will it also work for the 04 and 05? Or are we still shi# out of luck regarding derestricting them.
____________
2014 Loring AFB 14 runs over 200mph
with a best of 208.1 in 1.5 miles
and 204.5 in the mile.
posted September 03, 2006 09:49 AM
Edited By: ridgeracer on 3 Sep 2006 10:51
quote:an obvious possibility (which unfortunately doesn't make it easier to find), but it's quite possible the code stores an offset to the terminals in question (to be added to a base address).
It in fact does exactly that. As you may remember upthread we talked about how this code was obviously compiled from some higher level language, probably C. The code is very methodical and predictable. The following example is how the code clears bit 7 of PortH data register ( 0x0FFA0D )
quote:. But I have to ask WHEN you finally crack the code, will it also work for the 04 and 05?
Don't know for sure but here is my educated guess.
If you spend time and effort developing a hardware/software interface for your ecu and you change the ecu hardware why not write it to use your existing interface. That would be the most economical way to do it. Any way thats what Dilbert and Wally would do.
On the other hand they may have a different industrial cultural engineering ethic in Japan.
Of course the new 32 bit ECUs may have more features than the old interface could handle and it may be different for that reason.
I now believe I can successfully read all of the code, and RAM, from the CPU.
When I figured out that one of the Flash modules and the SRAM module were disabled during startup I started looking at the code I did have to see what if anything I could find. I found that eventually if the board passed some startup self test code it turned both modules on. I was checking into this when it suddenly occurred to me that my BDM port software may be causing the problem. Part of putting the CPU in BDM mode is resetting the CPU.
What if I wasn't giving the CPU time enough to run its start up routines before forcing it into BDM mode?
After putting a delay between the reset and BDM setup my search routine found another 32k of code and 4k of RAM. I know believe I have all of the ECU code.
Here is what I have
0000:0000 - 0000:01FF Reset and Interrupt Vectors
0000:0200 - 0000:EC6D 60,013 bytes of program code
0000:EC6E - 0000:FFFF 5,009 bytes of unused flash space
0001:0000 - 0001:7A21 31,265 bytes of data (map)
0009:0000 - 0009:07FF 2048 bytes of program code
A quick search of the new code and I have found all the things that I was complaining about up thread. Port B reads and writes to Port E followed by analog value reads.
That's the good news. The bad news is I now have twice as much code to plow through.
I'm currently trying to decide what the best approach is. I could go through the code from the beginning and learn how the ECU works and look at the Input Signals to Memory when I get to them. Or, I could concentrate on the memory signals but would I understand where they took me. If they fundamentally changed the way some aspect of the ECU worked would I understand the change with out a background in how the basic ECU code works?
HOME
NEW TOPIC
posted August 12, 2006 01:09 PM
) but actually I don't have much to report. 
Edited By: 
