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

JasonACT · 03-11-2021, 04:49 PM

Quote:

Originally Posted by happy1

Hi, very impressive what you have been able to find out and do with the ICC and cluster. '

Some years ago when I tried to swap in a full set of 2011 Mk2 XR6T(auto) electronics into a 2011 Mk1 XR6T(manual) I had problems to update the As-built data in the cluster, I needed to set it to 'manual' instead of 'auto', but couldn't figure that out back then.

Back then, if the vehicle had been a Focus III, there was a Russian website that had an as-built editor. http://ford.xtlt.ru/ab/ That editor wouldn't quite work with the Falcon file. Is that something that would be useful to do now, to develop an as-built data file fixer that works for FG2 and late Terri?

This link explains a little more how the FoCCCus app worked: http://blog.obdii365.com/2020/01/24/...-coder-reader/

I haven't looked too closely what Forscan can do these days, so maybe that has a solution for it already.

Cheers,

Thanks!

I've been running a 2nd hand 2014 cluster (so the newest Mk2 firmware) in my 2012 XR6T for the past half-year and I suspect it came out of a ute. Since I copied over my EEPROM and flashed the CCC data into the last block of flash memory, it is now a full clone - except for the FPV upgrades I gave myself. I'm sure if it came out of a manual, which I don't think it did, it wouldn't "remember" after what I did.

But other than a few details in the CCC data, like the formatted byte and VIN, I really don't know what any of the values do. I assume because it's "Central" data, it gets sent to a few other devices over the CAN BUS, so I didn't bother looking too closely at what the cluster firmware does with it. Most of the cluster firmware is driven by the EEPROM values.

Yeah, I have not looked at Forscan for a while either... I was hanging out for the in-code-out-code stuff to work on a Mk2 (they got it working on the Mk1) but I kind of beat them to the finish-line. I think my method of installing a new cluster is better anyway, nothing else in the car needs to be re-programmed to install the different cluster (or swap them back later).

jakka351 · 03-11-2021, 06:37 PM

Forscan Beta is inching closer to IDS level but not quite there yet. Even using a VCMII you still intermittently get 'this adaptor has can bus problems'. They had released a beta that could update firmwares, but has since been retracted due to people trying to flash things with china obdii dongles.

If you flash a chinese made car with a chinese obd clone will you have a bad time?

Also there are issues with reprogramming vin numbers as forscan only unlocks some modules when going into as built daaaada.

Some guides for anyone out there that might need:

ABS guide by Nigel, the CAN man:
https://www.tiperformance.com.au/kno...bo-conversion/

ICC modules by yours truly:
https://github.com/jakka351/FG-Falco...s-with-Forscan

rollex · 03-11-2021, 08:06 PM

Quote:

Originally Posted by jakka351

Also there are issues with reprogramming vin numbers as forscan only unlocks some modules when going into as built daaaada.

It is a suprise anything works at all ever with how uncomprehendingly complex the systems have become recently.

I have no idea how they manage the systems internally to keep everything running on the assembly line without frantic end of line re-flashing of modules to fix random issues.

jakka351 · 03-11-2021, 09:33 PM

Quote:

Originally Posted by rollex

It is a suprise anything works at all ever with how uncomprehendingly complex the systems have become recently.

I have no idea how they manage the systems internally to keep everything running on the assembly line without frantic end of line re-flashing of modules to fix random issues.

Thats why you have a team of dealerships to do that, just a little bit later on in the process.

What does a 2021 model year car have, 100 different modules or close to it. And these are probably all running some ridiculously complicated CAN networks, internet connected and borderline autonomous. May take a while to get used to that instead of the nice simple ms/hs can set up from ten years ago that the DIYer can play with at home.

Have to wait ten years until we see what theyre up to now.

stephenf7072 · 07-11-2021, 02:24 PM

Hi Jason, your efforts and this thread is so spectacular I made an account mostly just to say so. I have enough technical experience with PCBs and firmware to REALLY appreciate the time you've put in and your achievements. However the attention to detail in posting your findings is the most excellent.

