HOME ARTICLES JOIN GALLERY STORE SPONSORS MARKETPLACE CONTACT US  
Register | FAQ | Search | Memberlist
Username:    Password:       Forgot your password?
BIKELAND > FORUMS > ZX12R ZONE.com > Thread: Hacking the Planet one ZX-12 ECU at a time. NEW TOPIC NEW POLL POST REPLY
ridgeracer


Pro
Posts: 1309
posted August 12, 2006 06:09 AM        
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'



  Ignore this member    Click here to visit RidgeRacer's homepage. 
capt10ed


Expert Class
Posts: 326
posted August 12, 2006 12: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.

  Ignore this member   
Jason9R


Novice Class
Posts: 47
posted August 13, 2006 01:51 AM        
Thanks for the update RR.
  Ignore this member   
ninja12


Needs a job
Posts: 3310
posted August 14, 2006 09:37 PM        
+1

  Ignore this member   
swft


Needs a life
Full throttle!
Posts: One MEEEEEELLION
posted August 14, 2006 11:54 PM        
quote:
I will probably have to re-side the whole thing instead.


Doin that right now. Good luck! Did you have LP siding? I went from LP to Hardie Plank
____________
82 Gpz750, 84 Ninja 900, 2000 ZX12R (Muzzy Big Bore Kit), *another* 2000 ZX12R (Muzzy custom stroke crank 1341cc motor), 2004 ZZR1200, 2005 ZX10R, 2007 ZX14, 2008 Concours 14, 2014 Versys 650, 2014 Yamaha WR450F, 2015 Ninja H2


  Ignore this member   
navpreet318


Expert Class
one crazy 12
Posts: 192
posted August 15, 2006 03: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

  Ignore this member   
blitzkrieg


Needs a job
Road kill = Free lunch.
Posts: 2044
posted August 16, 2006 12: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".

  Ignore this member   
blueford


Needs a job
Posts: 2984
posted August 24, 2006 06:29 AM        
quote:
thank for the update.....condolences to your wife.....its hard...i know.....


+1

  Ignore this member   
Megabyte


Pro
Posts: 1047
posted August 24, 2006 07:22 AM        
quote:
quote:
I will probably have to re-side the whole thing instead.

I went from LP to Hardie Plank


Me too!
____________
We First make our habits and then our habits make us.

  Ignore this member   
Wideout


Expert Class
Posts: 300
posted August 24, 2006 09:49 AM        
quote:
quote:
quote:
I will probably have to re-side the whole thing instead.

I went from LP to Hardie Plank


Me too!


9 grand later +3

  Ignore this member   
ridgeracer


Pro
Posts: 1309
posted August 29, 2006 06:11 AM        
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.

BTW thanks for the Hardie Plank tip



  Ignore this member    Click here to visit RidgeRacer's homepage. 
Wideout


Expert Class
Posts: 300
posted August 29, 2006 06:35 AM        
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.

  Ignore this member   
Wideout


Expert Class
Posts: 300
posted August 29, 2006 06:38 AM        
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.
  Ignore this member   
ridgeracer


Pro
Posts: 1309
posted August 30, 2006 01: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.




  Ignore this member    Click here to visit RidgeRacer's homepage. 
droid


Expert Class
Posts: 133
posted August 31, 2006 08:40 AM        
Yellow wire
  Ignore this member   
ridgeracer


Pro
Posts: 1309
posted September 01, 2006 12: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

http://www.olympunet/mbially/ECUsch1.pd

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?

Configuration Option Voltage?
Cool Option Switch?


  Ignore this member    Click here to visit RidgeRacer's homepage. 
ridgeracer


Pro
Posts: 1309
posted September 01, 2006 11:04 PM        
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?

  Ignore this member    Click here to visit RidgeRacer's homepage. 
fish_antlers


Administrator
The Truth is Out There
Posts: 21764
posted September 02, 2006 05:32 AM        
quote:
But you know how it is, whoever reads the manual first?




____________
What business is it of yours where I'm from, Friendo?


  Ignore this member    Click here to visit fish_antlers's homepage. 
jscarb2


Expert Class
J&S RACING & PERFORMANCE
Posts: 176
posted September 02, 2006 07:13 AM        
this is so cool! short and sweet
  Ignore this member   
frEEk


Administrator
ummm... yeah
Posts: 9650
posted September 02, 2006 10:29 AM        
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).

  Ignore this member    Click here to visit frEEk's homepage. 
capt10ed


Expert Class
Posts: 326
posted September 02, 2006 11:28 PM        
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.

  Ignore this member   
ridgeracer


Pro
Posts: 1309
posted September 03, 2006 02: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 )

ldab #0Fh
tbyk
ldy #0FA00h
bclr 0Dh, Y, #80h




  Ignore this member    Click here to visit RidgeRacer's homepage. 
ridgeracer


Pro
Posts: 1309
posted September 03, 2006 03:00 AM        
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.



  Ignore this member    Click here to visit RidgeRacer's homepage. 
ridgeracer


Pro
Posts: 1309
posted September 03, 2006 11:26 AM        
UPDATE:

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?

For now I will just keep chipping away at it.

  Ignore this member    Click here to visit RidgeRacer's homepage. 
blueford


Needs a job
Posts: 2984
posted September 03, 2006 10:46 PM        
That's great, fantastic job, we're almost there!
  Ignore this member   
All times are America/Va [ This thread is 39 pages long: 1  -  6  7  8  9  10  11  12  -  10>  -  39   Next» ] < Previous Thread     Next Thread >
Quick Reply:

Email Notification: Send all replies to your email address.
BIKELAND > FORUMS > ZX12R ZONE.com > Thread: Hacking the Planet one ZX-12 ECU at a time. NEW TOPIC NEW POLL POST REPLY

FEATURED NEWS   Bikeland News RSS Feed

HEADLINES   Bikeland News RSS Feed


Copyright 2000-2015 Bikeland Media
Please refer to our terms of service for further information
0.39638710021973 seconds processing time