FORD technical service bulletin : ICC touch screen display

[JasonACT]

I thought I knew, but how wrong was I?

While probing the read by ID function (65K reads) in the Cluster, even before entering any special security mode, I got quite a few results. Some binary bits and bytes. 2 VINs, mine from the reprogrammed EEPROM, and the original. And some looked like Ford part numbers. I plugged the 4 part numbers I saw into the Ford "calibration files" download web-page and [just] one gave me a result.

I've now got the Cluster "vbf executable" firmware!

It has a text header, says Volvo along with quite a few other things. I removed the header (making the final binary file size what the text in the header said it should be) and after checking what was left, to cut a slightly longer story short, noticed the last 2 bytes in the file were some sort of checksum. Had to remove those, then add back 2 bytes up front to match the correct file size again.

I had installed "Ghidra" and "Java 11" - made a new project, imported the binary file, selected options to say V850 code and it loads at 0x15000 (location is mentioned in the original vbf header) and it de-compiles nicely!

I can see the seed-key function (value 0xC541A9, part of the algorithm, is a dead give-away there). I can see the read-by-ID routine too. Some of those readable IDs (out of 65K) have a 3rd byte sub-function though, so, oh - I don't have all the data I can possibly read yet. I was going to read the values out of my car tonight, but I'll hang off now until I can get them all.

I do feel like I've just time-travelled about 3 months into the future though

(Incidentally, I plugged the ICC part numbers I also got previously in, but got NOTHING back at all!)

[PHATAL]

I don't understand much of it but I love it...

Sent from my SM-G998B using Tapatalk

[Franco Cozzo]

JasonACT is probably the guy behind that AN0M thing that happened a couple days ago

Reverse engineering Ford ICC like

[JasonACT]

I have not found a way to read the entire EEPROM yet, so still looking there, but I can confirm that the last block of 4KB FLASH memory contains the "original VIN" - shown below is the "map" of an FGX Cluster tested for blocks of FLASH that are used (XX=used, __=blank, which was all I could tell from the special V850 programming mode I was able to enter)...


FLASH READER
Hit return to start
Starting
Sync...
Freq...
Baud...
OK.
Boot OK
// Reading 000000-000FFF...
Failed(16).
00000000: XX 00001000: XX 00002000: XX 00003000: XX
00004000: __ 00005000: XX 00006000: XX 00007000: XX
00008000: XX 00009000: XX 0000A000: XX 0000B000: XX
0000C000: XX 0000D000: XX 0000E000: XX 0000F000: XX
00010000: XX 00011000: XX 00012000: __ 00013000: __
00014000: __ 00015000: XX 00016000: XX 00017000: XX
00018000: XX 00019000: XX 0001A000: XX 0001B000: XX
0001C000: XX 0001D000: XX 0001E000: XX 0001F000: XX
00020000: XX 00021000: XX 00022000: XX 00023000: XX
00024000: XX 00025000: XX 00026000: XX 00027000: XX
00028000: XX 00029000: XX 0002A000: XX 0002B000: XX
0002C000: XX 0002D000: XX 0002E000: XX 0002F000: XX
00030000: XX 00031000: XX 00032000: XX 00033000: XX
00034000: XX 00035000: XX 00036000: XX 00037000: XX
00038000: XX 00039000: XX 0003A000: XX 0003B000: XX
0003C000: XX 0003D000: XX 0003E000: XX 0003F000: XX
00040000: XX 00041000: XX 00042000: XX 00043000: XX
00044000: XX 00045000: XX 00046000: XX 00047000: XX
00048000: XX 00049000: XX 0004A000: XX 0004B000: XX
0004C000: XX 0004D000: XX 0004E000: XX 0004F000: XX
00050000: XX 00051000: XX 00052000: XX 00053000: XX
00054000: XX 00055000: XX 00056000: XX 00057000: XX
00058000: XX 00059000: XX 0005A000: XX 0005B000: XX
0005C000: XX 0005D000: XX 0005E000: XX 0005F000: XX
00060000: XX 00061000: __ 00062000: __ 00063000: __
00064000: __ 00065000: __ 00066000: __ 00067000: __
00068000: __ 00069000: __ 0006A000: __ 0006B000: __
0006C000: __ 0006D000: __ 0006E000: __ 0006F000: __
00070000: __ 00071000: __ 00072000: __ 00073000: __
00074000: __ 00075000: __ 00076000: __ 00077000: __
00078000: __ 00079000: __ 0007A000: __ 0007B000: __
0007C000: __ 0007D000: __ 0007E000: __ 0007F000: XX

@ 0x7F000 ? 0xFC, 0x59, 0xA1, // b...Y. (RQST 22F106)
@ 0x7F100 ? 0x57, 0x34, 0x31, // b..W41 (RQST 22F114)
@ 0x7F10B 0x11 bytes (17) is the VIN number (RQST 22F190)

@ 0x7F116 0x06 bytes (06) ? :-
000001111111111111
BCDEF0123456789ABC
6FPAAAJGCMEU65281
___________^^^^^^

(0x101 = 257 - 3 = 254)
>22F106 62 F1 06
FC 59 A1 00 01 00 FC 06 04 02 47 02 02 00 00 00 00 00 00 00 00 00 00 00 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A1 00 00 3B 01 00 00 00 04 00 00 00 00 00 00 00 01 00 00 10 00 00 00 00 00 12 01 F2 50 00 00 02 03 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 02 00 01 00 00 00 00 01 00 00 00 00 00 00 00 01 00 02 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00

(0x102 = 258 - 3 = 255)
>22F114 62 F1 14
_W _4 _1 __ _s _q _0 _0 _5 __ __ _6 _F _P _A _A _A _J _G _C _M _E _U _6 _5 _2 _8 _1
57 34 31 82 73 71 30 30 35 0D 0A 36 46 50 41 41 41 4A 47 43 4D 45 55 36 35 32 38 31 00 0D 0A 00 00 0D 0A 00 00 0D 0A 00 00 0D 0A 00 00 0D 0A 00 00 0D 0A 00 00 0D 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


You can see the boot area has firmware which we don't have access to, but from 0x15000 to 0x7E000 is the firmware I was able to obtain.

I'm interested in the last block though (@ 0x7F000) which isn't part of the firmware. Seems that read-by-ID gets a quarter KB with requests 22F106 and another with 22F114, which is where the original VIN and some (non-as-built) config options are set. I can see the firmware decompiled code only accesses these two areas, and a few other places specifically check out the last 6 bytes of the original VIN in some calculations.

I suspect I can build a 4KB firmware file and flash it into that last block, but I'll probably do that on the FGX unit which I pulled the blue and red LEDs off to see if it still "works" afterwards with my copied EEPROM installed. We may have to blast, no wait, I may just need some time...

Erased FLASH tends to return values of 0xFF, so I assume I will need to set any unused bytes to 0x00 in that last block (looking at the existing data)... I hope there isn't a checksum value anywhere there though, because I won't know how to calculate one when I erase the last FGX Cluster FLASH block and set my new data in there. That poor FGX Cluster isn't ever going to be used again in any case - so no great loss I suppose.

[JasonACT]

Previously, a while ago now, I had modified the spare FGX circuit board so I could enter the V850 flash programming mode:









Purple wire is the reset (active low, so short to ground to reset)
Blue wire is the FLMD0 pin (Enter Flash Mode on Reset use 5V to do so)
Yellow is RXDA0 (Serial Receive, I connect my transmit pin to this)
Green is TXDA0 (Serial Transmit, connected to my Arduino receive pin)

Nothing like a bit of tough double sided tape to help out here.

Some care is needed to power up the unit, one of those serial lines is the car's indicator switch in normal mode, so if it's connected when powering-on or resetting, it doesn't enter flash programmer mode, but you do get alarms and an indicator LED flashing with the speaker tick tocking away.

Anyway, I reconstructed the "last" FGX flash memory block data along with running the checksum routines of the V850. I did the same on my PC with the data I had to see if they matched. They didn't. That was performed over 4096 bytes (the block size) and I thought I'd try smaller requests (the V850 chip really shouldn't let me do that, it's a bit of a security hole - but I'm sure you can't request a single byte - otherwise you would be able to just read out the protected data) and I was able to do 512 byte checks successfully.

I could see the first 512 bytes had data, and all the other 512 byte sectors were erased (0xFF) because the checksum algorithm is pretty basic and it's easy to guess. Now my data extracted from UDS 22F106 & 22F114 commands is almost 512 bytes (only 3 bytes were unknown) so it wasn't hard to work out their values (0x00) and get matching checksums.

With all this, I put together the data I now had, and ran the V850 verify flash command (it takes 4096 bytes and tells you if it matches what's in the flash memory block)... Succcess, it matches perfectly.

Next to do... Flash in my data using the V850 flash programming mode because...

I CAN'T WORK OUT HOW TO DO IT VIA OBDII !!!

All the CAN-BUS related stuff is in the firmware parts I don't have. It looks like the firmware part I do have is just an extension module, sort of like an operating system running an executable.

Still, if the block write command isn't locked out on the V850, I think I'm getting closer. I have not written up the logic to do/attempt a block write yet, but I [only] very vaguely recall reading the protection flags all that time ago and it was only boot-block-write and read-block protected. Here's hoping.

EDIT:

I forgot to mention the data in that 512 byte sector in the last block:

FC 59 A1 00 01 00 FC 06 04 02 47 02 02

FC = Initialised check byte
59 = Checksum (calculated over the following ~252 bytes of data - so not including the VIN data which starts at position ~256 onwards)
A1 = Start of data... These seem to be referenced by various data structures used by the code, probably options like 2 extra gauges, and 7K vs 8K RPM on the dial (I hope).

[jakka351]

Devils Advocate: The information that would let someone wind back an odometer for nefarious purposes, especially given the current climate.





Don't post that bit.

[Citroënbender]

I’d hope for a deliberate error in disclosure there, so if you tried to flick the speedo it displayed “HOLDEN”.

Still my favourite thread ever on the forum. I haven’t had the same visceral thrill since reading King Solomon’s Mines as a young fellow.

[JasonACT]

Well, it erased ok, programmed ok, verified ok... But in diags mode I only got back the FGX VIN though???!!!
Checked my program, I had forgotten to switch over 2 references to my data, I had only done 1. So still pointing to the FGX.
Attempt 2... erase fail. WHAT?! I had put back exactly what was where, how could it possibly know to "protect it" due to a discovered hacking attempt?
Reset my Arduino, reset the IPC and try again...
Erase ok, write ok, verify ok... Diags now show my VIN in the unit, but since this is the FGX cluster with a different firmware, I'm not putting it in my car to test!

I'll need to do all this again now on the spare FG2 unit I have, and before that, consider a better way to get access to pins FLMD0, RXDA0 & TXDA0 (RESET I don't need, a power cycle can do that).

Interesting though, the FG2 unit is from a ute, it has a lot of differences to my data in that sector. The FGX one has a new firmware, but only a single byte difference (0x01 vs 0x02 a quarter in) in this data. So for all I know, the FGX may work in my car.

[JasonACT]

Sad news, I only ever get "Erase fail" on the FG2 unit. I think it's write-locked. I've tried many, many times now.

I can "verify" that the last flash block has the data I expect, which it does, but once I attempt to erase the block getting it ready to write my new data, which fails, verify no longer works. Strange.

Maybe Ford locked early units, but in the last FGX run, decided to open it up a little due to spare parts being an issue?

[JasonACT]

False alarm! My apologies!

In a case of RTFM, if you pulse the FLMD0 pin it goes into different modes. 0 pulses is UART mode which I want. 8, 9, 11 & 12 pulses goes through the other interfaces that can be used.

Now, I've only got 2 hands, and I'm using alligator clips & wires on the smallest sewing needles I own here.

