How many damaged ECU's are out there after using Ecuflash?

OpenECU software executables and source code

Moderator: Freon

Postby NSFW » Thu Jan 11, 2007 10:42 pm

Perhaps I am thinking too much in terms of an embedded project I'm working on myself, and thus making too many assumptions about how the ECU firmware is laid out.

Basically, the project I'm working on has a boot loader that resides in two specific blocks of memory. The boot loader knows how to un-protect and write to every other block of memory, but if you tell it to modify itself, it does nothing.

The boot loader's job is to listen for few image firmware at boot time, and jump into the new image after (if) one is transferred.

Can we find the boot loader code in the ECU images? Is it fairly well localized, i.e. the first-instruction code, set, communications, etc, all in a reasonably well-defined address range?

If so, could the Subaru boot loader, the reflashing kernel, or EcuFlash itself be modified to never write anything to the boot loader address ranges? (Insert magic here r.e. each ROM having its own protected ranges, we'll solve that problem later if at all).

That was you could write hamburgers (0xDEADBEEF) across the whole ECU, minus the bootloader range, and still be able to deploy a good image since the bootloader would still boot up and accept new images.

Would this type of protection would have saved Zuczek's ECU?

It seems too easy right now for a minor mistake to brick an ECU - which bricks the whole car, basically. It also seems like a solvable problem. Given the seriousness of such mis-steps, it would be REALLY nice to see the developers in this group highly prioritize features that protect users from themselves (or, from each other, as the case may be).
NSFW
 
Posts: 31
Joined: Sat Dec 02, 2006 4:15 pm

Postby cboles » Fri Jan 12, 2007 4:21 pm

I think you have a good grasp on the problem. I write bootloaders too for all of the embedded work I do. The problem is, Subaru/Denso does not use a bootloader scheme - the communications code from which one can load a kernel is part of the "main loop" and not seperate from other ECU code. It's just bad design IMHO...
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby NSFW » Fri Jan 12, 2007 7:45 pm

Bummer. So, if the flashing code is in the main loop, does that mean that a bug in other parts of the ECU code (e.g. ramtune stuff) could hang the ECU and make it unrecoverable?
NSFW
 
Posts: 31
Joined: Sat Dec 02, 2006 4:15 pm

Postby Evo4Mad » Sun Jan 14, 2007 12:08 am

today was strange, i have flashed dozens of e7/e8 roms into my SH7052, but I came across one that actually rendered it unprogrammable (wont initialize to ecuflash). 04_LANCER_EVO8_USDM_94170015.hex into a JDM e7 and into a USDMe8.

Although I do have this funny feeling that I have successfully flashed this ROM a number of times before but today I was trying to use the "compare to ecu" feature of EcuFlash both times when it started failing, that may have given it the final nail.

How can I revive my now two unprogrammable ecu's. Would someone here be willing to revive them for me?
Last edited by Evo4Mad on Sun Jan 14, 2007 11:39 pm, edited 2 times in total.
Evo4Mad
 
Posts: 332
Joined: Mon Jun 13, 2005 11:58 pm
Location: New Zealand

Postby Evo4Mad » Sun Jan 14, 2007 12:11 am

where can I get a SH7052 eeprom programmer from? and can I run hookup wires to the chip on the circuit board and revive it while its still on the board?
Evo4Mad
 
Posts: 332
Joined: Mon Jun 13, 2005 11:58 pm
Location: New Zealand

Postby S54fan » Sun Jan 14, 2007 1:46 am

You used Jack's unlocker? There was a suggestion that this was a universal access procedure for recovery, although this puzzles me a little since I think there is likely to need to be some working software to interpret the init code sequence down the diagnostic port?
S54fan
 
Posts: 233
Joined: Fri Dec 16, 2005 4:39 am

Postby radsdau » Sun Jan 14, 2007 3:09 pm

cboles wrote:The problem is, Subaru/Denso does not use a bootloader scheme - the communications code from which one can load a kernel is part of the "main loop" and not seperate from other ECU code. It's just bad design IMHO...

If my thinking is correct:
- Subis use the same processor family as Mitsus
- The bootloader in the Mitsus is practically unerasable (or you would have to try pretty hard to erase it, because it lives in a separate area of flash)
If Subaru are not using this 'other' bit of flash, would it not be possible to write a 'kernel' that flashes a bootlader in here? Then we'd just have to work out a way of convincing the code to run from there instead of from the 'main' code (may not be such an easy thing). May involve some hardware, like Mitsubishi ECUs.
If there was a magic way of achieving this, it would potentially save lots of grief in the Subaru ECU world.
radsdau
 
Posts: 674
Joined: Wed Feb 08, 2006 6:56 pm

Postby NSFW » Mon Jan 15, 2007 12:40 am

I was thinking along similar lines as well - create a bootloader, just smart enough to initialize the hardware, download new firmware, and jump into that firmware. The tweak ecuflash to never write to where the bootloader lives. It would be a lot of work (esp since it would need to be done several times), but it seems like the current system might be fragile enough to justify that extra work.

Is there a watchdog timer in any of the Subaru ECUs that can force the ECU into the "limp home" mode and still accept new firmware over SSM? That could be better than nothing, especially if it's well documented for end users.

Are there emulators for the ECU microcontrollers? We wouldn't have to simulate the hardware exactly but it would be nice to be able to test the firmware changes to some extent before testing on an installed ECU.

Just thinking out loud...
NSFW
 
Posts: 31
Joined: Sat Dec 02, 2006 4:15 pm

Postby MalibuJack » Mon Jan 15, 2007 7:12 am

S54fan wrote:You used Jack's unlocker? There was a suggestion that this was a universal access procedure for recovery, although this puzzles me a little since I think there is likely to need to be some working software to interpret the init code sequence down the diagnostic port?


Thats true, the unlocker uses this recovery code to run this bit of code that never gets overwritten by reflashing. I'm not sure if its hard coded, or just a different inaccessible area.

If what Evo4Mad is saying is accurate, and the unlocker doesnt work, then he might have overwritten that recovery code.

I always assumed any system like this would have a basic bootstrap to allow a brand new ECU to be flashed for the first time, usually if it doesnt, then there's a JTAG on the system board that allows you to flash it directly.

this actually raises another thought about unlocking Subaru ECU's, as the Mitsubishi unlocker uses a built in recovery method (recovery bootloader, or whatnot) that the Subaru doesn't appear to have.
MalibuJack
 
Posts: 128
Joined: Tue Apr 25, 2006 12:10 pm
Location: Royse City, TX

Previous

Return to OpenECU Software

Who is online

Users browsing this forum: No registered users and 9 guests

cron