I just got a 2013 TS (mid range) Territory which came with a blank screen, which is how I got here. I read the entire thread twice, and successfully started talking to my blank screen via COM port using your instructions.

However it seems like my corruptions might be a bit more terminal. I don't have a /packages directory. From the command line, I can explore the files, including those on the USB stick. But everything seems to be read-only (even when I use your trick of <mount -uw /dev/hd0> < mount -uw /fs/usb0>). I can unmount the USB, but haven't been able to remount, even as read only. It seems to automatically mount/unmount when the stick is inserted/removed though.

I tried to copy one of your /package directories to the ICC memory but since it's all read-only that failed. A manual mkdir also fails. The scary scripts to re-core it appear to be absent (no files with "core" in the name).

A complete(?) listing of files is attached, so is the complete lot of serial output during my boot - 46k lines of error messages (most removed because the attachment was too big), takes a couple of minutes. I can't actually get the files onto the USB stick because I can't get write access.

Any thoughts would be welcome. I've spent too much time on this and have too many other projects at the moment so will probably just bite the bullet and get an ALS or wrecker one. But if you're interested in interrogating mine, I'll send it to you (I'm in Melbourne).

Cheers,
Stephen

PS: I'd be reasonably confident in replacing the BGA flash chip, if you reckon you can program it (and want to go down that rabbit hole). It's a challenge, but with a temperature-controlled hot air soldering station, and lead-tinned pads/chip, it's doable.

JasonACT · 07-11-2021, 04:00 PM

To make a stubborn USB stick go into RW mode:

umount -f /fs/usb0
slay devb-umass
devb-umass cam pnp blk cache=2m,auto=partition,automount=hd0@dos:/fs/usb0,rw dos exe=all

But.. Yeah, your flash chip looks cactus. The broken unit I got also doesn't keep files alive for very long (leave it on the shelf for a month and you will see corrupt files next time you boot). For that one, I deleted most of the files (but left the sym-links which are very small) and I use a mounted SD card with a sym-link in /packages pointing to /fs/sd0/factory where I've put all the files.

