OBDX Development - Developer Tools and Suggestions

[acln99]

Can anyone try putting these seeds into your Ford algorithm just to see if FCA copied Ford !!

<7E8,82,50,85,0,0,0,0,0,> 2008 aspen
<7E0,82,27,5,0,0,0,0,0,>
<7E8,84,67,5,C7,44,0,0,0,>
<7E0,84,27,6,F5,2A,0,0,0,>
<7E8,83,67,6,34,44,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>
<7E0,810,8,34,80,0,0,0,0,>


TX: 27 01 28 <- Request EEPROM access
RX: 67 01 F8 2C 8C <- Seed=0xF82C
TX: 27 02 B6 98 77 <- Key=0xB698
RX: 67 02 69 <- Key accepted


TX: 27 05 CS <- Request Flash access
RX: 67 05 41 55 CS <- Seed=0x4155
TX: 27 06 59 29 CS <- Key=0x5929
RX: 67 06 CS <- Key accepted

[kur4o]

I think mdi communicates properly but have some other issue.

The pcm might need some special command to enter programming mode or something.

In all logs this line is present before any unlocking is attempted

0005100400080B610031

What it does is and who send it is a little mystery so far.

Maybe some command to stop normal communication

00 05 10 if we follow standard header send from $10 target $05

00 40 mode 00 submode 40

Or this could be some IFR that can`t be properly monitored with elm.
Too bad Mdi have hardcoded filtering of monitoring using node_ID, and can`t monitor all traffic.

Maybe we will have more luck with ford VCI.
In-tech if you have time you can try to hook it and connect just like mdi. Only difference will be to select ford-VCI as j2534 device from the dropdown box.

[In-Tech]

Thanks kur4o,
I will try to study the logs a bit closer. I have never even plugged in my Ford VCM so that might take a bit to get familiar. I hope I am not interrupting Tazzi's thread too much. It would be very cool to get this communication error figured out. My biggest hope for interrupting is to help Tazzi any way I can. He has always been so helpful as well as many on this site

[Tazzi]

Can anyone try putting these seeds into your Ford algorithm just to see if FCA copied Ford !!

FCA algorithms are different to Ford.

[Tazzi]

I think mdi communicates properly but have some other issue.

The pcm might need some special command to enter programming mode or something.

In all logs this line is present before any unlocking is attempted

0005100400080B610031

What it does is and who send it is a little mystery so far.

I think the ECU actually spits that out? When I was tinkering with Ford IDS, it would send the 31 request immediately after receiving that frame.
That Frame is sent out after turning ignition on with FEPs enabled.

I am going to try send the 31 mode frame and then the seed request, and see if this changes my seed to a three byte (Which I doubt). I believe my EECV is the really really old variant which uses the old legacy EECV algo which I posted before.

I am just finishing off some final J2534 API commands for the GT and FT, but will be back onto making a quick little app to test out unlocking and making other requests shortly.

[In-Tech]

rtf have the benefit of color encoding send/recieve data, so you don`t need to guess.Thank you, understand and will correct my font size to correspond

I think you made major discovery why tazzi test pcm always send 2 byte seed starting with zero.Thank You, I agree. I love testing with you guys

Pcm needs to see mode 31 A0 requested before seed request. YES

Since we got it working now I made little test script, to confirm some stuff.

The goal is to make pcm enter high speed so tazzi can test the harware. If we can`t make pcm goes to high speed, we can use mdi set it to high speed and made a loop to send some data each 0.5 seconds. So some scope can be hooked and testing can be done.

To use the script

COnnect with mdi, click "upload script" button and select the script text file that is attached.

I noticed that you add the crc byte when you send messages, taken from the elm log. There is no need and it may bog the message.

So you just send only

64 10 F1 31 A0 00 D8 01 00
or
64 10 F1 27 01

OK, will test stuff, probably not till tomorrow

See replies in red

[In-Tech]

64 10 F1 31 A0 00 D8 01 00 BC
C4 F1 10 7F 31 A0 00 D8 00 91
64 10 F1 27 01 48
C4 F1 10 67 01 78 79 0B F4
64 10 F1 27 02 87 41 BC
C4 F1 10 67 02 34 A3
C4 10 F1 35 01 04 00 00 20 00 92 request 1024 bytes(0400h) starting at address 002000
C4 F1 10 7F 35 01 04 00 00 0D
C4 F1 10 36 FF FA 27 FE FF FF 33 6 bytes of read at address 002000
C4 F1 10 36 FF FF FF FF FF FF 7B Continues next 6 bytes read
C4 F1 10 36 FF FF FF FF 60 20 E6
C4 F1 10 36 63 20 66 20 69 20 4A
C4 F1 10 36 6C 20 6F 20 72 20 B4
C4 F1 10 36 75 20 78 20 7D 20 9E
C4 F1 10 36 82 20 87 20 8C 20 95
C4 F1 10 36 91 20 96 20 9B 20 BE


It does seem to be the 31 A0 is required with this Ford stuff, before it will allow a proper seed/key. otherwise just nonsense. I dunno, just watching

[kur4o]

In-tech can you measure if feps is enabled before reading the pcm and for how long it is on.

Look for relation between feps and this line in log
0005100400080B610031
You will need elm to monitor for it.

That might be the case why unlock fails.

[In-Tech]

Hiya Guys,
Unfortunately, I will not be able to test this quickly. I am on my way to Vegas for the Mint400 off-road race. I should be back Sunday night, late. I will report back as soon as I can get my work station set up to reply with better answers. I've always wanted to know how long FEPS needs to be active so it will be a good test. Sorry I can't comply quickly.

[antus]

Do check and compare timings. the UDS spec does say timing can be required and set by the vendor as part of the security process. I took that to mean a failure lockout, but it could be relevant to sending the key, too.