Flashing the SBEC-II

[ShelGame]

So, did some experimenting today. Turns out, the flash routine for the SBEC-II is exactly the same as for the rom-aided SBEC (which is the protocol I'm using for the flashable SBEC modification). So, short story - I can read and flash SBEC-II's on the bench. I know a few guys had asked about modifying the '92 T3 cal (and T1). It looks like I could do them now, at least minor mods. I'm not near ready to make a 3-bar version yet.

[turbovanman²]

Rob, you are the man, :hail::hail::hail:

[ShelGame]

Oh yeah, this also means that my interface cable for the SBEC will also work for flashing the SBEC-II...

[black86glhs]

Time for some T-III's to see some added boost and still be comp controlled, maybe??

[ShelGame]

Yeah, should be no problem. Well, except that the TIII boost control is more adaptive than the previous boost control. But, it still should be no big deal to max out the boost on the '92 TIII's (and T1's).

[black86glhs]

Awesome Rob!!! Great work.

[turbo_III]

Awesome, can't wait:):D

[Austrian Dodge]

GREAT news!!

i have to tell janus about it ;)

[ShelGame]

Well, I seem to have hit a bit of a snag with SBECII flashing. It seems Chrysler put some security features in there to keep you from writing any .bin file other than the original. I can read any file, and I can write back the same file, but if I try to write a different file, the write times out. Hmm...

I bet I could get around it if I can figure out what bytes are the security code. They must have some code stored on the multipurpose/PIA chip that's checking the data before writing it to the flash chip.

[Xtrempickup]

coool, sounds like getting a Masi cal for my 92 Daytona running 92 2.5 TI elctronics is in the future

[Xtrempickup]

when can i send you my 92 2.5TI cal and expect to have it back????????

[ShelGame]

Well, I have to figure out how to get around the security feature first. 2nd, the '92 code is all 3D like the T3 code. It will take a while to figure it all out.

[Xtrempickup]

so it wont be that soon? i have to figure out what to do with the car since it will be completely immovable. maybe il wait for you to get further along with this

[ShelGame]

OK, so I think I figured out the problem. The Toshiba chip used in the SBECII needs 20V to program it. But, the 20V has to be turned off to verify. So, the programming is complicated.

My write only failed because of the programming voltage. Not some Chysler security feature (though, there are a couple of security features when reprogramming via a DRBII, but they're not present when using a laptop...). So, If I put my SBEC module into a SBECII, it should work perfectly. But, flashing a stock SBECII is probably a no-go...

[turbo_III]

OK, so I think I figured out the problem. The Toshiba chip used in the SBECII needs 20V to program it. But, the 20V has to be turned off to verify. So, the programming is complicated.

My write only failed because of the programming voltage. Not some Chysler security feature (though, there are a couple of security features when reprogramming via a DRBII, but they're not present when using a laptop...). So, If I put my SBEC module into a SBECII, it should work perfectly. But, flashing a stock SBECII is probably a no-go...

In other words you are saying the SBEC II would have to be socketed with a different chip for You to be able to flash it with your module?

[ShelGame]

Well, you'd have to pull the original toshiba chip, and install one of my flash modules. I'm 99% sure the pinout is the same. So, no special socket or anything is required.

[risen]

OK, so I think I figured out the problem. The Toshiba chip used in the SBECII needs 20V to program it. But, the 20V has to be turned off to verify. So, the programming is complicated.

My write only failed because of the programming voltage. Not some Chysler security feature (though, there are a couple of security features when reprogramming via a DRBII, but they're not present when using a laptop...). So, If I put my SBEC module into a SBECII, it should work perfectly. But, flashing a stock SBECII is probably a no-go...

So, out of curiosity, was there a way for the dealerships to flash the SBEC-II? Did the DRB-II supply the 20V? I know that the USB adapter I've been using is able to set a line high or low with DCD so maybe that sort of functionality could be leveraged for this. Would something like that work? Triggering the 20v with the DCD line, write, drop the DCD/20v and verify?

Also, I may be getting a buddy's SBEC-II from his 92 ramcharger. It's a little flaky in-car, but cold on the bench it should be OK. So, LMK if I can be of any help. I've got a little more time now that I'm not fighting with my bench rig so much.

[ShelGame]

So, out of curiosity, was there a way for the dealerships to flash the SBEC-II? Did the DRB-II supply the 20V? I know that the USB adapter I've been using is able to set a line high or low with DCD so maybe that sort of functionality could be leveraged for this. Would something like that work? Triggering the 20v with the DCD line, write, drop the DCD/20v and verify?

Also, I may be getting a buddy's SBEC-II from his 92 ramcharger. It's a little flaky in-car, but cold on the bench it should be OK. So, LMK if I can be of any help. I've got a little more time now that I'm not fighting with my bench rig so much.

Yes, the DRB-II supplied the 20V. Though it's not clear where it got the 20V from. Wall transformer maybe?

I need to figure out which pin to apply the programming voltage to. If it's the same as the bootstrap pin, then it might be easy. I guess I can test that on my bench... hold on...

[ShelGame]

Nope, that didn't seem to work. I don't know if it's the timing (I was trying to hit the boot button manually), or if it's just the wrong line. I've got to look into it more...

[ShelGame]

I love patents. It looks like if you put 20V on the bootstap/Rx line, you get the programming voltage. If you want to know how/when to apply the 20v, look here -

SBECII Flashing Patent (http://www.google.com/patents?id=bSYjAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q=&f=false)

Scroll thru until you get to the flowchart. You can ignore the security stuff since we're bypassing all that and programming with a PC. Really, we just need to apply the 20V at the right times.

[bakes]

Sweet on a side note now we can flash the TCM using that protocol too.

[Xtrempickup]

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

[zin]

Sweet on a side note now we can flash the TCM using that protocol too.

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

Mike

[ShelGame]

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

[risen]

I love patents. It looks like if you put 20V on the bootstap/Rx line, you get the programming voltage. If you want to know how/when to apply the 20v, look here -

SBECII Flashing Patent (http://www.google.com/patents?id=bSYjAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q=&f=false)

Scroll thru until you get to the flowchart. You can ignore the security stuff since we're bypassing all that and programming with a PC. Really, we just need to apply the 20V at the right times.

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.

[ShelGame]

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.

[bakes]

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

[risen]

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.

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?

[ShelGame]

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

[wowzer]

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

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.

[Vigo]

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.

[janus]

what in hell!! ZOMG!!
Rob you're the man! :D :D *dance*

okay now, anyone got a 92 2.5 T1 .bin? :D

[ShelGame]

Yeah, I have a '92 2.5 T1 .bin now.

[ShelGame]

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.

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.

[janus]

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? :p)
i will take a look at my T1 SBEC-II to find out which chip is actually hiding in there.

[ShelGame]

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? :p)
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...

[risen]

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

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?

[ShelGame]

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.

[janus]

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?

[risen]

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.

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.


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?

3d tables are 2 inputs (x and y) and one output (z). 2d tables are 1 input (x) and 1 output (y) .

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).

[janus]

3d tables are 2 inputs (x and y) and one output (z). 2d tables are 1 input (x) and 1 output (y) .

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).

okay so i got that right with the 3D tables with my example of a table with input RPM and MAP, outputting SA :) thanks for clearing that up. wasn't sure we were talking about the same things.
i now remember the slopes of the 2D tables. i watched those d-cal tutorials about that. are these chrysler ecm's the only ones using slopes? but yeah, it would have to be recalculated in tunerpro for each point you move. don't know if that could be done by just supplying a definition file (xdf) to tunerpro?
oh and would you please explain some details of the non-conform fueling tables to me? :) until now i wasn't much involved with tuning on our cars as the SBEC-II was just out of reach to be tuned, but maybe there's a change of that in the future :)

