FORD technical service bulletin : ICC touch screen display

[jakka351]

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

[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]

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 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]

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]

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]

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]

Thanks PHATAL, that means a lot.

Originally Posted by 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 .

Yes, it is, at least on the FG2/X units, with the EEPROM...

0x194 = 0x00, 0x00
0x196 = 0x20, 0x03
0x198 = 0x40, 0x06

Change that to:

0x196 = 0x40, 0x06
0x198 = 0x80, 0x0C

And you will double the BOOST gauge's range (2 bar).

Chicka-chick-ahh.

[JasonACT]

Originally Posted by JasonACT

the EEPROM...

0x194 = 0x00, 0x00
0x196 = 0x20, 0x03
0x198 = 0x40, 0x06

Change that to:

0x196 = 0x40, 0x06
0x198 = 0x80, 0x0C

And you will double the BOOST gauge's range (2 bar).

I wanted to try this, so I took some photos while it was out:





For me, it makes more sense to make it a 1.5-BAR gauge though, as mine only really goes to about 16 PSI (having tested it this arvo). It only went a bit past the next notch after the centre one..

1.5-BAR...
0x196 = 0xB0, 0x04
0x198 = 0x60, 0x09

I also got the chance to re-zero one of the gauges while it was out, which is a physical needle position movement needed on the stepper motor shaft. FYI - you turn these needles anti-clockwise to pull them off, never clock-wise! Never directly up and off either! Pretend to unscrew it, even though there's no thread, while slightly pulling to get them off. If you do go clockwise by accident, the stepper moves and you need to reset them by powering it up, before putting back the needle.

It's nice to have all the needles perfect now!

[FPVAUS]

Worth a watch.

https://www.youtube.com/watch?v=kUUFz7pF0dU

[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]

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.

[JasonACT]

So.. Moving on..

I decided to run a brute force over the FG (I) EEPROM to check out if it's the same algorithm to protect the data areas (I don't have the firmware, it [the filename] is not divulged like it is with the FG2 unit)... Yep, same algorithm.

Plain dump:

0x000 00 00 75 00 00 00 d6 dc ad b9 5b 73 b6 e6 6d cd ..u...ÖÜ*.[s¶æmÍ
0x010 db 9a b7 35 6e 6b dc d7 b9 af 73 5f e6 be cd 7d Ûš·5nkÜ×.¯s_æ.Í}
0x020 9a fb 35 f7 6b ee 1e c4 36 46 50 41 41 41 4a 47 šû5÷kî.Ä6FPAAAJG
0x030 53 57 38 41 35 31 31 30 38 ff 1e c4 36 46 50 41 SW8A51108ÿ.Ä6FPA
0x040 41 41 4a 47 53 57 38 41 35 31 31 30 38 ff d3 73 AAJGSW8A51108ÿÓs
0x050 cf 66 93 33 ff ff 10 10 10 10 10 10 10 20 20 20 Ïf“3ÿÿ.......___
0x060 10 00 10 10 10 10 10 10 10 10 00 10 10 10 10 20 ..............._
0x070 20 20 20 20 10 20 20 20 20 20 81 0e 80 00 ff 00 ____._____..€.ÿ.
0x080 0f 5a ff 0f 1f 02 06 06 0a 00 56 97 19 01 08 c0 .Zÿ.......V—...À
0x090 50 36 ff ff 80 22 10 3c 06 00 38 52 32 39 ca 72 P6ÿÿ€".<..8R29Êr
0x0A0 1f 32 74 61 85 03 26 03 eb 02 a8 02 39 02 f9 01 .2ta..&.ë.¨.9.ù.
0x0B0 16 01 b6 00 7e 00 62 00 00 00 a0 0f 5e 1a 1c 25 ..¶.~.b...*.^..%
0x0C0 98 3a 50 46 c0 5d 78 69 30 75 f4 7e 11 00 94 70 ˜:PFÀ]xi0uô~..”p
0x0D0 00 00 a0 0f 40 1f e0 2e 80 3e 20 4e c0 5d 60 6d ..*.@.à.€>_NÀ]`m
0x0E0 00 00 65 02 0b 05 6b 07 cf 09 34 0c 98 0e fd 10 ..e...k.Ï.4.˜.ý.
0x0F0 02 00 84 71 00 00 00 14 00 1e 00 28 00 32 00 37 ...q.......(.2.7
0x100 00 46 00 82 00 00 00 15 00 1f 00 29 00 33 00 38 .F.........).3.8
0x110 00 47 00 83 00 00 59 03 06 05 b2 06 5f 08 35 09 .G.ƒ..Y....._.5.
0x120 b8 0b be 10 6b 13 04 00 28 4f 20 03 ab 03 c1 04 ¸...k...(O_.«.Á.
0x130 14 05 c8 05 ed 05 36 06 5e 06 00 00 0c 01 24 03 ..È.í.6.^.....$.
0x140 c4 03 2f 04 3b 05 53 07 5f 08 1e 00 47 c3 00 00 Ä./.;.S._...GÃ..
0x150 1e 01 e2 01 a7 02 2f 04 06 05 b2 06 89 07 5f 08 ..â.§./......._.
0x160 b8 08 c4 09 10 27 c4 09 f4 01 70 17 94 11 27 08 ¸.Ä..'Ä.ô.p.”.'.
0x170 0c 00 05 00 cf 03 0b 0b 0b 0b e4 cc 32 00 64 00 ....Ï.....äÌ2.d.
0x180 0a 00 00 00 2f 04 5f 08 00 00 70 00 e0 00 a0 05 ..../._...p.à.*.
0x190 c0 08 e0 0b 00 00 20 03 40 06 e8 cc 14 36 5e 80 À.à..._.@.èÌ.6^€
0x1A0 26 6e ba ff 80 a8 d6 ff 03 08 12 1a 80 a8 d6 ff &nºÿ€¨Öÿ....€¨Öÿ
0x1B0 00 08 12 1a 66 96 cf ff 66 96 cf ff 5e 01 7f 00 ....f–Ïÿf–Ïÿ^...
0x1C0 39 00 90 a7 c0 c7 c7 c7 c2 c2 c2 c2 f5 d1 00 00 9..§ÀÇÇÇÂÂÂÂõÑ..
0x1D0 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1E0 00 00 21 12 00 01 95 2c ff 14 06 07 00 14 46 64 ..!....,ÿ.....Fd
0x1F0 ff 12 00 02 80 41 46 32 30 cf 20 46 00 00 00 00 ÿ...€AF20Ï_F....


Breakdown - where a length is shown [in hex], the next 2 bytes are a checksum:


0x000 ____ 00 00 75 00 00 00 d6 dc ad b9 5b 73 b6 e6 6d cd db 9a b7 35 6e 6b dc d7 b9 af 73 5f e6 be cd 7d 9a fb 35 f7 6b ee
0x026 (14) 1e c4 6FPAAAJGSW8A51108
0x03A (14) 1e c4 6FPAAAJGSW8A51108
0x04E (08) d3 73 cf 66 93 33 ff ff
0x056 ____ 10 10 10 10 10 10 10 20 20 20
0x060 ____ 10 00 10 10 10 10 10 10 10 10 00 10 10 10 10 20
0x070 ____ 20 20 20 20 10 20 20 20 20 20 81 0e 80 00 ff 00
0x080 (08) 0f 5a ff 0f 1f 02 06 06
0x088 ____ 0a 00 56 97 19 01 08 c0
0x090 ____ 50 36 ff ff 80 22 10 3c 06 00 38 52 32 39 ca 72
0x0A0 ____ 1f 32 74 61 85 03 26 03 eb 02 a8 02 39 02 f9 01
0x0B0 ____ 16 01 b6 00 7e 00 62 00 00 00 a0 0f 5e 1a 1c 25
0x0C0 ____ 98 3a 50 46 c0 5d 78 69 30 75 f4 7e 11 00
0x0CE (24) 94 70 00 00 a0 0f 40 1f e0 2e 80 3e 20 4e c0 5d 60 6d 00 00 65 02 0b 05 6b 07 cf 09 34 0c 98 0e fd 10 02 00
0x0F2 (36) 84 71 00 00 00 14 00 1e 00 28 00 32 00 37 00 46 00 82 00 00 00 15 00 1f 00 29 00 33 00 38 00 47 00 83 00 00 59 03 06 05 b2 06 5f 08 35 09 b8 0b be 10 6b 13 04 00
0x128 (24) 28 4f 20 03 ab 03 c1 04 14 05 c8 05 ed 05 36 06 5e 06 00 00 0c 01 24 03 c4 03 2f 04 3b 05 53 07 5f 08 1e 00
0x14C (2E) 47 c3 00 00 1e 01 e2 01 a7 02 2f 04 06 05 b2 06 89 07 5f 08 b8 08 c4 09 10 27 c4 09 f4 01 70 17 94 11 27 08 0c 00 05 00 cf 03 0b 0b 0b 0b
0x17A (20) e4 cc 32 00 64 00 0a 00 00 00 2f 04 5f 08 00 00 70 00 e0 00 a0 05 c0 08 e0 0b 00 00 20 03 40 06
0x19A (26) e8 cc 14 36 5e 80 26 6e ba ff 80 a8 d6 ff 03 08 12 1a 80 a8 d6 ff 00 08 12 1a 66 96 cf ff 66 96 cf ff 5e 01 7f 00
0x1C0 (0C) 39 00 90 a7 c0 c7 c7 c7 c2 c2 c2 c2
0x1CC (16) f5 d1 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1E2 (04) 21 12 00 01
0x1E6 (12) 95 2c ff 14 06 07 00 14 46 64 ff 12
0x1F2 ____ 00 02 80 41 46 32 30 cf
0x1FA (06) 20 46 00 00 00 00


I can see the same tacho and speedo maps:


0x0CE
=====
00 00 = 00000 = 0
a0 0f = 04000 = 1000
40 1f = 08000 = 2000
e0 2e = 12000 = 3000
80 3e = 16000 = 4000
20 4e = 20000 = 5000
c0 5d = 24000 = 6000
60 6d = 28000 = 7000

00 00 = 0000
65 02 = 0613
0b 05 = 1291
6b 07 = 1899
cf 09 = 2511
34 0c = 3124
98 0e = 3736
fd 10 = 4349

02 00 ?

0x0F2
=====
00 00 = 000 (000)
00 14 = 020 (040)
00 1e = 030 (060)
00 28 = 040 (080)
00 32 = 050 (100)
00 37 = 055 (110)
00 46 = 070 (140)
00 82 = 130 (260)

00 00 = 000
00 15 = 042
00 1f = 062
00 29 = 082
00 33 = 102
00 38 = 112
00 47 = 142
00 83 = 262

00 00 = 0000
59 03 = 0857
06 05 = 1286
b2 06 = 1714
5f 08 = 2143
35 09 = 2357
b8 0b = 3000
be 10 = 4286

6b 13
04 00


So nothing especially different between the FG2 and FG, except for the CCC.

[JasonACT]

I feel my time here has come to an end. But it wasn't without many mistakes...


0x1E6 (12) 95 2c ff 14 06 07 00 14 46 64 ff 12
0x1F2 ____ 00 02 80 41 46 32 30 cf
0x1FA (06) 20 46 00 00 00 00

That's 12 HEX in the FG(I) dump Jason...


0x1E6 (12) 95 2c ff 14 06 07 00 14 46 64 ff 12 00 02 80 41 46 32
0x1F8 ____ 30 cf
0x1FA (06) 20 46 00 00 00 00

Also, it's not speed divided by 2, it's speed times 128, moving the significant part of the number(s) into the next byte but shifted by 1 bit - looking like a divide by 2.

Why do I feel like I'm done here though? Well, in the FG2 EEPROM, location 0x1DE (protected by a checksum at 0x1DC which my program will recalculate) controls this:



Setting it to 1 (binary 00000001) displays this splash screen. Setting it to 3 (binary 00000011) does the same, but also enables the 2 extra gauges. Setting it to 0x0B (binary 00001011) is what I'm settling on. The boost gauge can also act as a oil-pressure gauge on some FPVs (FG1 V8 non supercharged ones only I think)...

Once I worked this out on the FGX test unit running my FG2 EEPROM, I pulled out my G6E MK1 Cluster circuit board and did the whole EEPROM socket thing again (full size EEPROM socket for testing)...

Location 0x1CE (protected by a checksum at 0x1CC, which needs to be fixed in my sample FG2 EEPROM editing code, if you want it to work on a MK1) can be set to 0x0B to do the same thing.

Finally, on the FG2, location 0x062 is the options (Police mode = 0x01) but you can set 0x02 for the FPV 6K-RPM Alarm to go off. That's probably too late really, as I think the rev-limiter is 6K - but I've not found a way to lower it to something better like 5.5K - I'm not sure I really care though.

I've done what I came here to do.

Oh, sound volume was on my list, well... I think that's coded into the firmware raw sound data - so it would be far easier to do a circuit mod for that. Interestingly, there's a pretty big difference between the sound from the G6E MKI (think early 80's 8 bit micro) to what comes out of the FG2/X unit (proper chimes).