Ostrich+Latch board+ sbec. Diagnostics with Moates CALLING ROB

[shackwrrr]

I know I made a thread before but this time I have emailed moates and Ive gotten a response that I need help with replying.

This is what I asked:

Hi, I wanted help with figuring out some issues with using the ostrich
on the dodge SBEC computer. The problems me and others are having with
the ostrich is that it only works when it is hooked to usb power, when
you unhook the power the ostrich partially forgets the .bin and the
engine will run extremely rich. We have been able to temporarily fix
this issue by keeping the ostrich plugged into a USB cigarette ligher
adaper and it works fine. The ostrich has been used successfully on
other mopar ecu's like the logic module and the SMEC. The primary
difference between those two and the SBEC is that the SBEC uses a
87C257 chip with a memory latch. The sbec is converted to use the more
typical 28 pin chips like the sst chips and 27c256 chips, it works
great with these. The only problem arises with the Ostrich. We think
that this problem may be related to our other problem, the Ostrich
puts out just enough battery power to power up the MCU inside and its
requesting data, this leads to the ECU whine as if its on and
sometimes has killed batteries. Is there any information that you can
provide that can help us figure this out like what each pin does at
rest or powered by usb?

This is what the response was.

Sorry it's taken so long to get back to you. We've seen issues with stray voltage on Ostrich pins in 32pin emulation mode cause issues like what you're seeing, but that doesn't appear to be the case here as you're using things in 28 pin mode. The immediate solution that I would suggest would be to modify your 87C157->27C256 conversion board to include a Schottky diode on the power supply to the "chip" in order to prevent the Ostrich feeding back. The Ostrich has one of these internally so I'm not convinced this is the issue, however.

Also, how much of the address space (i.e. how big is the chip?) do you use? If the answer is 256k, what do you do with the highest address line used for 512k chips? (look at the SST 27SF512 datasheet if you don't follow and compare it to a 27C256. Top left pin) There is a possibility that the Ostrich is powering up the ECU through an unused address line that is getting pulled high. Another thing to try would be cutting the top-left pin off the emulation cable.

Do a little more digging and get back to us so we can help you get this resolved.

Thanks,
-Dave Blundell

Rob, if you can help with this that would be great. It would be amazing if we can get this figured out.

[ShelGame]

Well, the original latch boards left A15 floating. Which I ofund out is a mistake - the SST27SF512 doesn't like that line floating. It will return unpredictable data that way. So, on the latest revision I pull that line high to force the 27SF512 to return the top half of the memory contents.

If you run the Ostrich in 256k mode, this really shouldn't have been a problem. With the original latch (before July of this year), that wouldn't have been a problem anyway as A15 was not tied to anything.

One thing I also added to the latest revision was to pull the CE line high when the SBEC is in standby mode. This has the effect of forcing the memory chip into standby mode also. In addition, with the CE line pulled high, the address/data bus is put into high-impedance mode. Which would eliminate any chance of a power or ground circuit that way. What I do not know for sure is, if the Ostrich works the same way as a 27C256 with respect to standby mode. The new latch board didn't work any differently with the Ostrich when we tried it at SDAC. Though, it does now work correctly with the 27SF512 chips.

Maybe a little background is in order here - the SMEC and SBEC do not actually 'power down' when the key is turned off. They go into standby mode. The lower 16(? I forget exacly how many) bytes of RAM are battery backed (these are used for the adaptive memory). Which means that the processor and logic circuits remain powered up. My original thinking was that this was causing the memory to stay powered up. With the normal memory, that's not really a problem as it is only accessed by the MCU. But, when you have a battery-back memory module like the Ostrich, there's a chance that the module can supply power to the logic circuits, draining the battery. Hence my reason for trying to force it into standby mode.

In short, I also suspect this is a some sort of weird power circuit deal. But, I don't know what else it could be. For what it's worth, the guy I sold a latch board to for his BMW/Bosch ECU (which also uses the 87C257 in stock form) has the exact same issue with the Ostrich. If it's really a power-circuit type thing, I would expect to see the same issue with the SMEC. I thought that I heard it's a problem for the SMEC, too?

[ShelGame]

I just confirmed that the latch chip itself has it's outputs put into high-Z mode when the CE is pulled high during standby mode. So, there shouldn't be any kind of power loop thru the latch board at all when the SBEC is powered down. Everything is isolated.

[shackwrrr]

So basically the whole battery drain thing should be resolved? I am mostly worried about the ostrich needing 5 volts at startup to work, were you talking about this? I haven't had a problem with any battery drain.

[ShelGame]

We didn't check for the battery drain issue. That might have been a T-SBEC issue actually. There was a problem in the code that caused the AIS motor to stay on even after the key was turned off. That has been fixed.

We only checked for the startup issue on the Ostrich with no power applied. The pull-up to force standby mode did not fix that.

[turbovanman²]

Subscribed.

AFAIK, SMEC's have never had this issue.

[zin]

This is very interesting... I was under the false impression that the battery drain issue was due to the BlueTooth adapter that Quantum was using to wirelessly program his Ostrich, I didn't realize the problem was internal to the Ostrich...

Mike

[shackwrrr]

This is very interesting... I was under the false impression that the battery drain issue was due to the BlueTooth adapter that Quantum was using to wirelessly program his Ostrich, I didn't realize the problem was internal to the Ostrich...

Mike

I guess it was just a code problem. What we are really trying to figure out is why we need to keep the ostrich plugged into usb

[ShelGame]

Well, the pull-up does put the latch chip into standby, so the Ostrich can't find a gound loop thru that. But, the high order address lines may still supply power/ground to the Ostrich if it does not go into standby the same way a standard memory chip does. This is what I suspect must be happeneing. I don't think there's any easy way to fix that on the latch board side.