sounds good what you say about the EEC-IV. i have a euro-ford here, a ford scorpio, maybe merkur scorpio over in US?, anyways this is an NA 2.0 4cyl, that i was thinking about turbo-ing one day and it also has an EEC-IV.. sorry for the off-topic :D

[ShelGame]

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?

Yes, except that my plan to add 3-bar to the 3D code was to simply add a 3rd MAP range for the 14.7 to 29.4 area and leave the lower boost area stock, or nearly stock. That way you won't lose any driveability or emissions compliance, and I won't have to try and re-scale the 3D tables for 3-bar. So, the MAP variable would go to a 24-bit resolution - for all intents and purposes.

Everything prior to the '91 TIII SBEC used 2D tables exclusively. 1 input, 1 output. As in Spark advance vs. RPM, and Spark advance vs. MAP. The 2 results are added together.

[ShelGame]

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) .

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).

Ha, it only seems ridiculous becuase none of the other OEM's do it that way. If you think about it, the point-slope storage method is brilliant. Compare the Chrysler 2D lookup routine to the Ford or GM 2D interpolation routine. It's much more processor intensive to calculate the slope on the fly and project the next point, than it is to simply store the slope. I think Chryslers lookup is easily 1/4 the lines of code as Ford or GM's interpolation.

As for the 3D stuff, I know why they did what they did, but I think it couldv'e been simpler without sacrificing anything. I mean, if you're going to split the MAP signal, why not split it linearly, even if you have to use 4 bytes instead of 2 to get the resolution you want? Sometimes, I think they did things just to be clever and/or make it hard to reverse engineer.

