Data Tracing
Moderators: Mangus, robertisaar, dex
Data Tracing
I see in the current software of TunerPro RT there is a feature called ALDL Data Tracing.
I see that this is assocated with the new v2 OSTRICH from Craig Moates.
I was just wondering if anybody was using this feature and what there findings were.
I'm also lead to beleive that Craig's Roadrunner LS1 Real Time PCM has the same capability.
I was wondering if these features would be included into TunerPro in the future.
I'm a very curious sort of guy, I hope I don't ask to much...
Cheers
Mick
I see that this is assocated with the new v2 OSTRICH from Craig Moates.
I was just wondering if anybody was using this feature and what there findings were.
I'm also lead to beleive that Craig's Roadrunner LS1 Real Time PCM has the same capability.
I was wondering if these features would be included into TunerPro in the future.
I'm a very curious sort of guy, I hope I don't ask to much...
Cheers
Mick
ALDL data tracing takes the ALDL output and traces any corresponding maps (as defined by the definition). The address hit tracing implemented in the Ostrich 2 is a bit different.
Yes, I have a test app working with address tracing, but do not have it integrated into TunerPro. I will eventually.
Yes, I have a test app working with address tracing, but do not have it integrated into TunerPro. I will eventually.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Hi Sir,Mangus wrote:ALDL data tracing takes the ALDL output and traces any corresponding maps (as defined by the definition). The address hit tracing implemented in the Ostrich 2 is a bit different.
Yes, I have a test app working with address tracing, but do not have it integrated into TunerPro. I will eventually.
It would be a great news if you do it
Best regards,
Manu
Hi Mangus.Mangus wrote:ALDL data tracing takes the ALDL output and traces any corresponding maps (as defined by the definition). The address hit tracing implemented in the Ostrich 2 is a bit different.
Yes, I have a test app working with address tracing, but do not have it integrated into TunerPro. I will eventually.
I wonder if you plant to release this fonction in TunerPro RT. In fact, I am waiting this to get an registered version
Bests,
Manu
Excellent! Could you email me the XDF and matching bin for your Siemens ECU? What year and models is it for? Can I post it on the TunerPro web site?Lafuente wrote:If you need any tester, I have an ostrich and a well tuned XDF for my car (siemens ECU fenix1B). I'll have to do my maps soon and can help you to go through with trace fonction if you need/hope.
Bests,
Manu
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
-
- Posts: 9
- Joined: Sun Aug 31, 2008 3:44 pm
- Six_Shooter
- Posts: 590
- Joined: Sun May 06, 2007 7:32 am
I've been curious why the Ostrich 2.0 firmware would need to be updated for ALDL tracing. The way I understand it works aqnd have seen it work is strickly from the ALDL input and show up in the tables of the current bin shown in TP RT.Mangus wrote:ALDL data tracing takes the ALDL output and traces any corresponding maps (as defined by the definition). The address hit tracing implemented in the Ostrich 2 is a bit different.
Yes, I have a test app working with address tracing, but do not have it integrated into TunerPro. I will eventually.
What effect is the Ostrich 2.0 going to have? How does this relate to the tune?
I'm always interested in adding definitions to the web site if you'd allow. Feel free to email it to me along with vehicle compatibility list to mark at tunerpro dot netsideways danny wrote:awesome. Currently have a Ostrich 1.0 but i'll upgrade to 2.0 if tunerpro RT can work with a trace function. I'm running on a Nissan CA18DET with a JECS ECU. Can provide the xdf I have if needed
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
BUMP - Any updates ?
Greetings all - I am a noob on here. Regsitered user of the RTPro package and I have the mighty Ostrich 2.0 up and running...
I too would really love to know when any kind of trace functionality will be available via RTPro. I will happily take Alpha or Beta test builds.
I need tracing to do a couple of basic things -
1. Create a sequenced list of address hits from power up of the ECU - until its shut down, or when it hits some sort of limit - file size or timer. This is going to be a huge help in reverse engineering undocumented ECUs. I would happily take a standalone hack/application that can do this now - I just need all the address hits so I can sanity check my disassembly and attempts to understand my ECU a lot better.
2. Highlight address hits in real-time while viewing maps graphically. This will be a revelation for RT mapping with visual confirmation of where the ECU is working inside a live map view - much less guesswork - especially when the map scales are not yet known.
PS - RT TunerPro is great... I have spent a long time building XDFs for the ECUs I work with - it has been a bit labourious but the stability of the package and ease of operation is fantastic.
Getting the trace function up and running will be so cool - it is the reason I bought Ostrich and this software as my best hope for progression.
I too would really love to know when any kind of trace functionality will be available via RTPro. I will happily take Alpha or Beta test builds.
I need tracing to do a couple of basic things -
1. Create a sequenced list of address hits from power up of the ECU - until its shut down, or when it hits some sort of limit - file size or timer. This is going to be a huge help in reverse engineering undocumented ECUs. I would happily take a standalone hack/application that can do this now - I just need all the address hits so I can sanity check my disassembly and attempts to understand my ECU a lot better.
2. Highlight address hits in real-time while viewing maps graphically. This will be a revelation for RT mapping with visual confirmation of where the ECU is working inside a live map view - much less guesswork - especially when the map scales are not yet known.
PS - RT TunerPro is great... I have spent a long time building XDFs for the ECUs I work with - it has been a bit labourious but the stability of the package and ease of operation is fantastic.
Getting the trace function up and running will be so cool - it is the reason I bought Ostrich and this software as my best hope for progression.
BUMP - Any update from the makers of TunerPro RT on the availability of a trace function ?
Sorry to moan on about this, but even a message that said its 6 months away is better than hearing nothing.
I've been trying to get some direct connectivity with Ostrich for its claimed trace command set using various serial port programs but its proving pretty tedious as it seems I need TunerPro to initialise the comms properly, but then it hogs the COM port making it impossible to get reliable comms with another package to attempt some trace commands.
Even if a quick / dirty dialog box could be grafted onto TunerPro as a means to exercise the trace commands before any graphical or tabular support is provided - that would be awesome for people like me trying to reverse engineer some of these undocumented Bosch Motronic ECUs.
Sorry to moan on about this, but even a message that said its 6 months away is better than hearing nothing.
I've been trying to get some direct connectivity with Ostrich for its claimed trace command set using various serial port programs but its proving pretty tedious as it seems I need TunerPro to initialise the comms properly, but then it hogs the COM port making it impossible to get reliable comms with another package to attempt some trace commands.
Even if a quick / dirty dialog box could be grafted onto TunerPro as a means to exercise the trace commands before any graphical or tabular support is provided - that would be awesome for people like me trying to reverse engineer some of these undocumented Bosch Motronic ECUs.
The next version of TunerPro will not ship w/o tracing. The plan is to have two forms of tracing data visualization availble:
1) a raw list of address hits in an arbitrary window that the user specifies. This will be the most performant means of getting data from the unit, and the method least likely to miss data
2) visual tracing bubble on the active table. The user opens up a table to visualized, clicks "trace", and address hits are highlighted in the table.
I'm fixing a couple of hardware interfacing issues at the moment with the Roadrunner, and as soon as that's done, I'm moving on to tracing (for the love of God =). I've finally got my test bench back, which is what I've been waiting on to get this implemented.
I appreciate everyone's patience.
1) a raw list of address hits in an arbitrary window that the user specifies. This will be the most performant means of getting data from the unit, and the method least likely to miss data
2) visual tracing bubble on the active table. The user opens up a table to visualized, clicks "trace", and address hits are highlighted in the table.
I'm fixing a couple of hardware interfacing issues at the moment with the Roadrunner, and as soon as that's done, I'm moving on to tracing (for the love of God =). I've finally got my test bench back, which is what I've been waiting on to get this implemented.
I appreciate everyone's patience.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Mark,
Thanks for the update on this one... I really appreciate it.
I think the two methods you suggest are just what I need - Method 1 to help reverse engineer an unknown ECU and Method 2 to give visualisation of where the ECU is hitting a specific map in real-time.
My only request for Method 1 would be that it should be possible to specify a range of the entire address space and have a sequence dump of all the address hits into a text file for offline investigation - thats going to be a big help to confirm the behaviour of any reverse engineered / disassembled code... Watching how the chip is accessed at startup/reset for example or it traverses multiple maps, making various calculations to obtain a final result for injector times or whatever... Spare a thought for any of us trying to unlock some of the Bosch Motronic secrets. We need all the help we can get !
Really looking forward to support for trace, and only too happy to offer any services as an Alpha / Beta tester if it helps the wider userbase.
Thanks for the update on this one... I really appreciate it.
I think the two methods you suggest are just what I need - Method 1 to help reverse engineer an unknown ECU and Method 2 to give visualisation of where the ECU is hitting a specific map in real-time.
My only request for Method 1 would be that it should be possible to specify a range of the entire address space and have a sequence dump of all the address hits into a text file for offline investigation - thats going to be a big help to confirm the behaviour of any reverse engineered / disassembled code... Watching how the chip is accessed at startup/reset for example or it traverses multiple maps, making various calculations to obtain a final result for injector times or whatever... Spare a thought for any of us trying to unlock some of the Bosch Motronic secrets. We need all the help we can get !
Really looking forward to support for trace, and only too happy to offer any services as an Alpha / Beta tester if it helps the wider userbase.
Cool - we should compare notes on moates then
Mine is Bosch DME 2.3.2 - I'm not 100% sure on that but its an 8051 based thing that is keeping me awake at night with code disassembly.
I have written a PHP script for finding maps - if you like I can parse your Porsche binary for maps - assuming you know what labels to look for... I don't think they are the same across different applications.
My idea of the script is to eventually get it to create the XDF file that describes the locations of all the maps found - to save LOTS of time versus building the XDF manually.
Mine is Bosch DME 2.3.2 - I'm not 100% sure on that but its an 8051 based thing that is keeping me awake at night with code disassembly.
I have written a PHP script for finding maps - if you like I can parse your Porsche binary for maps - assuming you know what labels to look for... I don't think they are the same across different applications.
My idea of the script is to eventually get it to create the XDF file that describes the locations of all the maps found - to save LOTS of time versus building the XDF manually.
Well if your DME is 8051 based as well, then we are looking at similar dis-asm... What are you using to dis assemble? What size is your binary? I'm using a modified version of Dis51 and my binary is 8k.
Does your binary have a jump table? I know the locations of pretty much every map on the binary I have. If you know the jump table location - you just follow the jumps. Then just looking for familiar header information to help identify the table.
Do you have a link to your thread on moates.net?
-Rogue
Does your binary have a jump table? I know the locations of pretty much every map on the binary I have. If you know the jump table location - you just follow the jumps. Then just looking for familiar header information to help identify the table.
Do you have a link to your thread on moates.net?
-Rogue
I have been using DIS8051 - which is OK, but takes a lot of hand coding for good results.
Tonight I got a quick run thru with IDAPro and the quality in output is amazing - it also found all the datablocks automatically - no stupid TAG files here.
Based on the binary I gave it, it called out an 8051 variant that had no internal ROM - which makes sense to me as that would conflict with me finding reset and interrupt routines in one of the two external EPROMs.
Yes some of the code uses jump tables - and that definitely helps a lot locate those maps which don't have the motronic labels.
It will take a while to learn my way round IDA Pro, but it looks great. I can work on your binary if you like... Just send me a PM with an Email address and we'll go from there.
Tonight I got a quick run thru with IDAPro and the quality in output is amazing - it also found all the datablocks automatically - no stupid TAG files here.
Based on the binary I gave it, it called out an 8051 variant that had no internal ROM - which makes sense to me as that would conflict with me finding reset and interrupt routines in one of the two external EPROMs.
Yes some of the code uses jump tables - and that definitely helps a lot locate those maps which don't have the motronic labels.
It will take a while to learn my way round IDA Pro, but it looks great. I can work on your binary if you like... Just send me a PM with an Email address and we'll go from there.
PM sent back... Since my previous post I have been inside my ECU for a closer look as I couldn't figure how an Intel 8051 (built in 1980) was accessing so much external EPROM space.
Turns out my ECU has an 8051 running from internal ROM, and it also has 2 x AMD/Siemens 80535 micros - one for fuel/timing and the other for boost control. What a beast !
Anybody see why I need the trace function so badly
Seriously though - whilst I have a really nice package for code disassembly, its going to take a long time to completely map out both the external chips and properly understand when each map gets used. The trace function is going to be a vital assistant for that.
Turns out my ECU has an 8051 running from internal ROM, and it also has 2 x AMD/Siemens 80535 micros - one for fuel/timing and the other for boost control. What a beast !
Anybody see why I need the trace function so badly
Seriously though - whilst I have a really nice package for code disassembly, its going to take a long time to completely map out both the external chips and properly understand when each map gets used. The trace function is going to be a vital assistant for that.
ALDL mapping is irrespective of emulation hardware. If you can get ALDL data, you can potentially set up ALDL tracing.soldave wrote:Am I right in thinking then that the ALDL mapping will not be available for people with the Ostrich 1?
Address tracing, on the other hand, is an Ostrich 2 and Romulator feature (TunerPro will support the Romulator, but emphasis will beon Ostrich 2).
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Sorry, I meant address tracing. Getting a little confused there.Mangus wrote:ALDL mapping is irrespective of emulation hardware. If you can get ALDL data, you can potentially set up ALDL tracing.soldave wrote:Am I right in thinking then that the ALDL mapping will not be available for people with the Ostrich 1?
Address tracing, on the other hand, is an Ostrich 2 and Romulator feature (TunerPro will support the Romulator, but emphasis will beon Ostrich 2).
Well that serves me right for going the cheap route all those months back and picking up an Ostrich 1! An upgrade may be in the cards when the latest Tunerpro release is out.
we all are here and waiting for realtime map traking!!!!!!
i really need this. but i need to know if this feature became real in few time or not.
please give me some information about.
a lot of fast cars hope and wait...
if beta version is made, please post it and we try!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CRIS FROM ITALY
i really need this. but i need to know if this feature became real in few time or not.
please give me some information about.
a lot of fast cars hope and wait...
if beta version is made, please post it and we try!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CRIS FROM ITALY
- Six_Shooter
- Posts: 590
- Joined: Sun May 06, 2007 7:32 am