Sweet on a side note now we can flash the TCM using that protocol too.
Sweet on a side note now we can flash the TCM using that protocol too.
soo when are you doing one and seeing if it takes?? would be great to have a properly running car to at least drive a little more than gingerly
This is an interesting development, to me anyway. So, it seems we could flash a non-auto stick TCM with an Auto-Stick cal? I'm also curious about modding the TCM cal for higher performance/longevity... But, I might be getting ahead of myself...Originally Posted by bakes
Mike
"The Constitution is not an instrument for the government to restrain the people, it is an instrument for the people to restrain the government - lest it come to dominate our lives and interests." - Patrick Henry
Bad laws are the worst sort of tyranny.
- Edmund Burke
I'm positive the TCM uses the same flashing protocol. I have a ~95 TCM on my bench. Lemme see if I can find the pinout. Maybe I can bootstrap it and read the program off it. Decoding it is another story...
So, after boostrapping the smec and transferring the code to load the flash (which is non-trivial, but I'll ignore it for now), you need to send it 64 bytes, set the 20v on the RX/boot line, and wait for the 64 bytes to come back. I'm sure something like this can be done using the DCD line on a serial port or the USB controller I've been using.
As a side note, while looking at parts for my smecstim, I found that TI had a small package step up converter that would take 5v and boost it to 21v for a LCD. I haven't tested one but that might be a plausable source for the 20v, since there isn't a large need for amperage.
I'm not sure that the bootloader we're curently using does it 64bytes at a time. I think we send the entire 32K and then read it back. So, you possibly only need to turn the 20v on/off once. That's why I was thinking I could do it manully, but my bench rig only puts 12-14V to the Rx/Boot line - not 20.
2 car batterys wired in series
Got a 9v?
Anyways, I was wrong about which line the dlp-txrx-g adapter uses to control the external transistor. It's DTR, so that should be easily leveraged in software to turn the 20v on/off at will. From the schematic I briefly looked at, I think the 20v will need to be put through a pullup resistor, because the adapter grounds it.
However, I'm curious to know where the 32k gets stored before it's written to the prom. It's not like the uc has 32k of memory free, does it? Wouldn't it require a 'chunk' of data that fits in it's memory along with the write/boot code?
Well, yes it burns 32 bytes at a time (I think). But it doesn't verify until the entire 32k gets written. Of course, I could be wrong. I haven't really looked at the bootloader in years...Got a 9v?
Anyways, I was wrong about which line the dlp-txrx-g adapter uses to control the external transistor. It's DTR, so that should be easily leveraged in software to turn the 20v on/off at will. From the schematic I briefly looked at, I think the 20v will need to be put through a pullup resistor, because the adapter grounds it.
However, I'm curious to know where the 32k gets stored before it's written to the prom. It's not like the uc has 32k of memory free, does it? Wouldn't it require a 'chunk' of data that fits in it's memory along with the write/boot code?
sorry if i am not keeping up but r u talking about the t1 smec bootloading of a program? basically at bootstrap the builtin routine waits for a 256 byte boot program and stores it beginning at address 0000. when the last byte of the boot program is received the bootloader automatically executes the commmand at address 0000. the existing downloaded program then just waits for a read or write command. You can then send up to 255 bytes at a time; however, that is just a limitation in the downloaded program. it could easily be reprogrammed to write all 32k at one time, just need to use a word register versus a byte register. also, the verification response could be automatically included to echo back all 32k at one time, versus having to reread 255 bytes at a time.
What i want to know is, if you are able to flash sbec-2s, does that mean you could possibly find and move the rev limiter in 92-93 3.0 and 3.3 cals??
Id be interested.
what in hell!! ZOMG!!
Rob you're the man!
okay now, anyone got a 92 2.5 T1 .bin?
Yeah, I have a '92 2.5 T1 .bin now.
I may already know where the rev limiter is in the '92+ 3.0 cal (I'll have to check my dis-assy later; don't have it with me today). I haven't seen a 3.3 cal.
anything i can to do help disassemble the '92 T1? (or am i just making a fool of myself with this question because it's already been done?)
i will take a look at my T1 SBEC-II to find out which chip is actually hiding in there.
It's not finished, but I have started on it. The problem is, it looks like it uses nearly the same codebase as the '92 TIII - which is 3D. So, it's completely different from the '91 T1 code, which I'm pretty familiar with. Also, the '92 code introduced a new type of 3D table that isn't supported by D-Cal (or CHeM for that matter). So, there's currently no way to edit these cals except manually...anything i can to do help disassemble the '92 T1? (or am i just making a fool of myself with this question because it's already been done?
i will take a look at my T1 SBEC-II to find out which chip is actually hiding in there.
I was looking at tunerpro and it's definition files the other day and I'd bet that it could be used for our stuff. It's already got 3d support with a good graphing facility. I know there are other editors in the works but it probably wouldn't be all that hard to come up with a program to convert a .tbl to their definition format. We'd just need to decide how the entries in the .tbl need to look for 3d tables and I could probably code a converter in perl in a couple evenings. Anyone interested?
I've looked at that before. The problem we have is the transfer functions for the 3D inputs. The 3D tables don't use the same MAP and RPM signals as the 2D tables. First, MAP and RPM and fed thru a transfer function that re-scales them and splits the signlas into 2 8-bit ranges. Essentially making MAP a 16-bit variable (RPM is already a 16-bit variable). The problem is, the 3D MAP signal bit-density is different in vacumm than in in boost. For example, the first 10 bits might be used for vacuum (-14.7 to 0psi) and the 2nd 6 bits are used for boost (0 to 14.7psi). Chrysler did this to improve the resolution in vacuum - where emissions and driveability are the prime concerns.
What that really means that the X and Y axis of the 3D tables may not be linear. Tunerpro can't handle this. You can display the SBEC 3D tables in tunerpro - so long as you realize the MAP and RPM references are not correct as displayed.
Plus, Tunerpro can't display our 2D tables at all, as far as I can tell. I had e-mailed the developer (forget his name). He seemed open to supporting our 2D format, but I never followed thru.
i was aware of the SBEC-II's 3D tables, let me ask a question about this though. a SA table based on MAP vs. RPM is considered a 3D table, right?
that transfer re-scaler function you talk about is.. well, interesting. and wee, it's sick that vac operation got more attention (read bits) than boost, but well, you have already said why this was of more concern to chrysler. so do i read it right that with a 3 bar MAP sensor this would mean 10 bits resolution for -14.7 psi to 0 and only 6 bits for 0 to 29.4psi?
about tunerpro and 3D tables, i use that a lot with a GM TBI system i've been tuning. i could really imagine a .xdf for our .bin files to have them integrated into tunerpro, but as Rob said, that transfer function could produce some headaches there.. btw i think the developer is mark mansur. and what in hell are 2D tables?
Sometimes I forget the ridiculousness that comes standard with every chrysler ecu. You've explained the 3d issue to me before, but I keep forgetting that it's not linear. Well, back to rolling our own solution.
3d tables are 2 inputs (x and y) and one output (z). 2d tables are 1 input (x) and 1 output (y) .i was aware of the SBEC-II's 3D tables, let me ask a question about this though. a SA table based on MAP vs. RPM is considered a 3D table, right?
that transfer re-scaler function you talk about is.. well, interesting. and wee, it's sick that vac operation got more attention (read bits) than boost, but well, you have already said why this was of more concern to chrysler. so do i read it right that with a 3 bar MAP sensor this would mean 10 bits resolution for -14.7 psi to 0 and only 6 bits for 0 to 29.4psi?
about tunerpro and 3D tables, i use that a lot with a GM TBI system i've been tuning. i could really imagine a .xdf for our .bin files to have them integrated into tunerpro, but as Rob said, that transfer function could produce some headaches there.. btw i think the developer is mark mansur. and what in hell are 2D tables?
Now, the problem with our 2d tables is that chrysler had to go and stick the slope in after each x and y point. So tunerpro would need to both calculate the slope again after you changed a point and know that it has to use every other pair of bytes for the x/y coordinates to graph. Then there's the fueling tables that don't conform to the standard the other tables do.
I was actually looking at tunerpro for a friend who's looking to tune his own EEC-IV. Say what you want about the blue oval, but EEC-IV is actually quite flexible and capable for something back from the late 80's early 90's. Want bigger injectors? It's a matter of scaling 2 values and you're done. Have a bigger MAF? Pump in it's xfer function. You can even change the injector firing order (from what I saw).
Posting Permissions
Reply With Quote