The fuel tables are essentially the same format, they just return a 16-bit value (from an 8-bit lookup) instead of an 8-bit value. That's needed for fuel PW, but not for anything else.

[janus]

thanks again for clearing up the whole 2D/3D table confusion for me :) on the 3bar MAP, so you would end up with a 24-bit resolution of the 3bar split up into: 10bits for -14.7psi to 0, 6 bits for 0 to 14.7psi and another 8 bits for 14.7psi to 29.4?? or, is there a way to mod those transfer functions to make resolution of the MAP signal linear? i know i have a lot of questions, but i'm really anxious to learn about this and maybe, one day i can even contribute to something on here ;) what else is stored as a 3D table


If you think about it, the point-slope storage method is brilliant. Compare the Chrysler 2D lookup routine to the Ford or GM 2D interpolation routine. It's much more processor intensive to calculate the slope on the fly and project the next point, than it is to simply store the slope. I think Chryslers lookup is easily 1/4 the lines of code as Ford or GM's interpolation.

I haven't looked at any of the assembly code behind any of those computers but i was thinking the same thing when i saw those d-cal tutorials where the data actually stored in the cal was presented in this separate window as hex data and gets compared to the slope displayed in d-cal. it takes much more CPU time to calculate a value between two separate points in a table vs. getting data from the stored slope.

btw, i just took a look at a bin-file of GM's 305 TBI C3 ECM ('88-up), because that's just what i happen to have been learing from and gathering experience in tuning. there are actually 4 3D tables and 25 2D tables. as said, this was in an '88 ECM and i'm sure they used them some years before when TPI came up in '85, maybe even for their Crossfire FI of 82-84... anyways, i just never really understood why the 3D tables in the SBEC-II were that special or complicated, and also why chrysler has seemingly not used them before the '91 TIII SBEC came up. is it because chem and d-cal can't display those tables, or is it because of those non-linear scaling transfer functions Rob mentioned? or am i missing something else here.

thanks in advance for any enlightenment :) oh and anyways in general, thanks a lot for all the R&D that you guys on here put into reverse engineering!

