Siemens Simtec help greatly appreciated

European GM ECUs and PCMs
silentshout
Posts: 25
Joined: Sat May 17, 2014 5:49 am
cars: Holden Barina XC SRI 1.8L

Siemens Simtec help greatly appreciated

Post by silentshout »

Greetings All

Ive been attempting to disassemble the .bin file from my Barina SRI for a while now and managed to get some help from this site last year.

The trouble with this particular ECU is the fact that unlike most other ecus, the Simtec ecu doesnt seem to keep the map axis data and size near the maps and rather places them elsewhere in the cal segment (bin file)

I was wondering if someone more experienced in disassembling ecus could give advice or help me in finding the maps and axis data for the maps?

So far what I know is:

Injection table at 44BB
Spark tables at 3B93 and 3CB6
Checksum is 16 bit at 5EE0

Ive had a look in winols and the addresses definitly look like maps however i am unsure of the size and due to not knowing the x and y axis data im unsure how to interpret the z axis data.
Im hoping to be able to create an XDF file so the bin can be tuned in the TunerPro software as its a much more familiar tuning interface than winols.

Any help is greatly appreciated, Attached is my original file from the car, i can provide one from an astra G aswell.

The difference between the two is the astra was 90kw whereas the Barina SRI was 92kw with no changes to intake or exhaust manifold design i believe its down to the ecu tuning.

My goal was to compare the two and find out what was different which would hopefully give me some idea on where to go.

I understand its not a delco or bosch ecu but im hoping someone has the know how to help out.

Ive contacted every tuning company within 200km of the Gold Coast and the ones that didnt laugh at me informed me they had no idea how to tune the car.

Many many thanks in advance,

Kind Regards
Rick :)
Attachments
Base read.bin
(23.75 KiB) Downloaded 517 times
yoda69
Posts: 1215
Joined: Sun Mar 15, 2009 10:20 am
cars: 2004 VYII Acclaim Wagon V6 Auto LPG/Petrol
2004 VYII Berlina sedan V6 Auto
2005 VZ Monaro CV8 manual
Location: Geelong, VIC

Re: Siemens Simtec help greatly appreciated

Post by yoda69 »

It's been a while, but I'm pretty sure 1.8 litre in the barina was without EGR valve and the 1.8 astra has an EGR valve.
The disassembly is a little beyond me, but hopefully some others can help.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Siemens Simtec help greatly appreciated

Post by antus »

I think perhaps you might need to physically test here. For spark, assuming you can run the ecu with your changes loaded, make the whole table a value from the top right of the table (should be very small so safe spark advance), then at a certain row or column increase the value. Then put a timing light on it and gradually increase the revs and note where advance changes. This will give you a column or row value for rpm. Adjust the table and repeat. If your table is the other way around then load (map?) wont reach the point you changed when free revving and advance wont change. Then change the way your looking at it by 90 degrees and try again.

Another option would be get and use a chip emulator like an ostrich which i think can tell you the memory addresses the computer is reading. Then you could set it up to just monitor the table and run the car and see what value its loading from where while its running.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
silentshout
Posts: 25
Joined: Sat May 17, 2014 5:49 am
cars: Holden Barina XC SRI 1.8L

Re: Siemens Simtec help greatly appreciated

Post by silentshout »

Many thanks ill look into the Ostrich later when im home.

As for loading the map etc it is a little hard to check as the loading process takes around 15mins to write to the ecu. I have solved the checksum issues as the car needs a new checksum whenever a change is made.

What tools or programs do you guys use for viewing, decyphering or checking bin files?

Currently using winols which has discovered 43 "potential maps" based on looks however it didnt pick up the maps at the addresses provided so im not going to trust it.
Also been using Winhex or something like that which isnt car related however it makes looking at hex much easier than winols. only use it to find values and patterns.

Another thing to note is this particular ecu sadly doesnt have the x and y axis data before, in or after the map. Im told that its located elsewhere in the file and the ecu accesses it for reference.

