Attn: Anyone With Comp Prog Or Ee Talent

[BlackT5]

I can tune me7 and me5.....Anyone have any stock BINs that can post up.

Ill take a look and see what I see.

←

Unless someone has already done so, i'll send you my stock rom. PM me your email address.

[joel142]

The manual is posted on the Volvospeed main page. Go to Referneces and at the bottom of one of the OBD2 articles EOBD wrote.

I just checked that out. Those interested may want to check out the Seimens product folder - there's a lot more detail there:

http://www.infineon.com/cgi/ecrm.dll/ecrm/...v.jsp?oid=13735

I was reading through some of the varients of the 80C517 (there are others that are mask programmable which could be real trouble) and the basic ones seem to be:

80C517 -- 8KB onboard ROM, didn't see a protection mechanism. If the /EA pin is held high then it executes out of an external ROM.

80C537 -- no onboard ROM exclusivly uses external ROM

80C517A -- no onboard ROM, exclusivly uses external ROM

80C517A-5 -- 32kB onboard ROM, can be protected during programing with the option of expanding the ROM with an external chip.

The 'A' series is billed as a refinement of the original '517. Personally, the A-5 varient chills me the most as you could do all kinds of crazy things in 32KB of totally private program memory to make the external ROM very difficult to work with.

On the otherhand, if it's the classic 517 for sure then there is a very heartening passage from the Pin description portion:

External Access Enable.  When held at high level, instructions are fetched from the internal ROM when the PC is less than 8192. When held at low level, the SAB 80C517 fetches all instructions from external program memory. For the SAB 80C537 this pin must be tied low

At any rate I obviously still have alot to learn, but, this can't be totally impossible given the number of successful parallel development efforts. As far as checksums go and just making lives of reverse engineers difficult, there are a bewildering array to be sure.

I'll go check out the pgmfi.org site.

Joel

[EOBD]

A few images of the PCB iniside the ECU. There are three images, not that great quality but enough to let you see the layout. The green coloured device to the bottom of the first image is infact a ZIF socket I added for development work. This ECU is the one that will be sacrificed to this project.

Top image of the PCB

Left sided image of the PCB

Right sided image of the PCB

I will post more on the hardware once I have finished some prelim work

[Slater]

What are the extra little wires for?

[550]

my guess is the were traces that were not on the board it self. They seem to stem from a small IC, and go into the larger IC (the chip IIRC)

[EOBD]

I was attempting to get the boards own in circuit flash programming circuit to work, but I never did have success with it. I never really figured out how the board was manipulated to get it to work.

There is a secondary micro on the board, its the square device right in front of the ZIF socket at 12 o'clock in the first image. It has traces running from it to the FLASH chip. I assumed it was a backup micro, it may infact do other things. I am presently searching for a Datasheet on it.

[Slater]

I was attempting to get the boards own in circuit flash programming circuit to work, but I never did have success with it.  I never really figured out how the board was manipulated to get it to work.

There is a secondary micro on the board, its the square device right in front of the ZIF socket at 12 o'clock in the first image. It has traces running from it to the FLASH chip.  I assumed it was a backup micro, it may infact do other things.  I am presently searching for a Datasheet on it.

←

Sweetness - keep us posted.

[(_8*(l)Homer]

Hey Slater,

I'm

[(_8*(l)Homer]

Hey Slater,

I'm an out of work C++ programmer with quite a bit of soldering and EE experience.

[Guest Guest_BrightonBreezy_*]

Hey Slater,

I'm an out of work C++ programmer with quite a bit of soldering and EE experience.

←

And I'm a professional C++/Java/.Net developer (in work). Let me know if I can be of any assistance.

[drlava]

While this project is very cool and ambitious, it is also very dangerous. If you are able to get some help from the netherlands guy who has experience disassembling motronic ecus, then great. A good first step will be to disassemble the binary from the ROM and, with an understanding of the microcontroller that is on it, begin to comment it and label blocks of code and data tables. I have programmed a few timing-intensive assembly programs and I can tell you that it will be very very difficult to write a good, safe, engine control program from scratch without years of experience. So, dor this stage of the project it's better if we can decompile and understand the stock and aftermarket programs. Re-mapping curve tables is cake compared to adding subroutines and disabling certain aspects of the ECU.

We should set up a central codebase disassembly commenting page for those of us that know how to do so. At first the code will look like just a bunch of addresses and math, but with the hardware figured out, and using the microcontroller data sheet, we will begin to be able to assign labels to sections of code and to data variable RAM locations. So, here is a suggestion of how to proceed:

1) Set up a collaborative PRIVATE web section where the workers on this project can share information and outside entities cannot meddle in our affairs.

2) Gather and post data sheets on each and every component on the board.

3) Begin to post the hardware dissassembly information, beginning with which sensor goes to what pin on the ECU, and then trace it on the board through the A/D conversion and finally (most importantly) get the address by which the data point is accessed. The analog data may be digitized on the microcontroller itself, so the pin# of that input should be known. Also, remote ECU programming with the built-in bootstrap micro would be a great plus for this project. (lots of hardware work, soldering, and tracing, continuity testing, etc.)

4) Extract the ROM binaries from ECUs of the same model including stock and aftermarket code so we can see the changes they made and aide in checksum calculation.

5) Begin to put names to the disassembled code sections and variable locations, isolate subroutines, and and get a program flow diagram. (this pretty much requires 3) to be done)

6) continue with 5) for a long time until we think we know enough to change a little something and someone is brave enough to actually test it out!

once we are at this point, great progress can be made rather quickly.

[lax01]

I'm guessing we could use SourceForge.net as a good collaboration page....just a suggestion

[EOBD]

drlava,

Your post is very good. In respect of having own PRIVATE space that could be done. I have my own server space (10gb storage & 80gb bandwidth) and would be willing to work out something with those people who are interested. I can set up protected web space access so only those validated members can have access. Also can set up a forum area as well. If people need ftp access that can be done as well.

I am working on some of the hardware layout just now. SOme of the chips used are now obselete so getting datasheets is hard.

[Guest DougK]

If you give me decent software to tune by, I am always willing to try it out.

[jross]

May I make a post in reference to Dr.Lava's suggestion?

I've been thinking about doing somethign similar to this for a while. I really think we should try and log the ECU input/output signals during normal driving (I'd be willing to work on this on my car). We could also test various components in terms of their I/O response, and hopefully use that to build a small electrical test envirornment, where we can tweak ECU settings and determine exactly what is being modified in a labratory enviornment, without risking an engine.

On a related note, I have access to VADIS and an 850 wiring guide. There's alot of good information I'll post up here later in regards to I/O data.