I've had two critical updates since the Viking chip was born that required the use of the 'allow configuration word programming' button.
1) Irish actually bricked his controller. Here's how it happened. I was putting out .hex files with incorrect configuration bits (these are critical operational parameters stored in the Microchip). When you click 'allow configuration word programming' you're actually unlocking those bits. Then the next .hex file you flash will overwrite any bits (if the bits are defined in that .hex file). Well in any case, Irish was having problems one day so he decided to try clicking that "allow configuration word programming" box. He also happened to have one of my .hex files that had the wrong bits. So his mod chip got flashed with the wrong bits (the particular settings screwed up his USB clock so he could NO LONGER flash the mod chip lol). So needless to say I immediately fixed all of my hardware and instructed users to NOT press the allow configuration word programming box unless they had a .hex file that was a certain date or newer (all those .hex files have been removed from the Viking website a long long time ago)
2.) CG2 controller came out. I wrote in a 'sleep timer' into a lot of the drivers, whereby the mod chip counts up to about 11 minutes and puts itself to sleep if the user doesn't push any buttons. That way when your controller auto shuts off from being idle at about 12 minutes, the mod chip doesn't keep the LED's lit. In order for this new code to work, you have to have applied the right configuration bits (and if you've checked the allowed configuration button at least once while loading a driver dated 10/21/2009 or newer, then your controller now has those bits).
You'll notice on some very old drivers like the COD5 Nazi Zombie mode, once you flash your controller, you can't get it back into programming mode without holding down the Sync buttno BEFORE you even put the batteries in. This is because while your controller probably has the newest configuration bits in it, but the COD5 zombie code is older than 10/21/2010 and never got the right sleep timer code. So it doesn't work properly. Basically it's the wrong software for the wrong firmware.
I'd love to re-write this because I just confused mywelf but I hope you get the main picture. There's the .hex files that have the rapidfire code, then there's these configuration bits stored in the microchip. They all have to work hand in hand. The only way to update those config bits is to check the box. For awhile around October->January, people were having all sorts of random problems but it was because their controllers didn't have the updated config bits yet, but they were trying to run newer .hex that required the microchip to have the newer config bits.