There are 3 copies of the first boot file-system (which is, as you say, read-only) and I can see it is loading the first ok (start of the log says a lot of 0xE8's which is, I think, it successfully correcting errors) without having to move onto the next copy or the third.

Your entire 2nd file-system (the read/write one) is gone though (won't mount, with a lot of non 0xE8 errors) and it will need to be reformatted. I don't recall if I posted about the format command here, but there is a command to do that (etfsctl) - there also appears to be a flag (-e) to do it when first mounted (looking at the usbUpdate.sh file in /proc/boot, fs-etfs-swsa_2048).

I've heard from others who have "copied" the BGA flash to a new one, but they had issues with the unit refusing to do the boot sequence once replaced. I never heard back if they worked out what went wrong though, so I would say adding a SD card is the best way forward. I posted an SD card driver here, but I think I've made some updates since - if you want to try this (it'll be a bit of work) and get to the point where your formatted & empty flash partition allows you to create some sym-links to the mounted SD card - then I'll post the latest files on github.

At the moment, I don't think you can make the unit any worse off, unless you attempt to write those 3 boot 'r/o' file-systems, which I did describe how to do here, but which you certainly do not need or want to do.

stephenf7072 · 07-11-2021, 04:58 PM

The quick reply much appreciated! I may have missed it, but I didn't realise you had it working properly from the SD card. That sounds like a best-case long-term solution, much better than getting another ICC with only slightly less dodgy flash chip. I'd run the serial port wires somewhere nice and accessible, so am not too worried about having to fix minor corruptions occasionally. I'd definitely give that a go (I've got a spare microSD socket that should solder on nicely).

In the meantime, it'd be a super confidence-builder to format my flash and copy files onto it to get it working properly/temporarily. Is that as simple as copying the entirety of /packages of my guessed-best from your Github, or are there other folders?

For formatting, the etfsctl command is mentioned in post #260, but nowhere else (according to search anyway). I would guess on using this command, but your confirmation would help my heartrate...etfsctl -d /dev/etfs2 -S -f -c

I've got to finish a few other jobs, but will get out and experiment with the screen some more later.

JasonACT · 07-11-2021, 05:24 PM

It doesn't 100% boot off the SD card, it relies on those 3 copies of the flash boot r/o file-system, and being able to find a few hundred KB of flash which is still reliable (out of 128MB - so not such a big ask - and it will move files around if it detects weak blocks, which on a 'full' file-system quickly ends up retrying bad ones, but an empty one should be good). That space is for a number of directories and a large number of sym-links, along with my SD driver itself.

http://www.qnx.com/developers/docs/6...o/bookset.html

This is the documentation for "our" unit's operating system. Go to utilities and look up etfsctl. I personally have never had to use it, sorry, so you will be the first! Yours is currently corrupt enough to not be able to get anything back off it now, so there's no real risk in trying (I don't think).

To answer your question about what I've posted on github, no not that simple, there are many sym-links and directories (and a hand full of real files) that have to be put back, where I would create a script to do most of it. The files are there because it's most likely corruptions are in the large files, not the small links or fs-structures.

One thing at a time though, if this unit's flash memory is bad in an unfortunate spot, we may be wasting our time, so getting a mountable file-system back in place is the first step.

JasonACT · 07-11-2021, 06:01 PM

These are the commands used by the usbUpdater.sh and I would be more inclined to try these first before relying on SWSA having all "the real" QNX utilities in the fs-images...

Here, they terminate any running etfs file-system, and restart it with the -e (erase/format) option:

rm -f /fs/etfs
slay -f fs-etfs-swsa_2048
sleep 2
fs-etfs-swsa_2048 -r 16384 -f 32768 -e -m /fs/etfs

This is how it's mounted when booting

fs-etfs-swsa_2048 -r 16384 -f 32768 -m /
sleep 1
waitfor /dev/etfs2 5 && ln -sP / /fs/etfs

I can see a difference in where it's mounted when formatting, compared to when booting - where it appears to create a non-permanent memory link in /fs to the root mount point. Maybe they don't make it root when formatting in case the format fails? I can only speculate.

stephenf7072 · 07-11-2021, 10:23 PM

Alas, I think I have bricked it, or at least wiped the kernel and lost serial command. Like an idiot, I didn't see your most recent post (cramped into car with laptop the last couple of hours), but it may not have mattered. Thanks to your code I was able to write to the USB and copy most of the files to it (a few didn't work). Awesome.

"etfsctl" never worked for me, possibly because it needs an actual existing file system, possibly because it's for SRAM/RAM (first line of utility page says "Control an embedded transaction filesystem for RAM/SRAM". It wants to act on /dev/etfs2, which doesn't show for me, presumably since it's corrupted.

The obvious file systems were /dev/shmem (RAM), with a few files in it, like the system log, and /dev/mem (access to all memory?!). I'm not sure what the others were doing, but none for the /dev/efts2 (etc.) I was expecting.

During my travels, I became slightly less of a UNIX newbie and realised that "cat /proc/boot/version.txt" will show the contents of the file version.txt on the console. Beware of using on large or binary files though I suspect. Other vaguely useful commands include "pidin syspage=asinfo" and pidin mem for seeing RAM usage.

So after some more hunting I too came across the "fs-etsf-swsa_2048" command, and buried among the binary stuff in the file is a plain text description of how to use it and all the options. It's the self-confessed "ETFS Filesystem driver for the SWSA i.MX31 target board". Excerpt attached for the record. Given all my errors were from this command, I figured there was a good chance it might do something useful in re-formatting.

May I suggest, DO NOT ENTER THIS "fs-etfs-swsa_2048 -e"

The serial input/output is attached. Stuff immediately happened, suggesting the file system was being erased, with a couple of hundred errors but only taking a few seconds. And /dev/etfs1, /dev/etfs2, /dev/etfs3, /dev/etfs4 appeared as I'd hoped. Great success!

...So I did a shutdown/restart and after a 1sec boot with no errors, got a message that no valid kernel had been found, and no response to my "ls" or any other commands. This message hangs around for a couple of minutes then the screen resets and sends it to serial again. D'oh!!!

Bit sad it'd let me erase the operating system but it seems like that's what's happened. Only 16MB of memory indicates it's some kind of onboard thing, as the 70MB+ packages from your Github won't fit that. The longer version of the fs-etfs-swsa_2048 command with the -m option might have helped, but since it's also 16MB also appears not to apply to the main flash which was corrupted. I feel like I'm missing something around the etfs and stuff though, my knowledge is still pretty patchy.

So there it is. I did some half-hearted Googling for how to upload a QNX kernel, and found this link indicating it may be as simple as putting the files (which I did get a copy of) on an SD card... http://www.qnx.com/developers/docs/q...es_SIMPLE.html

One can only hope, but maybe, just maybe that would explain why there are pads for one on the PCB.

Some useful links for the record:
Documentation for "our" OS: http://www.qnx.com/developers/docs/6...o/bookset.html
Utilities: http://www.qnx.com/developers/docs/6...arch/fsys.html
etfsctl: http://www.qnx.com/developers/docs/6...e/etfsctl.html

JasonACT · 08-11-2021, 09:54 AM

Oh no. I think it's bricked too.

The "-r 16384" parameter means reserve and "do not touch" the first 16MB that contains the boot-loader and 3 copies of the kernel, but start the erase and format after that point. The "Reading startup header" messages just mean it's looking for the kernel in the first 16MB, which is part of the boot-loader process, and it knows it shouldn't go any further because it will be scanning the 2nd file-system.

Yes, re-reading the docs, etfsctl needs fs-etfs-swsa_2048 to be running, which yours wasn't, so my last post is (or was) the way to do it.

I'm really sorry it so quickly came to this! FYI - I think to make it boot off the SD card requires changes to the boot switches, not to mention also having it set up with a valid kernel image that contains an SD boot-loader (something we don't have). If you trade it in to ASL, I'm pretty sure they will replace the flash chip with a pre-programmed one, so I would just clean it up as much as possible and go that route unless you find a cheaper one on ebay/wrecker.

stephenf7072 · 08-11-2021, 07:41 PM

Ah damn, reserving the memory makes a whole lotta sense. Ye all be warned (be patient, and wait for a reply before hitting that enter button on the scary commands).

I went back through earlier posts looking for the flash chip and/or microcontroller datasheets, in case they give any hints to programming. The serial output still working means it might be possible to get the thing into programming mode or something.

I also noted:
1. Post #189 indicates the unpopulated SD card spot becomes active as part of the boot cycle. I doubt that's useful for me though.
2. Post #190 indicating there might be a 10-pin JTAG port. Now that's interesting - I have a JTAG programmer and have used it to program blank microcontroller memories to avoid using the serial interface.
3. Post #163 documents components, including flash and microcontroller(s). Useful for finding datasheets.
4. If you have the right blob of data and could access the pins on the flash, programming appears relatively simple (which probably means it isn't, but you never know)

Another lesson I've managed to learn the hard way is that the 2014 SZ Territory Titanium screen is different to the TS (different plug, and metal casing, I didn't have the heart to look at the actual circuitboard). Anyone want one...?

jakka351 · 08-11-2021, 09:54 PM

Revenge of the Flash

JasonACT · 16-12-2021, 02:43 PM

The Forscan guys have done a really good write-up of the Ford module flash process, there's lots of detail there that I was missing when I was trying out stuff ("secondary boot loader" was my missing piece of info, when I was trying out what commands I could run once I got security access with the brute forced keys):

https://forscan.org/forum/viewtopic.php?f=13&t=18751

It's quite a long read, but interesting (if you find this thread so).

There still appears to be no way to "extract" the firmware already in a module. They talk about it, saying it might be added one day. This is important as our cars age, because some firmwares are not available from Ford, think limited runs in the last few years of FoA making cars - I.E. GTF, FGX - where they found no bugs in firmwares, so never needed to upload a patched version for the dealers. Their download site does not host original version firmwares (everyone got at least that version already installed in the module in their new car). So you can't "convert" an FG2 cluster to a FGX one, even though the software is the only difference.

jakka351 · 16-12-2021, 05:48 PM

Quote:

Originally Posted by JasonACT

Thanks!

I've been running a 2nd hand 2014 cluster (so the newest Mk2 firmware) in my 2012 XR6T for the past half-year and I suspect it came out of a ute. Since I copied over my EEPROM and flashed the CCC data into the last block of flash memory, it is now a full clone - except for the FPV upgrades I gave myself. I'm sure if it came out of a manual, which I don't think it did, it wouldn't "remember" after what I did.

But other than a few details in the CCC data, like the formatted byte and VIN, I really don't know what any of the values do. I assume because it's "Central" data, it gets sent to a few other devices over the CAN BUS, so I didn't bother looking too closely at what the cluster firmware does with it. Most of the cluster firmware is driven by the EEPROM values.

Yeah, I have not looked at Forscan for a while either... I was hanging out for the in-code-out-code stuff to work on a Mk2 (they got it working on the Mk1) but I kind of beat them to the finish-line. I think my method of installing a new cluster is better anyway, nothing else in the car needs to be re-programmed to install the different cluster (or swap them back later).

Would you be able to shed any light on (cluster) CAN id 0x1D7, a remote frame request. I have seen it appear on the FDIM and the IC when they are isolated from all other modules.

And I also saw a 29 bit CAN id (not 11) message from the cluster with a DLC higher than 8. It appeared on the hscan, I am unsure whether it was a socketcan error, but it appeared along side the 0x1D7[7] remote frame request, one single message. have yet to reproduce.

JasonACT · 16-12-2021, 06:51 PM

Quote:

Originally Posted by jakka351

Would you be able to shed any light on (cluster) CAN id 0x1D7, a remote frame request. I have seen it appear on the FDIM and the IC when they are isolated from all other modules.

And I also saw a 29 bit CAN id (not 11) message from the cluster with a DLC higher than 8. It appeared on the hscan, I am unsure whether it was a socketcan error, but it appeared along side the 0x1D7[7] remote frame request, one single message. have yet to reproduce.

No idea sorry, that value does not appear in any of my CAN-BUS recordings on my FG2. Nor does it appear in the WSMs.

Just going back to your quote:

Quote:

Shift Alert or Engine Overspeed Alert?

See page 413-01-50 (instrument cluster) WSM for the FG(1) (section 9.3.33) "Transmission Shift Alarm":

Quote:

An audible chime for maximum vehicle performance will be sounded when a preset RPM threshold
is reached. A hyteresis offset is included to stop it from faults re-triggering. These
parameters - RPM threshold and hysteresis offset, plus number of chimes is EEPROM configurable.

No such statement is included in the FG2 WSM. Most of the really technical details (CAN ids) are gone too for the FG2.

It may be something you can set on the FG(1) or it may be the "secondary boot loader" that allows you to save and restore an EEPROM image... I don't really know (yet).

I wrote:

Quote:

I don't see the same repeating value of 0x78 like I do in my MKII Cluster.

Position 0x07E & 0x07F are the RPM Alarm configuration (here they are not set, being FF 00). On my spare MKI G6E Cluster, I've coded these bytes as 69 4A and turned on the RPM Alarm and it goes off when you hit 5250rpm (you can hit 5249 as much as you like, it won't go off). The value for 6000rpm (as mentioned earlier) and what an FPV will have set in these positions is 78 4A. The 4A part is some weird config to do with timing and how low the RPM needs to go below the set limit to reset.

