Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Using Enginuity


Guru

Status: Offline
Posts: 2338
Date:
Using Enginuity


Enginuity is currently down and finding support is not really easy. Maybe someone over here could help ?

In a process of generating a definition file using the analyze tool for sh7052 file I get an error message "Definition file not found" ?

The definition is found here:
http://macmadigan.no-ip.com/Public/ECU/Enginuity/SH7052.xml

EDIT - You can download the software, e.g. from here:
http://www.ken-gilbert.com/wrx/enginuity/


-- Edited by PetriK at 20:59, 2007-11-25

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:
Need Internal ID tags


An Enginuity definition can define multiple vehicles. The way it tells which definition to use with which BIN file is by the internal id tags.

In the ZX-12 ECU there is actually an ascii string in the map the is the same as the partnumber, 21175-1069, so I used that as a unique string to the BIN. On the 16 bit busa I didn't find any ASCII version string so I just picked some random ascii string.

Looking at the 32bit busa I see the same thing, or don't see as the case may be. So picking some string at random put the following tags in your romid at the top of the xml

(internalidstring)TOJFB(/internalidstring)
(internalidaddress)0x3689B(/internalidaddress)

note I used () instead of >< because the board treats it as a tag


Also your x axis data 23 is missing a /data end tag



-- Edited by RidgeRacer at 23:30, 2007-11-25

__________________


Guru

Status: Offline
Posts: 2338
Date:
RE: Using Enginuity


Excellent, thanks ! I need to work on the x and y axis, but finally making progress.

EDIT - scaling units is required, otherwise out of bounds message is likely. Corrected the xml code.

EDIT2 - I am a bit uncertain about the types used on these tables.

Spoiler



-- Edited by PetriK at 14:44, 2007-11-26

-- Edited by PetriK at 15:12, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

According to the analyze program there is 16 tables at the end of the flash area. Based on information from earlier ecus and similarities of those an educated quess can be made that those are fuel and ignition tables.

There is 946 bytes between the tables and the x header contains 23 elements and y header contains 36 elements just before the start of the table.

Based on this information the following table locations can be calculated:

Assumed fuel and injection map locations based on Analyze program
AnalyzeIntegerDiffTableX-axisY-axis
100032D12208146
946
32D1632CA032CCE
2000330C4209092330C83305233080
3334762100383347A3340433432
4338282109843382C337B6337E4
133BDA21193033BDE(36+23)*2)+4)" style="background-color: transparent; border: #d4d0c8">33B6836*2)+4)" style="background-color: transparent; border: #d4d0c8">33B96
233F8C21287633F9033F1A33F48
33433E21382234342342CC342FA
4346F0214768346F43467E346AC
134AA221571434AA634A3034A5E
234E5421666034E5834DE234E10
3352062176063520A35194351C2
4355B8218552355BC3554635574
13596A2194983596E358F835926
235D1C22044435D2035CAA35CD8
3360CE221390360D2(36+23)*2)+4)" style="background-color: transparent; border: #d4d0c8">3605C36*2)+4)" style="background-color: transparent; border: #d4d0c8">3608A
436480222336364843640E3643C

The one thing that needs to be verified is to understand the memory addressing model and type declarations for this (and other information).

Anyway I will write an excel sheet to provide an automated enginuity definitions file generation for this information which can then be updated in case the current guesswork about typedeclarations is incorrect.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:

First your axis definitions should all be endian="big", not small.

Then I'm pretty sure your X axis across the top is % throttle.

Your lowest value is 14080 which divided by 65536 = .2148 or 21.5%
Your highest value is 59392 which divided by 65536 = .90625 or 90.%

These are the same throttle values used by the other ecus
For scaling use:
<scaling units="%" expression="x*.00152587890625" to_byte="x/.00152587890625" format="0.0" fineincrement="1" coarseincrement="5" logparam="P8"/>

.00152587890625 is the reciprical of 65536 * 100 and converts a 16bit to %

Next is the RPM Y axis. If you use the conversion constant 5.12 used by both the kawasaki and suzuki 16 bit ecu you end up with a rev range from 400 - 7400 rpm.  400 is kind of low. All the other ECUs start at 800. Also 7400 is low for a bike that redlines at 10600. So I was thinking of using 2.56 which gives us a range of 800 to 14800. The 800 is a good starting place and while 14800 seems hi it does extend past the redline. Until we can prove otherwise I'd go with 2.56. All the map data is the same past 8800 anyway.


Here is your B map modified using the above