Are there any tricks for finding values prehaps? I tried to find the RPM limit to maybe see if i can find a pattern around it and find the rev limiter but that didnt turn up anything so im guessing they may use a funny number such as "6398" instead of the "6400" rpm limit i supposidly have.


Also i have the 2001 barina which does have the EGR valve, in 03 they had a facelift and took the EGR valve off as it was pointless and caused more trouble than it helped.
Been there dealt with that :) a $10 blanking plate from the uk and now the car actually functions, doesnt stall, doesnt bunny hop and doesnt spriatically rev while stationary at the lights.

Cheers for the replies guys :)
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Siemens Simtec help greatly appreciated

Post by antus »

The ostrich is for a stand alone DIP style chip. If its flash then its not going to be compatible.

I'll describe what your looking for when locating tables. This is obviously tunerpro but the concept can be applied to any similar tool, including winols.

Firstly look at the bin in a hex editor. Your looking for gradual changes and blocks of similar data. Keep in mind that values may be 1 or 2 bytes wide. In this case its 1 byte which makes it a bit clearer.

This is an 11P bin, and we already know where the table is so its good to use as a learning exercise. So cheating, the spark table (for power mode) is at 0x7534. Its 20 rows and 11 columns.

So pretending we dont know that, we have a look with tools->advanced->hex editor
finding tables in tunerpro 1.png
finding tables in tunerpro 1.png (60.74 KiB) Viewed 10265 times
Looking at the data in the hex editor, we can see a block that looks like it may be a table, which Ive marked with green lines. This would be a guess, based on the fact that the data before it is 14 10 00 0B which is not smooth then it jumps up to 39 39 39 and has a bunch of smooth numbers... This could easily be wrong, but you need to start somewhere.

So then we look at the data 39 39 39 39 39 0E 0B 09 06 03 00 69 69..

From this we deduce that it is a slope because the numbers are decreasing and they are not all over the place. Then we jump back up to 69 69. So probably one of the axis is 11 bytes long (marked in red) which is the point where the constant slope ends.

So we want to try and visualise this data to get it right. In tunerpro we go tools->advanced->3d data viewer. Set the address to our suspected start, rows to a total stab in the dark (10), and columns to 11. Ive put columns=10 in the first screen shot to show you in the screen shot what misaligned table data looks like. You can see there is a shape to it, but its offset diagonally. Thats a sign you are looking at a table but your number of columns is wrong. So l then bump the number to 11 from the analysis above. And then I bump up the rows a bit and it looks like the same table.
finding tables in tunerpro 2.png
finding tables in tunerpro 2.png (19.99 KiB) Viewed 10265 times
So, now were talking. We can assume columns=11 is right and rows is at least 15, probably more.

Can we validate the start? It looks like the first row does not match the rest in shape but it is sain for a particularly low rpm. I know from the xdf I already have that this is the right first row, but in a real session I would not. I could quite easily make an error here and discard the first row and start the table on the second row. In order to avoid this I would validate the findings against other factory tunes as they are less likely to have poor quality data than random tunes and hopefully decide the column is good.

So now the rows. We could keep incrementing this number by 1 until the newest row to appear looks wrong. But heres another way. We go back to the hex, and the green block I have marked spans from 7534 to 766E. So thats 766E-7534=13A bytes. Lets start working in decimal for these smaller numbers: 13A (hex)=314 bytes (decimal). 314 bytes / 11 (columns) = 28 rows. I set this and take a look and can see i've gone too far. Out of curiosity I kept going, up to 40. At 40 I can see what looks like 2 tables side by side. So, time to keep in mind that there is a second table here and it has the same number of columns (11). Bonus find! Whats more the 2 tables have the same shape, just offset. Since this application is for a VR which has power and economy modes, and because the shape is typical of a spark table it can be deduced we have found power and economy spark.
finding tables in tunerpro 3.png
finding tables in tunerpro 3.png (22.3 KiB) Viewed 10265 times
Some more experimenting shows 20 is probably the correct number of rows for the table I was originally looking for.
finding tables in tunerpro 4.png
finding tables in tunerpro 4.png (22.05 KiB) Viewed 10265 times
We can go back and try and define the other table later.