So I was releasing FLMD0 from +5v to open circuit so I could connect to the serial pins once powered up. Out with my "third hand" device (Jaycar "LED Magnifying lamp with third hand") to keep it at +5v...

And it's now programmed! Diags confirms my VIN from the EEPROM and Flash memory!

Sigh, now I need to pull my car apart again to test it all out (not today).

[JasonACT]

It was dark yesterday by the time I had reassembled the cluster, not to mention cold. But I got home from work an hour ago and pulled out my working one, hung this "cloned cluster" in its place:



Car was started, no problem, and when I stopped the engine - what's descripted in this thread:

https://www.fordforums.com.au/showthread.php?t=11486618

No longer happens, the door locks can now be locked/unlocked with the remote fob just like the original cluster, without any mucking around with the ICC door lock button.

So... Success! I now have a "spare" matched to my car working cluster (with 49497Ks on it) that my car can't tell isn't the original. When I had only copied the EEPROM and tried, I still needed to clear DTCs showing in the IPC, but not any longer. Straight to the pool room.

[JasonACT]

Originally Posted by maximafag

Devils Advocate: The information that would let someone wind back an odometer for nefarious purposes, especially given the current climate.
Don't post that bit.

There are at least 2 parts to this: One is the checksum - which would allow someone to change the EEPROM and make it "load" without an error with whatever change was desired. Then there is the algorithm used to store the odometer value, which in-itself isn't something I'd consider needing protection. I say "at least" because there's always more going on. Like a business protecting their investment, Ford, and third parties doing "bad things" for a price, where the information leak hurts them.

Where do you draw the line though? Which one of those two things do I not look into? My list had the odo algo at #6, the checksum at #7. But #3, 4 & 5 may need someone with a FG(I/II)-FPV to supply me their block data to confidently continue. That's probably not going to happen without trusted associates telling them "it's OK to extract it via OBDII" because they had already used the info I'm posting without an issue.

Anyhoo... I'm posting my slightly modified Arduino program files now, that I used to do the EEPROM and FLASH components. They are modified (in that I've removed my car's data - and only left the donor cloned unit's original data) along with some simplification from some of the source code I had been following from someone else's efforts (I wasn't the one who did this first).

I should also add, I've now got the ICC V850 firmware (most of it, anyway) because when I dumped my original cluster, I noticed the part-number was one letter behind the 2014 donor unit... I now know the Ford site only supplies the "latest" firmware - so mine is no longer available, but can apparently be upgraded. Using this information, I increased the last letter of the ICC part-numbers until I got something.