Sad news though, I'm sorry to say, but even though I can enable the RPM Alarm and set where it goes off, these config changes in the EEPROM do not alter any of the values you can read via an OBD2 tool.

So... These are not settable on a non-FPV MKI without disassembling the Cluster.

Again, maybe the SBL can do this??

When I changed the number of chimes (that weird config thing) it didn't actually work! So, a bug in the firmware.

I.E.
The 4A part:
the '4' part=4*50=200 RPM offset which you need to drop below before the alarm goes off again.
the 'A' part is the number of chimes, A hex is 10 decimal, and... which doesn't work properly in the FG2, you only ever get 10 or 15 or something like that depending on what you set.

The FG2 WSM states, the 3 repeating values I saw are for the different engine types (4cyl eco-boost, I6 & v8).

jakka351 · 16-12-2021, 11:14 PM

Quote:

Originally Posted by JasonACT

No idea sorry, that value does not appear in any of my CAN-BUS recordings on my FG2. Nor does it appear in the WSMs.

Just going back to your quote:

See page 413-01-50 (instrument cluster) WSM for the FG(1) (section 9.3.33) "Transmission Shift Alarm":

No such statement is included in the FG2 WSM. Most of the really technical details (CAN ids) are gone too for the FG2.

It may be something you can set on the FG(1) or it may be the "secondary boot loader" that allows you to save and restore an EEPROM image... I don't really know (yet).

