RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Sat Feb 17, 2018 7:25 pm

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: Tue Oct 02, 2007 6:10 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Freon wrote:
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.

The logger can't read whatever you define as representing the baud rate in ram until it already determines what the current baud rate is (by sending packets at each pre-defined rate until it receives a response). By then, it would already know the current baud rate. So, only the pre-defined baud rates need to be defined in the xml (ex. 4800, 9600, etc.). Also, having a byte value that represents a specific baud rate just adds unnecessary rom code rather than just using baud value itself.

Quote:
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.

I think this would also be unnecessary and a waste of code. You can already read/write via SSM. That is all that is needed. If the baud value is directly represented in ram, then the logger can simply calculate the correct baud value (when the user wishes to change it) based on the new user desired rate and write it -> done (and then the logger would switch to the new rate). You would only need to define the allowable baud rates in the xml and a simple expression to calculate the baud value. Rom code is setup so that if the baud value is null, then use a constant corresponding to 4800 baud (hard reset would therefore be the failsafe). Probably be something like 6 instructions.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 03, 2007 9:07 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Another step which I just thought of is the fact that the baud rate is set once post-reset unless when OBDII is being dealt with (10800 baud IIRC). However, this is easy to overcome. Clearing a bit in ram will run the baud rate set routine one time again, at least on the 16-bit ecu (haven't checked the 32-bit ecu). So, the steps would be -> 1. Write new baud value to ram 2. Clear bit effectively switching to new baud rate 3. Logger uses new baud rate. Additionally, instead of defining an conversion expression, the baud value could be explicity defined in the xml defs.

Remember, that 16-bit roms can be severely limited in unused rom space. One rom revision only has about 600 bytes total for code/data. When you start stacking on the features -> RamTune, on-the-fly map switching, per gear wg comp, launch control, etc., you run out room fast. So, any proposed feature that would impact this ecu (such as the baud rate change), should be keep this in mind -> How can we accomplish what needs to be done with the least amount of code/data? Running two different methods (one for 16-bit, one for 32-bit), doesn't make sense if we can easily meet the goals at hand with a single method.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 04, 2007 9:41 am 
Offline
RomRaider Donator
User avatar

Joined: Sun Apr 09, 2006 12:05 pm
Posts: 866
Location: Indianapolis, IN
Quote:
Remember, that 16-bit roms... Running two different methods (one for 16-bit, one for 32-bit), doesn't make sense if we can easily meet the goals at hand with a single method.

Well, I will not be writing anything for the 16bit ECU. I am purely concerned with the 32bit ECU. I'd rather take it further than split my available time and not get very far on either. I've done very little with the 16bit ECU and have no plans on spending further time on it.

Saving space in the 32bit ECU is not an issue. There is a fair amount of unused code branches that can be cleared if needed. Duplicate maps can be consolidated as well.

The 16bit and 32bit ECU are so far apart I don't see how it matters that they work in any sort of similar fashion. It might as well be a PC vs. Alpha/Unix. I don't see from the tuner/tuningprogram perspective how it matters what is happening in the background. Once the XML is set, it is irrelevent whether the codes mean. The code won't be similar between the 16 and 32bit ECU. The XML won't be either.

I just don't think it is a great idea to directly store register values in RAM. I think it is better for the ECU to protect itself, and only accept a switch byte and decide for itself what is safe. This is the way I'm going to write it. I think it is good practice.
Quote:
think this would also be unnecessary and a waste of code. You can already read/write via SSM

I think you misunderstood. I'm not suggesting any of the subject to which you're replying be written as new feature into the ECU. I definitely want to use the existing SSM write byte command and have already stated so.

What you're replying to here is talking about tuning program features. It would be immensely helpful for Enguinity or Ecuedit or ECUflash to have a generalized way to send write bytes so any arbitrary features in the future can be supported without specific support written into Enguinity/Ecuedit/ECUflash.

There's no reason for the Enguinity team to write support for a special baud rate feature when it would take just as much time to write in support for a generalized feature as I described above. It sounds like there is already support to send write byte packets. I'm only asking for a small extension of that so it can be a more practical to use feature while tuning a car.

Can you build a menu based on XML data? It would be killer to add a new drop down (i.e. File Edit Options .... Custom) that dropped down according to XML similar to what I posted before. This could handle your version of baud rate switch, my version, and all sorts of stuff in the future just by modifying the XML. Map sliding/switching could be done TOMORROW if something like this was available. (hint: its very easy to change a map slider to read from a fresh RAM address, it takes 30 seconds in a hex editor, and 0x0 [null on reset] is perfectly valid)

I think I'm going to start a new feature request post, because this thread is digressing.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 04, 2007 10:34 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Freon wrote:
The 16bit and 32bit ECU are so far apart I don't see how it matters that they work in any sort of similar fashion. It might as well be a PC vs. Alpha/Unix. I don't see from the tuner/tuningprogram perspective how it matters what is happening in the background. Once the XML is set, it is irrelevent whether the codes mean. The code won't be similar between the 16 and 32bit ECU. The XML won't be either.

I'm was talking about from the logger's perspective. Coding is trivial with your method or mine. Obviously, I can code for 16-bit ecu (and the 32-bit ecu as well), so I was thinking about how it would be added to the logger to be compatible with both ecus. I misunderstood what you meant, though, thinking you wanted to add a new SSM command byte to accomplish your goals.

Quote:
There's no reason for the Enguinity team to write support for a special baud rate feature when it would take just as much time to write in support for a generalized feature as I described above.

Can you build a menu based on XML data? It would be killer to add a new drop down (i.e. File Edit Options .... Custom) that dropped down according to XML similar to what I posted before. This could handle your version of baud rate switch, my version, and all sorts of stuff in the future just by modifying the XML. Map sliding/switching could be done TOMORROW if something like this was available. (hint: its very easy to change a map slider to read from a fresh RAM address, it takes 30 seconds in a hex editor, and 0x0 [null on reset] is perfectly valid)

Ok, I see where you are coming from now. That would very useful and would work with any method. I've figured out how to communicate via SSM in visual basic, for which I plan on creating my own real-time tuning app for testing as well as anything else like the baud rate change. Another option would be to change the baud rate on-the-fly, similar to the map switching I've already developed for the 16-bit ecu. Any specific combination of inputs/conditions (defogger switch/veh. speed/nuetral/rpm) could trigger the switch in baud rates. With the 32-bit ecu, you have even more inputs (all cruise control buttons, clutch switch).

So, have two rates to switch between (factory 4800 and say 19200). When you want to log, switch to the higher rate and then log. When you want to flash, switch back. That could be an easy interim solution that would not require the logger to support anything (only that you can define the baud rate in the xml which the test version of RomRaider supports).

EDIT: For the logger to do what you propose, the logger would need to determine the current baud rate by querying the ecu at each pre-defined rate until it received a response. Otherwise, the first time the user changes the baud rate, they won't be able to change it again (short of them manually modifying the logger's rate in the xml remembering what they had last changed it to).


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 19, 2010 10:46 am 
Offline
Experienced
User avatar

Joined: Tue Feb 12, 2008 11:00 pm
Posts: 153
Bump! :mrgreen:

Was there any progress on this?

I just went through my SH7058 manual (for A8DH201X ROM) eading up on the A/D converter and serial comms. Found all of the different SCI0-SCI4 setup routines, then traced the SSM ram addresses to confirm that it is using SCI2. I did the same for the A2ZJ710J, and found some similarities in SCI2's setup.

There are four routines for SCI2, all have many of similarities to those found in the A2ZJ710J ROM, ie: placement, surrounding code layout, and the values:
ROM: A8DH201X
0x4D2A4: Called from a small Jump table, 4800 baud / Async / 8-N-1 / n=0 @ N=d'129 (h'81)
0x4D3A4: Runs immediately after a small jump table, also 4800 baud / Async / 8-N-1 / n=0 @ N=d'129 (h'81)
0x881B1: Runs towards the end of a long subroutine, looks like SMR may be variable (pulled from incoming r13), BRR is set to d'59
0x19B2: Early rom, I haven't fully explored it yet. SMR = h'00 (Async/8-N-1/n=0) and BRR = d'39

_________________
06 Wrx Wagon 2.3 longrod in the works


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 19, 2010 11:47 am 
Offline
Senior Member

Joined: Mon Jan 19, 2009 2:31 pm
Posts: 1396
Location: Moscow, Russia
SH7058:
Divisor = 129+1 -> 80MHz\128\Divisor = 4800 bps (SSM)
Divisor = 59+1 -> 80MHz\128\Divisor = 10400 bps(OBD II)

SH7055:
Divisor = 39+1 but CPU clock used is under question..


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Wed Jan 20, 2010 4:38 am 
Offline
Experienced
User avatar

Joined: Tue Feb 12, 2008 11:00 pm
Posts: 153
Yup, I figured the d'59 was for OBD. In the 7055's, the d'39 routine always opens up, but the 7058's do not. I haven't traced it yet, but it looks like it may be unused.

After reading this thread and the one at OpenECU, I think adding either a new command or write routine to SSM is the way to go. Full control through the logger, and a reset will return to a flashable baudrate. However, Colby has been talking about adding adjustable baudrate support and a new multibyte request routine to improve SSM logging rates, so it may be unnecessary.

_________________
06 Wrx Wagon 2.3 longrod in the works


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Sat Jan 23, 2010 3:18 pm 
Offline
Moderator

Joined: Wed Nov 22, 2006 10:23 pm
Posts: 2476
So, a divisor of 11 would let us log at 56k? Where do I sign up? :)

If anyone needs laptop software to send specially crafted SSM packets, I will be happy to write it.

_________________
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: Baud rate for logger found for 32bit DBW
PostPosted: Mon Jan 25, 2010 12:51 am 
Offline
Senior Member

Joined: Mon Jan 19, 2009 2:31 pm
Posts: 1396
Location: Moscow, Russia
Probably I see a simple way to add logger dual\multi baud rate support without reflash compatibility problem.

