FORD technical service bulletin : ICC touch screen display

[JasonACT]

It's what you know (see signals below).. and even better when it's who you know - but I know no-one when it comes to this QNX operating system, so slow progress...

Hardware->driver->/dev/ser5->gps->/dev/swsa/gps_nmea->sym_link->/dev/ser11->nav_iGo...

This is the OS configuration of our FG2 sat-nav ICC units, and I didn't give it a 2nd though why "gps" even existed before.

The main function of "gps" is to blindly scan through all "standard" BAUD rates and send a command to "set the chip to 115200 BAUD" where once done, it switches back to 115200 so it can listen to any reasonable messages coming though. They come about once a second. There's some other config messages sent by "gps" after that (I have not decoded them, so don't know what they are) but then it's just the current physical position data coming in - once a second - that's used by the nav software. Some binary messages are also removed, but that's specific to this chip only - u-blox.

Ok, so I might not even need a 9600 BAUD (which is the power-up initial setting) port to get this thing working. There's an acknowledgement sent when it understands and accepts the BAUD rate change, but it doesn't seem to bother reading that - it just sends the same command at all the standard BAUD rates.

Sooo... Last Friday, I thought I was ready to pull out my most up-to-date ICC from my car and install things, but decided to try it all on the bench first with my older unit. 4 days later...

The "nav_iGo" software requests a notify signal for when data is available from "gps" but it expects 256 bytes to be able to be read at the data-ready signal-time (by the notify request). the "gps" software (a Sumitomo special!!) triggers when even 1 byte is available - meaning the "nav" software can get trapped in an operating system kernel call waiting for the other 255 bytes to come from the serial port...

No big deal, when initially powered up, that eventually happens... Until the unit goes into super-low-power mode after 10 minutes of non-use and the serial port (and CPU and everything else) is turned off. Somehow they worked around this problem by detecting the power change in the driver, but my Gauges software doesn't pass that power change message along - so it gets stuck waiting for bytes from a disabled serial port. They don't come, at least until the unit it powered back up much later.

The "nav" software panics that it hasn't got its 256 bytes after 10 seconds (as it can't unblock to process the car's accessories-off signal) and the "watching guardians" kill the "gps-nav" thread. The "gps" data is never again read and you will see a message in the "nav" software that the gps device has been "switched off".

4 days later... I've put in a "Repeater" program to replace the sym-link from /dev/swsa/gps_nmea to /dev/ser11 which only signals back when 256 bytes are actually available and the damn thing now sleeps and wakes perfectly.

Next weekend..... Should be good. But these may be famous last words.

[JasonACT]

Getting ready for the weekend (well, unless something else comes up)...

This is my spare sat-nav unit, a "transmit" wire needs to be added on the port at pin 6, the connection at the ribbon cable needs to be cut with an exact-o hobby knife - see the little red circle:



A "receive" wire needs to be added on the 50 pin board-joiner plug:



For testing everything is still working, I just re-joined the two wires, but later on I'll be sending the tx wire into the rx of my microcontroller, and the tx of my mc into the rx wire on the 50 pin connector:



I've designed a simple 3D printed "case" (no lid though) which I printed in ABS plastic so it's heat resistant:



Double sided tape used to stick the boards in place (weak thin stuff for the boards with nothing on the bottom - strong foam stuff for the others). I'll stick some glue in on the corners of each board tonight too and let it dry. I'll use the strong double sided take to mount the whole thing above the ICC's FDIM (under the "hat") on the weekend (hopefully).



All wired up according to the previous circuit:



I have added a 4 port bi-directional level shifter (I'm only using 2 ports, and only in one direction each) to convert the serial line to 3.3v (from 5.0v in my microcontroller). I wasn't happy with the resistor voltage divider method previously used because there's a 5v pull-up on the RX pin... The Internet says these level shifters should be good though and they are only $4 each.

More testing to go though before the weekend...

I've also got a $14 GPS module for Arduino boards (almost the same model as this one) on order from ebay. I'll see if I can load the gps software onto a USB stick and get it running on a non-gps FDIM unit (I'll probably have to hack away the FM radio for traffic broadcasts part in the nav software, we will see).

[JasonACT]

Looks like I need to adjust the space used by the new gauges, but hey! It did boot up and start the gps & nav software without a hitch - all going through my new microcontroller's serial port with gauge injection data:



Nervous times.

[JasonACT]

I still have to tape this thing in place with double sided tape, but it's in and working:



This was just a drive around my suburb.

I could hardly see the red-dot for gforce, so I've made it bigger. I also had the x-axis back to front, so I multiplied it by -1 in the microcontroller firmware - as well as changing FACTOR from 4.5 to 2.25 (each circle is now 0.5G).

I also did a 5.21s 0-100 (the time gets plotted on the speed graph). There was lots of wheel spin though - I need new tyres.

It can stay like this for tonight - I'll clean it all up tomorrow.

(Oh, I forgot - I had to put in a 5 second delay on the gauges thread starting up, these newer units have a power-up spash screen and I was grabbing the wrong graphics surface - so the gauges didn't work at first. Wasn't hard to see from the boot log though, the spash screen was still showing when my gauges setup output came.)

[JasonACT]

Well, it's all back together now. In case anyone was wondering about how I wired it up:



Cover fits on ok, I think it touches the wires, but that suits me as it will stop them from falling out. I did it this way so any service I get done can have the module removed - as it will be requesting data every half second. I've marked the plug with a sharpie pen (lighter colour wire - white, which is just showing - goes into the H pin).

For 12v power, I just soldered a couple of wires on to a 6 pin Arduino header plug and used my previous "flappy paddle" mod connector. This is sort of neat, as it's easy to unplug all this stuff (can't think why I'd want to though). That is also the battery saver power, which turns off after 15 minutes. It's all been working pretty well too - turns on and off exactly when needed and the gps/nav stuff doesn't notice any problems.

I did have to remove my high-priority setting for drawing the gauges (to prevent flicker) because I noticed tiny breaks in the audio when playing mp3s off a USB stick. No big deal, it only seems to flicker when I change the volume. Most of the time that area of the screen doesn't get re-drawn so it's all good. I've attached another zip (just rename it). There's vague instructions on installing it on the nav units in there, and a couple of startup.sh files from my two units that I've already applied the changes to. Use the one that matches most closely what you have, I guess.

The gauges also display when you're in reverse and the camera turns on - I was wondering if that was going to work. I thought it might because they showed ok when I entered the nav software on the work-bench.

[ShmallAZ6]

Yucky

[JasonACT]

So, I've been contacted for more information about nav maps and I thought it would be good to put this information here:

FYI the OS is QNX 6.4.1

The only other way I can see to hack this unit is by sending in a magic CAN BUS signal, I don't know what it is because it comes from another micro-controller inside where I can't see the software, but I can see it is possible from the QNX update software on the unit, that it can be signalled to run a particular script from the USB stick. It won't help, but this is the file that's run /fs/usb0/image-usb-recore/recore.sh

These are basic instructions or locations for more info...

Removing the ICC from the car:
https://www.aslautomedia.com.au/asse...0PROCEDURE.pdf

Disassembling the screen and adding serial port wires:
https://www.fordforums.com.au/showpo...&postcount=269

Ordering a USB serial adaptor:
https://www.ebay.com.au/itm/USB-to-T...i/201313271004
Please make sure you configure it for 3.3v usage!

Backup the unit's software to a USB stick:
mount -uw /dev/hd0
mount -uw /fs/usb0
cd /fs/usb0
cp -LR /etfsroot .
cp -LR /packages .
cp -LR /proc .

From there you will need to take a copy of the files that need replacing and update them, then copy them back - make sure you keep all the original files as a backup. "cp -f ..." may need to be used on exes to "force" the replacement of a running program.

Hack the exe (for more details on what file, see the next link too):
https://www.fordforums.com.au/showpo...&postcount=308

For the nav map files, I built a new "../MobileNavigator" folder. Make a copy of the old one somewhere and replace files with whatever files you have that are newer, I made sure the newer ones were renamed to what was already there - but I don't think it matters.

Copy the maps over, while keeping one backup - is described here:
https://www.fordforums.com.au/showpo...&postcount=245

[JasonACT]

It should have said:

cp -LR /etfsRoot .

Since unix is case sensitive. I also forgot to add the openscad file for generating 3D printer .stl files. Rename the .txt file to box.scad

[JasonACT]

THIS IS NOT A NAV UNIT!!!

This is in fact the Terry unit I fixed, dual zone, no bluetooth, and no sat-nav.

The gps module came today. I sent in the data that my good nav units do to configure the device and it seemed quite happy. The little antenna though doesn't like indoors, takes ages to get a lock. Much faster outside...

Seems these units have a default gps location when installed:



Plug in the gps unit (well, its output - I'm actually configuring it here with my mc the same way the gps program does on the real nav units, as I never did solder in the transmit pin on /dev/ser5 on this FDIM unit - didn't have a need for it until now)...

While I wait for the gps to get a lock, I'll plot a path for my car from Ford to my home (you don't get to see my address, if you turn up, it'll be death by razor blades...)



Oh, ok, it can get a lock indoors!



I just put all the MobileNavigator software on my usb stick, changed to that directory and ran these commands from that directory:

cd /fs/usb0/MobileNavigator
devc-sermx1 -u4 -F -b115200 -c66500000 0x43fb4000,47 &
Gauges.ino.elf &
gps -MIsC2 -b115200 &
Repeater.ino.elf &
igo_starter &
navi_2_hmi_connector &

NO-ONE GET EXCITED THOUGH!!! The USB turns off when these screens go to sleep and I have no idea what will happen in 10 minutes when that happens. This is just a test. Good fun though for $13.85

[raceteam]

Is that just a generic GPS receiver that outputs a location via serial and the software picks that up? If so, could you install some opensource software with updateable maps instead?

[JasonACT]

Yes and no, this is a u-blox neo-6m unit, the real sat-nav FDIMs are u-blox lea-6r but the only difference I could see is the lea-6 is a lower power unit. The iGo software understands heaps of formats, apparently, from looking at the exe. But yes, these devices use a simple 2 wire serial port. I could write a new "gps" program to use a different device (the current one configures u-blox ones only) but these are dirt cheap and readily available - so not worth the effort in my mind.

The trick in getting something else (open source) working on these units is the navi_2_hmi_connector program, as that's the thing that allows the navi software to take over the screen and get touch points back... I have no idea how it works, so it would be difficult to make other software work with it.

That's the main reason my gauges are using a part of the screen (the two bottom corners) that isn't used by anything else. That, and every QNX program I write ends up with me re-creating more and more of the QNX library - I doubt the QNX graphics lib I've already got working would be compatible in any way with open source nav software. So lots of work.

[JasonACT]

I got the soldering iron out again this week... These are the places to solder to if you want to "play" with a GPS device:



How they plug in:



WARNING! Vaguely tested - may cause much grief!

How to install navigation software on a USB stick for use on a mid level FG MKII FDIM: (requires debug port access on two units)

Gather the software from a donor FGII nav unit (you didn't think this would be easy, did you?!). Also take a copy of your existing /packages/factory/manifest.packages file. Merge the content folders from the donor units navi and navi_maps packages, copy over the license folder too. These should all go into a directory called root/usr/navngo/MobileNavigator on the USB stick matching the same directory structure as the units. Create a navi folder on the stick too, put a copy of the /packages/factory/navi/info and /packages/factory/navi/scripts folders in that - so you have navi/info & navi/scripts on the USB stick.

Add the navi entry to the end of your existing /packages/factory/manifest.packages file: (put it on the USB stick to edit and "cp" back it into place later):

<file content>
applications 336692
...
swsa_binaries_and_libraries 330391
navi 342767
<end file content>

The last line is what needs to be added to your existing manifest file. It's important not to use the nav unit's file because if you are missing anything listed then your unit will not fire up correctly.

These are the /packages/factory/navi/root/usr/navngo/MobileNavigator/sys.txt changes needed (navi start settings). These changes are mostly to fix up the missing tmc device, but also I send the save data into a RAMDISK (this means a power interruption will wipe your settings, but also, we won't fill up what precious little space is available in the flash memory on these small "mid" FDIM units = 128MB).

Newer (2014) units have a segments setting which I would turn off (=0), and I added the no_tmc=1 debug setting too - but this isn't the important area to change:

[debug]
enable_tmc_segments=0
no_tmc=1

Folder section for where to save data:

[folders]
;data="/fs/etfs/packages/persist/NNG_save" <--- This is the original save path
;data="/fs/ram/NNG_save" <--- you will see this in the existing file, I don't think it can be used as ram isn't a file system on the device.
data="/fs/tmpfs/NNG_save"

Add this tmc section to stop the traffic radio from being used, without these settings, when the unit goes to sleep it will timeout trying to shut down the missing radio, effectively crashing the software and it will need a restart:

[tmc]
show_tmc=0
init_on_startup=0
reinit_on_hardware_lost=0
ignore_suspend=1
ignore_resume=1
override_saved_config=1

I think it's important not to use the flash memory space because that will limit the system's ability to relocate bad-blocks of data in the left over block pool. In fact, I have removed two themes (replaced them with a symbolic link to "borderless" which is my choice of themes to keep) to free up 42MB of space for R&D and bad blocks.

Create the navi directory on the unit with just the info & scripts folders copied over (previously put on the USB stick):

cd /packages/factory
cp -LR /fs/usb0/navi .

Create a symbolic link for the navi "root" directory, pointing it to the USB stick:

cd /packages/factory/navi
ln -s /fs/usb0/root root

Create the required sym links that the unit needs to run packages:

cd /etfsRoot/bin
ln -s /packages/factory/navi/root/bin/gps gps
ln -s /packages/factory/navi/root/bin/navi_2_hmi_connector navi_2_hmi_connector

cd /etfsRoot/info
ln -s /packages/factory/navi/info navi

cd /etfsRoot/scripts
ln -s /packages/factory/navi/scripts navi

cd /etfsRoot/usr
ln -s /packages/factory/navi/root/usr/navngo navngo

As a last step, as, if this is wrong your unit will complain and stop very early on in a boot.. use these commands copy the manifest and keep a backup!:

cd /packages/factory
mv manifest.packages manifest.packages_o
cp /fs/usb0/manifest.packages .

Restart the unit with the USB stick inserted (if it isn't inserted, it will revert a normal mid level FDIM until it's rebooted again). You can unplug the USB stick, the navi software will pause until it can re-open the files, though to be safe I'd only do it while the nav software isn't showing. If you update the maps which are now stored on the USB stick, make sure you reset the unit (whatever method you prefer - battery disconnect, Forscan, or my favorite: the debug port "shutdown" command). I've also used both the older and newer navi software that I have on an older unit and both worked the same. I.E. no aparent incompatibilities.

You can clean up the USB stick so it only has a "root" directory now. Maybe copy some mp3s onto it (though the more there are, the slower it'll take to boot because of competing accesses).

[JasonACT]

A couple of things...

Should anyone follow me on the Gauges path, post a note here and I'll update the thread with new QNX programs (I've made a few changes, mostly around the grey lines for speed, since they are really hard to see in sunlight - and I'll probably make some more, maybe bug fixes should I find them). Posting them as I go though is just noise on this thread.

With my "repaired" unit, and having freed up a lot of flash memory space, I'm now seeing (I think) how the units operate. I think they record flash block read problems somewhere, but nothing is done at the time they occur. When I reboot the unit however, I see it "Validating duplicate sequence" messages (see page 8 on this thread) when it first starts (mounts the flash memory device). You never see these again, and I now suspect that it is validating the duplication of bad blocks into new blocks... In the simplest of terms, that can most easily occur when the file-system isn't yet mounted, though I question the overall robustness.

What I make of this is, if you never disconnect the battery (or do a proper shutdown using Forscan etc.), the unit will not get a chance to fix what it knows is going bad. One day a reboot may occur (from a jumpstart or just letting the battery drain) and it'll be totally borked.

Someone said, they often disconnect the battery / jumpstart - I can't remember... But it may well be the case that doing these things often gives the unit a chance to repair itself before it gets too bad.

I can only say, the massive amount of messages from this bad unit (and the fact that my good units have really gotten better over time, while I test them) makes me think this is how they operate.

[JasonACT]

I wanted to get a photo of the GPS board flashing its LED when it has a position locked...



Yeah, I've used the super strong double sided tape (thanks Linz & George) to stick it into place.

This is still the "repaired" Terry unit from 07/05/2013 - however, it has had some changes made (still missing a bluetooth chip, damn it)... It is now running the 2014 packages, which I was able to do because I've freed up a lot of extra space so I could do it bit-by-bit without too much risk.

There are quite a few symbolic links needed for extra things going on in the newer firmware:

// Navi changes that were not documented before...
cd /etfsRoot/etc
ln -s /packages/factory/navi/root/etc/navi navi

WARNING: Don't use the update menu inside the sat-nav software - it will crash the unit - I'm not sure why yet, but this was missing which was a candidate for what was wrong - but it didn't fix that.

// New package links

cd /etfsRoot/bin
ln -s /packages/factory/swsa_binaries_and_libraries/root/bin/seperate seperate
ln -s /packages/factory/swsa_binaries_and_libraries/root/bin/hmiEvent hmiEvent
ln -s /packages/factory/graphics/root/bin/exhibit exhibit
ln -s /packages/factory/applications/root/bin/fpv_gauges fpv_gauges

cd /etfsRoot/lib
ln -s /packages/factory/media_player/root/lib/libandroid.so libandroid.so

cd /etfsRoot/usr/bin
ln -s /packages/factory/swsa_binaries_and_libraries/root/usr/bin/dynamic_update_symlink.sh dynamic_update_symlink.sh
ln -s /packages/factory/swsa_binaries_and_libraries/root/usr/bin/dynamic_update_process.sh dynamic_update_process.sh
ln -s /packages/factory/swsa_binaries_and_libraries/root/usr/bin/dynamic_update_identify.sh dynamic_update_identify.sh
ln -s /packages/factory/swsa_binaries_and_libraries/root/usr/bin/dynamic_update_hmi.sh dynamic_update_hmi.sh

/// Moved: date -> /packages/factory/qnx_binaries_and_libraries/root/usr/bin/date
/// (it's now in /boot/proc -> need to copy it back to qnx.. as proc is the read-only partition)

/// Moved: gf-calib -> /packages/factory/qnx_binaries_and_libraries/root/usr/bin/gf-calib
/// (it's now in /packages/factory/graphics/root/usr/bin)
rm gf-calib
ln -s /packages/factory/graphics/root/usr/bin/gf-calib gf-calib

cd /packages/system/trailer
ln -s /packages/factory/swsa_binaries_and_libraries/root/usr/bin/dynamic_update_hmi.sh dynamic_update_hmi.sh

So, yeah, it's now really up to date and acting like my newest unit, except...

ERROR vehicle_se[ 2]receive_ipc_message vehicleSettingsIpcHa@327 : Incorrect message length 32, expected 3

That happens every couple of seconds...

ERROR diagnostic[ 1]NotificationHandler listManagerClient.c@606 : Failed writing list to HMI. Error returned (1)'Operation not permitted'

And that happens once on start-up.

I've reverted back to the original "vehicle_settings" and "diagnostics" executables (copied them into the newer packages) and it's now booting without any error messages. Not sure what's going on here, but I didn't re-write the read-only boot partition(s) as this has a real risk of bricking the unit. That may contain differences that will fix these two issues, but for now it can remain this way.

So, things to note... "libandroid.so" is new! "fpv_gauges" is now installed and running. dynamic_update... is also new - which runs every-time the ignition key switch changes. Seems these newer units are designed to update from the USB stick more easily... There might be an exploit here.

But for now, fpv_gauges is going to be my focus. My understanding is, while the Home screen is showing, the Home button says "FPV" which takes you to the FPV gauges. Inside the menus or nav-software, the Home button says "Home". I ask myself, how hard could it possibly be to hack this program into doing that on a non-FPV car? (Maybe months!)

[JasonACT]

This arrived this afternoon (I intend to use it for my original FDIM out of my car):



The u-blox chip looks a bit different to the other one (I wonder which one is a Chinese clone?!):



Both work though, and the new one has a USB port which configures a COM port on a PC so you can use it that way too.

$14.99 on eBay (the other guy ran out of stock).

[JasonACT]

No luck getting FPV Gauges working. The fpv_gauges program starts by sending a command to the smaller CPU to configure the times to request readings for each dial.. CAN BUS stuff.. Then it expects the values to come in repeatedly at those intervals. All it does it decode the data coming in and passes it to the HMI program (which apparently handles graphics and buttons). I was successful in faking the g-force data, and that has V1 and V2 formats (V1 only does g-force, V2 does all the gauges). I had thought having that one would enable things - but no. I even spammed the HMI data ports to try to get it working (and found a few interesting things as I went - like the firmware update screen, the navi overlay screen, bluetooth update screen among others).

In between having inspiration and being stuck, I worked on the touch screen. Damn thing took all week to work out. You need to read packets from the handle in multiples of 24 bytes otherwise you get nothing! Once I worked that out (this morning - after trying many other things all week) it was easily sorted.

I also worked out how to force a screen-refresh. That spam I had sent in really worked out. This was something I had wanted for a while - my "gauges" stop updating when the ignition is off and also stop painting.. They are meant to disappear at that point, but were just left hanging around. Not anymore.

Using the new touch screen press logic, I now allow each side of the "gauges" to be toggled on and off by pressing their location. Speed/G-force & Temps/Volts/Boost. You can also press them with ignition off now, which temporarily shows them (the one just pressed always and the other one if it isn't disabled) for a second to two. It only shows the last known values though, until ignition is turned on again.

Pretty happy with it all though.

[XD 351 Ute]

Originally Posted by JasonACT

Someone said, they often disconnect the battery / jumpstart - I can't remember...

Hi Jason, It may have been my jumpstarting/flat battery comment.
I haven't had it happen to me yet, (touch wood) but I have heard about people jumpstarting or replacing flat batteries; and then finding their ICC not firing up.

Apparently it's mostly with FGII's, so that's why I bought a memory minder.

Ed

[MustangNicko]

Hi JasonACT

Have you by any chance worked out why the screens go black in FG II's when you disconnect/change the battery? This thread is way too technical and has gone over my head

[JasonACT]

These devices (a small computer) rarely ever re-boot.. A lot of the software on them is loaded into RAM (which is very stable) where it runs for years. That is, until you spike the power (jump-start) or disconnect/reconnect the battery. The Flash memory chip itself (where all the files are loaded from, at boot time) has a 10 year "estimated life" but it goes bad in the heat much quicker. Bad files do get corrected by special software and extra bits on the chips, but if they get too bad, even that fails and the units can fail to boot properly - which means "blank screen" / "lines down the screen" / "stuck on the boot splash screen". Depends on which files and how far into the boot cycle it gets before it stops.

Image files are often reloaded as they are not kept in RAM all the time - so sometimes you can see corruptions in images on these screens without rebooting.

[MustangNicko]

Originally Posted by JasonACT

These devices (a small computer) rarely ever re-boot.. A lot of the software on them is loaded into RAM (which is very stable) where it runs for years. That is, until you spike the power (jump-start) or disconnect/reconnect the battery. The Flash memory chip itself (where all the files are loaded from, at boot time) has a 10 year "estimated life" but it goes bad in the heat much quicker. Bad files do get corrected by special software and extra bits on the chips, but if they get too bad, even that fails and the units can fail to boot properly - which means "blank screen" / "lines down the screen" / "stuck on the boot splash screen". Depends on which files and how far into the boot cycle it gets before it stops.

Image files are often reloaded as they are not kept in RAM all the time - so sometimes you can see corruptions in images on these screens without rebooting.

So the unit needs an update/reset?

Would have thought storing essential data into ram would be a bad idea given how volatile electrical systems are in cars.

[raceteam]

The info has to be stored in RAM; that's how a computer works. Think of it as the hard drive crashing in your computer. If the hard drive crashed while the computer was running, it may keep going again for a while. Disconnecting the battery does a reboot, and it can't start up again.

[MustangNicko]

Originally Posted by raceteam

The info has to be stored in RAM; that's how a computer works. Think of it as the hard drive crashing in your computer. If the hard drive crashed while the computer was running, it may keep going again for a while. Disconnecting the battery does a reboot, and it can't start up again.

RAM can only be written onto when power is gained and it is wiped when power is lost. Your computer OS isn't stored into ram, its on a hard drive. Data only gets written into ram to make caching faster. Why they would choose ram as primary storage in these units is beyond me.

*edited

[raceteam]

Originally Posted by MustangNicko

RAM can only be written onto when power is gained and it is wiped when power is lost.

Yes.

Originally Posted by MustangNicko

Your computer OS isn't stored into ram, its on a hard drive.

Or some similar storage like an SSD.

Originally Posted by MustangNicko

Data only gets written into ram to make caching faster.

No. It's the working memory of the device.

Originally Posted by MustangNicko

Why they would choose ram as primary storage in these units is beyond me.

*edited

They didn't.

[MustangNicko]

Originally Posted by raceteam

Yes.

Or some similar storage like an SSD.


No. It's the working memory of the device.


They didn't.

Okay I had to read Jason's post again haha It's the flash chips that get corrupted. Would like to hear how many have been fixed via software vs buggered hardware.

Sorry it's been a long day

Originally Posted by Fiji

Last week I disconnected the battery on my sx territory.

I connected it back up within 5 mins.

No screen on my ICC.

I was furious as car is as new with 60000km always services at ford.. but out of warranty.

I contacted ford, they acted like they wanted to help me. Took it into dealer for a check and they took serial number. Sinclair ford at kingswood. / Penrith. The service guy tells me it's a **** unit and they have replaced plenty. They know exactly why they fail..

Then I get email saying they won't cover it, car too old.

So for a disconnection of battery I'm out $1500-2000?

If I replace the unit how do I know the same problem will not return. It's just a defective unit and ford don't want to come clean.

One way to fix em... Don't buy another ford ..

Wonder how many cases have been taken up with Ford HQ?

[raceteam]

SX is a completely different unit to SZ so won't be the issue from this thread. Car must be 15 years old, just grab a 2nd hand ICC from a wrecker. There will be some config to pair it to the car but fairly easy with Forscan.

[JasonACT]

Car had 4 fat people in it :(

[JasonACT]

What is it that I have, that most others don't?
Patience? Nope...
Persistence? No, that's not it...
Tenacity? No, not that either...
FPV Gauges? Oh yeah...

Fake Sat-Nav unit:


Home button goneski


Default - Manual (not auto trans)


Next port along set to 1 (car has an auto)


Bite me Sumitomo & Ford!

[roboy07]

I'm so jelly that you (@JasonACT) can do all of these modifications. I wish there was an app or something easier that the rest of us can use to allow us to have what you have. I mean no disrespect to the hard work and days/weeks and maybe even months you are putting in, but maybe one day, if it's even possible, you could create a program that can be installed onto these units that I'm sure we would be happy to pay for. Just a thought ��

[JasonACT]

Yeah, it's like a big tease, isn't it. I don't mean it to be that way, but it is Ford (and Sumitomo's) fault it's so difficult with these units. I did try and enable the FPV Gauges in my car before I started working out the values I'd need to plug in to make everything work. Only 1 gauge works "out of the box" which is Voltage. All the other ones go to max when the ignition is on, or zero when it's off. G-Force does nothing.. but that's to be expected on a standard car.

Having seen what's happening, I knew I'd have to stop the real "fpv_gauges" program from running (otherwise it would interfere with my attempts). I quickly worked out the values needed (I had already gathered the ports from the fpv_gauges program - and now the gauges are displaying, it was easy to just plug in values until I understood them).

I say quickly, but I think I was having too much fun - I looked at the clock and it was 7pm! That's quite a few hours.

But the new software (after some testing on the bench) is now loaded in my car:





So, when the FPV Gauges are displaying, my little ones are disabled. Mine can be hidden too so they can be set to never display (I did that when I got touch events working). I think a real FPV only shows one of the two screens - as I couldn't work out how to flip that port's bit any other way... But, since I have touch screen events - I've coded it to toggle when I press the TRANS/VOLTAGE gauge. So I think that's better than a real FPV.

I took it for a quick spin around the block, boost and gforce is working the same as they do in my gauges - except very nice big numbers show now.

For the record, I think the FPV cluster (which shows some of these gauges too) is what's used to get the required messages from the high-speed CAN BUS to the mid-speed one. So without that, there's no chance to get this working without building something like the little microcontroller I've described here. So no software only solution, sorry.

[JasonACT]

I did also find some of the other HMI program's (Human Machine Interface) ports that were of interest to me...



Subtle, but this is how my screen should look above the buttons.

Yes, there's a port to turn off the dual zone output, and a port to turn on the single zone output. The buttons are controlled by the smaller microcontroller (they call it the V850 in the startup scripts)... So, I still need to use the middle fan controls, and the left "passenger" temperature rocker button does nothing still... But at least things are in the right place (for me) on the screen now!

The "Gauges.ino.elf" program now accepts a parameter of "1" or "2" to override the number of zones displayed.

(Yes, I've got the extra servo needed for a dual zone conversion, along with Forscan to reprogram the HIM, but I chickened out of pulling out the whole dash to install it... One day though.)