I wrote:

Again, maybe the SBL can do this??

When I changed the number of chimes (that weird config thing) it didn't actually work! So, a bug in the firmware.

I.E.
The 4A part:
the '4' part=4*50=200 RPM offset which you need to drop below before the alarm goes off again.
the 'A' part is the number of chimes, A hex is 10 decimal, and... which doesn't work properly in the FG2, you only ever get 10 or 15 or something like that depending on what you set.

The FG2 WSM states, the 3 repeating values I saw are for the different engine types (4cyl eco-boost, I6 & v8).

In the Instrument Cluster manual (mk1) it does say that the RPM threshold is a configurable value - doesn't say how. You would assume they had to set them at some point when assembling the cars, unless they came pre-set from supplier. But still all of the settings and configs would be double checked before releasing a vehicle.

I cheated, and used python-can to set mine

if message.arbitration_id == RpmMessage and message.data[0] == ShiftAlertByte0:
Data2 = message.data[2]
Data3 = message.data[3]
Data4 = message.data[4]
Data5 = message.data[5]
Data6 = message.data[6]
Data7 = message.data[7]
trigger = can.Message(
arbitration_id=RpmMessage, data=[0x66, 0x66, Data2, Data3, Data4, Data5, Data6, Data7], is_extended_id=False
)
if message.arbitration_id == RpmMessage and message.data[0] >= ShiftAlertByte0 and message.data[1] in ShiftAlertByte1:
cleanline()
cleanline()
print(message)
print("shift!", time)
task = bus.send_periodic(trigger, 0.01)
assert isinstance(task, can.CyclicSendTaskABC)
time.sleep(1)
task.stop()
time.sleep(3)
pcm = 0x7E0
cleardtc = can.Message(
arbitration_id=pcm, data=[0x03, 0x14, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00], is_extended_id=False
)
bus.send(cleardtc, timeout=None)
#flush_tx_buffer()

