I don't have a Mega 2560 but it sounds like you will have to burn the chip with a bootloader using the ICSP interface.Watchdog is enabled!Your bootloader cannot get access before the watchdog times out.

The way you have it in your schematic isn't the same as how you have it wired up!

Mega 2560 connected to Vista.Basic Blink sketch uploaded with 250 millisecond watchdog code added.Pin 13 LED now flashes rapidly.Sketches will not upload.Releasing reset while trying to upload doesn't work. LED flashes fast as soon as reset button is released.AVRdude responds with timeouts.It will go into DFU mode and USB driver installs but Flip or AVRDude cannot open/find USB device.Disable "AUTO RESET" did nothing.

What do I need to do to get this Mega working again?

I've done the same thing when testing if my mega1280 bootloader could handle short WDT timeout values. The test worked fine on all my 328P based boards using the Uno bootloader but 'bricked' my mega board with the same symptoms that you are seeing, fast switching of pin 13 LED.

The problem is that the bootloader in your mega does not disable WDT interrupts when it first starts up, so it gets locked up in a constant reset/start bootloader/reset loop condition. The only solution is to reburn a bootloader on your mega board using a hardware ICSP (which can be another arduino board running the arduinoISP sketch). Reburning the bootloader will restore it to operation but will not solve the ability of handling WDT short duration interrupts unless you locate a mega bootloader HEX file that has been patched to solve that problem, the default mega bootloader in even the current arduino IDE still does not fix this flaw.

This problem has nothing to do with the USB serial converter chip and you should not mess with it's firmware to try and fix this problem, unless you messed it up in attempting to fix what is a mega1280/2560 bootloader bug.

I've had this problem a number of times. With some luck it is possible to recover by holding the reset switch until the upload starts and then releasing it. This will take several tries to get right. However, the most reliable way is to replace the bootloader. I fought this problem for a solid year before I talked someone into fixing it and providing a bootloader that works.

Take a look at my blog page on the final resolution to this problem at: http://www.desert-home.com/2012/05/arduino-mega2560-wrapping-up-bootloader.html

Funny, the folks at Arduino said they would make this part of the distribution quite some time ago.

I've had this problem a number of times. With some luck it is possible to recover by holding the reset switch until the upload starts and then releasing it. This will take several tries to get right. However, the most reliable way is to replace the bootloader. I fought this problem for a solid year before I talked someone into fixing it and providing a bootloader that works.

Take a look at my blog page on the final resolution to this problem at: http://www.desert-home.com/2012/05/arduino-mega2560-wrapping-up-bootloader.html

Funny, the folks at Arduino said they would make this part of the distribution quite some time ago.

I followed your frustration working with the arduino developers and it's still amazing that the current arduino IDE distribution has not updated the mega bootloaders even after all this time.

Also do you know of an updated mega bootloader available for the mega1280 board, that fixes the same two problems?

No I don't. I have noticed that there a few people that have hit the same problem on the 1280, but no solutions have shown up.

Well the source code for the bootloader C file does have support for the mega1280 bootloader ( https://github.com/arduino/Arduino/tree/master/hardware/arduino/bootloaders/stk500v2 ) but it's just a matter of someone knowing how to compile a bootloader to a hex file to create the needed HEX file for the mega1280 board. Sigh!