FORD technical service bulletin : ICC touch screen display

[Superb]

Originally Posted by JasonACT

What may also make your head hurt (it does mine) is the FGII signal configuration doesn't contain the CAN IDs that control the dials - unless it's the GTF specific file, which transfers data through the CAN bridge. They are well hidden.

So the firmware file I supplied doesn't make it work?

Also don't suppose anyone knows what IPC DTC u2024:56 (Control Module Cal-Config Data) means?

[JasonACT]

Hi Superb, no mate, it works fine My comment was only to say that it's very complicated in how each part works. Which is why I have not posted (m)any updates. Your contribution was flawless though, thanks again, making that file available was priceless!

[Superb]

You've most welcome

[jakka351]

Originally Posted by Superb

You've most welcome

Pew.Pew.Pew. Good Job on a successful undercover mission 99.

[Superb]

Originally Posted by jakka351

Pew.Pew.Pew. Good Job on a successful undercover mission 99.

Ohhh Max

[jakka351]

Now that you have mastered the IPC, how about an easy side quest, does this image look familiar, JasonACT?

[JasonACT]

I've got one, yes it is familiar to me, here's a photo I took tonight...



But I've never seen a splash screen come out of it! But even on my MKII I have not bothered to enable the ICC ignition splash screen (but I did on boot, which is automatic with the > 2013 firmware, where my car is a 2012).

You can download the firmware for these from the Ford site: 8R29-14D017-AC

I've converted it to a "flat" binary file (using a program I wrote for .PHF firmware files) and I can see a couple of splash images in there. The thing is though, when I flashed my MKII ICC unit, I needed the SBL (which may not be needed here) but it erases the entire flash (unlike the MKII cluster where I can reprogram 4KB blocks at a time). So to do this "quest" will involve editing the firmware and reflashing it in its entirety.

The secret key on these is: 0x42, 0x72, 0x61, 0x64, 0x57 ("BradW")

But I would only be re-inventing the wheel, so to speak, if I took this idea any further.

[jakka351]

Heres an interesting tidbit - 0x6FC has - if you set the first byte to 0x01, 0x03 or 0x03, 3 modes to choose (display), appears to be the recieving ID of messages for Radio diagnostics from the ACM.

[jakka351]

I'm gonna have a go at re-inventing the wheel.

[jakka351]

I have got a mini MS-can network set up at home (ACM, AIM, BPM, FDIM, IC) I am planning on hooking it up to a rooted telstra modem, and streaming it online so people can 'hack my bus' for fun. Just not sure about the actual HTML interface. Will post when functional.

[JasonACT]

I finally worked out where the EEPROM was in the MKII FDIM (U1303 - the one that says "08B 2" which is a 24C08 automotive spec. 1KB chip running from 5v down to 2.5v... I had to pull it with my hot air station, I couldn't read it while it was on the board, even with all the tricks I know. Once I had its contents though, I worked out how to read it via OBD2... But you can only write back "most of it". There's some parts it won't let you write (the DTC area I think).

While trying all the code pathways in the disassembled firmware, I realised one of them had cleared the entire EEPROM, zeroed except for 0xFF at the start of every 16 byte row.

Next boot, it loaded up defaults for everything (VINs were left as 0xFF strings along with a couple of other things). Firmware strings were "low series" values.

It might not be such a good idea to let someone hack your bus over the Internet!

[gkhn]

[jakka351]

Originally Posted by JasonACT

I finally worked out where the EEPROM was in the MKII FDIM (U1303 - the one that says "08B 2" which is a 24C08 automotive spec. 1KB chip running from 5v down to 2.5v... I had to pull it with my hot air station, I couldn't read it while it was on the board, even with all the tricks I know. Once I had its contents though, I worked out how to read it via OBD2... But you can only write back "most of it". There's some parts it won't let you write (the DTC area I think).

While trying all the code pathways in the disassembled firmware, I realised one of them had cleared the entire EEPROM, zeroed except for 0xFF at the start of every 16 byte row.

Next boot, it loaded up defaults for everything (VINs were left as 0xFF strings along with a couple of other things). Firmware strings were "low series" values.

It might not be such a good idea to let someone hack your bus over the Internet!

Well, whats the word they can do? eject the cd from the ACM, spitting out spinning like a jigsaw blade, and it chops.my leg off? Ill wear shin guards from now on.

[jakka351]

Originally Posted by JasonACT

I finally worked out where the EEPROM was in the MKII FDIM (U1303 - the one that says "08B 2" which is a 24C08 automotive spec. 1KB chip running from 5v down to 2.5v... I had to pull it with my hot air station, I couldn't read it while it was on the board, even with all the tricks I know. Once I had its contents though, I worked out how to read it via OBD2... But you can only write back "most of it". There's some parts it won't let you write (the DTC area I think).

While trying all the code pathways in the disassembled firmware, I realised one of them had cleared the entire EEPROM, zeroed except for 0xFF at the start of every 16 byte row.

Next boot, it loaded up defaults for everything (VINs were left as 0xFF strings along with a couple of other things). Firmware strings were "low series" values.

It might not be such a good idea to let someone hack your bus over the Internet!

If the Mk2 is running QNX, would it replacing the boot image be simply enabling ssh access or similar and simply replacing the file with a image of correction dimension and filename(case sensitive due to linux) and then bobs your uncle. I think you already make use of remote access for your RPI? I assume root access is probably needed.

[JasonACT]

The worst? they can do is erase the FLASH & EEPROM leaving you to sort out reloading it all to get it working again.

Yeah, MKII splash screen is pretty easy to change with my ICC Comms program already, using the recore button & USB script to replace the default image. And yes, my units all have WiFi root terminal access with Y-MODEM file upload and download - so I've got a few options.

What you are after though is a CAN recording of firmware 8R29-14D017-AC being loaded into a MK1 low-series FDIM by IDS... That's what I meant about re-inventing the wheel (since you need to upload the entire firmware, I would only be re-inventing the IDS firmware upload process - also, I don't think Forscan can do this, .PHF files are a bit different to the .VBS files Forscan handles).

The actual process to unpack, edit, and repack with new CRCs a MK1 firmware for changing the ICC splash screen is not very hard. But you really want to choose your image carefully, it's a big process to go through on a whim.

[jakka351]

Originally Posted by JasonACT

The worst? they can do is erase the FLASH & EEPROM leaving you to sort out reloading it all to get it working again.

Yeah, MKII splash screen is pretty easy to change with my ICC Comms program already, using the recore button & USB script to replace the default image. And yes, my units all have WiFi root terminal access with Y-MODEM file upload and download - so I've got a few options.

What you are after though is a CAN recording of firmware 8R29-14D017-AC being loaded into a MK1 low-series FDIM by IDS... That's what I meant about re-inventing the wheel (since you need to upload the entire firmware, I would only be re-inventing the IDS firmware upload process - also, I don't think Forscan can do this, .PHF files are a bit different to the .VBS files Forscan handles).

The actual process to unpack, edit, and repack with new CRCs a MK1 firmware for changing the ICC splash screen is not very hard. But you really want to choose your image carefully, it's a big process to go through on a whim.

Ill be using the most ridiculous image I can find, likely a pic of pixelized boobs. Could one point me towards software that could unpack? Would this be converting .phf to a binary file, and then unpacking the binary to a 'readable' format, changing the image out and then repacking and recalculating checksums, converting to phf and reflashing the unit via can diagnostics.

[JasonACT]

Unpack... Yeah, I've got that (see attachment, it's C code, and produces a full block of memory from 0 to "however long" with 0xFF as the padding) and yes, that would be the process. But I have not worked out the CRC algo (most probably a standard one, I think only the EEPROM checksums are Ford's own).

Best to use a hex editor that can be adjusted (I.E. not always show 16 bytes per line) when looking for splash images. From memory, the IPC images were 15 bytes wide, and with the hex editor set that way, you could see the ovals in the ASCII.

Edit: Hmmm, is that a single byte checksum - might really be a sum or subtraction algo.

[JasonACT]

[JasonACT]

Considerably better than...



(Oh, and the hexedit snapshot I posted is from the Mk1 low-series ICC firmware.)

[jakka351]

Originally Posted by JasonACT

image

ahhh I see it! thanks

[jakka351]

Originally Posted by JasonACT

Considerably better than...



(Oh, and the hexedit snapshot I posted is from the Mk1 low-series ICC firmware.)

Im working on software to edit the mk1 monochrome screen...going to call it FDIMtec. Will include functionality for multi-tune, (the radio station that is), launch control(full volume when you are at full throttle) and Boost by Gear(Turns volume up more as you progress through the gears.


The software will require you to purchase a sense of humour before you can use it though.

[jakka351]

Originally Posted by Whiteford

"What you are after though is a CAN recording of firmware 8R29-14D017-AC being loaded into a MK1 low-series FDIM by IDS... That's what I meant about re-inventing the wheel (since you need to upload the entire firmware, I would only be re-inventing the IDS firmware upload process - also, I don't think Forscan can do this, .PHF files are a bit different to the .VBS files Forscan handles)."

I think I know an ordinary bloke who can help with that.

IDS will do it, forscan cant. I will have to download the firmware and wait until a sunny day comes.along and I get to use the IDS.

[JasonACT]

I've made up my mind on the IPC Splash screen...



A bit busy tonight though... to load it into the bench cluster.

[jakka351]

Originally Posted by JasonACT

I've made up my mind on the IPC Splash screen...

image

A bit busy tonight though... to load it into the bench cluster.

For the OEM look

[JasonACT]

I can't believe how "late" I am...

[JasonACT]

I taught myself how to build new "FG2 ICC update files" thinking it might be useful (new apps for the peeps) and ran myself through a single package upgrade. Failed - Memory fault. WHAT?! So, it had got through checking, installing, verifying, reboot, verifying everything on the device (had a few issues there, since I've modified quite a bit on my test unit (and in-use unit!) - but I had that covered with a fixer program) and right at the point where it literally deleted all the symbolic links and tried to rebuild them - bang! Memory fault.



After a fair bit of debugging traces (option -vvvvc) I saw it recursively processing directories ending in /././././.

Subtle, I know, a couple of functions (shown here, which is the same on every device I have from 2012 to late 2014) have a bug. They process directories using a variable called symList, but attempt to exclude "." (current directory) and ".." (parent directory) using the variable name "symlist" (no capital L on List) so it gets stuck in a loop and crashes when it runs out of space for the directory name.

Sumitomo must have really hated Ford.

There must be a technical service bulletin for this! I fixed mine, and it completed ok.. There's an override directory where you can copy updated scripts.. but that's in the area which gets unmounted by this very script!! So, I copied a 1 line script there to run the real [fixed] script from where the new mount point is.

Sad though, all those failed updates by Ford dealers. And increasing the complexity for any new package, I make, to be installed - I'm inclined to just "move on".

[jakka351]

Originally Posted by JasonACT

I taught myself how to build new "FG2 ICC update files" thinking it might be useful (new apps for the peeps) and ran myself through a single package upgrade. Failed - Memory fault. WHAT?! So, it had got through checking, installing, verifying, reboot, verifying everything on the device (had a few issues there, since I've modified quite a bit on my test unit (and in-use unit!) - but I had that covered with a fixer program) and right at the point where it literally deleted all the symbolic links and tried to rebuild them - bang! Memory fault.

image

After a fair bit of debugging traces (option -vvvvc) I saw it recursively processing directories ending in /././././.

Subtle, I know, a couple of functions (shown here, which is the same on every device I have from 2012 to late 2014) have a bug. They process directories using a variable called symList, but attempt to exclude "." (current directory) and ".." (parent directory) using the variable name "symlist" (no capital L on List) so it gets stuck in a loop and crashes when it runs out of space for the directory name.

Sumitomo must have really hated Ford.

There must be a technical service bulletin for this! I fixed mine, and it completed ok.. There's an override directory where you can copy updated scripts.. but that's in the area which gets unmounted by this very script!! So, I copied a 1 line script there to run the real [fixed] script from where the new mount point is.

Sad though, all those failed updates by Ford dealers. And increasing the complexity for any new package, I make, to be installed - I'm inclined to just "move on".

Might be time to flash over it with something a little bit more user friendly. I am currently trying to load QNX in a virtual machine.


Also this may be useful to some: https://mfa.surdu.me/

[JasonACT]

*And Ford clearly hated Sumitomo.

Yeah, there's a Raspberry Pi version of QNX on github, along with other archives there too... But I've managed to "find" a treasure trove of tools elsewhere - USB network drivers for this device in particular, FTP daemon.. some good stuff. I've got 4 old USB dongles that work, but you just can't buy them anymore - so while I play with them, they are not all that useful anymore in general.

[jakka351]

Apps for the peeps

[JasonACT]

You do always have to keep in mind, this unit is half a Raspberry Pi Zero (not even a W wireless model) in terms of CPU power, AND also in terms of available RAM. It's basically worse off than the lowest model original Pi. It unfortunately can't do much more than it's already doing, but I do have a VNC remote desktop client working on it.

And I've made a custom USB WiFi adaptor for it:



Which also gives you root terminal access... and it all works, mostly due to a massive work around in what I think is a bug in the WiFi chip, which the manufacturer isn't admitting to.

Even though it works (with the work-around) I'm not promoting their product in any way until they supply more information on the issue - so I can be sure the work-around is totally safe. But it seems that may never happen.

This does let you run a super powerful Pi 4 in our cars, controlled from the touch screen.