<table type="3D" name="Map B" category="Maps" storagetype="uint8" endian="big" sizex="23" sizey="36" storageaddress="0x330C8">
<scaling units="UNKNOWN" expression="x" to_byte="x" format="#" fineincrement="1" coarseincrement="10" />
      <table type="X Axis" name="Throttle" storagetype="uint16" endian="big" sizex="23" storageaddress="0x00033052" >
        <scaling units="%" expression="x*.00152587890625" to_byte="x/.00152587890625" format="0.0" fineincrement="1" coarseincrement="5" logparam="P8"/>
      </table>
      <table type="Y Axis" name="Engine Speed" storagetype="uint16" endian="big" sizey="36" storageaddress="0x00033080" >
        <scaling units="RPM" expression="x/2.56" to_byte="x*2.56" format="#" fineincrement="50" coarseincrement="100" logparam="P8"/>
      </table>
</table>



__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent ! I vaguely recall the maps from 1999 busa being very alike and about in same order. Anyhow there is supposed to be 2x4 pressure maps and 2x4 TPS based maps so the scaling elements should not be as alike as they are ?

Anyhow...here you are with updated xml definitions (updated to the initial file in the beginning of this thread to avoid having misleading information left).
http://macmadigan.no-ip.com/Public/ECU/Enginuity/SH7052.xml

Here is the excel tool to generate the xml from addresses (very crude, but works).
http://macmadigan.no-ip.com/Public/ECU/Enginuity/Tables.xls

Here is the link to the .bin
http://macmadigan.no-ip.com/Public/ECU/SH7052.BIN

And latest version (when writing this) of enginuity can be found from here:
http://www.ken-gilbert.com/wrx/enginuity/

Just occured to my mind that if those are the exact multipliers that perhaps could help us to find the RPM limiter ?


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:
Something wrong with your BIN?


Something is not right here.

If you look at your Enginuity definition for the a map you have the address as 0x32d16 but if you look at it in analyze the map obviously starts at 0x32d12. Also if I check IDA hex view I see 0x32d12 as the correct map address.

However the maps work on Enginuity. They look correct. On all the other definitions I have done the addresses agreed, and the maps worked. Also your bin is 4 bytes short of going all the way to 0003:FFFF. And when you consider that your program pulled 4 bytes (32bits) at a time it makes me wonder if something is missing somewhere.

I think this needs to be resolved before we start changing values and reflashing maps.

__________________


Guru

Status: Offline
Posts: 2338
Date:
RE: Using Enginuity


Yes you are absolutely correct - I too noticed the 4 bytes (a longword ?) difference between the analyze and Enginuity but as both are new to me I did not pay much attention to it. I recall reading some problems with the 32 bit support of Enginuity - so it is possible that enginuity does not support the 32 bit files so well ?

But if you say that there is 4 bytes missing from the total lenght that means surely something !!!

Regarding this I have have gone over and over the reliability of the .bin data for several times in my head during past couple of days:
- The jump vector tables in the beginning match, so there is no offset difference ?
- There is no row level checksum error from the downloading process, so no row contain incorrect data ?
- The row count matches, so no single row is missing ?
- The idapro can dissassemble the files quite well without address offset (the variables match) ?
- The .mot was downloaded twice, no difference between downloads ?

Hmmm, more food for an intensive thinking to keep the mind in top condition smile.gif
... on the other hand, the mot2bin does not take in the rowcount so its possible that there is one row downloaded twice and missing one row ?
... alternatively is the memory addressing model for 0x003xxxx is different than with other segments ?
... should the .mot file actually have address 0x0000001 for the first byte ?
... is there a bug in the download program for the first byte ?
... There is a tag for motorola in analyze which I do not understand ?
... Is there a ROM checksum or other which is not downloadable at the end of the data ?

edit:
... there is an offset parameter in mot2bin... maybe that has a role in this ?
... I do not write the last longword to the .mot file if it contains 0xFFFFFFFF, maybe the mot2bin can not guess how long the .bin should be without having the last byte written to the .mot file smile.gif) See the spoiler below for more details...

Spoiler



-- Edited by PetriK at 18:56, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:

It sounds like the problem is with Enginuity. It may be that you have told Enginuity that it is a 256kB file but because it is in fact 4 bytes short of 256kB it is messing up the Enginuity pointer math some how.

Maybe you should add a dummy last line to your mot file to add the missing 4 bytes when you convert it.

__________________


Guru

Status: Offline
Posts: 2338
Date:

That is likely as these are the four last records from sh7052 in .mot format are:

S3090003FFF04242333419
S3090003FFF44242333514
S3090003FFF82256FFFF86
S3090003FFFFFFFFFFFFF9
S50500000004F6


... which also made me to think if the S5 record data actually should be 0004 instead of 00000004 for mot2bin - then only allowing max FFFF records for a .mot file segment ... (well in this .bin there is only 0x9025).

Anyway this finding does introduce a potential problem of if enginiuity can be trusted for writing the map values ? But lets first find where are the rev limits, top speed limits and which maps are used as basic maps and if the others are behind a map swich (possibly cos or ms) ?



-- Edited by PetriK at 20:32, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

As much as I wanted that to be true, I am afraid there is more to this.

When using mot2bin after adding the last record this is the result:

offseterror

1) The s-record produces bytes backwards  ?
2) The FDT reads them backwards as a bin ?
3) I write them backwards ?

Here is the program I using, dont see anything wrong with that...

Spoiler


Sometimes it is just one step forward, two steps backwards... but I am really grateful that its noticed now !



-- Edited by PetriK at 20:39, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

EDIT - Everything OK after fixing the last record into the .mot file.

Error in the posted data (and C programming code),

S3090003FFF04242333419
S3090003FFF44242333514
S3090003FFF82256FFFF86
S3090003FFFCFFFFFFFFFC
S50500000004F6

Lastwordfixed



Will update the files liked earlier to have the correct information.



-- Edited by PetriK at 20:59, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

OK - fixed the last byte error in both .mot and .bin which showed on as last byte error on enginuity tables.

lastbyteerror

Enginuity seemed to count from the last byte onwards so also fixed the .xml and .xls accordingly.

Everything seems to be ok now, no more +4 bytes. I feel so silly about going back and forth with this. (I tested the mot2bin conversion several times, but somehow it did not update the FDT until I deleted the file from dos window - looks like windows cache is out of sync between dos window and windows file system. I must check this with my day time job and with the sw dev persons if they have ever noticed the same.).

lastbyteok

Below recalculated map positions.

















Analyze

Integer

Diff

Table

X-axis

Y-axis

Map1

1

00032D12

208146

946

32D12

32C9C

32CCA

Map2

2

000330C4

209092


330C4

3304E

3307C

Map3

3

33476

210038


33476

33400

3342E

Map4

4

33828

210984


33828

337B2

337E0

Map5

1

33BDA

211930


33BDA

33B64

33B92

Map6

2

33F8C

212876


33F8C

33F16

33F44

Map7

3

3433E

213822


3433E

342C8

342F6

Map8

4

346F0

214768


346F0

3467A

346A8

Map9

1

34AA2

215714


34AA2

34A2C

34A5A

Map10

2

34E54

216660


34E54

34DDE

34E0C

Map11

3

35206

217606


35206

35190

351BE

Map12

4

355B8

218552


355B8

35542

35570

Map13

1

3596A

219498


3596A

358F4

35922

Map14

2

35D1C

220444


35D1C

35CA6

35CD4

Map15

3

360CE

221390


360CE

36058

36086

Map16

4

36480

222336


36480

3640A

36438



-- Edited by PetriK at 21:21, 2007-11-26

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:


Next is the RPM Y axis. If you use the conversion constant 5.12 used by both the kawasaki and suzuki 16 bit ecu you end up with a rev range from 400 - 7400 rpm.  400 is kind of low. All the other ECUs start at 800. Also 7400 is low for a bike that redlines at 10600. So I was thinking of using 2.56 which gives us a range of 800 to 14800. The 800 is a good starting place and while 14800 seems hi it does extend past the redline. Until we can prove otherwise I'd go with 2.56. All the map data is the same past 8800 anyway.



The weel size was moved from 8 pin to 21 pin which means that there is a difference of 2.625. On the other hand I like the 2.56 more as that gives clear cut values for each rpm level.

Anyway to find the RPM limiter which is at 10800 we should then look at the figure 6C00 (or 6EBE).



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:

Did you repost the fixed SH7052.bin file? All the ones I've downloaded only go to 0x3FFFE. Still one byte short.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, These files are updated:

http://macmadigan.no-ip.com/Public/ECU/Enginuity/SH7052.xml

http://macmadigan.no-ip.com/Public/ECU/Enginuity/Tables.xls

http://macmadigan.no-ip.com/Public/ECU/SH7052.BIN

I checked that the sh7052.bin above goes to 0x0003FFFF by clicking that from internet and loading the bin to FDT.

-- Edited by PetriK at 06:08, 2007-11-28

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

Page 1 of 1  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard