View Single Post
Old 20-06-2021, 01:28 PM   #455
JasonACT
Away on leave
 
Join Date: Apr 2019
Location: ACT
Posts: 1,732
Tech Writer: Recognition for the technical writers of AFF - Issue reason: Outstanding work on the FG ICC issues. Technical Contributor: For members who share their technical expertise. - Issue reason: The insane amount of work he has put into the Falcon FG ICC is unbelievable. He has shared everything he has done and made a great deal of it available to us all. He has definitely helped a great deal of us with no personal gains to himself. 
Default Re: FORD technical service bulletin : ICC touch screen display

Previously, a while ago now, I had modified the spare FGX circuit board so I could enter the V850 flash programming mode:









Purple wire is the reset (active low, so short to ground to reset)
Blue wire is the FLMD0 pin (Enter Flash Mode on Reset use 5V to do so)
Yellow is RXDA0 (Serial Receive, I connect my transmit pin to this)
Green is TXDA0 (Serial Transmit, connected to my Arduino receive pin)

Nothing like a bit of tough double sided tape to help out here.

Some care is needed to power up the unit, one of those serial lines is the car's indicator switch in normal mode, so if it's connected when powering-on or resetting, it doesn't enter flash programmer mode, but you do get alarms and an indicator LED flashing with the speaker tick tocking away.

Anyway, I reconstructed the "last" FGX flash memory block data along with running the checksum routines of the V850. I did the same on my PC with the data I had to see if they matched. They didn't. That was performed over 4096 bytes (the block size) and I thought I'd try smaller requests (the V850 chip really shouldn't let me do that, it's a bit of a security hole - but I'm sure you can't request a single byte - otherwise you would be able to just read out the protected data) and I was able to do 512 byte checks successfully.

I could see the first 512 bytes had data, and all the other 512 byte sectors were erased (0xFF) because the checksum algorithm is pretty basic and it's easy to guess. Now my data extracted from UDS 22F106 & 22F114 commands is almost 512 bytes (only 3 bytes were unknown) so it wasn't hard to work out their values (0x00) and get matching checksums.

With all this, I put together the data I now had, and ran the V850 verify flash command (it takes 4096 bytes and tells you if it matches what's in the flash memory block)... Succcess, it matches perfectly.

Next to do... Flash in my data using the V850 flash programming mode because...

I CAN'T WORK OUT HOW TO DO IT VIA OBDII !!!

All the CAN-BUS related stuff is in the firmware parts I don't have. It looks like the firmware part I do have is just an extension module, sort of like an operating system running an executable.

Still, if the block write command isn't locked out on the V850, I think I'm getting closer. I have not written up the logic to do/attempt a block write yet, but I [only] very vaguely recall reading the protection flags all that time ago and it was only boot-block-write and read-block protected. Here's hoping.

EDIT:

I forgot to mention the data in that 512 byte sector in the last block:

FC 59 A1 00 01 00 FC 06 04 02 47 02 02

FC = Initialised check byte
59 = Checksum (calculated over the following ~252 bytes of data - so not including the VIN data which starts at position ~256 onwards)
A1 = Start of data... These seem to be referenced by various data structures used by the code, probably options like 2 extra gauges, and 7K vs 8K RPM on the dial (I hope).

Last edited by JasonACT; 20-06-2021 at 01:36 PM.
JasonACT is offline   Reply With Quote
This user likes this post: