ECU module programming guide using FDRS

[Bob_Mac]

Whoa! That is a new one! Does anyone have any additional info on what 22028 Rev 358 is? I thought 21281 rev 244 (OTA 2.3) was the latest.

No, the latest is 22028 Rev 358 which is what mine updated to this morning.

Sponsored

 

[iceman77]

No, the latest is 22028 Rev 358 which is what mine updated to this morning.

Any noticeable changes in Sync ? Did they fix the ACC SSR ? How is CarPlay screen look like ? I had a full list of bugs reported to them.

 

[abd79]

For the smarter guys in here, I was able to pull logs from the nano itself, wireshark works as well but includes all the USB overhead so I'm trying to filter it out and see if there is anything of use. I'm suspecting that the problem maybe timeouts/buffering in the nano that needs to be tweaked. could be wrong but its a start unless you already had this. May be useful in talks with AllScanner guys. I should also note this log is of a offline network scan

 

[Snakebitten]

No, the latest is 22028 Rev 358 which is what mine updated to this morning.

OTA or FDRS?

I hope this recent turn in the thread doesn't scare folks off too much. Just when there was amazing momentum to addressing trucks that were far behind in updates, suddenly it feels like the updating wasn't worth the risk.
Maybe I SHOULD be more worried but I can't find anything malfunctioning on my truck and I've done all the "scary" updates. Lol

And I haven't even figured out how to go check and see if my cloud is "corrupted".
I guess I need to go back and re-read the posts that I wasn't paying close enough attention to.

 

[iceman77]

OTA or FDRS?

I hope this recent turn in the thread doesn't scare folks off too much. Just when there was amazing momentum to addressing trucks that were far behind in updates, suddenly it feels like the updating wasn't worth the risk.
Maybe I SHOULD be more worried but I can't find anything malfunctioning on my truck and I've done all the "scary" updates. Lol

And I haven't even figured out how to go check and see if my cloud is "corrupted".
I guess I need to go back and re-read the posts that I wasn't paying close enough attention to.

I will check your AB data in cloud tomorrow morning and let you know!

 

[Snakebitten]

I will check your AB data in cloud tomorrow morning and let you know!

Well that's mighty nice of you kind sir.

So if it is, I thought it was established that in the long run it wasn't an issue since the truck itself would.... I think it was described "talk to the mother ship" and overwrite anything FDRS might have uploaded less than perfectly. Afterall, the truck is the final say.

By the way, I could buy another license for doing it myself, but I really appreciate you sparing the expense. I swear I should just purchase the annual subscription and be done with it. Lol

 

[abd79]

I will check your AB data in cloud tomorrow morning and let you know!

If you don't mind could you check this one as well?

 

[TJSparky]

Iceman- if you could check my cloud data too I’d appreciate it. PM sent

 

[Snakebitten]

Lol
Iceman deserves a cape

 

[TJSparky]

Lol
Iceman deserves a cape

“I’m Batman” Says the Iceman! LOL

 

[Darkjeep]

Is checking the AB data just looking at the motorcraft site?

 

[Darkjeep]

I have been comparing my first AB data to the most recent. That stuff is weird. I think when I tried to fix the lost radio tuner and out the original AB from July I was almost able to apply the 1.7.1 APIM usb from FDRS. It at least saw the data on the drive. Then I screwed up everything.

 

[antho]

For the smarter guys in here, I was able to pull logs from the nano itself, wireshark works as well but includes all the USB overhead so I'm trying to filter it out and see if there is anything of use. I'm suspecting that the problem maybe timeouts/buffering in the nano that needs to be tweaked. could be wrong but its a start unless you already had this. May be useful in talks with AllScanner guys. I should also note this log is of a offline network scan

Just flipping through. For example. This transfer contains 34 messages.

[19:48:29.115] PassThruReadMsgs.
[19:48:29.115] ulChannelID = 1
[19:48:29.115] pstructJ2534Msg = 0x43e6c7a8
[19:48:29.115] *pulNumMsgs = 100
[19:48:29.115] ulTimeout = 50
[19:48:29.115] ulTimeoutReal = 50
[19:48:29.176] RX Msg Timeout. rxMsgs = 34
[19:48:29.177] *pulNumMsgs = 34
[19:48:29.177] Msg Num = 34

Message 0 looks good.
[19:48:29.177] Msg #0 :
[19:48:29.177] Msg->ulProtocolID: 0x00000006
[19:48:29.177] Msg->ulRxStatus: 0x00000009
[19:48:29.177] RXSTATUS_TX_MSG_TYPE
[19:48:29.177] RXSTATUS_TX_INDICATION
[19:48:29.177] Msg->ulTxFlags: 0x00000040
[19:48:29.177] TXFLAG_ISO15765_FRAME_PAD
[19:48:29.177] Msg->ulTimeStamp: 2965564453
[19:48:29.177] Msg->ulDataSize: 4
[19:48:29.177] Msg->ulExtraDataIndex: 0
[19:48:29.178] Msg->ucData: 00 00 07 26

Message 5 looks bad See the highlighted in red. This is what im thinking is corrupting the Hex.
When i remove the Hex in red, The remaining Hex converts to ML3A-7H417-GE
[19:48:29.182] Msg #5 :
[19:48:29.182] Msg->ulProtocolID: 0x00000006
[19:48:29.182] Msg->ulRxStatus: 0x00000000
[19:48:29.182] Msg->ulTxFlags: 0x00000000
[19:48:29.182] Msg->ulTimeStamp: 2965615346
[19:48:29.182] Msg->ulDataSize: 31
[19:48:29.182] Msg->ulExtraDataIndex: 31
[19:48:29.182] Msg->ucData: 00 00 07 69 62 f1 13 4d 4c 33 41 2d 37 48 34 31 37 2d 47 45 00 00 00 00 00 00 00 00 00 00 00

00 00 07 69 62 f1 13 = ???
4d 4c 33 41 2d 37 48 34 31 37 2d 47 45 00 00 00 00 00 00 00 00 00 00 00 = ML3A-7H417-GE

 

[antho]

Msg->ucData:
00 00 06 f8 62 f1 13 4d 4c 33 54 2d 31 34 44 30 36 38 2d 45 48 00 00 00 00 00 00 00 00 00 00

Removing the above in red makes the HEX = as shown below. Not sure what these extra values are.
4d 4c 33 54 2d 31 34 44 30 36 38 2d 45 48 00 00 00 00 00 00 00 00 00 00 = ML3T-14D068-EH

 

[abd79]

I’ve fired off support messages to both the hardware and software vendors. I’ll see what they come back with if anything and PM you.

Sponsored