SSM location 0x60 is for ecu reset.
It is read as 0xAA value.
If you write something else into this location your ecu will be reset after ignition OFF\ignition ON.

The first two readable RAM locations (0xFF8000 0xFF8001 for SH7055) hold 0xAA and 0x55 that are swaped if not 0xAA is writen to SSM 0x60. This is the flag for ecu reset after ignition ON.

Thus 0x60 SSM LUT function may be modified in order to reprogram SSM baud rate (by direct BRR modification). SSM baud rate will be changed for this particular logger session. And will be reset just after ignition OFF\ON.

There is a but.
All or some learned values will be erased that may be a drawback of this approach. But may be easily overcome with appropriate ROM mods.

Edit: As earlier was proposed an alternative SSM LUT entry (currently empty or readonly) write maybe used for baudrate change in order to prevent learned values to be erased.


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Mon Jan 25, 2010 8:29 am 
Offline
Experienced
User avatar

Joined: Tue Feb 12, 2008 11:00 pm
Posts: 153
If I understand correctly, I don't think such a caveat (forced restarts) is necessary.

If the 0x60 routine is passed the entire byte from the SSM command, the routine could be rewritten to use a certain byte, say h'00, to reset, and any other byte to change BRR.

The only issue would be connecting with an actual SSM computer, unless we know exactly what data they send for a reset, it could end up adjusting the BRR without a reset. Worst case scenario you need to do a hard reset.

However, if we're rewriting something, might as well just write a new routine in one of the unused spots.

_________________
06 Wrx Wagon 2.3 longrod in the works


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 26, 2010 1:44 am 
Offline
Moderator

Joined: Wed Nov 22, 2006 10:23 pm
Posts: 2476
fujiillin wrote:
However, if we're rewriting something, might as well just write a new routine in one of the unused spots.


I prefer this approach, it seems like there is a smaller chance for surprises to happen this way.

I also like Sasha's idea of tweaking the reset flag at the same time baud rate is changed, so that the baud rate change can be un-done just by turning they key. At least until the baud rate change is thoroughly tested.

Are you guys certain that the ECU reset routine also resets BRR? It seems like an odd thing to include in a 'warm reset' routine. As if Subaru (or Denso) predicted that people would be experimenting with BRR some day? :)

_________________
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: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 26, 2010 1:29 pm 
Offline
Experienced
User avatar

Joined: Tue Feb 12, 2008 11:00 pm
Posts: 153
According to the hardware manual:
Quote:
The CPU can always read and write to BRR. BRR is initialized to H'FF by a power-on reset and in
hardware standby mode. It is not initialized by a manual reset and in software standby mode. Each
channel has independent baud rate generator control, so different values can be set for each
channel.


It's still unclear to me exactly what they mean by power-on and manual, but I'm pretty sure a hard reset will clear it.

For the SSM packet application, would you be modifying RR java, C#, or something else? Open source? It would be a great way to start some progress towards ramtuning, and I've been meaning to pick up C# when I have the time. Also, there's a SSM library around here somewhere in C#.

_________________
06 Wrx Wagon 2.3 longrod in the works


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 26, 2010 2:27 pm 
Offline
Experienced

Joined: Sat May 31, 2008 10:14 pm
Posts: 125
Location: Quebec
According to the hardware manual, the limit would be 38400 right? uhm I believe the evo guy can go up to 56k no?

fujiillin wrote:
According to the hardware manual:
Quote:
The CPU can always read and write to BRR. BRR is initialized to H'FF by a power-on reset and in
hardware standby mode. It is not initialized by a manual reset and in software standby mode. Each
channel has independent baud rate generator control, so different values can be set for each
channel.


It's still unclear to me exactly what they mean by power-on and manual, but I'm pretty sure a hard reset will clear it.

For the SSM packet application, would you be modifying RR java, C#, or something else? Open source? It would be a great way to start some progress towards ramtuning, and I've been meaning to pick up C# when I have the time. Also, there's a SSM library around here somewhere in C#.


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 26, 2010 2:49 pm 
Offline
Senior Member

Joined: Mon Jan 19, 2009 2:31 pm
Posts: 1396
Location: Moscow, Russia
It depends on the circuitry at ecu and cable sides.
Cheap optocoupled cables are limited by 19200-38400, more elaborated and DC coupled are capable to operate at higher rates.


Top
 Profile  
 
 Post subject: Re: Baud rate for logger found for 32bit DBW
PostPosted: Tue Jan 26, 2010 4:16 pm 
Offline
Experienced

Joined: Sat May 31, 2008 10:14 pm
Posts: 125
Location: Quebec
well 19200 (if working well) is better than 4800 ;)

now I need to put my hand on a 32 bits ecu and make something happen.

Sasha_A80 wrote:
It depends on the circuitry at ecu and cable sides.
Cheap optocoupled cables are limited by 19200-38400, more elaborated and DC coupled are capable to operate at higher rates.


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 2 guests


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