in my "research" folder, i had this file about those 91 T3 SBEC 3D tables that i think came from either Derek or Rob. i don't know if it is of any help, i myself never understood it thoroughly, but i just thought i'll share away :D
http://nopaste.info/20c3ae611a.html
hmm, makes me wanna learn some 68HC11 assembler :D (this is the right µc ain't it?)

[ShelGame]

No, there's simply no 3D in any of our cals before the '91 T3. After that, they kind of show up everywhere.

You could re-scale the transfer functions, but then you'd have to also re-scale the 3D tables, since they are based on a certain byte equalling a specific MAP value.

[risen]

Ha, it only seems ridiculous becuase none of the other OEM's do it that way. If you think about it, the point-slope storage method is brilliant. Compare the Chrysler 2D lookup routine to the Ford or GM 2D interpolation routine. It's much more processor intensive to calculate the slope on the fly and project the next point, than it is to simply store the slope. I think Chryslers lookup is easily 1/4 the lines of code as Ford or GM's interpolation.

Why limit it to the OEMs, I'd like to find any example other than Ma Mopar who does it this way. :) Someone definitely gets a gold star for the slope after the points idea, but I still wonder why they did it at all. Are these old motorola processors really not powerful enough to do a proper interpolation on the fly? I've often thought that the amount of additional space required to put the slope in for each point could have been spent coding a regular interpolation routine and/or on a 3d map x rpm table. You could end up with fewer table lookups, less function call overhead, etc. Maybe the older processors just didn't have the oomph to do all that was asked of them and changing the format was enough to get them plenty of breathing room.

It's still frustrating that we can't use the tools others have created. I mean, we're editing data not attempting to prove that P=NP. You can't tell me I'm the only one frustrated by that.



As for the 3D stuff, I know why they did what they did, but I think it couldv'e been simpler without sacrificing anything. I mean, if you're going to split the MAP signal, why not split it linearly, even if you have to use 4 bytes instead of 2 to get the resolution you want? Sometimes, I think they did things just to be clever and/or make it hard to reverse engineer.

The fuel tables are essentially the same format, they just return a 16-bit value (from an 8-bit lookup) instead of an 8-bit value. That's needed for fuel PW, but not for anything else.

Seriously, I've spent more code on being clever than just solving whatever problem is at hand plenty of times. But I always look at it after and wonder WTF I was thinking :D.

I'll bet that in some bar out in MI, there's chrysler engineers boozing it up and joking about the stuff they put in these old ecus.

[ShelGame]

You have to remember also, that the 2D table format was originally developed for the LM, which is just a 6803 with NO provisions built in for divide functions (like the 6811 has). Imagine how much code would be required to calculate the slope on one of those antiques. Plus, it's slower overall than the 6811. I think it skips interrupts at near 6k rpm. Meaning the main loop takesso long to get thru, that you ignore some of the distributor interrupts at high RPM. if you add compute time to the main loop with a full interpolation routine, you lower that RPM.

Of course when they went to the 6811, it wasn't as big a problem, but the investment had already been made in the code and calibration. A complete re-write was likely too much to expect...

[Xtrempickup]

so what does this all mean to the average person that needs a cal and is waiting to have one made

[risen]

You have to remember also, that the 2D table format was originally developed for the LM, which is just a 6803 with NO provisions built in for divide functions (like the 6811 has). Imagine how much code would be required to calculate the slope on one of those antiques. Plus, it's slower overall than the 6811. I think it skips interrupts at near 6k rpm. Meaning the main loop takesso long to get thru, that you ignore some of the distributor interrupts at high RPM. if you add compute time to the main loop with a full interpolation routine, you lower that RPM.

Of course when they went to the 6811, it wasn't as big a problem, but the investment had already been made in the code and calibration. A complete re-write was likely too much to expect...

It kind of makes one wonder why they were so wedded to the 6803, if they couldn't get it to handle the interrupt rate around 6k. Unless they figured no one would ever rev one out there.

I guess since they set it and forget it with the cals, it wasn't as big a deal to them as it is to me. You know, only having to edit a cal a few times makes these sorts of things easy to overlook. But when you have time to ponder it because you're searching for the next table you have to edit, it becomes a little more obvious (or maybe I could just get better at tuning). There must come a point where you ditch the legacy code because it's holding you back, though. I'd wonder how many of the vestiges of our ecus are in things like the neon ecu.


so what does this all mean to the average person that needs a cal and is waiting to have one made

Very little, if anything. It's all arcanum.

[ShelGame]

...I'd wonder how many of the vestiges of our ecus are in things like the neon ecu....

Surprisingly a lot - at least in the '94/95 FCC (Four-Cylinder-Controller - essentially a specialized SBEC III). Though, the processor is a 16-bit motorola unit (I forget which one), so some of the code is differen due to the more advanced instruction set and register availability. But, it still used the 2D transfer function/3D table scheme as the TIII...

[bakes]

link to tunerpro rt
http://www.tunerpro.net/downloadApp.htm

[Xtrempickup]

any progress with this

[ShelGame]

Ok, so I got my flash adapter from eBay. In studying the patent for this SBEC-II Flash module, I don't think it will hard at all to hook up the Chrysler flash adapter to a PC using an FTDI cable. We should be able to use one of the unused handshaking signals to control the 20V on/off. I'll have to open up the module to see what Chrysler used for the 20V regulator. If it's not a proprietary chip, then it should be easy to duplicate (and probably improve) the adapter.

[risen]

Ok, so I got my flash adapter from eBay. In studying the patent for this SBEC-II Flash module, I don't think it will hard at all to hook up the Chrysler flash adapter to a PC using an FTDI cable. We should be able to use one of the unused handshaking signals to control the 20V on/off. I'll have to open up the module to see what Chrysler used for the 20V regulator. If it's not a proprietary chip, then it should be easy to duplicate (and probably improve) the adapter.

I can give you the part number and schematic I used for the 23v bootstrap on the smecstim if you want to try that. It needs a 5v input, the 8 pin boost converter, a diode, a coil (I used a small 10uH one) and a couple of resistors. The resistors are used to make a divider to set the output voltage, or you can pwm the chip to get the desired voltage.

I can give you the 2 resistors on the smecstim to change if you'd like to try and make the 20v there first.

[ShelGame]

it looks like the reg they used takes various inputs, and outputs 12v (for Bootstrap) or 20v (for programming). It must be some kind of switchable power supply. The patent doesn't really give any specifics except on how it works...

[DodgeZ]

I just read the whole thread. I thought I was nerd, good god..... Keep up the work BTW :)

