Turbo Dodge Forums banner

Odometer Chip ID Requested

24K views 124 replies 27 participants last post by  Turbinator 
#1 ·
Does anybody know which EEPROM chips were used in the late '80s to early '90s digital clusters?

These are the markings on what I am trying to ID:

GI (manufacturer)
2208
8425
14-Pin

Harris nSemi
4374040 (Chry P/N)
H 9201
14-PIN

Thank you
 
#2 ·
Those numbers don't come across me as EPROM part numbers, but I plugged them in at work here and checked my catalogs and I can't find a match for any kind of IC.

It is possible, unlikely, but possible that the IC's were one time - spiecal made for the clusters only. Which would be bad because you would never find a new example.

I would like to know if anybody turns something up, because I have been buying EPROM's, IC's and microswitches for TD's like crazy recently (dirt cheap through work) to have a supply, everything is being factory discontinued:bang head
 
#3 ·
May I ask why you are looking for replacement ICs? I'm glad to learn that we have a few EE/CE people on here!
 
#4 ·
I am aware that the numbers that I listed are not standard part numbers. They are the propreitary Chtysler part numbers.

I am looking for id's on these chips because I would like to know the format that Chrysler stores the odometer inforation in, for these years. (Essentally for my own EE edification). In the spring, I will be doing a bit of work on my '93 Spirit. One item on the list is to install one of my digital clusters. I would rather pull the EEPROM, reflash it, than hook a pulse generator up to the speedometer input to roll it forward.

(For those who have seen some of my other posts, the SBEC-II schematic project is ongoing: One PCB layer left to delainate and digitize, then the fun really begins.)
 
#5 ·
For those who are interested:

There are two power leads that got to the digital clusters. One is constant power, the other is switched (ignition) power. On the non CCD clusters, the speedometer signal is accumulated by the MPU on the cluster logic board, as opposed to the cluster's display board. When the switched power is lost, an erase/write routine is initiated and the speedometer pulse sum is written to the EEPROM. On power-up, this data is loaded into one of the cluster's MPU registers and the speedometer pulses are accumulated and summed to it. The cluster's MPU has two divide constants: one for the metric (kilometer) display, the other for the English (mile) display. By toggling between the two constants (M/KM button), the cluster's MPU knows which to divide the accumulated speedometer pulses by, before sending the data to the display driver circuitry.

By powering a digital cluster on the bench, one can pulse the speedometer input and advance the mileage, as well as drive the speedometer display. If the constant power is removed, before the switched power, the mileage increase will not be stored, and the previous mileage will be displayed upon the next power-up.
 
#6 ·
I haven't seen any of your other posts yet. Are you attempting to reverse engineer the SBEC-II in order to build one from scratch with some critical improvements? Do you have a link?
 
#7 ·
ZoskalonMPI --> I am reverse engineering the SBEC-II to get a better understanding of how it functions, as well as to dispell the "black-box" mentality that is pervasive in the auto-mod world. Mainly, I am looking to see the hardware interactions of the SBEC-II's calibration (program) code. I am going to be doing a TBI to MPFI conversion on my 2.5, 1993 Spirit. I would like to figure out how to add the coilpack code into the calibration file and eliminate the spark jump in the distributor. The wiring aspect is not an issue: I have already added power locks, power windows, Bendix-6 ABS (with 4-wheel disk conversion), the premium overhead cluster, traveller, power seats, auto climate control, and a few other amenities. The electronic cluster, EVIC (Electronic Vehicle Information Center) and 22-function EVA (Electronic Voice Alert), as well as new paint, will be comming this spring.
 
#8 ·
Where is all this work shown??? I would love to see everything you've done to this car! I don't recall ever seeing EVIC on a Spirit before, only the 2 button travelers. What do you mean by "premium overhead cluster", is it just the temp/compass console? What year ATC did you use? Info and pics PLEASE! Lol.
 
#9 ·
Mangelhaft, stupid question, but the information you gave from the first post is of the IC's themself? I just wanted to make sure. If that is all the information you have to go by it may be very hard to find a datasheet on one of those without harrassing Chrysler every hour day after day.. or back probe the IC's in the cluster with the dash torn apart while somebody drives:First TD:

If you do come across a datasheet or even functional schematic of the whole digital dash post it up, it might help to revive the dying breed.

I have yet to dig into my two digital clusters for my daytona, they work but have some funny speedo bugs under vibration I have to work out.
 
#10 ·
The numbers that I listed in my previous post are the numbers that are stamped on the chip. Chrysler, as well as other manufacturers, had their ICs custom marked. An example is the chip marked SC80575VFN 4632459 which is a Motorola 68HC11A1 used in the SBEC-II. SC80575VFN is the motorola reference part number for the chip with the custom Chrysler ROM mask and 4632459 is the Chrysler part number. Another example is the Interstil SD68HC68S1 which has the Chrysler part number 4374040. It is used to decode the CCD databus for the chrysler traveler modules. This is usually for preprogramed MPUs, but also applies to other chips that were replaceable, or serviced by Chrysler and/or its authorized service providers. Chrysler has part numbers for the odometer EEPROMs because they could be replaced or reflashed when a cluster was replaced. This was before the time when the odometer info was stored in the BCM or ECU.
ZoskalonMPI --> As for pictures, I have not taken any, yet. I am still in the process of reupstering the interrior and prepping for paint this spring. The AA bodies never came with an EVA, EVIC, nor auto climate control. The overhead cluster is the one with the compass and temperature. There are provisions on the board for two more buttons and some unoccupied pads for additional electronics. I have yet to figure this out. The overhead clusters with the tripodometer pulled their data off of the ccd bus, and was supplied by the BCM. I added the two button traveler, but would like to add the twelve button traveler, once I figure-out the injector pulse feed, and finish the dashboard transplant. As for the climate control, I believe that it was from an '89 New Yorker. I replaced the sixteen-year-old heater core (Christmas eve 2009) and figured that since the dash was out, I might as well add this.

Why all this work? I bought my 1993 Spirit, in 1999, when I was stationed in Texas. It's body is solid and in great shape. It has only seen a few Michigan winters. I am getting c. 32 MPG, average. It is very reliable. And last, but not least: I am an engineer, so why not?

For anybody that is looking at doing some of these "upgrades", do not be intimidated by the wiring. Check with your local library for the Mitchell's Manuals. Their wiring diagrams are superior to AllData. Remember to get the connectors. Solder and heat shrink the splices: DO NOT USE CRIMP CONNECTORS! Take your time. Be patient. Ask questions. Have fun.