Now for Axis. This is hard one. It really helps to know what to expect from your manufacturer tables and typical equations for types of tables. I probably would have been better off showing a factory Holden bin, rather than 11P here... as less assumptions can be made for aftermarket code :lol: But if it was original GM I'd go and take a look at other similar defined bins, and apply the same equation and check that degrees look sain, and apply the same headings once I had found another table that has the same resolution for the same purpose.

If someone has the disassembly skills they can find the references to this table in code and deduce more data by analysing that. This is often done, but is beyond the scope of this document. Anyway I hope this helps you and helps others understand the work involved. Ive been meaning to write an overview of this process for a while, so here it is! (i'll probably move it to a PDF later, and drop a link here instead).
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Holden202T
Posts: 10311
Joined: Sat Feb 28, 2009 9:05 pm
Location: Tenambit, NSW
Contact:

Re: Siemens Simtec help greatly appreciated

Post by Holden202T »

nice write up antus!
Dylan
Posts: 3355
Joined: Mon Aug 02, 2010 6:35 pm
cars: VR Commodore V8

Re: Siemens Simtec help greatly appreciated

Post by Dylan »

That's a good read i got something out of it. Thanks
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: Siemens Simtec help greatly appreciated

Post by vs ss »

Well done antus,thanks. :thumbup:
silentshout
Posts: 25
Joined: Sat May 17, 2014 5:49 am
cars: Holden Barina XC SRI 1.8L

Re: Siemens Simtec help greatly appreciated

Post by silentshout »

Thank you very very much :D

I didnt realise tuner pro had its own hex editor in it and can view data in 3d tables too.

Ill be playing around with it a bit more now i think. Unfortunately there arent any similarly defined bins out there for my car so it will make it very very hard to find anything.

Im currently on the hunt on the opel forums for anyone who has had their astra or barina with the 1.8l tuned and could out of the interest of science let me grab the bin file off them to compare the two.

as they would have probably paid an arm and a leg for it i doubt anyone will let me but one can hope :)

This writeup is super handy for finding tables etc, but what if you were looking for the rev limiter or idle speed? i assume it gets much harder as they are just individual values vs tables.

Thank you again i will keep everyone posted on how I go. Happy to share any discoveries as i guarentee there are some of you out there with a z18xe in an astra, barina or zafira etc. Horrible things to crack :)
Leinad78
Posts: 10
Joined: Tue Jan 13, 2015 4:26 pm

Re: Siemens Simtec help greatly appreciated

Post by Leinad78 »

Having a short look at your file, it turns out its pretty much the same structure as Siemens MS43 and MS42 :mrgreen:

The axis definitions are separated in the first part of that file and are pretty easy to find. However, the correlation to the maps isn´t easy and maybe only possible by disassembling.

Heres how to find them:
8bit_axis.jpg
8bit_axis.jpg (700.09 KiB) Viewed 10235 times
Note the raising and falling look on the right side. That normally shows where maps are, bit in this case you can see the column size is changing alot. That does mean they are just 2d maps or the axis descriptions. But as the size of the "map" now is in front of it, its no map ;)

By having a look at the 16bit equivalent, they are much easier to find.
16bit_axis.jpg
16bit_axis.jpg (964.91 KiB) Viewed 10235 times
Note: 008 gives the actual size of that axis descriptor.


This is what the guys at Siemens MS41 are using to find the correlation, but either i´m not clever enough to work it out at MS43 or its just not working at newer ecus. Maybe you guys have more luck.
map locations array pointers.jpg
map locations array pointers.jpg (152.09 KiB) Viewed 10235 times
Post Reply