jakka351 · 17-12-2021, 06:47 PM

The Phantom Function
Attack of the VCM Clones
Revenge of the Flash
A New Code
The EEPROM Strikes Back
Return of the Faultcode

jakka351 · 21-12-2021, 01:06 AM

Cluster AsBuilt from Forscan....6 Blocks, 1-2-3-4-5-7. Skips Address 6. raw asbuilt: https://github.com/jakka351/FG-Falco...510_070111.abt

JasonACT · 22-12-2021, 08:35 PM

Quote:

Originally Posted by JasonACT

There still appears to be no way to "extract" the firmware already in a module. They talk about it, saying it might be added one day. This is important as our cars age, because some firmwares are not available from Ford, think limited runs in the last few years of FoA making cars - I.E. GTF, FGX - where they found no bugs in firmwares, so never needed to upload a patched version for the dealers. Their download site does not host original version firmwares (everyone got at least that version already installed in the module in their new car). So you can't "convert" an FG2 cluster to a FGX one, even though the software is the only difference.

Today, after the best part of 7 days working solid on this, I have extracted the two FGX firmware areas, signal-config and firmware-exe, and the Central Config cluster at the end. The first 20KB (the primary boot loader) cannot be extracted... I guess that's not important (I assume they are all the same, since the FG2 secondary boot loader works on the FGX... Now to try it on a FG[I]).

The RAM cannot be extracted either, so, no EEPROM copy without disassembly of the IPC module to get physical access.

That's pretty much the usual method though, so I'm very happy with what I've got now.