The ICC firmware is packed in 32 byte segments with a checksum (unlike the cluster's which is byte-for-byte) so I needed to unpack it, work out where it loaded (around 16K in, FYI) and I could see a very good de-compile using the tools already mentioned. But be warned, not to update this firmware, because the QNX software (on the iMX31 chip) before mid-late 2013 doesn't really like the newer one on the V850 chip.

You will need a more powerful Arduino board to run the Flash-program, it's using a lot of RAM, though it could be modified to work on something with 8K I suppose (I've got ones with a lot of RAM though, so I didn't go to that trouble). At ~600 lines of code, I consider it a trivial program, but many may not. Enjoy.

[JasonACT]

Originally Posted by maximafag

Devils Advocate: The information that would let someone wind back an odometer for nefarious purposes, especially given the current climate.
Don't post that bit.

Are you absolutely sure?

The IPC, like most modules, boots in mode 1 (or 0x81 in some modules like the ICC).

I've been tinkering with mode 2 (the security key for this mode is request 1 [key-response-2] with secret key DoWZy) up until two days ago. This mode turns off most of the IPC and I know think this is firmware update mode. So I wasn't able to write any data using "those" commands.

There's also mode 3, which I didn't find at first, being in mode 2 didn't help - as I hadn't returned to mode 1 before continuing to search. Rookie mistake. You enter security mode with request 3 [key-response-4] and secret key DRVFl (of course I'm making this up, there are 65K of them to choose from, so I just pick the one which looks the best out of the alpha-only key search I coded up)...

Ah, I can now write data (though the list is pretty short, looking at the decompiled firmware). One of the functions allows you to write (up to 3 times, unless you can re-program it again using an Arduino!) a new ODO value (as long as it's greater than the current one):



My cars have never had so many KMs!

So, playing with a new EEPROM (it's a full size chip, from Jaycar, with a socket [this will never fit back in the case now] so I can easily switch back and forth from the IPC and the Arduino I'm using to read/write) I've worked out the algorithm, worked out the "extra protection" and...



I can now set it to anything I want between the min-max values.

DO NOT PRESS LIKE ON THIS POST - If I see lots of likes, I'm likely to spill the beans on ALL of this!

[JasonACT]

On the other hand, another post you may "like"... To balance things out...



(And Back-To-The-Future II was on last night, so... "If you're chicken!")

[jakka351]

Well I do agree that information should be free....hard line to draw

[jakka351]

But can you do this.....

[JasonACT]

Why so slow?

[QIKESP]

Firstly; Absolutely outstanding thread and a fascinating read !

I'm curious if it's possible to change the input scaling for a gauges servo motor in the clusters code ?

For those of us running more than 1 bar, the boost gauge is constantly maxed out and it drives me nuts .

[jakka351]

Thats the max that was allowed by forscan. Outdone.

[JasonACT]

Originally Posted by JasonACT

odo algo at #6, the checksum at #7. But #3, 4 & 5...

#3 = 7k vs 8k Tacho setting
#4 = Lower the sound level on the IPC speaker, I don't need any unexpected loud surprises shaking my chest!
#5 = Enable FPV Boost and Oil gauges

So, no wonder I had already tested both Tacho & Speedo to their max... Usually I have the Speedo set to 220, to see if it (the stepper/needle) goes to max. with any change I make, since that's the non-XR max. speed. If only I had an FG2 EEPROM of a non-XR6 cluster!!! I've tried all the FLASH settings I can see are read, with their apparent valid values, none changed these two large gauges though. The only non-XR6 cluster I own is a FG(I) G6E - and it's sooo different, it's no good to me except for the part I bought it for. The silver arches over the fuel and water-temp.

#5 is why I have the water-temp & fuel steppers in the boost & oil-temp positions in my photos... To see if they move on a reset (all active steppers attempt a reset to zero on a reboot). Nothing yet though.

I have the Tacho set to 7K, if I can get the range to 8K then it won't quite be in the position of that last photo. Just a little above it.

I have far less hope to "halve" the Boost gauge's range with a setting (making it 2 bar) without hacking the firmware and working out a new checksum for it. Probably not going to happen, not to mention, mine isn't a FPV - I coded up my own with a new FPV facia & Arduino which allows it to "go past" the 1 bar limit already, to the point it almost touches the plastic case at more than 90 degrees angle to the right.

If I get any more likes on "that other post" I'll post what's needed to reset a cluster to 0 (from there anyone can increase it) and I'll describe the command used to set the KMs if they are greater than what's current. I may even post the two programs I created, one to increase the KMs (which is what I started with) and the one I used to decrease them back to zero.

But remember! I said: DON'T PRESS THE LIKE BUTTON!

[Franco Cozzo]

Reckon you could work your magic to make a couple thousand of those Bitcoin things magically appear in my account? Be a slab in it for you

[JasonACT]

Someone had to go and press the like button... So you asked for it, whatever "it" is...

The first 8 bytes of my EEPROM read:

0x09, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x00

The first 8 bytes of the FGX test unit read:

0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

So there's not much going on there that you can decipher. However, I can say these 2 things:

1/ Byte 7 (counting from 1, so the 2nd last one, where in a C program it would be counting from 0 - making it byte position 6 in an array) is the count of "re-programs" done to increase the KMs - of which you get 3 unless you clear it with an EEPROM programmer - which I've done many times now as a single edit.

2/ Bytes 4, 6 & 8 are 0 unless you hit 1,000,000 KMs where all 3 turn into 0x80 and the main counter resets.

You see, the algorithm "clocks" at 1,048,560 back to what was zero - so the Ford people decided to reset it a bit early and set something else to signify >=1M KMs. You want to clear bytes 4, 6, 7 & 8. May the force be with you, always...

The next 32 bytes are the ODO value, which I assume they did this way so each KM added to the car updates a different byte in the EEPROM, in a round-robin sequence, making it last 10 times longer than if it was coded in the minimum number of bytes (3) you could do it in. This is ZERO:

0x0A, 0xF5, 0x15, 0xEA, 0x2B, 0xD4, 0x57, 0xA8,
0xAF, 0x50, 0x5E, 0xA1, 0xBD, 0x42, 0x7A, 0x85,
0xF5, 0x0A, 0xEA, 0x15, 0xD4, 0x2B, 0xA8, 0x57,
0x50, 0xAF, 0xA1, 0x5E, 0x42, 0xBD, 0x85, 0x7A

But... Bytes at 0x208 & 0x209 (hex positions, counting from zero) are special... Every so often when the ODO increases by 0x6000 or 0x4000 KMs, it recalculates these two bytes. I assume this long period between needed updates is to prevent the EEPROM from wearing out, after all the effort spent on the 32 bytes of ODO value. If you have the wrong values entered, you get "ERROR" displayed in the ODO section.

Set byte 0x208 to 0x00, and byte 0x209 to 0xFF. I don't have the exact algorithm worked out, but this part is a bit weak, in that it allows quite a few values to pass the check. I could see (from counting up, with the FGX unit at 38K and mine at 49K) that it was working a particular way. I concluded 0x00, 0xFF were the right values. That worked right away for an ODO of zero. 0x00, 0x00 also worked, as did 0x80, 0x80, so as I say it's a bit weak, but when I told the unit to increase by 1 KM, it recalculated those two bytes as 0x00, 0xFF.

After entering security mode 3, security seed 3, reply key 4...

You want to execute a Write-by-ID command 0x2E, 0x61, 0xBB with 3 more bytes with the ODO value you want. In terms of the ELM327:

2E61BB000001

Sets the KMs to 1.

2E61BB00C15A

Sets the KMs to 49497. I've checked the bytes at 0x208 & 0x209 when doing this, they are recalculated to my actual EEPROM snapshot values, which were 0x18, 0xE7.

I say I haven't worked out those two bytes exactly, but I can say, it subtracts or adds to the first byte, then does the opposite to the second byte. EG "-8"...

0x18, 0xE7
0x10, 0xEF
0x08, 0xF7
0x00, 0xFF

And that's how I concluded 0x00, 0xFF were the correct values, before confirming it by settings the KMs to 1 (after first resetting to 0).

[JasonACT]

Regarding the Cluster's FLASH memory (not the EEPROM this time)...

Originally Posted by JasonACT

I'm interested in the last block though (@ 0x7F000) which isn't part of the firmware. Seems that read-by-ID gets a quarter KB with requests 22F106 and another with 22F114, which is where the original VIN and some (non-as-built) config options are set.

Did I say non-as-built? That last FLASH block (the first 512 byte sector, anyway, though the rest is all 0xFF) is As-Built data. It's the CCC_DATA (Central Config) data in the file you get from Ford when you request it.

So, no need to read out the data from your original unit, just use the 512 bytes of data Ford gives you to clone up a spare Cluster. I've still no way to get the EEPROM data though, without pulling the chip off the board.

My next tinker with this... Setting the FPV CCC data (that burkey05 got for me) into the FGX test cluster, since there's quite a few bytes different there. The EEPROM As-Built data from this FPV only had 1 difference to my XR6, and that yielded nothing special. Fingers crossed.

Edit: tried it, but no change to the 2 extra gauges, and no change to the RPM range (that's I'm looking for) damn.

[jakka351]

The difference between mk1 and mkII clusters being mainly that mk1 doesn't use central config?

[JasonACT]

From what I've read, the mk1 doesn't have a CCC, but I can't say if that's "mainly" the difference.

I've worked out the KMs checksum, attached is a Windows exe that may guide you, seems to be producing the results I want for the 3 FG2/X units I own.

I'm starting to think the FPV firmware is different on a FG2, I can see the low-level routines can operate 6 gauges, but I have not found a way to enable the extra 2 within the firmware I have. Same for the 7K vs 8K RPM gauge.

Maybe I shouldn't expect tinkering with an FGX Cluster to allow enabling these options either, it's a different firmware for sure, and FPV were gone baby gone when these were coded.

[JasonACT]

I do have an FG(I) EEPROM dump (someone was doing it, a long time ago, far far away)...
The EEPROM is 512 bytes (0x000 to 0x1FF) on these. The one I just looked at has 99128KMs on it.

Seems to be offset 0x006 for the 32 bytes ODO value. Offset 0x1F8 for the 2 byte checksum. Not sure about the 0x80's for the >= 1M KMs.

But they were right, nothing ever changes.

[JasonACT]

Interested hackers, find attached a new Arduino EEPROM .ino file. This one recalculates all the checksums (there are quite a few) in the various data areas of the EEPROM. I have worked out how to calibrate the speedo...



But that damn tacho, nothing yet, even with the unit now not complaining about any edits I do.

Things I've noticed:

Speedo needle not moving (and digital readout of 0) is because the checksum doesn't match the calibration data.

Lights in the digital readout not working, you may have a corruption in areas between 0x19A to 0x1DB (checksum didn't match).

Speedo calibration table values are 1/2 the KMs actual value. EG: 0x0014 (20) really means decimal 40. 0x82 (130) really means 260 (max speed).

There's a +1 difference in one table vs another, that makes a +2 difference in KMs speed - but I've played around a bit and set them to be the same (except for that 320KMs image I posted, where I went wild) like what you get in Police mode. Seems to be working well.

The FG2 and FGX differs at around 140 KMs (and you can see the fascia's are slightly different at 140).

[JasonACT]

You might be able to imagine, I'm pretty chuffed with myself at the moment. And I don't even have any photos to share...

static eep eeprom [] = {
{ 0x0000, 0x02, 0x00 }, // 0 Header
{ 0x0002, 0x26, 0x00 }, // 1 ODO
{ 0x0028, 0x14, 0x01 }, // 2 VIN (Full)
{ 0x003c, 0x0a, 0x01 }, // 3 VIN Again, Only Last 6 Letters/Digits
{ 0x0046, 0x08, 0x01 }, // 4 ID C00C
{ 0x004e, 0x12, 0x00 }, // 5 IDs C105, C199 & C19E reference this
{ 0x0060, 0x1c, 0x00 }, // 6 ID DE04
{ 0x007c, 0x02, 0x00 }, // 7 ID DE03
{ 0x007e, 0x04, 0x00 }, // 8 ? Values: 0x78 0x78 0x78 0x4A
{ 0x0082, 0x08, 0x01 }, // 9 ? 511
{ 0x008a, 0x1c, 0x00 }, // 10 ?
{ 0x00a6, 0x32, 0x01 }, // 11 ID DE00
{ 0x00d8, 0x24, 0x01 }, // 12 TACHO TABLES (RPM*4, DialPos 0..4349)
{ 0x00fc, 0x34, 0x01 }, // 13 SPEEDO TABLES (Speed/2, Corrected/2+1, DialPos 0..4286)
{ 0x0130, 0x24, 0x01 }, // 14 ID DE05
{ 0x0154, 0x2e, 0x01 }, // 15 ?
{ 0x0182, 0x18, 0x01 }, // 16 ?
{ 0x019a, 0x36, 0x01 }, // 17 ID EE25 & D902
{ 0x01d0, 0x0c, 0x01 }, // 18 ? Divisor of 194
{ 0x01dc, 0x14, 0x01 }, // 19 ? Flags
{ 0x01f0, 0x04, 0x01 }, // 20 ?
{ 0x01f4, 0x14, 0x01 }, // 21 ?
{ 0x0208, 0x02, 0x00 }, // 22 ODO Checksum
{ 0x020a, 0x06, 0x01 }, // 23 ?
{ 0x0210, 0x04, 0x00 }, // 24 ? (May have a boot counter)
{ 0x0214, 0x06, 0x01 }, // 25 ID DE01
{ 0x021a, 0x02, 0x00 }, // 26 ? (May be options)
{ 0x021c, 0x2e, 0x01 }, // 27 ?
{ 0x024a, 0x1c, 0x01 }, // 28 ?
{ 0x0266, 0x1c, 0x01 }, // 29 ?
{ 0x0282, 0x1c, 0x01 }, // 30 ?
{ 0x029e, 0x1c, 0x01 }, // 31 ?
{ 0x02ba, 0x04, 0x00 }, // 32 ? (May be to do with the VIN)
};

EEP_000D8_CHECKSUM_0x94,_0x70
EEP_000DA
0x00,_0x00,_____0_?____0
0xA0,_0x0F,__4000_?_1000
0x40,_0x1F,__8000_?_2000
0xE0,_0x2E,_12000_?_3000
0x80,_0x3E,_16000_?_4000
0x20,_0x4E,_20000_?_5000
0xC0,_0x5D,_24000_?_6000
0x60,_0x6D,_28000_?_7000

EEP_000EA
0x00,_0x00,_____0
0x65,_0x02,___613
0x0B,_0x05,__1291_(+678)
0x6B,_0x07,__1899_(+608)
0xCF,_0x09,__2511_(+612)
0x34,_0x0C,__3124_(+613)
0x98,_0x0E,__3736_(+612)
0xFD,_0x10,__4349_(+613)

0x02,_0x00,__?????

*****_IF_THIS_IS_RPM_***
!!!_4349_now_is_8000_while_before_it_was_7000
!!!_4349_/_8_=_543.625

0x00_0x00____0
0x1F_0x02____543
0x3F_0x04____1087
0x5E_0x06____1630
0x7E_0x08____2174
0x9E_0x0A____2718
0xBD_0x0C____3261
0xDD_0x0E____3805_<<_This_is_the_new_MAX!
_____________4349_<<_AS.._This_can't_happen now.
*************************


I've just recalibrated my XR6T 7K tacho to match an FPV 8K tacho fascia and it appears to work perfectly (on the bench).

[rollex]

The seed key alg is the same as the pcm uses. I posted it up here. You will need to brute force the 5 byte seed key though. You should be able to read and erase/write to your hearts content if you enter the level 1 security unlock mode.

https://pcmhacking.net/forums/viewtopic.php?t=4940

The vbf format is relatively simple to unpack and repack. Your issue will be finding and checksums it needs.

I would like to do this on the mustang icc or cluster at some point to add custom logos to it. Pm me if you are interested in looking into this, I can probably give you a helping hand on doing a full flash read of the eeprom over obd. There are a lot more f150s and mustangs than there are falcons. Could be profitable.

[JasonACT]

I got the algorithm from here: https://github.com/andrewraharjo/CAN...i/FordStuff.py I didn't post it earlier, because I figured it was pretty easy to find. I have already posted two 5-byte seed-keys for the FG2 Cluster (level 1 to flash, level 3 to configure).

You're right though, about firmware checksums, that's going to be tough since no-one has the boot-loader firmware (first 72KB of flash inside this cluster). But I have already extracted the update-able part from the Ford file.

The EEPROM is mapped into (well, copied into and written back as needed) the V850 chip's RAM, that's how I've been able to find out what some of it does. I'm using Ghidra to decompile the firmware to C (and assembler, but I rarely have to look at that). I have not attempted a read-by-address for a few weeks, so my memory is hazy, but it only rarely yielded sensible data. I did try a number of "styles" too, without any real luck.

I'm not sure you can assume the PCM (and its well defined behaviour over OBD) translates to the instrument cluster, which I believe has been locked down a little more (if only by obscurity, but more likely lack of functionality).

Thanks for the offer of help though. To be honest, the list of things I want to do to this unit is very short now, and I'm not sure modifying the firmware is going to be needed. Time will tell.