[risen]

it looks like the reg they used takes various inputs, and outputs 12v (for Bootstrap) or 20v (for programming). It must be some kind of switchable power supply. The patent doesn't really give any specifics except on how it works...

I looked at the datasheet for the LT1307 which I used for the smecstim. It can be powered from +12v, so I think you can probably manage to get away with the setup I have on the stim, swapping +12 for the +5. You could leave the converter disabled and have a 12v output and enable it for the 20v output. The only issue would be the drop of the diode when in the +12 mode, but a schottky could minimize that. Anyways, If you're interested I'll send you the schematic from the smecstim's boost converter.

[risen]

I just read the whole thread. I thought I was nerd, good god..... Keep up the work BTW :)

Well that's 20 minutes of your life you'll never get back... :D

[ShelGame]

OK, here's the schematic for the SBEC-II Flash adapter.

Basically, U1 is a step-up power supply that is used to create the 20V programming voltage (VPP) from the 12V battery supply. U2 is the precision 12V supply (VBB). It looks like U1 is very similar to the LT1307 you mentioned - though not the exact same chip. I'll open up the module tonight and see what chip they're using there.

BUS(+) and Bus(-) control the switching between the voltage levels. When Bus(+) is low, you get normal SCI communication. When Bus(+) is high, SCI communication is disabled and either VPP or VBB is put on the SCIRx line. Bus(-) determines which voltage is put on the line. If Bus(-) is lo, then you get VPP (programming voltage); if Bus(-) is hi, you get VBB (bootstrap voltage). It should be pretty easy to use the extra control signals on the FTDI cable to control Bus(+) and Bus(-).

[janus]

good research progress :) hope you can work it out Rob!

[risen]

OK, here's the schematic for the SBEC-II Flash adapter.