rollex · 23-12-2021, 06:15 AM

Have you tried end of life security unlock (level 5) to read the ram?

You can read and write ram on other modules using that. Your are limited to reading 4 bytes at a time so it is very slow.

JasonACT · 23-12-2021, 02:57 PM

Thanks rollex, I'll see what I can find.

I've started uploading Cluster firmware files at my github repo:

https://github.com/Jasoroony/Ford-Fa...n/extracted_fw

There's a couple of FGX ones there now

No luck on the FG[I]... It even doesn't like the "diagnostic device connected" signal (keep-alive) and also rejects my attempt to increase the security level

rollex · 23-12-2021, 03:34 PM

Start an infinite loop trying to unlock level 5 (or 1/3 if you dont have the key for level 5) and power cycle the cluster. Some devices have a back door within the first 20ms to enter the PBL instead of the SBL which gives you a different level of access.

jakka351 · 25-12-2021, 10:49 AM

Quote:

Originally Posted by JasonACT

Thanks rollex, I'll see what I can find.

I've started uploading Cluster firmware files at my github repo:

https://github.com/Jasoroony/Ford-Fa...n/extracted_fw

There's a couple of FGX ones there now

No luck on the FG[I]... It even doesn't like the "diagnostic device connected" signal (keep-alive) and also rejects my attempt to increase the security level

are you sending teater present as 720[8]023E0100000000000? You can also send 720[8]023E020000000000 to suppress the response, In extended diagnostic sessiom 87, or ecu sdssiom 85,. Ive also not beem able to get a positive response when requesting level 3 or 11 seeds

JasonACT · 26-12-2021, 10:11 AM

The exe is extremely useful even without J2534 support. If I want to extract the firmware more quickly, I'll use my micro-controller that already runs as fast as an FG2/X Cluster can provide it the data, where that solid MC code base was the template for the ELM327 exe version. I put the exe there (and updated it today with more error handling) so the "ordinary guy" can get the data. I've not included the code to produce a valid ".vbf" Ford firmware file, as I hope that "ordinary guy" will give me their raw data to do so - and I can upload more firmwares to the github repo.

But I'm glad you noticed

jakka351 · 26-12-2021, 02:38 PM

Quote:

Originally Posted by Whiteford

The exe would be extremely useful with J2534 support ;)

pssh no we need socketcan support. What a demanding bunch we are.

JasonACT · 26-12-2021, 06:58 PM

Ha ha... Long time, no speak Whiteford, but I wasn't really phased. I uploaded it for someone else to try out and report back, but you noticed it first. Truth be told, I don't have a J2534 so I can't add support for it. Most stuff I do will be with a micro-controller (MC) first, but I do have an ELM327 clone that I can convert things that work over to.

No dramas.

JasonACT · 26-12-2021, 07:11 PM

I'll consider it. My comments to the person who I developed this for was, there's a very limited number of uses for this (only a handful of Cluster firmwares were created, and I've got a bunch of them already)... There's only one left that I'm really interested in (the GTF, which has a confirmed different Signal Configuration to the other FG2s).

jakka351 · 26-12-2021, 08:57 PM

Quote:

Originally Posted by JasonACT

Ha ha... Long time, no speak Whiteford, but I wasn't really phased. I uploaded it for someone else to try out and report back, but you noticed it first. Truth be told, I don't have a J2534 so I can't add support for it. Most stuff I do will be with a micro-controller (MC) first, but I do have an ELM327 clone that I can convert things that work over to.

No dramas.

I would be happy to long-term lend you one. Inbox message me a shipping address will send it this week.

jakka351 · 26-12-2021, 09:01 PM

Quote:

Originally Posted by JasonACT

I'll consider it. My comments to the person who I developed this for was, there's a very limited number of uses for this (only a handful of Cluster firmwares were created, and I've got a bunch of them already)... There's only one left that I'm really interested in (the GTF, which has a confirmed different Signal Configuration to the other FG2s).

Is it a correct assumption that this progran will not work with MK1 clusters due to the different format, or will it still provide the raw data to create a firmware file...phf in for mk1s.