FDRS Upcoming Updates Information

[BHunted1]

Interesting! If 2.4.1 is a GWM update, that might be what @BHunted1 is trying to install. Sounds like it just showed up for him in FDRS.

Yup, but it failed via usb drive. I cannot figure how to get it to generate a new flash drive from fdrs. Any thoughts?

Sponsored

 

[Jesse-Infotainment]

Not sure. I5t should allow downloads until it has checks the files and seen it was successful

 

[JEB]

Yup, but it failed via usb drive. I cannot figure how to get it to generate a new flash drive from fdrs. Any thoughts?

Nothing comes to mind. I don’t have an active FDRS license or I’d take a look. Stupid as it sounds, maybe log out, unplug and walk away for a bit. Take another run from scratch in a little while, Your license should be good until midnight.

 

[MikeYQM]

I had a GWM update pop up yesterday in FDRS after clearing out all updates on the day before. I do not believe it required a USB though.

 

[MikeYQM]

G2132533 I believe

 

[TJSparky]

mine showed the same after the mini APIM update.

Mine shows the same as well.

 

[TJSparky]

So I had 2 updates in FDRS one was a GWM and a APIM both were small in size… here are the latest version I have with everything updated.

 

[iceman77]

Sorry for the confusion. Yes..
Just checked something in fdrs. (Today is last day. Want to make sure everything is right before it expires). Is what is circled right? Shouldn't it be sim to others with full p/ns?

There seems to be a bug in FDRS software when J2534 pass-through protocol is used, where the tool mangles up certain "F" fields in your module configuration report during network scan. Specifically the F10A (ECU CONFIGURATION) and F188 (STRATEGY) field values are affected. These fields are reported to the mothership and your As-Built dataset is updated accordingly. I did not find any issues with F10A field value being mangled up but F188 field (which reports the module strategy revision) is known to cause issues. For instance, if this affects the GWM, you will loose OTA as well as SecuriAlert. I have a thread about it here.

This bug is the reason why after various networks scans, different module SW updates pop up, either though you updated those modules before. And then when you try to update the module again, it does nothing, it just "flies trough it". And example would be user's @JEB report that an APIM update popped up for him shortly after he updated his APIM, but when he ran it, it went through fast, without asking for USB. I personally think, this was just a glitch in his FDRS network scan, where his Strategy info got mangled up, so the tool thought it needs update. However when he triggered it, it just skipped the entire update after module validation reported correct SW version. You can notice this when you trigger module update and the tool just quickly jumps from "Checking for software updates" to "The module will now be configured" message. All it does, it reloads your As-Built data in your module at this point but nothing is updated.

The fix to this issue is rather easy: Just re-run your network scan in FDRS and you will be fine. If you don't have access to FDRS anymore, your truck will report all NODE fields to mothership by itself. I am yet to find out what triggers this auto update (if its an autoupdate) or just a routine (scheduled) report.

 

[BHunted1]

There seems to be a bug in FDRS software when J2534 pass-through protocol is used, where the tool mangles up certain "F" fields in your module configuration report during network scan. Specifically the F10A (ECU CONFIGURATION) and F188 (STRATEGY) field values are affected. These fields are reported to the mothership and your As-Built dataset is updated accordingly. I did not find any issues with F10A field value being mangled up but F188 field (which reports the module strategy revision) is known to cause issues. For instance, if this affects the GWM, you will loose OTA as well as SecuriAlert. I have a thread about it here.

This bug is the reason why after various networks scans, different module SW updates pop up, either though you updated those modules before. And then when you try to update the module again, it does nothing, it just "flies trough it". And example would be user's @JEB report that an APIM update popped up for him shortly after he updated his APIM, but when he ran it, it went through fast, without asking for USB. I personally think, this was just a glitch in his FDRS network scan, where his Strategy info got mangled up, so the tool thought it needs update. However when he triggered it, it just skipped the entire update after module validation reported correct SW version. You can notice this when you trigger module update and the tool just quickly jumps from "Checking for software updates" to "The module will now be configured" message. All it does, it reloads your As-Built data in your module at this point but nothing is updated.

The fix to this issue is rather easy: Just re-run your network scan in FDRS and you will be fine. If you don't have access to FDRS anymore, your truck will report all NODE fields to mothership by itself. I am yet to find out what triggers this auto update (if its an autoupdate) or just a routine (scheduled) report.

Funny you mention this. Secure Alert on FP and Scheduling on the app and web have disappeared. But truck seemed ok. This whole thing is nutz!

 

[iceman77]

Open FDRS and run another network scan. Once done, make sure your GWM module is showing a valid Software P/N (the field should not contain any spaces or special characters). Should be ML3T-14H021-XXX. See example below:

This usually fixes the SecuriAlert and Horn&Ligths issue. If not, you might need to restart FDRS and run another network scan. Repeat this until GWM Software P/N is shown in proper format

 

[JEB]

There seems to be a bug in FDRS software when J2534 pass-through protocol is used, where the tool mangles up certain "F" fields in your module configuration report during network scan. Specifically the F10A (ECU CONFIGURATION) and F188 (STRATEGY) field values are affected. These fields are reported to the mothership and your As-Built dataset is updated accordingly. I did not find any issues with F10A field value being mangled up but F188 field (which reports the module strategy revision) is known to cause issues. For instance, if this affects the GWM, you will loose OTA as well as SecuriAlert. I have a thread about it here.

This bug is the reason why after various networks scans, different module SW updates pop up, either though you updated those modules before. And then when you try to update the module again, it does nothing, it just "flies trough it". And example would be user's @JEB report that an APIM update popped up for him shortly after he updated his APIM, but when he ran it, it went through fast, without asking for USB. I personally think, this was just a glitch in his FDRS network scan, where his Strategy info got mangled up, so the tool thought it needs update. However when he triggered it, it just skipped the entire update after module validation reported correct SW version. You can notice this when you trigger module update and the tool just quickly jumps from "Checking for software updates" to "The module will now be configured" message. All it does, it reloads your As-Built data in your module at this point but nothing is updated.

The fix to this issue is rather easy: Just re-run your network scan in FDRS and you will be fine. If you don't have access to FDRS anymore, your truck will report all NODE fields to mothership by itself. I am yet to find out what triggers this auto update (if its an autoupdate) or just a routine (scheduled) report.

Interesting. But now I’m puzzled. If my APIM strategy was somehow corrupted, which resulted in FDRS offering me another essentially false update opportunity a couple of days later, how did the APIM manage to pass the post-install validation procedure immediately after the first update? Wouldn’t the server have to have an uploaded record of what was installed?

 

[iceman77]

Interesting. But now I’m puzzled. If my APIM strategy was somehow corrupted, which resulted in FDRS offering me another essentially false update opportunity a couple of days later, how did the APIM manage to pass the post-install validation procedure immediately after the first update? Wouldn’t the server have to have an uploaded record of what was installed?

You APIM Strategy never got corrupted. Its the network scan result that gets corrupted when J2534 pass-through device is used. Apparently this is not an issue when VCM3 device is used. Here’s what I think happened in your APIM case: You ran network scan. The scan result comes back messed up for APIM. RFDS cannot match your APIM strategy revision (from network scan) against the online database, so it determines it is not up to date and offers update. You launch update, the APIM sw revision is validated again, this time directly, (not via networks scan), now it sees the module is up to date, it skips programming and jumps to configuring module (aka As-Built data reload). You can check the FDRS logs located in ProgramData directory. It is pretty detailed about what it does to your modules

 

[BHunted1]

Going to try again today to rescan. Still no Secure Alert and stuff missing in FP. Hope this works. Just got another 2 day subs.

 

[JEB]

You APIM Strategy never got corrupted. Its the network scan result that gets corrupted when J2534 pass-through device is used. Apparently this is not an issue when VCM3 device is used. Here’s what I think happened in your APIM case: You ran network scan. The scan result comes back messed up for APIM. RFDS cannot match your APIM strategy revision (from network scan) against the online database, so it determines it is not up to date and offers update. You launch update, the APIM sw revision is validated again, this time directly, (not via networks scan), now it sees the module is up to date, it skips programming and jumps to configuring module (aka As-Built data reload). You can check the FDRS logs located in ProgramData directory. It is pretty detailed about what it does to your modules

Ok. I think I’m following. Does that explain why GSM and ABS update prompts never seem to clear despite multiple update attempts? The network scans are consistently corrupted for these modules, prompting the update offers, but then when the update is attempted, the s/w version is validated directly, found to be current, and then terminated with an as-built reload?

 

[iceman77]

Ok. I think I’m following. Does that explain why GSM and ABS update prompts never seem to clear despite multiple update attempts? The network scans are consistently corrupted for these modules, prompting the update offers, but then when the update is attempted, the s/w version is validated directly, found to be current, and then terminated with an as-built reload?

I am not sure about ABS and GSM. Even though the FDRS networks scan corrupts the node information in your as-built, the truck runs its own version of network scan and reports it to the mothership periodically. This type of scan fixes all the glitches FDRS creates. Why ABS and GSM module keeps popping up is a mystery to me

Sponsored