Mine were exactly as the spreadsheet showed.

 

Mine were as well...

So I reverted to default in three settings...I mis-spoke, and forgot about the fogs with high beams.

In this order:

1) Double Horn Honk (BdyCM)
2) Seats and Wheel on home screen (APIM)
3) Fogs with Highs - LED (BdyCM)

I did them one at a time, with several starts between to see results. From my unofficial...relatively unscientific standpoint (could have used three more control groups) I believe the Fogs with High Beams to be the culprit. Theres a lighting cycle that takes place when you start the truck in the dark, and i hear relays firing...and for whatever reason, the relays had one less click with the Fogs setting enabled, when removed...everything worked 12 times straight. Must have to do with a lighting launch sequence.

All I have changed now is TPMS...I'll leave that alone for a while and see what goes on. Also, my center screen has frozen a couple of times this week...and required a reboot (power and advance buttons). Hopefully that is gone now too.

 

Unscientific works a lot of time. I think everyone who's had strange behavior (truck wise, lol) to have done the "Bambi" hex-code modification, me included.

 

I've done it and no issues. If it's the cause, it must be limited to certain truck configurations.

 

For me, I only did two things in ForScan:

1. Remove double horn honk
2. Attempt to activate DPF screen (which failed)

The issues all surfaced afterwards. I drove the truck again late last night - no issues Drove to work this morning - no issues.

So for now, I'm leaving the double horn honk cancelled and will continue to drive and monitor. The issues that popped up were pretty disconcerting. I was not happy I couldn't open the moonroof when I wanted to on a 6-month old truck and even less happy when it wouldn't let me in yesterday morning. The traction control basically didn't bother me, nor did the ambient lighting. But not being able to unlock or lock the truck, and having it lose connection while driving is pretty bad.

I did NOT do the bambi mode.

As someone who's career is working as an IT technician and now IT manager, these results are puzzling. Changing the code digit from a zero to one or vice versa should provide expected results. I wonder if the "Checksum error" is at fault. Somewhere else in the system is expecting a particular checksum but the new values don't agree. ForScan seems to override, but perhaps the result is the unexpected behavior?

 

I think if that was the case Tyler, we'd see more of this. There are tons of guys here who have done this and far more on the F150 forums where this all started without reported issues like yours. Not saying you're wrong as there certainly is a first time for everything. But, I'd be inclined to think otherwise.

 

The checksum error is displayed because the values that we are changing don't include the new correct checksum value. FORScan recalculates and enters that value for us and we only know what it is after the save and then return to see what it is. If we knew how to calculate it, we could enter it at the same time when we are saving the new 1 or 0 and we wouldn't get the error message. It would be much less concerting if it said something like, "Checksum value was XXX and will now be XXX. OK?" The checksum message is a red herring.

For what it's worth, I did the following changes and have yet to notice any incorrect behavior:

Remove double honk
New TPMS thresholds
Fog lights with high beams
Heated and cooled seat icons
Secure idle

Pretty sure your weird behavior is going to return because it's probably mechanical. If it's FORScan, and that's a big if, it's only because you changed something you didn't intend to and a reset to As Built settings would remedy that. You still have that option to try if the problems reappear.

 

I'll wait on TR's report then, and if he goes back "in" what happens.

darn! the unscientific method failed us!

 

Rodney, Epic...what you are saying makes sense. I generally don't buy into the "loose wire" theory since in my experience true electrical problems with wires and grounds don't occur until the vehicle is older and with more miles. I know there was allegedly one example listed here of a wiring problem, but dealer techs also make stuff up.

Anyone, thanks everyone for the insight. I will continue to post any new weird behavior I notice, and if things continue to be alright.

 

Hey troverman you need me to come over and put my computer/forscan voodoo skills to work for you...... lollolol.

 

Dunno, makes sense to me. I'm betting the routines for all the options are stored on the flash on the vehicle in ROM, and the values we're writing are pointers to memory addresses for various functions (Similar to how a CMOS/BIOS works). If you put a value in that leads to a valid routine without a prerequisite routine running first, the "scoreboard" on the processor will get lost, and has no way of knowing that it's lost, so it's just going to do whatever's in memory at that address. So if it needs to load that memory first then read and run it, you might have unintentionally run arbitrary things on the BCM BIOS on the first pass, but by the second pass, the data was pre-loaded, making it work correctly. That's entirely speculation on my part, but I've seen mine behave oddly, and in a manner consistent with a BIOS losing state... such as BCM commands working yet being unable to query state (or crashing the BCM when querying state). It also explains why restoring the data from backup so reliably fixes mine.

Not saying that's what's happening, just a possible condition. It kinda seems like the BCM acts like a bit of a daughterboard for a master controller, and is consistently re-initialized. That's how I'd design such a system anyways: if you screwed up and memory got mangled, it'd readily clear itself and work properly and average joe would perceive it as computer quirks.

The way you reset the auto windows when they get confused lines up with this way of thinking, too.

 

Final note: check this https://www.fleet.ford.com/truckbbas/non-html/Q-264.pdf

Bit me, and before that was published. I sorted it out on my own, though.

 

I don't have much experience with Ford vehicle computer systems, but I do have a fair amount with lovely British Land Rovers. In those vehicles, the BCM was the master and it used a CAN bus network to communicate with various other ECUs for sub-systems like the power windows / door locks / mirrors / memory system / HVAC, etc. It would make sense the BdyCM is the master on the Fords? Anyway, the values I was changing looked similar to the Registry on a Windows computer which is just a switch. That's why I don't understand why I was seeing the other seemingly unrelated glitches, unless the sunroof, traction control, smart key, and ambient lighting are all stored in the BdyCM module.

 

I just had another thought. On my 2011 the OBDII adapter would cause some glitchy truck behavior just by itself. I can't remember the details exactly but when that particular adapter was installed I would have weirdish things happen like what you describe. I read once somewhere that even the OBDII readers (if they are monitoring a ton of PIDs) can create enough demand on the bus that it can conflict with truck communication traffic. It isn't a stretch to think that a bad or adapter could cause problems all by itself. I eventually replaced that adapter with another one for a different reason and didn't see those glitches again. One more option in addition to the suggestions just given is to simply yank the adapter right after the next glitch and see if the erratic behavior goes away?

 

I _believe_ they are stored on the BdyCM module. That's interesting, though, my experience is with GM, Ford, and Toyota, and I don't think any of them have used sub systems like that. I know Ford does for the radio and climate control, but the BdyCM still is the master even for HVAC, afaik. I'm going to see if I can't sniff the various CANs and get a better idea of the layout maybe this weekend.
The registry analogy isn't wrong, but the usage is quite different. (The following is speculation by me) There doesn't appear to be an operating system involved, the BdyCM code is running directly on the hardware, and the registry is stored in ROM-like CMOS, which the whole system trusts inherently because only the IDS tool is supposed to set those values, and can set them knowing the impacts. So, where Windows will be like "Hey I need to know what is in this value, so I can use it to set parameters for this other piece of software" on the BdyCM, there's no "other piece of software" so it says "I am reading these values from these locations so that I know what to do next." It will then do whatever it's told to, based on the values in the current register, and the result of the calculation of the value from the CMOS-like registry and the known locations of next routines to run. ("0x00 is in registry, we are at 0x00FB, we know that we are going to the next instruction, so set next register to 0x00FC" vs "0x01 is in registry, we are at 0x00FB, we need to advance to the next instruction and add the value from registry, so set next register to 0x00FD")
So if it loads a bad value from its "registry" at some point, all instructions after that point will behave erratically (running whatever is in RAM at that address (or L2, or processor cache.... dunno the architecture)). This continues until some condition says "Set next register to <known address>" where <known address> is known and valid.

Essentially, Windows gets a few chances to look at the value and say "That ain't right." The truck has no such luxuries, it accepts whatever values are given to it, and instead handles bad values by resetting state after the fact. Bad values should be rare, IDS should never give them, so they'd only happen as a result of hardware degradation, bad external commands, or noise in the system.