Basically, U1 is a step-up power supply that is used to create the 20V programming voltage (VPP) from the 12V battery supply. U2 is the precision 12V supply (VBB). It looks like U1 is very similar to the LT1307 you mentioned - though not the exact same chip. I'll open up the module tonight and see what chip they're using there.

BUS(+) and Bus(-) control the switching between the voltage levels. When Bus(+) is low, you get normal SCI communication. When Bus(+) is high, SCI communication is disabled and either VPP or VBB is put on the SCIRx line. Bus(-) determines which voltage is put on the line. If Bus(-) is lo, then you get VPP (programming voltage); if Bus(-) is hi, you get VBB (bootstrap voltage). It should be pretty easy to use the extra control signals on the FTDI cable to control Bus(+) and Bus(-).

Nice find. :thumb:

After looking at the schematic it dawned on me that my suggestion to use +12 from the car to feed a LT1307 may not be the best idea. Any variation in the car's +12 voltage will result in a variation in the output from the boost converter. I believe this is the reason they feed the +12 converter from the boost converter.

Changing the resistors on the divider for the LT1307 (or using pwm) to make it put out +12 or +20 after passing the battery voltage through a 7805 would be enough to handle the 2 voltages with a good deal of accuracy, though.

[ShelGame]

Ok, so Chrysler used a MC33063A DC-DC regulator. They're still available from Digikey in various packages and prices. So, that means it's really easy to copy the SBEC-II / EATX flash module. Just need a little software and flashing these should be no problem with a FTDI USB-Serial cable and a laptop.

BTW, my module has obviously never been used. It still has dielectric grease on the 60-way pins...

[DodgeZ]

Ok, so Chrysler used a MC33063A DC-DC regulator. They're still available from Digikey in various packages and prices. So, that means it's really easy to copy the SBEC-II / EATX flash module. Just need a little software and flashing these should be no problem with a FTDI USB-Serial cable and a laptop.

:thumb::thumb: Now you should get cracking on the the 92/93 R/T stuff:D

[turbovanman²]

Wow, I don't know where you guys get this stuff from but keep it up, damn. :hail::hail::hail::hail::hail:


Ok, so Chrysler used a MC33063A DC-DC regulator. They're still available from Digikey in various packages and prices. So, that means it's really easy to copy the SBEC-II / EATX flash module. Just need a little software and flashing these should be no problem with a FTDI USB-Serial cable and a laptop.

BTW, my module has obviously never been used. It still has dielectric grease on the 60-way pins...

So do this mean A604 reprogramming is coming? ;)

[zin]

So do this mean A604 reprogramming is coming? ;)

Oh, yeah!!!:thumb::thumb:

Or at least I hope so!:nod:

Mike

[ShelGame]

A604 flashing should be possible. Just need one of the early .bins to start with. The nice thing about the A604 (at least the early version), is that Chrysler put nearly the complete flowchart for it's operation in the patents. Later patents have the flowcharts for some of the newer operation (like auto stick) and other improvements they made.

[92 R/T]

:cheer2::thumb:

I wish I could understand a quarter of the stuff you are saying.

Thanks for all the research and hard work.

[sev80]

what ever came of this?

[wowzer]

did you see this link: http://www.turbo-mopar.com/forums/showthread.php?70122-ECU-Tuning-Options&highlight=sbec+ii+flash

all of the chips mentioned can be flashed, including the neon fcc chips (don't recall where rob ended up with the factory flashable sbec2 chips) via mptune. the best option was to get a boost button flash module / adapter and socket the ecu. i assume an ostrich can be used in place of the sbec2 chips but someone else would need to confirm that.

[sev80]

thanks for that link, I had not seen it before. The bad news is It looks like at the very least I'd need a latch board to use a normal flash chip, but Boost button is no longer selling any items..

[chromguy]

thanks for that link, I had not seen it before. The bad news is It looks like at the very least I'd need a latch board to use a normal flash chip, but Boost button is no longer selling any items..

If you can solder or know someone who can you you can order the boostbutton latch board from OSHPark and get the chips from Digikey. LMK if you need more info

[wowzer]

thanks for that link, I had not seen it before. The bad news is It looks like at the very least I'd need a latch board to use a normal flash chip, but Boost button is no longer selling any items..

hopefully there will be another source of populated boards in the near future since i will need some also!!

[ShelGame]

Yes, I sold all of my remaining inventory to another user or 2 (I will let them make any announcement when they are ready). I'm working on packing up my stuff for them this weekend.

That said, most of the V8 and Jeep SBECII's are flashable from the factory. Look thru the semi-clear potting; if you have a 32-pin or 36-pin Toshiba chip, it's flashable. I can probably setup a benchtop or in-car flash adapter for you guys to test with.

Morris - this would use the same basic software we used for the Neon stuff. Just a slightly different write routines due to the different .bin size. I think the Toshiba erase/write commands are the same even. I'll need to confirm the Toshiba chip ID for the SBECII.

The reason I stopped pursuing this is simply because my flash module doesn't require the external adapter to get 20v for programming. And, most of the turbo SBECII's don't use the Toshiba flash chip. So, this external flash setup is really only useful for the 'other' cars.

[wowzer]

he's back!!

hey rob L, (off topic a bit), did you see the jeep 781 bin i posted up? i was thinking while you are sitting outside on your back deck drinking your moheto in balmy michigan that maybe you'ld like to "browse" over that cal and clean it up/enhance it a bit!! especially what the 3d tables are referencing as well as rev limiter, etc. just saying............

[sev80]

So I have a SBEC II with a 12/93 date on it and it is definitely 28 pin (counted as you mentioned).

I ordered a 2/95 one and it should be coming next week, I'll check to see if it has a 32 pin or 28 pin setup.

Really excited about getting the jeep cals figured out. It's pretty much on my mind all day.

[sev80]

If you can solder or know someone who can you you can order the boostbutton latch board from OSHPark and get the chips from Digikey. LMK if you need more info


i can solder pretty decently as long as it's not SMT stuff.

[chromguy]

i can solder pretty decently as long as it's not SMT stuff.

Good news it is SMD so you are good to go.... LOL

On a serious note, it is much easier than you think. Here is a good video by Dave Jones on the exact topic
https://youtu.be/b9FC9fAlfQE

[sev80]

Good news it is SMD so you are good to go.... LOL

On a serious note, it is much easier than you think. Here is a good video by Dave Jones on the exact topic
https://youtu.be/b9FC9fAlfQE




Nooooop!! I'm hoping there's a few pre assembled ones left for when boost button's new owners get stuff in place.

[sev80]

Nooooop!! I'm hoping there's a few pre assembled ones left for when boost button's new owners get stuff in place.


anyone know what the value of the R1 resistor is on the bottom of the latch board? Going to order the components to put it together. i see the top requires a 28 pin socket..already have those, whats the part numbers on the pins on the bottom?

Seems easy enough to put together.

[ShelGame]

anyone know what the value of the R1 resistor is on the bottom of the latch board? Going to order the components to put it together. i see the top requires a 28 pin socket..already have those, whats the part numbers on the pins on the bottom?

Seems easy enough to put together.

You don't need the resistor. It's only there to try and force the Ostrich into sleep mode. It didn't work.

Just FYI - Hand soldering the TSSOP stuff is a -----.

[olk93]

Hmmm... interesting to see toshiba eeproms mentioned above. I have couple native '93v6 sbecs here, i assume them to be sbec2, too.
They have sgs-thomson m28f256 eeprom and need 12v-pp.

So whats going on here?

I will post the .bin(s) as soon as i manage to transform the bin into usable state. They look somehow x'ored or bitwise manipulated to me.

I used the 'ancient' chad's smecflash-foobar tool with wine under linux using usb fti-cable (homebrew with inverted rx/tx).

[ShelGame]

Cool. I'd never seen one, actually. But, the command codes are known for reflashing them, too. Seems nearly the same as the Neons except for the memory size.