RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Tue Jan 16, 2018 11:46 am

All times are UTC - 5 hours [ DST ]





Post new topic Reply to topic  [ 69 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Thu Mar 22, 2007 7:55 pm 
Offline
RomRaider Donator
User avatar

Joined: Sun Apr 09, 2006 12:05 pm
Posts: 866
Location: Indianapolis, IN
I'm back in business.

Colby and xswrex on openecu suggested having the ECU change the baud rate on the fly based on a trigger sent from the logger.

So the plan is to interject some code and write in a new accepted command byte in the SSM pack. This new command byte would bump the baud rate. On ECU reset it would revert back to default 4800.

Say, here's a normal packet:
0x80 0xF0 0x10 0x01 0xBF 0x40

You can look up info on SSM, and the people responsible for the logger will understand the packet structure. Briefly for those interested and ignorant on the subject, the 0x01 is size of the "data" of the packet (depending on command could be very long), 0xBF is the "command byte" to tell the ECU what you're trying to do, and the last byte is a checksum.

The plan is to introduce a new type of command byte, say 0xDF or whatever, that the ECU will use to trigger changing of baud rate. Then reconnect at the new baud rate and good to go. I've already started to write code to do this and I've identified where the h'A8, h'A0, h'BF, etc. commands are interpreted. I will jump out of the Subaru code right before the first check and check for this new special baud rate switch command. The CPU will immediately change the bit rate registers for the appropriate SCI channel, then the logger would just need to reconnect. I think I've planned how to do it without disturbing any CPU registers as well and with zero memory footprint.

I think all I need is the ability to send a packet like this:

0x80 0xF0 0x10 0x01 0xNN 0xCK where NN would be defined by the logger XML, and 0xCK is checksum. The XML just needs NN, two hex characters set to run Y baud rate. For now I'll probably just add 0xDF for 9600 baud, but while we're at it I think it might as well be made extensible by XML. It will be trivial once it works to add several options for different baud rates. 9600, 14400, 19200, etc., perhaps by 0xDF, 0xDE, 0xDD, and so forth.

I can go ahead and write this into the ECU, but I need a logger to support sending this packet to test it.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 22, 2007 8:08 pm 
Offline
RomRaider Developer

Joined: Tue Jul 11, 2006 9:25 pm
Posts: 1025
kascade should be able to help this along ^^


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 22, 2007 8:12 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Wouldn't it be easier to designate a byte in ram to store the baud rate? Then the logger could simply write to this byte to change the rate. Also set it up so if the value is null, the default rate would be that which is used by Ecuflash for flashing.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 22, 2007 10:04 pm 
Offline
RomRaider Donator
User avatar

Joined: Sun Apr 09, 2006 12:05 pm
Posts: 866
Location: Indianapolis, IN
Hmm, I suppose that would work as well. The inclusion of the check for null would mean its just about as complex as what I'm suggesting, I believe.

Just changing where the BRR is pulled (from a ROM address to RAM) in the current routine wouldn't do it though, because changing the value in RAM would not cause the subroutine to be rerun immediately. I believe (read: assume) it is only run on boot up, so you'd have to restart the whole car for it to take effect. Then you'd have to hard reset the ECU if you had problems connecting at the new baud rate, not just restart the car. You'd also have to remember to set it back to 4800 or reset the ECU if you wanted to reflash the car.

Another option would be to see what limit there is to using the write address (h'B0) command right into the register directly. I really don't understand enough about h'B0 right now, but I'll look into it and see if there is some sort of way to use that with a simpler change to the ECU code. Are you using h'B0 to write memory for real time tuning?

I'm open for other suggestions.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 22, 2007 10:48 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Freon wrote:
Just changing where the BRR is pulled (from a ROM address to RAM) in the current routine wouldn't do it though, because changing the value in RAM would not cause the subroutine to be rerun immediately. I believe (read: assume) it is only run on boot up, so you'd have to restart the whole car for it to take effect. Then you'd have to hard reset the ECU if you had problems connecting at the new baud rate, not just restart the car. You'd also have to remember to set it back to 4800 or reset the ECU if you wanted to reflash the car.

Assuming once you've tested all available baud rates, you could eliminate from the xml those that cause any connection issues. Plus, the logger could be set up to reset it to 4800 when logging has ceased (assuming the user doesn't yank the cable out before finishing the log). Maybe when flashing is integrated into RomRaider, the ram address in question can be cleared when the user is ready to flash.

I would write a simple routine to increment a memory byte each time this routine is run. Then you will know for sure how often it is executed.

Quote:
Another option would be to see what limit there is to using the write address (h'B0) command right into the register directly. I really don't understand enough about h'B0 right now, but I'll look into it and see if there is some sort of way to use that with a simpler change to the ECU code. Are you using h'B0 to write memory for real time tuning?

It only allows you to write to ram. Support will need to be added for this anyway for real-time tuning which is why I suggested storing the rate in ram. Why reinvent the wheel? :D Anyway, this should be awesome for logging regardless. Good job on figuring this out! I'll see if I can find it on the 16bit ecus.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 23, 2007 9:20 am 
Offline
Administrator
User avatar

Joined: Mon Jan 30, 2006 9:05 pm
Posts: 774
Location: PA, USA
Great Job Guys! Very exciting stuff!

_________________
Enjoy,

Jeramie


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 01, 2007 9:44 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
I've found the baud rate for the 16-bit ecus but I guess Ecuflash doesn't have the ability to change the baud rate for reading/flashing, so no easily viable solution for the end user is possible yet.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 01, 2007 11:13 am 
Offline
RomRaider Donator
User avatar

Joined: Sun Apr 09, 2006 12:05 pm
Posts: 866
Location: Indianapolis, IN
I'm going to revisit this soon. I think I can rewrite a jump in the current subroutine that operates the BRR and include a branch in code that checks a byte in a currently unused memory location.

Is it possible to write a generalized packet sender for Enguinity? So I can write a payload for testing this? I effectively just want to set one bit high using the current SSM "write single memory location" command.

Eventually, in the logger XML a new item will be added with a memory location and codes.

i.e.

Code:
<CustomSend>
  <value>
    <name>Baudrate Control</name>
    <loc>0xFFC410</loc>
      <option data='0x0' display='4800'/>
      <option data='0x1' display='9600'/>
      <option data='0x2' display='19200'/>
  </value>
  <value>
    <name>Something else</name>
    <loc>0xFFC412</loc>
      <option data='0x0' display='Opt1'/>
      <option data='0x1' display='Opt2'/>
      <option data='0x2' display='Opt3'/>
  </value>
</CustomSend>


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 01, 2007 12:25 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Freon wrote:
Is it possible to write a generalized packet sender for Enguinity? So I can write a payload for testing this? I effectively just want to set one bit high using the current SSM "write single memory location" command.

You can do this with the test release of RomRaider.

I think it would be easier to designate a byte in ram for the desired baud rate. The logger could read this (as well as modify) and calculate the current baud rate rather than having a limited number of pre-defined rates. If null, set it up so that the ecu defaults to the factory rate (therefore an ecu reset would be all that was needed to default if there were issues).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 10:04 am 
Offline
Experienced

Joined: Wed Jul 26, 2006 3:19 pm
Posts: 650
Location: Connecticut, USA
merchgod wrote:
I think it would be easier to designate a byte in ram for the desired baud rate. The logger could read this (as well as modify) and calculate the current baud rate rather than having a limited number of pre-defined rates. If null, set it up so that the ecu defaults to the factory rate (therefore an ecu reset would be all that was needed to default if there were issues).
The logger can't read the current baud rate from RAM unless the logger already knows what that value is. The logger can't do an SSM2 Reset command unless it knows the current baud rate.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 10:23 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Jon [in CT] wrote:
The logger can't read the current baud rate from RAM unless the logger already knows what that value is. The logger can't do an SSM2 Reset command unless it knows the current baud rate.

Ahh, that it true. Guess I didn't think that all the way through. There's no way for the logger to determine the baud rate ahead of time. Kind of a chicken-egg deal. Although you could still store the baud rate in ram and setup up the rom code to revert to 4800 baud if null. Then if you wanted to flash or to change the baud rate in ram or you forgot what you had it set to, you just do a hard reset by disconnecting the battery.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 10:59 am 
Offline
Experienced

Joined: Wed Jul 26, 2006 3:19 pm
Posts: 650
Location: Connecticut, USA
merchgod wrote:
There's no way for the logger to determine the baud rate ahead of time. Kind of a chicken-egg deal. Although you could still store the baud rate in ram and setup up the rom code to revert to 4800 baud if null. Then if you wanted to flash or to change the baud rate in ram or you forgot what you had it set to, you just do a hard reset by disconnecting the battery.
If there were only two possible baud rates (i.e. the default "normal" rate and a new standardized "fast" rate) then the logger or reflash program could try each baud rate, beginning with the default rate.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 11:10 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Jon [in CT] wrote:
If there were only two possible baud rates (i.e. the default "normal" rate and a new standardized "fast" rate) then the logger or reflash program could try each baud rate, beginning with the default rate.

Yeah, that would work. In fact, it could be any number of rates as long as each were defined for the logger so the logger could request, say, the ecu initialization string at each rate until it receives a response. Still should be a failsafe, though, so that a hard reset will default to the factory rate in case there are any problems.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 5:06 pm 
Offline
RomRaider Donator
User avatar

Joined: Sun Apr 09, 2006 12:05 pm
Posts: 866
Location: Indianapolis, IN
I don't see the need to set the BRR value "directly" (i.e. "64", "32", etc), nor write a 16bit or FP equivalent of the baud rate number (i.e. 0x2580 for 9600, etc). The logger might as well just use a single byte with each value representing a standard baud rate. 0x0 is default, 4800, 0x1 could be 1200, 0x2 could be 2400, 0x3 is 4800 again, 0x4 is 9600, 0x5 is 14400, etc. We don't need to run odd ball baud rates. 255 possible values + 1 failsafe (0x0) should be plenty. This also seems safer to me, though I guess as worst an ECU reset would fix it.

I'm actually finding some time to finish up the SD stuff and I'll work on this next. I am more than willing to have this "integrated" into Enguinity, or at least, I intend to write it in a convenient way for any logger that wishes to integrate with it. FWIW, I think giving general custom packet sending capability will cover this, as well as many other possible future tweaks. It'd be really neat to see a way for Enguinity to process features the way I described above in the xml post.

Only other caveat for *this* particular feature would be that Enguinity should switch its own logger baud rate in step to be the most user friendly. But a generalized packet maker tool definitely leave the door open to test other tweaks.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 02, 2007 6:10 pm 
Offline
Experienced

Joined: Fri Mar 24, 2006 3:14 pm
Posts: 768
That is great news! We look forward to your work! 8)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 69 posts ]  Go to page Previous  1, 2, 3, 4, 5  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