RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Fri Jan 19, 2018 9:00 am

All times are UTC - 5 hours [ DST ]





Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 2:45 am 
Offline
Moderator

Joined: Wed Nov 22, 2006 10:23 pm
Posts: 2459
The EcuFlash process seems to be to download code from the laptop and then execute that code on the ECU. I wouldn't be surprised if the "official" reflash process simply executed code that's already in the ROM. It's pretty common for embedded devices to use a bootloader that knows how to reflash the device, and it would be easy to have that code maintain a reflash count.

_________________
2005 Legacy GT w/ ATP 3076, IWG, MBC, BCS, BC 272, LC, FFS, OMG
Please don't send me tuning questions via PM - use the forums instead. Thanks!


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 2:56 am 
Offline
RomRaider Donator

Joined: Tue Apr 24, 2007 6:49 pm
Posts: 243
I guess that begs the question, if you flash using ECUFlash and the count is wiped out, when you reflash to stock, I assume it will be restored? Doesn't affect me, but I'm sure some people might be concerned.


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 12:43 pm 
Offline
RomRaider Developer

Joined: Wed May 20, 2009 9:49 pm
Posts: 5698
Location: Canada eh!
If you write your stock map back, the counter is set to the value in the map. For mine it's currently 0xFFFF. EcuFlash, I'm pretty sure does not bootload your ROM, unless you bricked it and had to build that funky bootload circuit and open the ECU to connect it. I believe EcuFlash just runs the flash software that already existing in the CPU.
The Manual (page 833) wrote:
Programming/erasing interface by the download of on-chip program.
This LSI has a dedicated programming/erasing program. After downloading this program to the on-chip RAM, programming/erasing can be performed by setting the argument parameter.
The user branch is also supported.
- User branch
The program processing is performed in 128-byte units. It consists the program pulse application, verify read, and several other steps. Erasing is performed in one divided-block units and consists of several steps. The user processing routine can be executed between the steps, this setting for which is called the user branch addition.


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 1:36 pm 
Offline
Experienced
User avatar

Joined: Wed Nov 10, 2010 7:56 am
Posts: 371
dschultz wrote:
EcuFlash, I'm pretty sure does not bootload your ROM, unless you bricked it and had to build that funky bootload circuit and open the ECU to connect it. I believe EcuFlash just runs the flash software that already existing in the CPU.


I think so too:
a "real" Boot-Loader can wirte into an empty flash and is able to recover after bricking a ECU.


ECUFlash needs an other flash option and a boot load circuit for this function. This is a "real" boot-loader.
The software of the ECU is down because prozessor is in boot mode.

Flashing with ECUflash in normal mode needs a running software to wirte the flash and this looks like "normal OBD flashing"

btw:

Does this boot-loader of ECUflash works on the new 32bit ECU too ?
So acutal petrol and Diesel ECU can be recovered after bricking them up ?

_________________
performence based on engineering..


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 2:53 pm 
Offline
RomRaider Developer

Joined: Wed May 20, 2009 9:49 pm
Posts: 5698
Location: Canada eh!
Jochen_145 wrote:
Does this boot-loader of ECUflash works on the new 32bit ECU too ?
So actual petrol and Diesel ECU can be recovered after bricking them up ?

I believe it does.
viewtopic.php?f=14&t=866&start=37


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 08, 2011 3:15 pm 
Offline
Senior Member

Joined: Mon Jan 19, 2009 2:31 pm
Posts: 1384
Location: Saratov, Russia
To be correct:

EcuFlash uses it's own bootloader and does not (almost) rely upon UserMode bootloaders available inside ecu ROMs.

32 bit ecu has at least three (I may be incorrect - it may have just two) bootloaders not taking into account BootMode bootloader hidden (that may be used for ecu recovery).

The first one is started at ecu reset and uses CAN_0 (not available outside the ecu ). SH7058 1 MB ROM based ecu also uses CAN_1. This bootloader is usually inside 0-0x0FFF ROM space. The protocol is rather simple and uses (I suppose) just 2 CAN ID. I am afraid it is almost impossible to catch it manually. It is looped just in case there is no other software already loaded behind it. Formally manufacturer's software is able to use it just after hardware reset.

The second one usually occupies 0x1000-0x1FFF ROM space and involves SCI_2 (serial port) as well that is seen outside the ecu. It looks like ecuFlash is trying to catch this bootloader. It runs no longer than 40-50 ms after hardware reset and passes control to engine OS if checksum (of the ROM starting 0x2000) is correct. Otherwise this bootloader is cycled similar to the first one.

At this stage simplified init sequence is excepted by ecu and SSM BlockWrite command (or equivalent) is allowed. ecuFlash catches ecu program at this stage and loads it's (Colby's ) kernel to get control.

If you miss this stage OS starts and you are to get control thru correct seed-key algorithm (and probably are to encode new downloaded ROM content) exactly as FHI (Hitachi?) software does. I suppose this is the third downloader included into the OS. I do not know for sure if ecuFlash is able to get control here for CAN enabled ecu's.

BootMode uses the program code that is reloaded from hidden ROM into RAM and allowed User ROM to be reflashed (being completely wiped after program negotiated with flashing tool ). SCI not available outside the ecu is used. That means that in order to revive bricked ecu you are to be connected to RESET\MDx\FWE, RB15 (watchdog interrupt source), SCI_0 RX, SCI TX pins of the processor and use Renesas Flash Development Toolkit (free software) to download applicable ROM image.


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 11, 2011 12:31 pm 
Offline
Experienced
User avatar

Joined: Sat Jan 06, 2007 1:18 pm
Posts: 185
I had made some changes after talking to Paul that were intended to consolidate the Logger and Editor code. My end goal there was to have a master RomRaider IDE with the Logger and Editor both equivalent tabs within it, but was working at a much lower level than that, refactoring to get more common code. I thought this would help with coordination between the two and make for a cleaner overall package.

