FORD technical service bulletin : ICC touch screen display

[raceteam]

Would have thought that data would already be on the CANBUS, although is the FDIM only on MS-CAN, and the required data on HS-CAN?

[JasonACT]

It depends on what I'm going to pick to display. Yes, the FDIM is only on the MS-CAN, but to complicate things - how would my new FDIM program read the CAN messages from the smaller board? I know the large board has the CAN transceiver, but it just passes those messages to the small board. The small board communicates back to the large board through a serial port (3). I've got no way to get that data (some other QNX process has that serial port open). I have no way to tell which messages the small board thinks it needs to pass back, many I may be interested in may not be passed...

In two words: It's complicated. (Ok, that's sort of 3 words.)

I know everything I would want to display is on HS-CAN. That's why I need to see if there's serial port 4 access somewhere before I even start... Meaning writing a "Hello World" program if I can get /dev/ser4 set up.

It's not going to happen quickly. But that's ok, this is just a bit of a hobby for me. I hope I get the sat-nav maps before I return to work next week though

[JasonACT]

Surprising news.. I had pulled the broken screen apart to do my final check (of many, many other checks) before putting it away forever - which is why I was able to document exactly how to disassemble them.

One of my earlier hacks on the USB traces (the D+ or D- line, not sure which + or - one) was shorted to ground, I don't know how I missed this - but I used the solder sucker to clean it up and USB is now working on the broken board. That's the USB3340 chip that replaced the USB83340 chip.

I've got USB access back! I've replaced the bad file, and bad programs before now correctly load - but there's more corruptions - I can tell the one file hasn't fixed everything.

But I can now save off the entire filesystem and compare everything on my PC instead of being boxed in! Then replace files if I find them (tomorrow). Shame about the BT chip, but you have to break eggs sometimes

[JasonACT]

