BA Falcon Instrument Cluster EEPROM Programming

[Rerouter]

0x24 = CI
0x25 = HW

Back on first page it was said they contain the part number, any chace you could note what part number and possibly what serial number on each?

[aumatt]

The odometer has a very unique coding process.

The eeprom contains DTC's, Serial Number (which consists of the date), the CI Number, hardware version, model number etc.

Matt

[LangasLS]

Edited my previous post with the respective part no's of the clusters - not sure what the serial no. is on them.

[Rerouter]

Ok to me it looks like there are 7 possible maps for gauge positions in the file, 1 changes with each bin so i am going to assume its either fuel (different tank volumes) or speed ( Different top displayed speed / offset)

I've gone and changed the one that changes every time to half the values on your 793361 bin, by rights after burning it i would imagine either your fuel gauge to show half of its previous value, or the speedo to show half your actual road speed,

Fuel gauge on these are meant to be 10 Ohms full, 280 ohms empty, from what i have on hand however this doesn't match any other ford so i am a little suss on those values,

[TazzI]

Hey guys, I've been playing with this too. There's a great forum on using the com-port to speak to modules via the CAN through an elm scanner, "http://www.fordmods.com/ecu-fuel-system-eec-f21/ba-bf-sx-sy-scantool-fun-t25010.html".

I have my BF cluster apart at the moment and have piggybacked onto the eprom (93c56w) with a G540 chip programmer.
I have been able to flash both of the BIN's uploaded previously, onto my own cluster with success. The odometer values read correctly according to the file titles.

I have worked out that the odometer value is in the top line of code, and I think there is something in there that plays with the illumination. Trying to decode the top line to make sense of the HEX code is proving difficult though. I've been at it two nights and the only way I can get visible change is by swapping the entire top row from the BIN. I'll upload my own BIN at some stage. any ideas on translating the HEX would be a step forward I think.

Im still a little unsure what protocol fords use to communicate with everything. I know that the old ford ecus's used PWM at some stage, then upgraded to using CAN. Im unsure what the actual cluster and all other modules utilize.. I would have assumed it would be CAN!
This site shed some light on programming these units. It does look like we will be hooking up an ELM after all.. even mentions some stuff to do with odo programming with the ford global programming service: http://www.fordmods.com/documents.php?d=37

Try changing just a single byte in the first line... the last byte where you think the odo sequence ends. I imagine there will be an "algo" for us to work out.. but it would be good to start tinkering!

Yep - I will try and get this POS BA running on the weekend for some more dumps.

Yeah, this will be a tremendous help! Even getting just 2 or 3 reads at 1km increments will make this a hell of alot easier to crack.
When Im back in Aus, ill hook the microcontroller onto the speedo line and try increment it that way

The odometer has a very unique coding process.

The eeprom contains DTC's, Serial Number (which consists of the date), the CI Number, hardware version, model number etc.

Matt

We will without a doubt smash out the algo after getting a few reads of small increments.

And for anyone wondering what is "EE Version", that is eeprom version number. Id assume.. even if the version changes, the same model cluster will till have the same "map out". Just possible have some additional features implemented.

Also, another thing, has anyone checked if the "trip" value is reset after power is removed? Or is this value also stored in the eeprom? (I am assuming the clusters have a trip value!). If the trip is stored, we will need to note down the trip distance on each dump, and also do a "clear trip" and read that value to identify where the trip value starts and see if this is incorporated in the odo calcs.

[LangasLS]

My slight bit of playing for the night - In my 457225km bin - changing address 0x07 from F4 to F5 resulted in the ODO being displayed changing from 457225km to 457223km. I still need to get the cluster back into the car and have a play.

BTW: Trip Meter A is showing 88.6 and Trip Meter B is showing 9177.8. The value can be reset with the cluster powered up but is restored after a power cycle indicating to me it is stored in the eeprom. Obviously when the trip meter is zeroed the values in the eeprom are not overwritten until the vehicle has moved.

Edit: For the 793361km dump - Trip Meter A is showing 516.6 and Trip Meter B 2041.8. I believe the 793361km dump came from a cluster that was in a wagon also - possibly a dedicated gas car being a taxi too.

[aumatt]

Tripmeter A 2bytes long start 0x10
Tripmeter B 2bytes loing start 0x12

Calculated by (xxxx*2)/10 if I remember correctly.

I have the formula for the odo but not sure how public it should be. BTW took me quite some time to work it out even by incrementing. There is an easier way of changing the odo anyway. Zero the odometer out in the EEPROM, then issue a CAN command to change the odometer to the value you want. Re read the eeprom and manually remove the DTC for the eeprom and all traces are gone

As I said be mindfull that BA and BF clusters have a slightly different EEPROM layout. Mainly feature set is located at different positions.

I have probably mapped approx 70% of the BA/BF EEPROM, just the checksum's i havent really figured out yet.

Matt

[TazzI]

Yeah I read up on that. Silly dtc needs to be erased after programming odo when under 100kms. Will work on that one when I pick up the scantool. Or use this dedicated ford programming service which seems to be the GM SPS equivalent.

I figured the BA and BF would be slightly different, we will have to treat them as two separate entities and name everything correctly so nothin gets confused.

Still, if we have to go into the eeprom to wipe the odo, while we are there, might as well change it to the required value.. What's an extra 10sec of work.
The algo won't be hard, can't be worse than reverse engineering a crc checksum. Or the GM ecu algos.

At least when I generate the speedo pulses, we will have unlimited reads hopefully. Can hook the eeprom programmer to read at every 1km, and the micro can turn the cluster off to ensure the eeprom write initiates and the reader can then do it's job!

Nice Langas! So increase from F4 to F5 decreases the odo by 2. So could it possibly be changing to F6 will decrease by another 2.

If that's the case, the odo will have an algo similar to what matt posted. (Early comments though! Don't have a bin file reader on the iphone!)

Very keen to get the elm hooked up, I'd imagine it will communicate over 11bit 500kb CAN or 29bit 500kb. Hopefully we could read out section by section of the eeprom. Or modify the mandatory DID's which could be basic cluster settings.

[LangasLS]

Well, I think I've managed to uncover the Police Mode purely by chance (or atleast partially uncovered it) whilst playing with the trip meter locations

Location 0x14 when set to 04 or greater (set to 01 - in the dumps I posted) Police mode becomes active. The cluster will display 'Police' on the RHS LCD for a few seconds when powered on then revert to the ODO reading and from what I can work out the LHS LCD displays the trip meter and distance to empty? Not too sure yet.

In Police Mode it appears locations 0x10 and 0x11 are the trip meter locations used (Same as Trip Meter A) 0x12 and 0x13 are Trip Meter B.

To change the values of the trip meter are as aumatt described:
(Desired value in km / 2) *10

Eg for 100km
(100/2)*10 = 500, then convert to hex = 01 F4. Easy. Useless really but handy to know how it works.

Edit:
Further more in my playing today (home sick..) I zeroed out the top row (0x00 to 0x0F) to 00 and the odo reads 777215 irrespective of the bin file in use (either the 457225km bin or the 793361km bin). Could this be the offset?

[TazzI]

Alright! Sounds like police node has been sorted. Does a digital display pop up after the police symbol shows on screen?

That odo thing kinda makes sense with what was done before. As the top line increases, the odo decreases. Soooo... If the top line is zero, then it should be the max kms value. I imagine one or two of those bytes in the first line will some how make the odo higher than 777215.

If you got some time, what happens when increasing location 0x0F by 1 now that the top line is zeroed?