(Now is it worth adding the cell phone visor and associated electronics" just because...)
 
#11 ·
I for got to add that I am sure that there is a standard EPROM that is compatable with the Chry P/Ns. If all else fails, I can trace the EEPROM datalines and construct the pin out, and use trial-and-error to acheive a coherent ROM dump.
 
#12 ·
I have a 1985 Laser XE cluster on my benchtop right now with the ODO chip signals on the logic analyzer. You have to be careful as there are two negative power supplies to the chip. There is a -5 which probably would not kill my test equipment, but the apparent programming voltage(always present) is -30V!

I started by probing each pin with a volt meter to try and determine the power supplies. There were several pins that are always low, so I'm not sure which of those are the actual ground power pin. One pin seemed to be steady +5 V, so I'm assuming that's the main Vdd. The negative programming voltage is curious, most EEPROMs I've seen use +27V or so for programming. -5 V is not unusual for older chips. Perhaps this is an NMOS device and not full CMOS?

I could only identify five signals that actually toggled during the apparent read cycles(On power up) or write cycles (On 12V ign powerdown with 12V batt still powered). This suggests that the device is in some manner serial instead of parallel which will make decoding a bear.

With the apparent writes, the signaling made some sense with one of the signals appearing to be a clock or strobe of some sort. The period was 80uS which looks right, but I haven't figured out which signal(s) are data, chip select, rd/wr yet. Also, there seem to be a very large number of repeated bursts for the shutdown sequence compared to the startup read sequence which looks like one single burst after some sort of setup sequence.

Reads look totally different, where the writes look slow and synchronous, the reads look completely asynchronous, and the signal timing looks impossible. There are several short (10-20ns) pulses and delays that can't possibly be actual chip timings as there is no way 1984 automotive technology was running at 50-100MHz. What looks like synchronous 10-20ns setup/hold timings must be the actual propagation delays of these old devices. I clearly have more work to do here...
 
#13 ·
I've solved part of the Odometer Chip Mystery! This part is a renumbered GI ER-1451 700-bit serial EAROM(Electrically Alterable ROM)! I just picked up a handful of new blanks on eBay. With the pinout and datasheet for the part handy, I could easily setup my logic analyzer to take ROM dumps. On power up, the dash will dump the contents of the ROM which contains the regular ODO and the trip ODO values. On ignition powerdown, it erases and writes the new value. Of course, that means at around 10K ignition cycles, the chip is going to go bad and give you the ------ of death. Anyhoo, I still need to write a perl script to turn the logic analyzer listings and turn them into a readable ROM dump (Basically de-serializing with software). Then I can correlate the mileage on the ODO with the contents of the ROM to figure out how to burn a ROM with any arbitrary mileage in the ROM. I'm not doing this so that people can roll back their ODO's, it's so people can swap a cluster or fix a broken ODO, or if they restore their car and want it to say 0 miles. You can always check the box on the title that says "not actual mileage" and no one is going to believe that a falling apart rust bucket actually has 400 miles on it :p At this point in the life of these 80's and early 90s cars, the number on the clock means very little compared to the obvious condition of the car as determined by inspection...
 
#14 ·
Here is a link to a website that has some source code for our ECU's. Be a good starting point. At least with the code you can figure out your input/output, and which one's are analog.

I don't know of a good decompiler for the CPU. Depending on the CPU you can use ASMFLOW to flow chart it.

Later Dennis
 
#18 ·
I'm getting close, but It looks like I'm going to have to build a burner for the ER-1400 chip as it uses some strange power supply (-30V). Its a pretty simple burner with a schematic and software online, but it may take me a few months to get the time to construct it. I ordered some blank chips on eBay and I plan to offer ODO chip replacement for a nominal fee to cover the parts cost and recoup the cost of building the programmer as a service to us Digi-Dash enthusiasts. Most likely your chip is dead as after 10,000 ignition cycles or so the chips cannot be programmed anymore as they electrically "wear out"...
 
#16 ·
Great information. Here is my website and what I have done with the traveler: Mangelhaft's Chrysler Info I believe that the traveler uses the Motorolla 6805 MPU. I do not have the hardware to do a dump, though.

I am almost done with the SBEC-II. I need to clean-up the schematics. After that, I will start on the digital gauge clusters.
 
#19 ·
I currently have the ------- display of death on my 85 laser XT. It failed in 1999. I have probably driven the car 50,000+ miles since then. If I replace this chip you are talking about, should I assume the odometer will work again? Do you know where I can find a repacement chip? Also, where is the chip located? I assume the car's computer no longer has any idea how many miles it should read, nor do I. Any help you could send would be great. I posted some pictures of the car if you would like to take a look. Thanks.
 
#23 ·
OK OK, just hold tight. The chip have to be programmed and I still need to figure out the data format as well as construct the programmer as it is different than the existing generic EPROM programmers out there. I may not have the proper time to work on this seriously until winter, but stay tuned to this thread as I'll post info as soon as I have it...
 
#26 ·
Mangelhaft any update on how the project is coming?

Dennis
 
#28 · (Edited)
Posted this on another thread - but it also belongs here...

Hello everybody - I actually just found the time to resurrect my investigation. I had an old power up logic analyzer trace on the control and data lines on the ER1451 odometer ROM and just wrote a perl script to convert the serial trace into ROM access commands. The trace is incomplete, but it was good enough to start developing the script. Once I have a complete conversion script I can easily pass many analyzer trace dumps to it and try to decode what's going on. However, my first pass looks pretty daunting. These chips hold 700 bits of data organized into 50 14-bit words. I was assuming that there would be a lot of unused space in the ROM as even counting at the 'tic' level (Pulses from the speed sensor), you probably don't need that many bits to hold a number up to 200K miles or so(I've believe that I read that these "roll over" somewhere in the 200K range, possibly equating to whatever 100,000 Kilometers is in miles. There seems to be a LOT of data in use, though. More than it would appear to just hold the main ODO and if stored in there also, the trip odo. There may be some funky encoding scheme going on, or maybe multiple copies in a rotating buffer with pointers and the like to attempt recovery of a corrupt reading? It looks alot more complicated than I was originally hoping.

My plan of attack is to use my bench 12V supply with my spare cluster, which I have already sucessfully been able to feed a square wave to to simulate speed sensor pulses and rack up miles on the ODO (As well as exceed the speed limit!) I'll do several rounds of Racking up miles and saving traces that are both read and written to the ROM, including iterations where I only feed a single speed 'tick' to the cluster to see which bit(s) change from one round to the next along with the recorded ODO reading for that trace. Hopefully, with enough data collected, I'll be able to reverse engineer how the miles are stored.

My take on the * (Asterisk) that appears on some clusters is that the symbol is the electronic equivalent of "Not actual miles". I've heard that when you "roll over" the cluster, it starts at zero only with the asterisk. And when you get a new chip from the dealer it also starts at zero and has the asterisk. I also think I've heard evidence that a cluster that has been corrupted, but not to the point of the "------" of death, will also show the asterisk. I'll see what I can find out about that as well. Once I have a theory on the encoding; I can program test ROMs and see what the cluster reading looks like for different programming. I too have a schematic for a ER14xx programmer from a Russian website. I'm going to modify the design a little as it uses a coil type step up transformer to make the -37V programming voltage required. (For you EEs out there - It takes a 12V DC, feeds it to a 555 as an oscillator to make it 12V AC, then off to a transformer to step it up to 3X or 36V, then MINIMAL filtering with a Diode and Cap. Looks pretty sketchy from a noise perspective and bulky with the transformer. I plan to find a suitable switching boost regulator to make a cleaner programming voltage)

I have a handful of ROM chips, but they are ER1400, which are 100x14 instead of 50x14. I believe that they will work fine, though and just have the upper 50 words unused as the access is random anyway and not sequential. ER1451's are impossible to find and even the ER1400's I have come across are getting expensive($25-$30 per chip) as there apparently is some demand for these in the vintage arcade game market. So, another project I plan to try is to make a small FPGA controlled emulator that will make a modern serial flash chip behave like the ER1400. Not really expecting to save cost here though, but it will make a bountiful supply chain available again, and with the plus if not needed the -36V supply at all! Also, I could make a programming "Back Door" that will make it easier to flash the mileage since most potential customers will need a custom mileage from their existing vehicle programmed in.

There will be waivers on use of course, but with the age of these cars, no one is going to really profit from false odometer readings. If the car has 200K on it, it's going to show - EVERYWHERE. And if a car looks like crap, but claims to have 40K on it, I'm paying on the actual condition anyway. Believe me, I've seen quite a few supposed low miles cars that looked like crap so there's no way I would have paid a premium on them anyway. Condition is everything when cars get to be this age. Still, there will be some waiver of liability on my part if someone provides false mileage for their chip. I'd really just be selling them a ROM with some arbitrary data requested by the customer in it and no guarantee of the usefulness or even the end use of the data provided.

On a side note, I'm also planning a re-engineering of the 84-87 Logic Module controllers. I believe that with modern technology applied to these old cars, not only can you provide better performance, but also smoother engine running. I believe the reason some of these older ECU based cars aren't as stable as their modern counterparts is the fact that the older, slower CPUs can't adjust to changing conditions as fast as newer, faster ECUs can. I'm probably going to stick with 8-bit for now, though as I'll have to port the existing source code and then tighten the loop timing and scale everything appropriately. I should be able to provide a 10x tighter control loop which should greatly improve engine response and still fit a few extra goodies like logging in. Since I'm in SMOG controlled California, the ECU will need to behave like a factory unit when hooked up to the tester's equipment, so that will be a challenge. Maybe I'll have a "SMOG Mode" switch. However, I expect the replacement computer to allow for lower emissions than stock, so I may even go after CARB certification. I'm sticking with the older LM units for now because (1. They're located in the passenger cabin and won't need to be underhood resiliant. 2. They are basically just the Brain, with the Brawn in the power module under the hood. And 3. All of my Turbo Dodges are LM equipped). Other people are working on SMEC and SBEC designs anyway, so I won't be duplicating other's efforts. I'm actually hoping to have the time to create a complete suite if interacting components to replace the electronics on my '84 Laser Digital Dash/31 Function Monitor/12-button Nav equipped car, with a single computer doing all of the work including the ECU and the Dash, Monitor, and Nav just being display units accessed by the main computer. The replacement equipment will be a combination of LED and LCD to replace the Vacuum Flourescent original displays. We'll see how far I get, this could take a while. The Odo Chip is a nice start, though and get's me working with my newly acquired test equipment.
 
#32 ·
On a side note, I'm also planning a re-engineering of the 84-87 Logic Module controllers. I believe that with modern technology applied to these old cars, not only can you provide better performance, but also smoother engine running. I believe the reason some of these older ECU based cars aren't as stable as their modern counterparts is the fact that the older, slower CPUs can't adjust to changing conditions as fast as newer, faster ECUs can. I'm probably going to stick with 8-bit for now, though as I'll have to port the existing source code and then tighten the loop timing and scale everything appropriately. I should be able to provide a 10x tighter control loop which should greatly improve engine response and still fit a few extra goodies like logging in. Since I'm in SMOG controlled California, the ECU will need to behave like a factory unit when hooked up to the tester's equipment, so that will be a challenge. Maybe I'll have a "SMOG Mode" switch. However, I expect the replacement computer to allow for lower emissions than stock, so I may even go after CARB certification. I'm sticking with the older LM units for now because (1. They're located in the passenger cabin and won't need to be underhood resiliant. 2. They are basically just the Brain, with the Brawn in the power module under the hood. And 3. All of my Turbo Dodges are LM equipped). Other people are working on SMEC and SBEC designs anyway, so I won't be duplicating other's efforts. I'm actually hoping to have the time to create a complete suite if interacting components to replace the electronics on my '84 Laser Digital Dash/31 Function Monitor/12-button Nav equipped car, with a single computer doing all of the work including the ECU and the Dash, Monitor, and Nav just being display units accessed by the main computer. The replacement equipment will be a combination of LED and LCD to replace the Vacuum Flourescent original displays. We'll see how far I get, this could take a while. The Odo Chip is a nice start, though and get's me working with my newly acquired test equipment.
Sidetrack warning!

I totally missed this post. I've recently started working on a 'SuperLM' duagterboard myself. Basically, I'm replacing the original 6803 uProcessor, memory, bus control, and A2D with a 68HC11E0 and new memory and bus chips. Basically, you get a processor upgrade, and a flashable LM all in one. I have a thread over on TM.com - Flashable LM or Super LM?

I have the circuit designed, and have kind of started the board layout. But, I want to finish porting the SMEC code over to it before I finalize it (the SMEC's IO needs to be remapped to the LM's IO chip).

It will be flashable the same way the SBEC is - the boot signal is MUX'd with the SCI Rx line.

Anyway, I'd love to hear how your progress is going and what your plans are/were for the LM...
 
#29 ·
Good to see some action on the EEPROM. I was going to figure it out, but now have went to the analog cluster from a 90 Sprit. The VFD's are failing on my cluster and every cluster I pulled from the junk yards(rare too) had the same dim VFD's also. My car ODO rolled over at the 200K Mile point and went back to 0 miles with the * in the display.

I would love to keep the VFD cluster and though about using LED's in place of them, but thats going to take some time figuring it out. I need to get my Caravelle back on the road as the gas prices went up 20cents in two days!

I am currently rewiring the harness to use a 90 Labaron SBEC,BCM and travler while keeping the EVA. It is sure intresting how Chrysler did the wire harness of our cars. They have minimal splices but run wires to one big splice(soldered too) then to power what ever. No wonder why these under dash harneses are so bulky!
 
Top