Windiff has made light work of comparing directories (mine and the broken Territory's) which are a few of months apart, many exe files have text in them that say compiled on this date - and they are 6 weeks apart. Most have no other changes.

Most of the graphics files (3000 odd) are identical - but there's around 100 that are different - that's pretty serious I think because those should be the same. This unit also had more ECC reports while backing it up than I've seen before. Maybe it was always parked in the sun?

The hmi application is also different (and media-player too) and others. The hmi one has a byte here and there different - so I'm fairly confident in saying those are corruptions.

In total 330 files are different (but as I say, some exes just have a different timestamp). But it's going to take some time to go through them - if only I had an original backup to use instead

[JasonACT]

Wow, these three packages are the only ones that should be different:



There's so much wrong with this broken unit!

[JasonACT]

She's alive!



A bit of a novelty that this unit has dual zone climate, but no sat-nav:

[Citroënbender]

Brilliant work!

[JasonACT]

I worked out how to start the /dev/ser4 driver, but it crashed as soon as I did anything with it. Wondering if I had done something wrong, I tried /dev/ser5 on the non-sat-nav unit and it worked. I sent a large file to serial 5 and I found the pins on the small board that carry the signals to the non-present GPS unit.

Reading the manual, I noticed that UART4 & USB-OTG (which is what this ICC uses for USB) have a conflict on the iMX31 chip.

This is from the Windows CE 6.0 pdf for the iMX31 chip:

24.3.1 Conflicts with Other Peripherals
UART1 and UART2 do not have conflicts with any other module and are configured in functional mode.
UART3 has conflicts with SOCI1 and SOCI3 modules and must be configured in alternate mode 1.
UART4 has conflicts with ATA and USB OTG modules and must be configured in alternate mode 1.
UART5 has conflicts with PCMCIA and USB modules and must be configured in alternate mode 2.
Table 24-2 shows pins to be configured for serial driver for different UARTs.

So that's why they skipped 4 and went to 5 for the GPS. Back to the drawing board

[happy1]

Hi,
Amazing what you have learnt and achieved by all your hard work on this unit!

I was looking through my old IDS software to see if I could find any files for the ICC or FDIM, but looks like my IDS is too old. (V.86), or the files for the FDIM are kept separately and not via the IDS at all?

I searched all post for 'FDIM' and looked at some old posts on here, and in 2012 there were guys discussing software version for the FDIM: One guy wrote:
'Mine is 9.4.7.255063 dated Aug 29 2012'
Another guy wrote: 'I just checked mine and its version 9.4.0.203539 Aug 23 2011. so mine is way out of date'
Then somebody wrote:
'smellyfish in the Territory Sat Nav update thread has a GPS with software version: May 22 2013 9.4.7.301704 (http://www.fordforums.com.au/showpos...9&postcount=64)
So, all the software versions that I've seen posted on here so far for FG2/SZ GPS:
* Aug 23 2011 9.4.0.203539, Australia 18 Maps (26/01/2011)
* Apr 16 2012 9.4.7.230356, Australia 18 Maps (26/01/2011)
* Aug 29 2012 9.4.7.255063, Australia 19 Maps (10/01/2012) - the ICC firmware that seems to be paired with this version has 2 extra themes and a few extra menu items, e.g. QWERTY/ABC keyboard pref.
* May 22 2013 9.4.7.301704, Australia 20 Maps (21/06/2013)'
Someone responded:
'My current software which appears to be the latest on Ford's web page is,

https://www.ford.whereis.com.au/default.asp

https://www.ford.whereis.com.au/shop...asp?search=yes

Then someone wrote:
'Jun 4 2014 9.4.7.402188 - the ICC firmware that seems to be paired with this GPS software version has an extra menu called "Information", that shows some numbers (maybe a software or hardware version number) for Bluetooth (guessing easier access for service technicians diagnosing bluetooth problems)'

So it looks like there has been 5 different software updates.
If you had any of these update files, would that help in rebuilding the corrupted files?

Cheers,

[JasonACT]

Those version numbers are the sat-nav software which is just one package, with the maps and speech it makes 3 packages in addition to the ones I listed above in the white, yellow & red picture.

The actual firmware has different numbers you can only see by looking in the packages/system folder on the unit. The dates I get are from when it was installed on the units (the now-fixed unit has the same firmware as my spare sat-nav ICC, except it misses out on the 3 sat-nav packages as it doesn't have the hardware or space on the smaller flash chip):

H 3.0.255197 - 31/08/2012 (my original)
J 3.1.273483 - 16/11/2012 (spare sat-nav), 6/12/2012 (fixed terry)
N 3.4.354825 - 17/12/2014 (the sat-nav now in my car)

After taking the screen shot of WinDiff (the red & yellow differences picture) I realised all my units had different versions. That's how I was able to get the broken unit fixed so quickly. There were 197 graphics files, 1 library file, 2 exes (hmi & media-player), 1 bluetooth firmware update file (for the chip I think) and the core.ifs file that can be used to rebuild the boot partition (which needs 3 copies installed) all corrupt... All 3 copies in the boot partition were actually good, but if someone had attempted to use the core.ifs file - bye bye unit forever most probably.

Given the graphics files takes up the most space - on average, you would expect corruptions to happen on these files.

With so many files corrupt, this most probably wasn't because of the jump-start.. That probably just initiated a reboot and it became apparent the unit was now broken because the files wouldn't all load. Before that time, they had all been loaded into RAM where they may have been for years without showing any trouble.

You can see, there's a couple of firmware versions I'm missing (K, L & M - though the numbers don't add up 3.2 & 3.3 may be what I don't have, who knows how SWSA decided on version numbers).

Personally, given Ford has orphaned us, my thoughts are that these should be up for publishing on the Internet. I think there's precedent for that, you could take it to the courts and most probably win, but it's just as easy to ask Ford in an open letter... It makes it hard for them to deny the request.

I do think it's very risky to attempt to update an old firmware to the new firmware, so the more versions we have access to the better.

I'm still waiting for the sat-nav maps to arrive (Aus-Post has only just started delivering in Canberra again today) and the tracking number I've got doesn't even mention if the plane has landed here yet.

Since I couldn't really go outdoors in the last few days, I've been creating an Arduino microcontroller profile for "Sumitomo QNX - i.MX31" so I can build new exe's for this unit. Yesterday I got the Hello-World program working:

#HelloWorld.ino.elf test1 test2

Hello, World! 1
Parm0=HelloWorld.ino.elf
Parm1=test1
Parm2=test2
Env0=_=HelloWorld.ino.elf
Env1=PATH=:/packages/system/override:/bin:/usr/bin:/usr/sbin:/sbin:/proc/boot
Env2=apsCansole=on -X aps=Debug
Env3=apsIPC=on -X aps=Debug
Env4=boardVariant=mid
Env5=LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/lib/dll/font:/lib/dll/mmedia
Env6=apsDebug=on -X aps=Debug
Env7=HOME=/
Env8=ETFS_FILES=32768
Env9=boardVersion=3.50
Env10=TERM=qansi-m
Env11=ETFS_RAWSZ=16384
Env12=useAPS=small
Env13=SYSNAME=nto

I've rebuilt all the dlls (.so files) so I can link against them on my PC (they were stripped of symbols) and I'm now reconstructing the graphics include file based on the QNX advanced graphics documentation.. That's a slower job, with lots of guessing, but I'm hoping I'll only need a handful of the available functions to be able to create some nifty programs for my unit.

[raceteam]

With the FDIM you fixed, did you just copy the corrupt files over from a working FDIM with the same firmware?

[JasonACT]

Yes, that's exactly what I did. Mind you, the media-player is the same package on both early firmwares - so the fixed FDIM now rocks the modified 10,000 playlist version instead of the 1,000 original.

Edit: To be honest, there were so many graphics files that were bad, I just copied the whole parent folder (HighSeries/*) in one go - to save my sanity. For the exe's, some were running and I have to "rm -f" (force delete) the files first.. Only a couple though.

Even though there were corruptions, I don't think the flash blocks are "bad" - they have just lost the data, but are reusable with a refresh, but that's just a bit of a guess.

[raceteam]

Given that, would copying the file system from one with newer firmware instead upgrade the firmware?

[JasonACT]

It's a tough question to answer, and is why I have not tried. I've read a few of the upgrade scripts, I put the "scary" comment in one of my posts above. The thing is, the kernel (in the boot partition) has been changed between 2012 and 2014. I know this because I get better debugging output from the 2014 one - and I can see the core.ifs is a fair bit larger.

Now, you don't want to upgrade the kernel without the new packages. You don't want to upgrade the packages without the new kernel. The whole thing needs to be done together or you may brick the unit. The SWSA guy gets around "problems" by using the ramdisk to copy everything he knows he will need there - so it's available when he switches off the filesystem to rebuild it.

Another complication is, the debug port (serial 1, which I'm using) becomes unresponsive until something else outputs data on the terminal (like switching the accessories off and on - my hack for getting commands to run while in the car). So you don't want to be in a situation where nothing else is running because you've cleared the filesystem - and you no longer have the ability to get your commands to run!

If you were going to do this, you need to build a script, and test it thoroughly - meaning on a development board where you can recover. I don't have a dev board, and I'd really like to keep my 4 units working (the fixed unit will never go back in a car - but it's great to have a board to fool around with for new programs I may write).

So sure, it's possible to upgrade the firmware - the hardware has no differences that will stop you... Nerves of steel will be required though.

I'd be more inclined to just update the parts of packages I'm interested in like the sat-nav exe. I've hacked both, but I don't see any problem with bricking the unit by trying the new one (with all its zip files etc.) on the old unit. The deep-down stuff though (hmi, qnx libs & swsa libs) I would leave alone.

[JasonACT]

Sooo, I've got my basic C HelloWorld program calling the graphics routines and showing a black screen (because I've not drawn anything on it) then it waits 5 seconds and ends. I think the trick though is going to be saving the state the screen was in, so I can restore it once I'm done (go back to the main screen / menus / whatever):



(^^^- Look ma! No bluetooth chip!)

I had to press the touch-menu-buttons to get this to show, it was left on a black screen until the real FDIM software wanted to change the display. (Yes, the screen is upside down.)

[JasonACT]

The QNX example rectangle code has been added to my C program:



I'm actually pretty happy seeing that!

[raceteam]

So just a couple more lines of code until you've got Apple Carplay / Android Auto working then?

[JasonACT]

Decent media-player: tick
Decent navigation: tick
FPV gauges: lots of progress

Weren't those the three things I rated for the ICC? I don't even have data on my 8 year old Andriod!

This is the QNX guide I'm following: (I'm in the "basic drawing" section at the moment - they forgot though to tell me to call gf_layer_update (layer, 0); to apply set-surface changes (took a bit of effort to work that out).

http://www.qnx.com/developers/docs/6.../gf/dev_guide/

But seriously, having those two extra features would be good, raceteam - I'm not likely to do it, but once I'm happy with the Arduino stuff to build exes for this FDIM I'll probably release it. Unfortunately, Arduino has no concept of dynamic libraries (everything is static, as there's no OS) so I have to edit the config to arrange which dynamic libs are included. I could add them all (and it would work - since they are all available) but it would make every exe built load every dll - wasting memory on the FDIM. Details details.

Someone might work out how to do it though, with the hand up from these instructions

[happy1]

There is a PID-list in the FGII WSM for parameters that can be logged via the CAN network from the ICC, and there is a DTC-list too for all the error codes that can go wrong with the FDIM / ICC and be reported via the CAN.
Have you got this particular WSM section? Not sure if it is relevant for you?
It also describes 7 different test graphics that the IDS can call up, but I guess that's more to diagnose the display itself, and not related to the stuff you're developing now.

Another thing, I have a complete MKII ICC, touch screen, (non-sat nav) that I have sitting on my shelf. I could pay for postage and lend you that FDIM for a while if you wanted to investigate another unit. I believe it is one of the earlier versions, not updated after 2012ish.

Cheers,

[crumpet]

This has been an awesome thread to read through, great work.

I came across it as my ICC has failed, starting out with the iPod not being detected plus menu text through sub menus combining on the screen (i.e. old text not being removed), then when I did the fuse pull trick to reset it, the screen now just stays black. I was trying to figure out what the heck had happened since it’s usually been a battery replacement that’s done it to others.

What you’ve found re corruption in the flash memory goes a long way to explaining what happened (if I’ve understood correctly!) as it would mean the OS on flash was basically cactus prior to the fuse pull. It might also mean Ford can reflash it for me.

Really appreciate the work you have put in here.

[mungus]

I have read this thread all the way through and thank you and congratulations JasonACT for all the work you did in getting your faulty ICC working. Unfortunately I have no idea what most of the programming stuff written in this thread means but would like to ask what all of this means to mugs like me who have a faulty ICC?

[JasonACT]

Back to work today, in my lunch break.

@happy1: Yes, I've got the WSM. I've also seen the 7 graphic files in the filesystem. Regarding your spare unit, if it's working and someone gets authority from Ford to publish the files (I'm not inclined to contact them, my bluntness in general, and my disappointment at how they treat customers would probably not get a result with the nasty letter I would write them) then I could possibly extract the files at some later stage (hoping it's G 2.9). We should wait and see, but thanks!

@crumpet: I hope Ford can sort you out. And thanks!

@mungus: Thanks.. I've always hoped knowing what goes wrong with these units will lead to someone local to you being able to offer a service to fix them (a local electronics guy, though now s/he would need a bit of unix software knowledge too). It's early days though so maybe it means nothing at the moment, unless you're mates with someone who can help more.

Companies who "recondition" these units (and charge a small fortune for it) are in fact redistributing the firmware files - someone also contacted me about the Bluetooth package, saying there's a service to upgrade it to the latest version.. Again, that's a redistribution of firmware files. They either have permission (and charge like a bull for the service) or are doing illegally (so should be doing it cheaper).

I really think the public should be asking Ford to step up here and allow them to be published online. It'll probably take more than one voice to get their attention - they seem to be pretty deaf in my dealings with them.

[JasonACT]

A long day at work today, and it's movie night in this household...

I did read through all the functions looking for a solution to the FDIM screen restore problem after my program finishes. There's a way to use a single display buffer in the library, across all exes, but you need to know the SID number to do it. That way, I can use it to save and restore the memory/display contents. Thinking that's exactly what the sat-nav exe would probably be doing, I looked at how it obtained this magic SID number and I saw...

gf_surface_sidlist(...);

First result from Google has this link:

https://bugreports.qt.io/browse/QTBUG-28576

Says the function is undocumented! It contains a complete use-case though Thanks! (No, not to you QNX guys!)

[JasonACT]

I feel like I'm having a little bit too much success:

[raceteam]

Looks like image retention from corrupt flash!

[PHATAL]

These are the same as the SZ Territory units correct? I am loving this thread by the way.

Sent from my SM-G965F using Tapatalk

[JasonACT]

Yeah, raceteam! That corruption may end up being a nice set of gauges along the bottom of the screen!

[JasonACT]

My last thought of the night... (Movie is about to start...)

Controversial, I'm sure, but anyone attempting to get $200 deposit back from certain companies who recondition these units are mad! Everyone should have a backup they can mod!

[raceteam]

Originally Posted by phatal

these are the same as the sz territory units correct?

fgii = sz
fg-x = szii

[PHATAL]

Originally Posted by raceteam

fgii = sz
fg-x = szii

Cheers mate that is what I thought was the case.

Sent from my SM-G965F using Tapatalk