pulled my rom - ZA1JA01C
when saving as hex got a msg:
"this rom image contains sections of invalid data which must be zero padded to make a contiguous file. It is possible upon subsequent loading of this file that you might flash over valid areas with these zeroed areas."
the files was saved with first x8000 (32768 dec) zero padded, 1.25mb.
i was also able to open the file in RomRaider with RR_ZA1JA01C.xml def file (from this post http://www.ft86club.com/forums/showp...2&postcount=12)

http://i803.photobucket.com/albums/y...psd5dd8b87.jpg

some folks are reporting the roms needing to be zero padded. i don't believe it's an issue at all, and it should work fine for you.

that was exactly the point of my post, everything worked fine out of the box! :D

oh i wasn't sure if you had just pulled it or actually done anything with it and successfully flashed it back on. disregard.

didn't flash back, just pulled it. i saw that post from SkullWorks, so I think I'll wait.
but i did not have an issue with zero padding others reported.

yeah i wouldn't go flashing anything not based on the rom that came off of your own car until more is understood. personally i've flashed roms based on my pulled image as well as another (stock image) dozens of times with no issues. i suspect the guy flashed the wrong rom for his car or had some other sort of hardware issue.

I have flashed both a stock image with the 0 padding issue and one of the shiv roms with the bad checksum (I believe its the calculation that is having issues). Both cars were perfectly fine after the flash.

That's what I'm thinking as well - he flashed an OFT stage 2 rom I think. At this stage, I would edit whatever rom was pulled off the car to flash, the architecture (i.e. CAL ids) of the various roms is only just being identified.

I hope he managed to get hold of Skullworks, they should be able to take him through the SHBoot process.

Ah, interesting - so you didn't correct the checksum error? I believe Skullworks did, might be the issue.

maybe you're right, I hope it's not a beta soft.

I can tell you that using the various older version of Ecuflash, I've used it literally hundreds of times on my STI, without any problems.

just like many other folks :thumbup: i have faith in Ecuflash but it's still a beta
PS for brz i mean

Per MikeyPSF: He understood that Colby had worked out the recovery method for this ECU, BUT he was under the impression that there was an AUTO recovery feature, that appears to be not working ***IN MY CASE*** I have full faith that it will work, However Colby is getting married this weekend, Mike offered to try and steal some time from him to help me solve my issue, I insisted that he not think about my utter stupidity until after he has taken care of getting hitched.

Again I have full faith that my issue will be handled early next week and that we will find the issue is my stupidity.

I'm sure you'll come right - don't be too hard on yourself - I've also nearly fried the ECU.

I didn't realise that when I got into the car, I had kicked the OP2 extension cable just enough to have it half in half out... I was lucky that I picked it up after a couple of failed attempts, and with the ignition on, and the cable firmly in place, I managed to flash.

I remember having a couple of stiff whiskeys that night :D

How does EcuFlash behave when writing the padded ROM files to our ECU? Does it write all the 00s or does it write from 8000 on?

Asking because my ROM pull was padded and I have not yet tried to write with this beta.

Along those lines... the only thing I absolutely detest about my BRZ... is the location of the OBDII port. It's like they designed it to put the OP2 in harm's way.

well, based on this

if i had to guess, looks like the EcuFlash just writes block 8000-13FEFF and thus the padding difference between oft (FF) vs ecuflash (00) for the first 32768 bytes and last 256 bytes doesn't matter as long as checksum correction is not applied

To answer that:

Is the boot loader part of that address range?

I assume so - my understanding is that Colby is also coding a new kernel based reflash alongside the logging capability.

I have started on the Ecuflash definition, it's a work in progress and requires an updated 32bitbase.xml - check out the original definition thread for the new links.

is this viable for the unwashed masses yet?

tactrix cable waiting,

very computer literate, but 100% programming retarded.


thanks,

Wouldnt say its viable to the masses as they are some little things getting ironed out but it is usable. If you have never have used ECUflash I would wait for things to get ironed out with the checksums / padding so that your not taking the risk of flashing a bad rom. Its very close though.

So if you flash without the correct padding you will brick the ECU?

No, I wouldn't think so - Ecuflash can read the unpadded bins no problem - but you won't be able to edit using Romraider - since it expects a contiguous set of data, and the CAL id to be at 0x8000.

That's why it's only been released on request for now, and mostly to devs. I expect the next release will have kernel based flashing and data logging enabled.

I've completed updating the 32bitbase - this should provide a full Ecuflash definition for 00C. I'll put up 001C asap.

Crossing fingers for 01J definition :)

does flashing have the same effect as disconnecting battery? another words does the ecu need some driving time to adjust to the new tune?

With most ecus, yes, it will reset the AF learning and other values.

ah, thank you!

001C is up, working on A01G next, I've actually got A01J mostly disassembled already (since it was the first BRZ rom uploaded, before the beta was even mentioned).

Check my response on the RR forums - you've downloaded the wrong A01c def - it's a bare bones one that I initially uploaded to test the beta. There is a fully defined one now.

Get an extension cable with a right angle on it. Now it wont be anywhere near you. I had to do this for logging with EcuTek, leg would hit the damn cable. -.-

ZA1JA01G, RR and Ecuflash definition is up on the RR forum.

ZA1JA01J, RR and Ecuflash definition is up on the RR forum.

You have just made my day!!!!!!!!

Right - if anyone can get me the A01K, A01D, A01I and A01H, I'll get definitions out for those as well.

And I gather there's a ZA1JA01N model as well, China.

The more, the merrier.

But I think for a market THAT large it is -> BAZILL10N :confused0068: