Folks,

This was a thought I had.

Seems lately I have run into a snag with 'switching' units. Primarily, when larger 29C chips are hooked up as surrogates for the 27C256 with address bank selection, all heck breaks loose. Works fine with some ECMs/Chips, but not with others. Intermittent crap like that gets under my skin big-time. There is a failure to communicate somewhere, and I am thinking it might be attributable to the circuit capacitance and associated rise/fall timing.

A similar issue (I think) is seen when one tries to add an extension for their EPROM location. You end up with either crosstalk or capacitance soaking. Don't know what happens, but the net result is that the ECM and EPROM quit communicating 'properly'.

One thing that MIGHT help is to set up closely-coupled line drivers / buffers. Could put a pair of 74HC541s at the ECM to drive the address lines and one out at the EPROM location to push the data back to the ECM. Am I thinking right? It would be good to know whether the address lines or the data lines are the ones giving grief, then you could just go one way or another. I guess we could try it both ways and see.

If this works, it could allow several things. For one, you could mount your EPROM most anywhere. For another, any touchy chip compatibility issues can be put behind us.

I'm no electrical/electronics engineer, so would appreciate any guidance in this matter. Clearly, this can lead to all kinds of projects, emulators and cheap reflashers among them.

Many thanks,
-Craig

 

Yep, you can use buffers if the issue is a high capacitance loading problem. There are a bunch of styles out there, but I haven't actually been keeping up with them. I'm thinking thats the issue, because the data through-put is pretty slow(120ns or similar), so you're ecm drivers simply can't drive that long a line. One other thing that is possible is that more grounding/shielding is necessary. I've seen ribbon cable that has a foil shield, and the latest PC intercomponent cables for harddrives, etc, use a double wire ribbon to help with data throughput, and to provide shielding. If you're having problems with adapter boards, it's possible you need a harder pull-up for your upper address lines, like a 2.2K or something similar, or maybe even some of the other adress/data lines. Do you know offhand how many devices inside the ecm share the bus? Typically, if you have a bus that is shared with alot of devices, you will have a bus buffer right out of the microprocessor, but maybe it's not enough. Its hard to say without actually monitoring the problem on a scope to see if its a timing issue, or a level issue.

 

I don't think it's the grounding issue, I know some people have tried foil shielding and what-not without success. Maybe to avoid crosstalk, ATA-66-type cable could be used?

I'm gonna try the harder pull resistors, but I think it's more than that since even with all 'higher' address lines pulled low, the problem persists when trying to use the larger chips as surrogates. And the fact that it works with some ECMs (165) but not others (730/LT1) also leads me toward an ECM driver bank issue.

I don't know how the Bus is routed in the ECM, I would have to guess the I/O is managed/buffered solely at the PROM end of things and is then cached/buffered elsewhere into the system. Don't know. Guess a schematic view would be helpful.

Hmm, maybe I can try some Serial-Parallel shift registers? The transition times I guess would add up pretty quick to be unacceptable. It'd be a nice cable reduction maneuver though.

 

Yeah, parallel to serial would get ugly fast. You're best bet is to use the surface mount type data buffer/drivers, ones that have like 8 or 16 in a package, but they are tough to solder if you're not a pro. Thats the cable I was talking about(brain fade), the ATA-66 cable, since it has either redundant signals, or grounds in between each line. That would be the most effective, other than buffers. I'd need to get a good look at an ecm schematic, or a few, to get a feel for the bus fan-out, but I'm lazy, hahhah(plus this wicked workload doesn't help). I'll keep my eyes out for anything interesting that comes along, in the meantime, I'll try and mess around with some stuff as time allows. I do know this, some of the emulators we have running in our labs will not work with ribbon cables unless there are multiple ground paths on the board, so maybe thats the key. I tried to cheat the connectors one time, tying all of the grounds to one connector pin, and nothing would work until we put on alot of ground pins. Maybe you can give that a try and see what happens, before jumping into buffers and drivers, at least on running long ribbon assemblies. From the sound of it though, GM probably didn't leave too much headroom in the buffer output so maybe you are on the hairy edge of actually working. HTH.

 

16 would be real sweet. Most I could find was octal. On the ECM end it's kinda cramped. On the remote end, all the real estate in the world. Need the 16 at the ECM for the address lines, assuming their exertion is limiting. Probably need to put the data buffer at the remote.

I guess it could be set up to utilize a 'standard' ATA-66. As I recall, they're kinda squirrely on the layout, with grounds (at the pins) alternating here & there. The actual wires alternate grounds. Kinda like 'twisted pairs' to prevent the crosstalk. I'm 'guessing' that these speeds might not induce the crosstalk, particularly with adequate drivers. Hmmm...

Might need to breadboard some 541's this weekend...

 

here is a 16 bit wide device, but it's ssop48, which means its a small surface mount package.
It's a 5V tolerant device, which means you'd have to power it from a regulated +3.3v, and use pull-ups on the ecm side to get 5 volt output swings, but it works with a heavy load, and is very small. The width of the package is only about the diameter of a penny. Try these, cypress semiconductor also makes them, at least they used to. Even two octal soic devices would be pretty small, if you put one one the top and bottom of the interface board. The only problem with the 74lvc parts is that they are hard to prototype, becuase the pins are so dense.

datasheet

 

Good thinking Craig. If anyone read my article about how the switching works, you'll see at the bottom my little disclaimer about switching on the fly. The buffer is a great idea! I have a friend who likes to build electronic gismos, too bad he's wasting his talent on a self-maintained kitty litter box/catscan lookin' machine ... anyway, he suggested the same thing, but then with the inverter I was looking at using, plus the buffer chip(s) ... can get a little much BUT ... how's this ... just an idea:

If the circuit you are building is starting to look like the hood of the delorian in Back to the Future part III ... then you "could" try a very short ribbon cable and relocate the PROM, memcal and circuit just outside of the ECM box. That way you could still close the lid on the ECM to protect the rest of the circuit from ... bugs or whatever and maintain everything just outside of the box. Maybe have an "auxiliary" box and some how have it so it can be mounted via the same dash screws or something so it just doesn't bang around. Will probably have to special order the ribbon cable and inserts as it's 66 pin ... you would need at least a 28 pin for the PROM and 30 pin for the memcal piece ... eh ... yeah ...

 

Craig,
You might check the output drive strength of the FLASH devices you are using to see if they meet the min. requiremnets of the microprocessor.
Also, the signal layout could be an issue......coupling and things like that. I think the only sure-fire approach to solving the problem would be to view the address/data on a logic analyzer and or 0'scope to capture the cause of the problem.

The other problem is using a switch itself. Typically, they are never hooked to an electrical circuit directly. They are usually buffered and debounced.

Cheers,
J

 

Crap, didn't work! Yet...

- Used a short ZIF extension.
- Included a 74HCT541 octal buffer on the data lines between the ECM & EPROM.
- Address lines were connected normally.
- A 'bypass' chip/socket was made up to circumvent the 74HCT541.

- Tested on a 165 using 27C128. Worked fine with 'bypass' chip/socket installed.
- Swapped in 74HCT541, and instant SES on keyon, no EPROMo worko.

- Tried 29C256. Worked fine without extension. 'Baubly' in extension with bypass chip.
- No-go with buffer installed.

WTF?!? Are the data lines incapable of driving the buffer?!? Just barely able to drive into the ECM? Gotta keep at it I suppose.

Suggestions welcomed...

 

Craig,
It could be the delay of the HC device is too long. That is what it sounds like to me.

J

 

I forgot to mention one thing. I tried the image swither a long time ago. I had all sorts of problems. Eventually I gave up and built a lot of logic to get around it. It turned into an on the fly tuner. I had the switcher working "most of the time" but that was with a ton of logic. More than would fit on a board inside the ECM.

The thing that makes me wonder is why you can't get it to work inside of the ECM. What is the speed of the FLASH devices you are using?

J

 

The Flash is 90ns, whereas the EPROM is 150ns. I've used 250ns chips no problem before.

The buffer circuit is listed as introducing around 5-15ns additional propagation delay. I would have assumed that this would be well within the tolerance.

The buffer I'm using is a HCT 'TTL' device. Maybe that could be a problem? Didn't think so.

Weird...

 

The FLASH speed and HCT part should be fine for you application. Kind of a simple thought here, but do you have the output enable connected correctly and the direction of the data towards the ECM. That is the only things I can see that could possibly make it not work. Those two problems would can an SES light.

J

 

Yep,

I tied the OE line of the EPROM to the OE1 & OE2 lines of the 541 (it requires both to be low). Then in a blind attempt tied the 541 OE1/OE2 lines to ground. Same result.

As far as direction, yeah, tied the An lines to the EPROM and the Yn lines to the ECM cable...

Weird...

 

Craig,
Wicked funny.....I just realized something now that you have explicitly told me how you have it connected. Your problem lies in your connection on the OEx lines.
Here is what you did: you connected the OE lines essentially to ground. Now the ECM is always seeing the output of the HCT driver on the data bus even when it wants to see something else.
You need disconnect whatever you have connected to the HCT OEx lines and connect the chip select line to the OEx lines of the HCT. I can just about gurantee you that this will eliminate your SES light.
Remember where you heard it....give it a try.

Cheers,
J

 

You guys are talking alot of "geek talk" but there are MANY people that would be interested in a remote EPROM. I for starters. This sounds great someone with good knowledge is serious about making it work.

I can't be of much help but here is the internals of the '730 ECM.
http://www.cruzers.com/~ludis/1227749schematic.html


For other ECM's go to the beginning here. http://www.cruzers.com/~ludis/p4xref.html

Here's this guys list of good stuff for ECM's. http://www.cruzers.com/~ludis/

 

Yeah, quite a bit of geek talk in this thread. I have to give Craig credit though for not giving up. Almost has me thinking that I should market my on the fly tuner. HHhhmmm, maybe by the end of the year.
Ludis has done a remarkable amount of work on the GM ECMs. One word of caution though on the 730 schematics there. A few of the signal names/connections appear to incorrect.

J

 

Well, iron's hot... Lemme give it a try. I did have the OE of the HCT tied to the OE of the EPROM. Let me try tying them to the CE of the EPROM/ECM...
(...10 minutes passes...)

Well, I tried driving the HCT's OE off the EPROM/ECM's OE and CE lines, neither worked. Still full SES. Eprom still works fine with 'HCT Bypass' lines installed.

Grrr...

 

I am at a loss here. I had just about the same setup working last year when I was trying to write a FLASH device using the ECM.
I had the ECM chip select line drive the OE line of the buffer. The Ax lines connected to the FLASH and the Yn lines connected to the ECM data lines. My setup would read just fine, but I ran out of time on the programming/writing side.
The only thing I can think of is probing the the OEx lines of the HCT part to see if they are toggling. Using a voltmeter on the DC scale would yeild about 2.5 volts if it is toggling. 0 or 5 if it isn't.
Sorry, I thought that would work for sure. How long is the cable you are using?

J

 

You guys are talking alot of "geek talk" [/QUOTE]

I suppose so...

J, if you want to get /w/ me offline maybe we can talk...