Should we use standardise on 160K or 192K images for tuning?

Developer topics relating to software that provides a tuning UI to alter ECU code and data

Moderator: Freon

Should we use standardise on 160K or 192K images for tuning?

Postby crispyduck » Sat Jan 07, 2006 12:58 pm

All,

Further to a recent question on here, about using either a 160K or 192K ECU image when reflashing, it got me thinking that people using the new ecuFlash (me) have 160K images and people using the command line version might be using the 192K variant.

ecuEdit allows you to convert the 160K images to 192K images. My first question is this, should we all standardise on the images sizes we are using? If, yes I'd recommend the 192K size as that matches the ECUs address space.

The rational being that it makes sharing ECU offset information easier. I've just published my ecuEdit XML config file for Euro MY03 WRX's and it only works for 160K image sizes. If I convert my image to 192K then ecuEdit fails to show my maps. As stated in the ecuFlash command line release notes, the "192K image contains a blank area from 0x20000 to 0x27FFF which is represents the area normally occupied by RAM."

This leads me on to my second question; can I simply add 0x07FFF to all my offsets to quickly get all my ecuEdit maps working again?

Third and final question (I promise!); can the new version of ecuFlash be configured to output 192K images?

Thanks in advance for any help,
-Steve.
crispyduck
 
Posts: 186
Joined: Sun Nov 13, 2005 1:15 pm
Location: www.scoobypedia.co.uk

Postby qoncept » Sun Jan 08, 2006 12:59 pm

I agree with 192kb -- that's the image that's on your ECU. I don't really think standardization is all that important, though. I'll be supporting either in Enginuity, and it should be abstract and never be noticed by the user. I suppose I'll have to make some way to distinguish between the two sizes in the ECU definition editor, but other than that, it should all be taken care of by the program.

I imagine epifan just never tested like ECU versions with the different sizes and will fix that with his next release. It's as simple as subtracting/adding 32 * 1024 to the offsets in XML. But that does raise a question for the XML. The XML will need to be standardized as offsets to either a 192 or 160kb file. All the offsets in the forum appear to be from 192kb files, so I say we go with that.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby epifan » Tue Jan 10, 2006 12:42 pm

qoncept wrote:I imagine epifan just never tested like ECU versions with the different sizes and will fix that with his next release

ok, this would be in next release (coming soon: log viewer, ecu struct inheritance and other useful stuf) :wink:
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Postby Freon » Tue Jan 10, 2006 1:52 pm

I seems 192k makes more sense. Or more generally, include the TPU in the image (other ECUs may be different sizes). Space should not be an issue if we're all using laptops to do this.

Eventually, I think we may end up wanting to flash that area of memory anyway. This is essentially the volitile RAM memory, correct? What is holding the KC map, IAM, etc, correct? Or do we hypothesize that?
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby cboles » Tue Jan 10, 2006 2:44 pm

The TPU area only contains code for bootloading the kernel on 02-05 WRXs. There is nothing in there related to tuning - it's just code. The new flash/tuning tool I'm working on supports all of the file formats we are talking about and more, so it will work either way. It can see if a binary matches the compacted or expanded size for a given CPU memory map. For some processors, you can't lay the memory out linearly without ending up with a 4GB rom file - you need to discard the empty spaces between...
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA


Return to Tuning Software

Who is online

Users browsing this forum: No registered users and 5 guests