Problem with OpenFlash Tablet please help *urgent*

[Tromatic]

Originally Posted by phrosty

I feel like we could find some way to make this a little more foolproof. When a ROM is being uploaded, CRC different chunks of it to ensure only known tables have been modified. If anything else is, notify the user and confirm. Maybe even have an initial "novice" mode that restricts editing to a few common tables like MAF scale, FFS, LC, etc.

The OFT dudes have done their part, IMO. Only so much you can do. "ummm... read me file? lol"

[Shiv@Openflash]

Originally Posted by Slyith

If I bring it back to the dealer will they be able to find out that I've tuned my ecu ?

PM'd you

[Tromatic]

Originally Posted by Slyith

If I bring it back to the dealer will they be able to find out that I've tuned my ecu ?

Depends on how honest you are. ETA: Shiv, just out of curiosity, has there been a hard-brick of an ECU because of the OFT system itself, not user error?

[Shiv@Openflash]

Originally Posted by Tromatic

Depends on how honest you are. ETA: Shiv, just out of curiosity, has there been a hard-brick of an ECU because of the OFT system itself, not user error?

Nope. Still doesn't make what happened here any less unfortunate though :/

[steve99]

Originally Posted by Tromatic

Depends on how honest you are. ETA: Shiv, just out of curiosity, has there been a hard-brick of an ECU because of the OFT system itself, not user error?

all the issues re flashing i have been involved with tactrix or oft ect have ALL been due to the user editing a rom with the incorrect definition files causing corruption to the program code in the rom.

Do not know of any issue where people have flashed a rom they have not edited.

ie the flash process is very robust, with either tactrix/oft/brzedit.

it all basicly people messing up the editing with romraider or ecuflash both will correct the checksum so the flashing device does not know the rom code has been altered.

always check some tables when you open a rom like OL fuel table and Base timing B and see the values look good if they dont your rom and def are mismatched.

[phrosty]

Originally Posted by Tromatic

The OFT dudes have done their part, IMO. Only so much you can do. "ummm... read me file? lol"

Not ragging on the OFT guys here, I'm sure they have their hands full. OFT Manager is just very obviously a "made by a dev for a dev" utility. It's a type of software we all make, it just rarely sees the light of day as a commercial supported product.

As a software developer myself, I strongly support a "user first" mindset. Anything I can do to make the user's experience better, safer, more intuitive, is a plus. It's not just about doing the minimum to make something work. It's the mindset of "you're not using it wrong, I just didn't anticipate you doing that, let me safeguard it or make it easier for next time".

[Tromatic]

Originally Posted by phrosty

Not ragging on the OFT guys here, I'm sure they have their hands full. OFT Manager is just very obviously a "made by a dev for a dev" utility. It's a type of software we all make, it just rarely sees the light of day as a commercial supported product.

As a software developer myself, I strongly support a "user first" mindset. Anything I can do to make the user's experience better, safer, more intuitive, is a plus. It's not just about doing the minimum to make something work. It's the mindset of "you're not using it wrong, I just didn't anticipate you doing that, let me safeguard it or make it easier for next time".

I blame YouTube. Ain't nobody got time fo 'dat instruction manual reading crap.

[ZZT86]

Do you guys think the fact he opened the door could have played a part in the write failure or was it purely code mismatch ?

A timely reminder that everyone needs to be EXTREMELY careful when altering roms. Double triple check everything.

[steve99]

Originally Posted by ZZT86

Do you guys think the fact he opened the door could have played a part in the write failure or was it purely code mismatch ?

A timely reminder that everyone needs to be EXTREMELY careful when altering roms. Double triple check everything.

It not a good idea to open/close doors or mess with anything electrical in the car ie turn lights/radio on ect as this may cause a momentary drop in battery volts and you need stable volts for a flash.

However in this case it dont think its the issue.

[Tromatic]

Every flash I've done has been with drivers door open, radio on. Here's hoping it's not actually bricked.

[Target70]

Let us know how everything turns out. I hope it isn't bricked, but this is exactly why I have been too scared to attempt to modify any files, even just for FFS or E85 cold start.

[steve99]

Originally Posted by Target70

Let us know how everything turns out. I hope it isn't bricked, but this is exactly why I have been too scared to attempt to modify any files, even just for FFS or E85 cold start.

His ecu doesnt talk to obd port any more. and car does not start

Cause , he used incorrect romraider definitions to modify tune file

Using incorrect definitions means your likely altering the program code in the ROM rarther than the desired table area. This likely results in the ECU attempting to run borked code and it goes off with the fairies , the watchdog timer probably kicks in an resets ecu and it promply goes of with the fairies again cycle continues, hence engine no workie and OBD port no workie, commonly known as bricked.

Unfortunatly subaru ecu appear to put the boot loader in with the rom table and program data. If they had a separate protected boot area that just ran the obd port communications and enough smarts to reflash would be good. Hence if you flash a borked rom your locked out This will happen regardless of the flashing tool ie Ecutek Tactrix OFT Alientech ect.

If someone has a bricked ecu they dont want i am keen to try to recover a brz/86 ecu.

always use correct definitions and check the values and axis of a couple of known tables to check your rom matches definition.

[Tromatic]

Word?

[Target70]

Originally Posted by steve99

His ecu doesnt talk to obd port any more. and car does not start

Cause , he used incorrect romraider definitions to modify tune file

Using incorrect definitions means your likely altering the program code in the ROM rarther than the desired table area. This likely results in the ECU attempting to run borked code and it goes off with the fairies , the watchdog timer probably kicks in an resets ecu and it promply goes of with the fairies again cycle continues, hence engine no workie and OBD port no workie, commonly known as bricked...

I thought he had both definitions(1.5 and 2.X) loaded in RR. I am almost completely unfamiliar with the software, but I thought he could choose which definition he was using out of the list of definitions that he had loaded in RR. He was just uncertain which one was selected:


quote: im not sure if it got crossed with the old one because when i use rom reader i left both of the definitions in the list and clicked on the 2.xx one before pressing apply


Or does even having more than one definition file loaded in RR cause the interference problem?