FORD technical service bulletin : ICC touch screen display - Page 11

JasonACT · 08-01-2020, 06:08 PM

I'm no artist, so dials are a fair bit off, but I decided to create a basic font (small enough to use with dials in the space I've got to play with). Uppercase and digits only, it's easy to add symbols to though...

I reckon I could get 6 dials in that space. 3 each side. Currently I'm showing 7 lines of text by 55 characters each side. I could get a lot more info in here this way - if only I could read it!

There was a lot of flicker in the text when I first ran this test, so I create a handle to the orginal surface and created my own new one. I refresh my new surface from a copy of the old surface 4 times a second (works well) - flicker has almost gone. (The flicker is because there's 2 apps updating the surface, and I can't coordinate mine against the original - but by taking a regular snapshot I can coordinate when mine gets displayed - in the vertical retrace of the screen (a 47Hz LCD screen) to reduce the flicker.

I am thinking though, with basic line drawing, I can set something up like this:

30C--------------80C--------------130C
OIL-------------------------|
TRN----------------------|
WTR--------------------|

Which would be quite readable. Did I mention, I'm no artist?

JasonACT · 08-01-2020, 06:18 PM

These are being discontinued at Jaycar (sale price ~$6 each) so I bought what my local store had left:

These will require some basic graphics (bright pointer with a tail that dims as it ages, I'm thinking).

**PHATAL** · 08-01-2020, 06:39 PM

Still say you can make bulk coin with this if you get it sorted.

Imagine boost figures shown directly on the bottom of your ICC #NOICE

Sent from my SM-G965F using Tapatalk

JasonACT · 08-01-2020, 08:37 PM

I don't think there's any problem getting this sorted.. The non-sat-nav unit has a spare serial port available.. It's the sat-nav unit (which I'm keeping in my car, if the new maps work - and they have now landed!) that I'm going to have to pull the proverbial rabbit out of my dark hole which is the problem.

I've refined things a little - 8 lines each side. Double buffered surfaces, so there is absolutely no flicker at all now.

I also have a plan to multiplex the sat-nav serial port into two with special packet identifiers (that there's no way the sat-nav would ever send over serial). Well, it's a plan

mungus · 09-01-2020, 08:43 AM

Sorry to once again poke my nose in this thread, and I know @JasonACT you are now moving on to different things, but I just would like to get back to the faulty blank screen. I'm trying to decipher the info in this thread and would I be correct in saying (in layman's terms) that nothing was actually wrong with the unit, other than the fact that a power spike simply caused some start-up files to become corrupted? Thanks again @JasonACT for sharing all of your experience with the work you have done here.

JasonACT · 09-01-2020, 09:38 AM

The faulty FDIM that I obtained had a bad USB transceiver chip (the chip that takes serial data and turns it into byte data for the main CPU). I don't know why it was broken, there is lots of protection around this area - so it's not like the guys kids stuck some metal in the socket and it broke - that shouldn't be possible. I don't even know that the jump-start broke it (I should ask him if he ever used it).

The flash chip is only rated for 10 years data retention, that's probably with the error correction too (which allows 4 bits per page before you notice a problem). I reckon the data had been gone for a while, and the jumpstart just caused a reboot when meant loading the data again for the first time in years. So all of a sudden we think "Oh, the jump start broke it."

But, yes, I think in most cases, the hardware is fine and it just needs some files copied back to fix it.

JasonACT · 14-01-2020, 10:58 PM

You always have to get your priorities right, at least that's what I've been taught. So the new (tiny) gauges on the screen have taken a back seat since late last week when I got the Chinese SD card with the updated sat-nav maps. The card came with some very old licenses, none for the latest maps though. Keeping the base map, which I am licensed for, makes the unit load up ok - the newer base map makes all maps unlicensed and the app terminates... But I could see the 2019 maps were named as inactive when the unit booted ok without a license for them.

I talked to the Chinese guys, they said they wanted to help, until I mentioned the QNX operating system and I never heard back from them! They wouldn't supply me with a newer license file for the maps either, so my advice is don't bother with them.

I bought a very cheap new Android (Vodafone Smart C9) that I was able to download the iGO nav software on and purchase maps for ($27.02 !!!

)

So I now consider myself licensed. And I will always pay for my maps.

You can plug the phone into a computer and get the maps off the unit, but I'm unable to root this phone, so no license files - except the basic one for the software executable itself. Still, this is almost everything the Chinese SD card came with - so that's going to be my method of getting new maps from now on.

Not wanting to waste anything (it's a life choice) I took a look at the DLL the Chinese gave me. It's not an exe, but a JNI thingy (I guess a Java Native Interface "shared object"). I found the version string in the file. I downloaded the original unmodified "apk" Android install file and ran it through WinRAR - and got all the files. I did a binary comparison, found 7 edits. Out of those, they appeared to be in 3 functions.

It took a while (I wrote some programs to put text strings in the disassembly at the point they are referenced - which was tricky since the Android one is "relocatable code" and has a double de-reference mechanism) but after doing so, I had discovered that one of their 3 changes was the one I had already done on the FGII unit! Yay! I tracked down the other two functions by limiting my searches to within where the license-type strings started and ended in the exe - and looking for constants common between the 2018 Android and 2012 QNX software. After a few hours, I had cracked it and the maps loaded:

So, these maps have actually cost me a bit under $200 (and a whole heap of time.. 4 days). But from now on they will cost me $27.02 a year!

I think I'll need permission though from a forum moderator to post the changes I made to the FGII unit software (I've only done the older firmware - from 2012 - not the one in my car yet from 2014).

JasonACT · 15-01-2020, 08:25 PM

I "upgraded" my car this afternoon:

Please don't pirate any maps... Universal FGII version search & replace in a hexeditor:

2500000a003090e5030054e10000a0330100a023
2500000a003090e5030054e10000a0330100a0E3 (23->E3)

0000a0830100a093ddffffea0000a0e3
0000a0830100a0E3ddffffea0100a0e3 (93->E3, 00->01)

000001e0000050e30200001a0000a0e3
000001e0000050e30200001a0100a0e3 (00->01)

50004BE2DC101BE5
DC101BE50100A0E1 (complete replacement)

(The last one was documented 2 pages ago and I'm not inclined to spell things out more clearly in this post.)

JasonACT · 20-01-2020, 10:14 PM

Work, as usual, is mad. Little incentive to spend time on this now I've got 90% of what I wanted sorted in my holiday... Today, I had thought maybe a hair drier might help with a broken unit... The bad unit with hundreds of corrupt files (which I've fixed) seems to produce lots of ECC messages (which I assume are properly corrected) when I power it up after sitting on the bench for days unused... The flash chip hovers around 40C when powered up for a while, and then doesn't report too many ECC problems after many reboots, as opposed to sitting for days and reporting a huge number of ECC corrections when first powered up after a lot of time.

Letting it sit for a few hours though - nope - not too many ECC problem reports when back to ambient. Very confusing.

Very dodgy too. These flash chips don't instill confidence.

(Oh, and I'm trying to remove the double buffered video thing I added before, that removes flickering, which is why I'm playing again - 3MB of buffers & copying it 10 times a second seems like it would be pushing the unit - and I want to see if I can get it working properly, more efficiently, before going forward.)

Nothing to see here, sorry :(

**PHATAL** · 20-01-2020, 10:24 PM

Hi just as an FYI from my territory SZ unit if it assists in any way... It would be epic to upgrade the maps as I constantly find incorrect streets etc on here that have changed.

Sent from my SM-G965F using Tapatalk

JasonACT · 20-01-2020, 10:35 PM

Right bac-atcha...

**PHATAL** · 20-01-2020, 10:38 PM

That is the most up to date official one then yeah?

Sent from my SM-G965F using Tapatalk

JasonACT · 20-01-2020, 10:43 PM

No.. apparently. Late 2015 was the latest - and a firmware upgrade to-boot to allow it to work (which is what I've read).

But since I've included enough hex-bytes - and those bits didn't change over at least two years - I'd say it's (the hack) is good for quite a few versions.

**PHATAL** · 20-01-2020, 11:00 PM

No worries. Cheers.

Sent from my SM-G965F using Tapatalk

JasonACT · 26-01-2020, 12:20 AM

I have located the two pins on the large 50 pin connector that joins the two boards in the ICC which are UART#5.. It's the spare serial port on the non-sat-nav units. I've even written a program that confirms it works with proper output (on both the S5-Tx line and the S1-Tx line - which is the debug terminal).

This image always had my interest though. And today, I had to "repair" the Terry unit again! The hmi executable had a new corruption (actually there's about 15 files that no longer match the snapshot I had taken after fixing the unit a month ago).

No wonder, some "smart-ar people" are keeping repaired units in temperature controlled environments before moving them on.

My computer room got to 34C today - between boots where it was working to when it failed (yep, I had caught it between boots - and there were lots of reported ECC errors, more than usual).

(Tx line from the main CPU marked - 34 [tx] & 36 [rx].)

raceteam · 26-01-2020, 06:01 AM

Do the flash chips need to be replaced then?

JasonACT · 26-01-2020, 10:33 AM

With the right software/firmware it could be managed ok I think - as long as it didn't sit around while unplugged. Some sort of low priority background task to check each in-use block once a week and re-map it when 2 or more bits are being corrected.

The flash chip is also one of those really hard to replace bga types. Way beyond my skill level, and I've watched a couple of videos of the experts repairing iPhones and things now... Something you might want to pay for, if your whole life is on your phone and you were careless.

There's also the USB port, I've been running quite a few programs directly off USB. You could in theory run the entire firmware off USB, except that I think it's in USB1.0 mode (1MB/s) which is quite slow. Only the sat-nav software would be a problem though I think - which I guess is why they use 16bit flash instead of the 8bit flash on the non-sat-nav units - twice the speed. The way it's set up, you should only need to change a handful of the sym-links to switch it over. I think USB is mounted quite early in the boot, if one is plugged in.

I suspect neither Ford nor Sumitomo are going to address their monumental stuff up here though.

JasonACT · 27-01-2020, 04:12 PM

My public holiday is nearly at an end, so back to work tomorrow - and this project goes into slow motion again. I did make some progress though:

It's only a "partially working" mock-up in that I've got the code to read values from the serial port, but it's not part of the graphics program yet. I've got some information on how to get the values from the CAN BUS too, but not all - and this will be the last part to be done. There's still some flicker too, I know I can get rid of it, but I don't want to run this unit like a games console.

I've tried to keep "yellow" as the reading you want to see in the corner of your eye.. So I've tried to match up the values on the display so they line up - even though the code allows you to offset that centre band for each gauge.

On the left is a speed read-out graph (my car-mad mate at work thinks it's not useful - but I said I could plot some text saing "4.9s" if it reads 0-100 within 7 or so seconds). He liked that.

The square box on the left-hand-side, right portion, shows a red cross for current gforce & a blue cross for maximum gforce seen in the last however many seconds I decide on... This is a mock-up, so I've just got them set to constant values at the moment (though the speed is going up and down from 0-158km/h - so it is animated right now).

Breeny777 · 02-02-2020, 12:22 PM

JasonACT, mate, what a read! I came here looking for info for a blank screen in my 2014 SZ ICC doing almost exactly what PeteXR's screen did, and if there may be a way to avoid a $4-700+ replacement....

My screen died simply from me being an idiot and not disconnecting the battery when it removed and refitted my ICC to add in a car phone mount (yeah, I know and I bloody should know better it's 100% my fault)
So my question now is, is it probable I can get a dealer to do a firmware update on it and maaaybe bring it back to life?

And does anyone know of a dealer in Adelaide that may have the smarts to know what I'd be asking for and not just say nah mate, new screen for you?

I have used one place to do an update to my TCM and they were ok, so I'm thinking of using them again.

Actually, kinda keen to have a crack at doing the filesystem replacement you did and avoid the dealer altogether....Would that be even possible with minimal hacking? Assuming mine still might have a working USB chip?

Anyway, sorry to derail, continue on, this whole thread has been brilliant

JasonACT · 02-02-2020, 05:23 PM

If you regularly service your car with a Ford dealer, they are more likely to try and help - and I would give it a good chance of success. You can tell if your USB port is working too, by plugging in a memory stick with an LED light (or card reader with an LED light). If it flashes the light for a short time and it stays lit solid soon after (with blank media, but flashing will continue a while if there's lots of mp3s on the stick) then you should be good. If the light goes out, or doesn't stop flashing, bad USB.

I posted a link a while back for a USB to serial device for your PC (it needs to be resoldered for 3.3v use as most come configured for 5.0v which will wreck the FDIM's serial port). However, without a copy of the firmware files, or access to another ICC from around the same time as yours (to get them) then you are kind of out of luck. I want to post the set of 3 firmware version's files I have on the Internet - but I'm not doing it until Ford or Sumitomo provide written permission.

My latest update for my gauges is, I've created a new device driver to simulate serial port 5 for the sat-nav GPS chip (turns out the early 2013 one starts the serial port at 57600 baud and the mid 2014 one 115200 baud - so it looks like the GPS chip got a firmware update at some stage). I've been loading the original serial driver for "ser5" as "ser4" and I can pass along the non-gauge data (GPS stuff) to the other port... Rabbit in dark-place, meet the light.

I'm still thinking about how to "save power" though.. I'll be using another microcontroller for the CAN-BUS stuff and I want it to all turn off after the car's been off for 15 minutes (using the car's battery saver circuit). When this happens, the GPS data will no longer be sent to the FDIM (not sure this is a problem, but I want to avoid a gps software crash). My latest thought is to use a micro-relay to reconnect the GPS chip directly to the FDIM CPU and bypass my new microcontroller. I may be overthinking it though, when the battery saver comes on in 15 minutes, the whole ICC should be fast asleep.

Breeny777 · 02-02-2020, 07:57 PM

Yeah I checked, I'd left my iThing plugged in the whole time, but it is showing the ford logo and current(last played i guess) track when connected and appearing to be getting power - so i'm hoping that's a good sign. I'll prep a USB stick with some MP3's and have a play.

I figured the actual firmware files would be the biggest issue and I totally understand you not wanting to post anything up yet. I'll have a chat to my dealer - I've had a few services done there - as well as the TCM update - so hoping they'll help out.

I'll update this thread for any one else out there having issues once I try out the dealer firmware path option.

Thanks again!

Breeny777 · 07-02-2020, 07:27 PM

No joy from Ford trying to re-flash. Time to research other options - very tempted to android up.

JasonACT · 16-02-2020, 06:44 PM

I'm not surprised Ford re-flashing these units often doesn't work, I've had a look at the update scripts and they do a full check of all the files to ensure they are "good". If any one file fails the check, then the unit doesn't progress to the final update stage... Most files are images too - and who cares if a bit is wrong here and there on those? I'd rather see a weird image than the whole screen stay blank.

Progress on the gauges.. 3 microcontrollers talking to the screen (and 2 of them to each other)..

I had started the one with the g-force measuring device level, then put it on its side (so 1G is showing).

Prototype:

Not sure if I've got the vehicle speed CAN message correct - so I've added an LCD screen so I can do some in-car testing without fully installing it:

Again, unit is on its side - so Y is showing -0.9G

Oh, I also found a bug in my serial comms code - which is why I was having to turn the car key to off/accessories when entering commands. With that fixed my FDIM "debug" console is much more reliable/responsive. It was only sending in characters when it received some first - my bad.

Speed, I'm still testing. G-Force, Battery, Baro, Boost, Water, Oil and Trans are all working. I can request speed, but I'd rather find the address/data item for the broadcast message for the cluster to show - as I'm using it in the 0-100kmh timing code, it needs to be "as it happens" and not by my request.

JasonACT · 18-02-2020, 06:30 PM

It's 31C today in Canberra (according to my car) and I had really given it a good work out to get the temps up to these:

"Spd" changes to "Tim" (flashing for 10 seconds) and shows the seconds to two decimal places if you do a 0-100 time under 10 seconds. I've seen Bst go as high as 15 too (though mine is tuned).

Here's a circuit diagram and component list (components touching each other mean they are connected - and as I've got two screens I can show the front and back at the same time - you only need one of course):

I'm not entirely happy with "voltage" as it always shows "XX.0V" - 12 when the car is not started, 13 or 14 when it is. I don't know where the decimal place disappears to, in my tests it should work - so I don't think the car gives the value to that precision despite being able to.

The attachment is a zip file with the microcontroller source code (with no warranty!) and the compiled FDIM software program (which is tested only on a non-sat-nav unit). I'm concerned about using a 5v microcontroller on the 3.3v FDIM - the resistors should protect it, but I need to do more research on the Nano before I try. A non-sat-nav FDIM only uses the Nano's TX output, which I have tested as being good with those resistors - it's the Nano's RX input that I'm concerned about, since the USB chip underneath is pulling it up to 5v.

When I do test on my FDIM, I'll need to edit the navi package startup script:

Changing u5 to u4, and starting the gauges before "wait /dev/ser5" is run...
devc-sermx1 -u5 -F -b115200 -c66500000 0x43fb4000,47
to:
devc-sermx1 -u4 -F -b115200 -c66500000 0x43fb4000,47

I've been running this from the debug console:

devc-sermx1 -u4 -F -b115200 -c66500000 0x43fb4000,47 &

For my bench testing (& on the end makes the program run and the debug shell come back right away).

The FDIM gauges software opens ser4 and creates a new device ser5 (so it should in theory still send the sat-nav chips output to the right place).

Anyway, I'm pretty happy with the LCD (standalone) mode and maybe people with an FG (I) or FGX will get use out of this? Rename the .txt file to .zip of course - I hope I can break the forum rules on this file in this case?

block58 · 18-02-2020, 08:52 PM

Is the section of the startup script responsible for checking the files able to be commented out or removed entirely?

JasonACT · 18-02-2020, 10:05 PM

No, unfortunately. That part of the update process is in the read-only boot partition, not the update-able 2nd partition for packages. Strangely, the main update script can have an override in the 2nd read/write partition.. but to fix this problem you would need to rebuild the QNX ipl/spl system.

I can see one good thing about this, and that's when these devices were first built, the bad units get chucked in the bin... Except, those resourceful Chinese "chexkers" (did you see the photos of the FDIM stickers?) might just plug into the debug port to get the useless units working to the Aus. standards by fixing files by hand.

I say Aus. standards, only based on the comments in the scripts, which are generally better than what I see in other foreign source code I see in my day job.

JasonACT · 19-02-2020, 06:45 PM

SOB (in my case, all meanings, but son-of.. mainly)...

I started testing my spare sat-nav unit this arvo, it starts /dev/ser5 at 57600 BAUD, by software changes it to 9600 to listen to the sat-nav-chip, sends a command to change the chip to 115200 (along with ser5) where it remains at.

Well, the Nano only has 1 serial port and I was (going to) use it to cut the serial wire line between the nav-chip (TX) and the main CPU (RX) and connect both to it. Now I need another serial port (which the Nano doesn't have) to listen to the main CPU TX line for the command to change BAUD rates.

I might as well pick a 3.3v unit (and that will be more expensive). So what I've posted previously will only ever work on a non-sat-nav unit. I think this project is going to be on hold indefinitely for the sat-nav units. Since the new microcontroller is going to turn on and off with the battery saver, I will need to work out a way to know the "currently set BAUD rate" when it powers up each time the car is unlocked.

block58 · 19-02-2020, 07:32 PM

Quote:

Originally Posted by JasonACT

No, unfortunately. That part of the update process is in the read-only boot partition, not the update-able 2nd partition for packages. Strangely, the main update script can have an override in the 2nd read/write partition.. but to fix this problem you would need to rebuild the QNX ipl/spl system.

Dang. Thought it might allow for some "preventative maintenance". In any case I am tempted to follow your instructions and see if I can't create/copy my own theme to the unit. Just not sure if I possess the fine soldering skills

JasonACT · 19-02-2020, 09:58 PM

Pulling the ICC out of the car is a pain. Putting it back in and clearing all the codes (because I don't bother disconnecting the battery - as I don't think that plays a part in the units going blank - and I've clocked up ~1500 restarts on 3 of my units now) is a pain. Removing enough screws from the ICC brackets to dislodge the FDIM is a pain. Disassembling the FDIM to the point where you can start to solder... is a real pain! The smallish connector traces where you need to solder two wires onto, isn't really that bad, relatively.

I'd be keen to try out a new theme, even if it was only the home screen that was different. I'm not artistic at all though.. #cybertruck.

JasonACT · 19-02-2020, 10:54 PM

Hmm, time to start looking at the SoftwareSerial library on Arduino... There's a good chance I can temporarily use D2 as a dedicated 9600 BAUD serial input (directly connecting pins RX0 to D2 so both get the same signal) and tell from what's received that I'm in ICC initial boot mode vs booted & established 115200 BAUD mode.

There's a light at the end of this tunnel... Or a train heading my way.