Here is the current problem as I see it. If you can offer suggestions then please do so, however Flash Magic has to remain a general purpose non-specific ISP tool.
In order to disable the watchdog, on entry into ISP mode UCFG1 needs to be read and then reprogrammed with WDSE and WDTE set to zero.
Because UCFG1 only takes effect on a reset, another reset needs to occur.
Users expect after performing any ISP operations to have UCFG1 restored on the next reset, so the procedure is transparent to the user.
So, the sequence is:
1. Enter ISP mode either with Start BootROM command, break condition or pulse entry.
2. Read UCFG1
If WDTE and/or WDSE set then:
3. Program UCFG1 disabling watchdog
4. Program status bit to 1 and reset command (note that some of the ISP entry methods do not set the status bit to 1, so we have to do it)
5. Program UCFG1 back to original value
Problems with this:
Programming UCFG1 takes around 4ms. Programming the status bit takes another 4ms. So this won't work if the watchdog times out in anything less than 8ms + time to receive and process reset command. However, the watchdog may be configured to time out in as little as 5.5us. A lot of applications need a watchdog with a timeout shorter than 8ms.
After sending the Start BootROM command, Flash Magic does not know precisely when the device resets. An application may save some data to non-volatile RAM before resetting, for example. Therefore Flash Magic waits for a fixed length of time before trying to autobaud with the device. Currently that delay is 8 seconds. The maximum watchdog timeout is around 2.62 seconds. Therefore unless the device takes 6 seconds or longer to reset AND uses the longest possible timeout for the watchdog, the watchdog will reset the device before Flash Magic starts autobauding.
What happens if there is a reset glitch or glitch on the power supply or Windows crashes between steps 3 and 5? The result is that when attempt is made with Flash Magic to try again, it will think that the watchdog was never turned on and will not turn it back on again for the user.
Flash Magic uses the Windows API to control the COM port. There are no guarantees that the command to read, program and reset will take place in any specific time period. If Windows is heavily loaded, running a realtime thread, crashed, etc. then that process may not be completed in x ms, where x is anyone's guess. The longer the watchdog timeout period, the greater the chance of success. Not being able to make definate claims about what is and isn't possible will lead to greater confusion for users.