I'm not sure how this fits in the current vision, but at the time, there didn't seem to be one for the long term. Most effort seemed to be towards individual features.

The menus were also something I looked at initially, although I didn't get to far before my Real Job reared its ugly head. Standardization there, including keyboard shortcuts, looked like a good improvement.

EDIT: I've been watching the development of launch4j and IzPack. Both have patch-level updates from what we're using, so I could update those again, but the next major release of IzPack is still Beta, and according to the developers, still has quite a ways to go before it's ready for release.


Last edited by lizzardo on Tue Jan 11, 2011 12:46 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 11, 2011 12:44 pm 
Offline
Experienced
User avatar

Joined: Sat Jan 06, 2007 1:18 pm
Posts: 185
I'll bring a side discussion from another thread over here.

If we wish to have support to run within a 64-bit JVM, we'll need to have 64-bit DLLs. The other thread touched only on rxtxserial.dll, but there are others. Anything in the main lib directory would need to be replicated in 64-bit form, probably in a parallel directory (lib64, perhaps) to avoid name collisions. If there's a project to change the graphics libraries in use, we should make sure to import the 64-bit versions, even if they're not going to be used right away. It's better than having to dig them up later.


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 11, 2011 1:15 pm 
Offline
Administrator
User avatar

Joined: Fri Jan 13, 2006 12:33 pm
Posts: 2085
Location: Palo, IA
lizzardo wrote:
I'm not sure how this fits in the current vision, but at the time, there didn't seem to be one for the long term. Most effort seemed to be towards individual features.

I'm not sure, either. Honestly, my plan for this overhaul isn't going to use much of the existing editor code. A lot of lessons have been learned and the new implementation is going to be very different. I'll probably pull pieces of the old code but overall it's going to be new.

I do like the idea if more tightly integrating the logger and editor. I think a lot of what Airboy and NSFW's spreadsheets do could absolutely be done within RomRaider, and I even think we could add things like automatic open loop fuel corrections once we get RamTune working, similar to how the ECU adjusts closed loop trims.

If we're going to move toward both 32- and 64-bit versions, you're right, we need to be thinking forward with existing and new libraries. And that's gotta be better than asking everyone to use a 32-bit JRE.

_________________
- Jared


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 11, 2011 4:17 pm 
Offline
Administrator
User avatar

Joined: Fri Jan 13, 2006 12:33 pm
Posts: 2085
Location: Palo, IA
I just emailed Colby about a library or command line args for flashing from RomRaider.

I tried toying with EcuFlash to see if there were any undocumented command line args we could use and found it takes only one argument, an input filename. It opens a new instance each time it's called (rather than opening the file in the current instance). If nothing else, I think that's a workable solution. Click on a "flash" icon in RR, it makes sure the current file is saved (or maybe saves it as a temp somewhere) and opens it in EcuFlash.

_________________
- Jared


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 11, 2011 9:42 pm 
Offline
Experienced
User avatar

Joined: Sat Jan 06, 2007 1:18 pm
Posts: 185
qoncept wrote:
If we're going to move toward both 32- and 64-bit versions, you're right, we need to be thinking forward with existing and new libraries. And that's gotta be better than asking everyone to use a 32-bit JRE.


I haven't tried it, but I think a JRE can be bundled with the application using IzPack. I'm not sure though, and even if possible, it's not ideal, but I think it's an option.


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Thu Jan 13, 2011 4:27 pm 
Offline
Newbie

Joined: Thu Oct 08, 2009 9:50 am
Posts: 16
Location: Gainesville, FL
I have nothing right now to bring to this project but i just wanted to say keep up the good work. I love this project and everything it has done for the subaru community! :mrgreen:


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 15, 2011 6:32 am 
Offline
Experienced
User avatar

Joined: Wed Nov 10, 2010 7:56 am
Posts: 371
qoncept wrote:
Click on a "flash" icon in RR, it makes sure the current file is saved (or maybe saves it as a temp somewhere) and opens it in EcuFlash.


looking from a "only-users-eye":

If only the "flashmirrow" of ECUFlash appiers, this, IMA, is a very good solution
(As long as ECUflash keeps on working on the Diesels, too :oops: )

_________________
performence based on engineering..


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Sat Jan 15, 2011 11:51 am 
Offline
Administrator
User avatar

Joined: Fri Jan 13, 2006 12:33 pm
Posts: 2085
Location: Palo, IA
Jochen_145 wrote:
qoncept wrote:
Click on a "flash" icon in RR, it makes sure the current file is saved (or maybe saves it as a temp somewhere) and opens it in EcuFlash.


looking from a "only-users-eye":

If only the "flashmirrow" of ECUFlash appiers, this, IMA, is a very good solution
(As long as ECUflash keeps on working on the Diesels, too :oops: )

I think I agree. I'll go ahead and implement that with the GUI changes coming up.

One of these days Subaru is bound to bring diesel to the states. When that happens I think you'll see a lot more activity.

_________________
- Jared


Top
 Profile  
 
 Post subject: Re: Rom Raider development roadmap
PostPosted: Tue Jan 18, 2011 8:22 am 
Offline
Experienced
User avatar

Joined: Wed Nov 10, 2010 7:56 am
Posts: 371
I want to focus your eyes on the news form Subaru Diesel Crew concerning the bootloader for Subaru Diesel... http://subdiesel.wordpress.com/2011/01/15/bootloader-stuff/


I am not a programmer, so I cannot help really with this , but maybe some of the develloper here are interessed to work on this open source bootloader and implementate the result into one of the next RomRaider Versions to be able to flash the diesel?


Best regards
Jochen

_________________
performence based on engineering..


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl