Ahhh, good to know. It took me a while to figure out that what I had for pin 12 was actually 13, same with 13 and 14. It's my own fault for trying to hurry and squeeze it in last night.Originally Posted by ShelGame
Just out of curiosity, it doesn't matter to the smec that it's being fed 12v instead of the 8v it normally gets from the power board part of it?
that dash is for winlog, not logworks.
hey, keith, would it be possible to get the logworks to read the TechEdge 2.0 dataframes? (http://www.wbo2.com/sw/logger.htm) you say that logworks rocks.
Brian
No, it doesn't care. I'm actually feeding it ~14V because that's what my home-grown power supply puts out. It power up just fine...
I'm sure we could push that data into logworks with a plugin but you're going to have to run logworks with the mtsstim.dll (which fakes logworks by making it think there's a full innovate logging chain). It might be better to see if it's possible to convert the techedge data into the MTS format (which is innovate's serial format) and let logworks pick it up.that dash is for winlog, not logworks.
hey, keith, would it be possible to get the logworks to read the TechEdge 2.0 dataframes? (http://www.wbo2.com/sw/logger.htm) you say that logworks rocks.
Brian
It can be done, but I think it's going to be a bit of an undertaking and my plate's kinda full ATM. And to complicate maters I don't have access to any techedge hardware.
I'm using an old AT style PSU which has a solid 12v signal and plenty of available juice. I found out the hard way with portmon that the serial port built into my laptop won't do 62500 baud, good thing the pcmcia card I have does.No, it doesn't care. I'm actually feeding it ~14V because that's what my home-grown power supply puts out. It power up just fine...
Has anyone ever gotten good serial tests against the smec on a bench? It seems like it's working but I can't seem to get stable vaules back from the switch to high speed test. I send it 0x12, switch from 976 to 62500, and send it 0x12 and 0xf2 in alternating sets, I get 5 bytes back. It seems like it ends in 0x40,0xff each time, or at least the last 2 tests did.
I've been powering it with +12v on the asd line, and removing the power as soon as I see a slight dimming/flash on the RX led on my serial converter. If I leave the asd connected or disconnected completely, I get nothing in return from the serial tests.
Is there a low speed test that I can use to confirm it's working properly in low speed?
I'm pretty sure what I have is an 88 or 89 T2 SMEC, so it's low speed is 976 and high is 62500, correct?
Man, you kids are making me feel OLD! I started with an IBM 1620 in college, punchcards, FORTRAN and took up a room.
old is right - i started with assembler, punch cards, and my big success story for my freshman year (1978) was a calendar printed out with xx's and oo's for the numbers on 11x 14 inch computer paper.
Ok, I won't even mention that I wasn't alive in 1978. I do wish that I was a little better with ASM though, since no one has yet built a (successful) processor that will interpret a higher level language on the fly.
I've got to build an app that'll let me hand-test the ecu on the bench a little better. The fact that I got it to respond is a good step though.
If it's a T2 SMEC, then you shouldn't need to send the 0xF2. That command is only used on the DRBII computers (89 2.45 T1 and later, including the V6 SMEC), and only to confirm hi-speed mode. I think they added this so that you can actually log what's at memory address 0x12. I think 0xF2 on the T2 computer will just give you whatever value is stored at 0xF2...
Test 0x10 or 0x11 should send out the error codes even if the engine is off (maybe only if the engine is off). So, they should work. You can compare them to the codes you get on the CEL to see if it's working.
Those are the correct baud rates for a T2 SMEC.
What's the last 3 digits of the computer P/N? Should also be on the chip if you can read it under the potting.
I was actually messing with the 0x10 test a little earlier, and it seems like it's sending stuff back at the low baud rate, but it could just be the same (seemingly) random junk I was getting before.
Does the CEL pin get pulled to ground to turn the light on or is it provided power? I've been testing with a led and trying to use it as if that pin is getting power, but the LED is very dim. The DVOM I have seems to show that it's +5v when the CEL is on. Or, maybe now that I've got the ASD trick down, it will light the LED a little better on flash.
It looks like the last 3 digits are 246, the whole number (I belive) is 6233246. I haven't cracked it open ever, so the potting is still there.
If I gave you a release binary, would you be able to check it against a known working SMEC and send me the portmon output? Doesn't matter if it's T2 or the newer ones. It may retrievie the autoID right, but it probably won't work properly other than trying to connect and get the id.
I'm pretty sure the CEL is grounded to power the light. I forgot to mention that mine is inverted on the output - IE, it's on, then turns off when flashing codes. Not sure how it gets inverted in the vehicle; maybe there's a 12V driver for it in the dash?. Mine is pretty dim, too. But it's a 12V LED and I think the output is only 5V.
The only P/N I have ending in 246 is 4639246. It's a 91 2.5 T1 (SBEC). That's the first time I've seen a 3-digit ID code repeated. I wonder if the # on the box is a reman #? If so, it might be different from the cal ID.
I can try to read the ID with my bench rig. I may need some guidance setting up Logworks without a WB, though. I looked earlier but couldn't find that .dll you mentioned.
I'm using a 12v led too and I'm sure that's the reason it's so dim but mine's so dim that I can't even see it. I thought it was always powered because the CEL is normally on solid when the engine isn't running. I'll have to try and get a 5v led or regular lightbulb to see if I can get it flash.
It's definitely not a SBEC, I haven't ever scrapped a car that new. I'll crack the case and check it. Hopefully I won't have to cut the potting.
You won't even need to start logworks to test the autoid. Basically, the program has to connect to the ECU before logworks is started, so everything needs to get done before bringing up logworks. Only thing you'll need is to have logworks installed so the program will find the needed library.
You can run the autoid just by starting the program, setting the com port, and clicking autoid. I'm more interested in the portmon, so if you want to log it to a file and just attach it here, I'd appreciate it.
I can included both the mtsstim.dll and the program in the zip file attached here. You need to put the mts.dll in the zip in the logworks install dir (save the old one first). After that, logworks won't ask you what com port the wideband is on, but it will have a bunch of channels sending faked data.
UPDATE: I included the static linked binary in the zip attached here. Hopefully it's only the MFC lib that's missing.
Last edited by risen; 05-05-2009 at 10:44 PM.
You can usually see the # thru the potting - especially on a SMEC because the back of the power board makes a nice smooth surface in the logic board potting.
OK, I'll give it a shot tonight.You won't even need to start logworks to test the autoid. Basically, the program has to connect to the ECU before logworks is started, so everything needs to get done before bringing up logworks. Only thing you'll need is to have logworks installed so the program will find the needed library.
You can run the autoid just by starting the program, setting the com port, and clicking autoid. I'm more interested in the portmon, so if you want to log it to a file and just attach it here, I'd appreciate it.
I can included both the mtsstim.dll and the program in the zip file attached here. You need to put the mts.dll in the zip in the logworks install dir (save the old one first). After that, logworks won't ask you what com port the wideband is on, but it will have a bunch of channels sending faked data.
Ok, so, now not only do I not have a test rig working with serial comms, I have the mystery smec to deal with, lol. See the pics, the chip definitely says 246.
Well, if you put 24v on pin 11, you should be able to pull the cal off with D-cal. If it's a 16k file, it should be a T2. 32k and it's a T1.
I don't think I have any power sources >18v kicking around. I'll have to check. Would 3 9v's ganged together be too much voltage and can I just tie the - side to ground of the 12v circuit?
-Keith
Last edited by risen; 05-05-2009 at 01:49 PM. Reason: ideas
I know other guys have said they bootstrapped it by putting a 9V battery in-line with 12V and putting that to the bootstrap pin.
I don't know if 27V will hurt anything or not. The bootstrap zener is rated at something like 21.8V and I hit it with 24V with no apparent ill effects.
Ahh, that's a good idea with the 12V. Maybe I'll tie that, a 9v and a D cell and see if 22.5 V is coming out the other end. The 9v I have is a bit old and I'd hate to just fall shy of the 21 needed.
Ok, so I tried to bootstrap the SMEC, no go. I noticed 2 things.
1: the +5v sensor rail is still coming up with the 22v on the bootstrap. Is that normal? or should I get nothing on the +5v sensor if it's bootstrapping?
2: the version of Dcal I have is using 1200 baud and 9600 baud to write the bootloader to the ecm. Is that correct? Shouldn't it be the 976? or is it different because it's in bootstrap?
It's different in bootstrap. The default is 1200, D-Cal's boot loader changes it to 9600 for the fastest possible download (from a standard PC serial port anyway).
On the bootstrap, you have to put the 24V on pin 11 before you power the rest of the system. If it doesn't see that pin high on reset, it boots normally. So, pin 11 first, then power the FJ2 and 8V pins.
Posting Permissions
Reply With Quote